Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit
GELÖST

ARP-Problem zwischen LANCOM VP-100 - Raspberry

Frage Netzwerke Netzwerkprotokolle

Mitglied: NetBoi

NetBoi (Level 1) - Jetzt verbinden

01.03.2014, aktualisiert 21:45 Uhr, 2435 Aufrufe, 24 Kommentare

Ich habe hier einen Windows-PC, ein IP-Telefon (Lancom VP-100) und einen Raspbian-Raspi in einem LAN.

Vom PC aus kann ich alle Geräte anpingen. Vom Raspi und dem Telefon den PC. ABER: Pings zwischen Raspi und Telefon gehen nicht.

Ich habe Telefon und Raspi jetzt mal direkt verbunden. Folgendes passiert:
- "arp" auf dem Raspi listet die MAC des Telefons
- "arp-scan" listet sie nicht
- ein "arp-scan" auf die telefon-MAC bringt 0 Responses.

Wireshark zeigt, dass das Telefon (bei Neustart) via ARP ständig in die Runde fragt, wem die IP des Raspis gehört. Der Raspi antwortet auch immer brav mit seiner MAC, aber irgendwie scheint das Telefon das komplett zu ignorieren (und fragt halt weiter und weiter...).
Was kann das sein?



Mitglied: MrNetman
01.03.2014 um 10:01 Uhr
Und wo liegt jetzt dein Problem?
Geht dein Telefon nicht? Oder hat es gar aussetzer wegen der Anfragen?

Gruß
Netman
Bitte warten ..
Mitglied: Dobby
01.03.2014 um 11:14 Uhr
Hallo,

kann es sein dass das Telefon die selbe IP hat bzw. bekommt wie der PI?
Warum sollte ein Telefon auf einen Ping hören bzw. antworten?

Gruß ♪
Dobby♬
Bitte warten ..
Mitglied: NetBoi
01.03.2014, aktualisiert um 11:43 Uhr
@MrNetman:
Das Telefon soll sich am Asterisk des PI anmelden, was dummerweise eine Netzwerkverbindung vorraussetzt
An der Fritzbox im Netz funktioniert es normal.

@Dobby:
Telefon und PI haben feste IPs bekommen (zumal für den Test, bei dem sie direkt verbunden sind).
Beide Geräte sind (im LAN) von jeden anderen Rechner auch normal anpingbar. Nur eben untereinander bekommen sie keine Verbindung.


Wenn der PI einen ARP-Scan macht, dann antwortet das Telefon schlicht nicht. So wie andersherum auch. Hat sich bei dem ARP-Zeugs mal irgendas geändert, oder was ist da u.U. problematisch?
Bitte warten ..
Mitglied: aqui
LÖSUNG 01.03.2014, aktualisiert um 23:18 Uhr
Das Verhalten ist auf alle Fälle unnormal und könnte auch ein HW Defekt sein !
Ein Ping MUSS problemlos möglich sein sofern ICMP im Endgerät nicht geblockt wird usw. was beim RasPi und dem Telefon aber sicher nicht der Fall ist.
arp -a zeigt übrigens den ARP Cache an und nix mit scan usw.
Du solltest mal tcpdump auf dem RasPi installieren mit apt-get install tcpdump und genau checken ob der RasPi ein sauberen ARP macht.
tcpdump -i eth0 arp zeigt dann nur ARP Packete und dort kannst du checken ob das Verhalten korrekt ist.
Benutzt du ein customiztes Image für Asterisk ?
Falls ja solltest du ggf. mal eine 2te SD Karte investieren und ein nacktes Raspbian checken ob das auch dieses Verhalten zeigt.
Wenn nein, dann ist in deinem Image vermutlich irgendein Packet Filter aktiv (iptables).
Weitere Analyse Tips findest du auch hier.
Bitte warten ..
Mitglied: NetBoi
01.03.2014, aktualisiert um 16:47 Uhr
Danke für den Link.

Also der PI hat ein nagelneues Raspbian drauf, feste IP eingestellt und ein "apt-get install asterisk" ist alles was da gemacht wurde. Der funktioniert ja auch super. Wie gesagt, Pings im LAN (z.B. von PC auf Telefon und PI) sind ja auch kein Problem. Nur eben (ausgerechnet!) zwischen den beiden Geräten läuft nix.
"arp-scan" ist nur ein Tool, um mal Pakete rausschicken zu können, die ich dann im wireshark untersuchen kann.

Iptabels hat keine Einträge.

Was das "saubere ARP" angeht, so antwortet der auf alle Anfragen des Telefons. Das Telefon hingegen antwortet nie.

"tcpdump -i eth0 arp" ergibt unablässig folgendes (wie man sieht wieder im LAN):
15:34:28.969310 ARP, Request who-has raspberrypi.fritz.box tell LANCOM-VP-100.fritz.box, length 46
15:34:28.969416 ARP, Reply raspberrypi.fritz.box is-at b8:27:eb:60:1f:69 (oui Unknown), length 28

Gruß
NetBoi
Bitte warten ..
Mitglied: Pjordorf
01.03.2014 um 18:54 Uhr
Hallo,

Zitat von NetBoi:
Also der PI hat ein nagelneues Raspbian drauf, feste IP eingestellt
Konsolenmodus oder GUI? Direkt ohne Anpassungen für Sprache, Geolocation, Tastatur usw? Also ein wirklich "frisch aus der Kiste" was in Standort GB annimmt? Dann mach dies noch einmal bis hierhin und ohne feste IP und schau was dann passiert. Alles was du brauchst ist eben ein andere SD Karte wo du nicht schon irgendwie etwas geändert hast oder ein Asteriskt drauf ist. Auch wenn du nicht an der IP rumfummelst sollte dein PI sich per Ping eine Antwort einfangen oder auf ein Ping antworten, wo dein arp -a dann dir die MAC anzeigen kann.
Wie gesagt, nackt wie dein PI geboren wurde Zumindest kannst du dann HW Problem ausschließen.

Gruß,
Peter
(der sein PI auch zerlegt hatte )
Bitte warten ..
Mitglied: aqui
01.03.2014, aktualisiert um 20:18 Uhr
Also am RasPi liegts nicht... "Reply raspberrypi.fritz.box is-at b8:27:eb:60:1f:69 (oui Unknown)" zeigt ja das er antwortet !!
b8:27:eb:60:1f:69 ist einen Mac Adresse der Raspberry Pi Foundation.
Am besten du schaltest mal mit -n das Namen Aufläsen der dämlichen FritzBox ab damit die nicht immer alles mit ".fritz.box" auflöst intern. Mit apt-get install libnss-mdns kann der RasPi das auch selber
Zeigt der Raspi mit arp -a denn die Mac des Telefons an ?

Nebenbei: Ein lokaler Asterisk RasPi pingt ein SNOM 360 und ein Grandstream Telefon die über ihn arbeiten hier vollkommen fehlerfrei !
Bitte warten ..
Mitglied: NetBoi
01.03.2014, aktualisiert um 20:51 Uhr
@Pjordorf
Konsolenmodus, lokalisiert auf DE (ich kann mir nicht vorstellen, dass das was am ARP-Cache macht)
IP fest eingestellt, da sonst die Direktverbindung mit dem telefon schlecht möglich wäre (hat keinen DHCP eingebaut)
Keine sonstigen Änderungen.
Ich hab das ganze gestern Nacht auch direkt mit einem frisch aufgespielten Raspbian probiert. -Es ist exakt das selbe

@aqui
mit "-n" bekomme ich die korrekten IPs.
"arp -a" zeigt die Zuordnung korrekt. Der PI kennt die MAC des Telefons, aus dessen Anfragen, nehm ich an.
"ip neigh" bringt für die IP des Telefons:
192.168.2.144 dev eth0 lladdr 00:a0:57:12:fe:40 STALE

Die MAC stimmt dabei.
Ich muss mir wahrscheinlich das ARP-Paket des PI mal genauer ansehen (Gott behüte, ich hab keinen Plan davon!).
Das Telefon macht ja ansonsten keinen Stress im Netzwerk (wie der PI auch ;), aber ich bekomme langsam das Gefühl, dieses Lancom-Drecksding verkackeiert mich hier.

Gibt es denn bei den ARP-Implementierungen irgendwelche Absonderlichkeiten?
Was ist der Unterschied zwischen Win und Debian?

(Ich hab die phys. Verbindung übrigens auch schon div. Hubs, Switches laufen lassen ... aber immer das selbe. Am Telefon wurde auch schon ein Werksreset gemacht)
Bitte warten ..
Mitglied: NetBoi
01.03.2014, aktualisiert um 21:21 Uhr
Was ich noch sehr eigenartig finde:
Wenn per "arp-scan" eine Anfrage absetze, dann antwortet das Telefon, wenn ich (auf dem PI) eine fremde MAC als Absender-MAC einsetze!

Also (mit Fantasie-MAC):
01.
sudo arp-scan --srcaddr=00:13:d1:fc:99:12 --destaddr=00:a0:57:12:fe:40 192.168.2.144 
02.
Starting arp-scan 1.8.1 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/) 
03.
192.168.2.144   00:a0:57:12:fe:40       LANCOM Systems GmbH 
04.
 
05.
5 packets received by filter, 0 packets dropped by kernel 
06.
Ending arp-scan 1.8.1: 1 hosts scanned in 2.178 seconds (0.46 hosts/sec). 1 responded
->TCPDump dazu:
01.
20:03:32.312363 ARP, Request who-has LANCOM-VP-100.fritz.box tell raspberrypi.fritz.box, length 28 
02.
20:03:32.313101 ARP, Reply LANCOM-VP-100.fritz.box is-at 00:a0:57:12:fe:40 (oui Unknown), length 46
Wenn ich das gleiche mit der echten MAC des PI mache:
01.
sudo arp-scan --srcaddr=b8:27:eb:60:1f:69 --destaddr=00:a0:57:12:fe:40 192.168.2.144 
02.
Interface: eth0, datalink type: EN10MB (Ethernet) 
03.
Starting arp-scan 1.8.1 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/) 
04.
 
05.
3 packets received by filter, 0 packets dropped by kernel 
06.
Ending arp-scan 1.8.1: 1 hosts scanned in 2.549 seconds (0.39 hosts/sec). 0 responded
und im TCPDump gibt es auch nur die Anfrage und keine Antwort:
01.
20:03:09.992407 ARP, Request who-has LANCOM-VP-100.fritz.box tell raspberrypi.fritz.box, length 28 
02.
20:03:10.092568 ARP, Request who-has LANCOM-VP-100.fritz.box tell raspberrypi.fritz.box, length 28 
03.
20:03:11.961819 ARP, Request who-has raspberrypi.fritz.box tell LANCOM-VP-100.fritz.box, length 46 
04.
20:03:11.961962 ARP, Reply raspberrypi.fritz.box is-at b8:27:eb:60:1f:69 (oui Unknown), length 28 
05.
20:03:12.961859 ARP, Request who-has raspberrypi.fritz.box tell LANCOM-VP-100.fritz.box, length 46 
06.
20:03:12.961968 ARP, Reply raspberrypi.fritz.box is-at b8:27:eb:60:1f:69 (oui Unknown), length 28 
07.
20:03:13.961867 ARP, Request who-has raspberrypi.fritz.box tell LANCOM-VP-100.fritz.box, length 46 
08.
20:03:13.961986 ARP, Reply raspberrypi.fritz.box is-at b8:27:eb:60:1f:69 (oui Unknown), length 28
(Die Anfragen des LANCOM sind "die üblichen", die eh die ganze Zeit durchlaufen)
Ich hab das Gefühl, das LANCOm filtert (aus versehen) die MAC des PI.
Oder wie is das erklärbar?

Update: Hab grad rumprobiert: Source-MAC, die mit 00: beginnen scheinen zuverlässig zu funktionieren. Eigenartig.
Bitte warten ..
Mitglied: Dobby
01.03.2014, aktualisiert um 21:45 Uhr
Hallo nochmal,

installiere doch mal schnell den ColaSoft MAC Scanner und dann hast Du
Gewissheit was da alles so in Deinem Netzwerk und vor allem wie installiert ist.

Gruß
Dobby
Bitte warten ..
Mitglied: NetBoi
01.03.2014, aktualisiert um 21:45 Uhr
@Dobby:

Ich hatte die beiden Geräte (PI mit neuen Raspberian und VP-100 Werksreset) bei dem Wireshark-Test direkt verbunden.
Die Ausgaben des Arp-Cache und die TCPDumps sind ja auch eindeutig.


Lösung
Das LANCOM VP-100 ist buggy. Das ignoriert die Pakete von der PI-MAC.
Ich hab jetzt einfach die PI-MAC geändert. Nichts einfacher als das. Die /boot/cmdline.txt wurde einfach (sinngemäß) so ergänzt:

01.
smsc95xx.macaddr=00:12:34:56:78:90
Und siehe da - die LANCOM-Tussie hat plötzlich kein Problem mehr!
Dieses verfluchte Mistding hat mich Stunden gekostet. Verdammt!
Bitte warten ..
Mitglied: Pjordorf
01.03.2014 um 21:47 Uhr
Hallo,

Zitat von NetBoi:
Die MAC stimmt dabei.
Mach doch mal deine Ping test mit einen PC oder anders Linux wo du vorher die MAC des PI hinterlegt hast, ob dann dein telefon immer noch spinnt. Nicht das dein Telefon den oui Unknown abweist.

Was ist der Unterschied zwischen Win und Debian?
Dafür ist in diesem Forum kein Platz. Da reicht Franks Festplatte nicht aus

(Ich hab die phys. Verbindung übrigens auch schon div. Hubs, Switches laufen lassen ... aber immer das selbe
Trage die PI MAC mal an einen aderen Client ein und teste. Es sollte wenn dein Telefon die oui Uknown abweist, schon ein b8:27:eb:00:00:01 reichen.

Am Telefon
Firmware Update verfügbar?

Gruß,
Peter
Bitte warten ..
Mitglied: Pjordorf
01.03.2014 um 22:06 Uhr
Hallo,

Zitat von NetBoi:
Das LANCOM VP-100 ist buggy. Das ignoriert die Pakete von der PI-MAC.
Oder nur eine kleinen Teil davon? Siehe auch http://en.wikipedia.org/wiki/MAC_address#Address_details

Dieses verfluchte Mistding hat mich Stunden gekostet. Verdammt!
Etwas an den ersten 6 Byte der MAC (b8:27:eb) ist schuld.

Gruß,
Peter
Bitte warten ..
Mitglied: NetBoi
01.03.2014, aktualisiert um 23:39 Uhr
Trage die PI MAC mal an einen aderen Client ein und teste. Es sollte wenn dein Telefon die oui Uknown abweist, schon ein
b8:27:eb:00:00:01 reichen.
Hab die MAC jetzt mal am PI eingesetzt. Auch diese Adresse ist für das Lancom VP-100 tabu (und die steht auch als "oui Unknown" im tcpdump).

Welchen sinnvollen Hintergrund kann das Verhalten des LANCOM-Telefones haben?

Das VP-100 hat die letzte Firmwareversion (3.04.0012)
Bitte warten ..
Mitglied: Pjordorf
02.03.2014 um 00:55 Uhr
Hallo,

Zitat von NetBoi:
Welchen sinnvollen Hintergrund kann das Verhalten des LANCOM-Telefones haben?
Sicherheit bei eben "unbekannter hersteller"?!? da hier VOIP?!? Sicher sagen kann es dir aber nur Lancom warum es dort entweder implementiert ist oder ein Käfer ist. Is it a bug or a feature?

Nimm mal ein
BC:27:EB:00:00:01
80:27.EB:00:00:01
FC:27:EB:00:00:01
00:1E:68:00:00:01
00:1F:3C:00:00:01

Ich vermute bei 2 davon geht es.

Gruß,
Peter
Bitte warten ..
Mitglied: NetBoi
02.03.2014 um 01:04 Uhr
> Welchen sinnvollen Hintergrund kann das Verhalten des LANCOM-Telefones haben?
Sicherheit bei eben "unbekannter hersteller"?!? da hier VOIP?!? Sicher sagen kann es dir aber nur Lancom warum es dort
entweder implementiert ist oder ein Käfer ist. Is it a bug or a feature?
Also die MAC zur Authentifizierung zu nutzen wäre ja keine so gute Idee. Zumal ja offenbar jeder 30$-Rechner diese beliebig setzen kann.
Ich nehm an das ist schlicht ein Bug. Oder ein Auswuchs seltendämlicher Arroganz seitens Lancom.

Nimm mal ein
BC:27:EB:00:00:01
80:27.EB:00:00:01
FC:27:EB:00:00:01
00:1E:68:00:00:01
00:1F:3C:00:00:01

Ich vermute bei 2 davon geht es.
Das dauert. Wenn du mir genau erklärst, wohin diese Forschung führen könnte, dann probiere ich das aber gerne aus
Bitte warten ..
Mitglied: aqui
02.03.2014 um 12:49 Uhr
Das ist schon sehr verwunderlich das Lancom keine registrierten Mac OUI nutzt. Eigentlich ist das zwingender Standard bei einem Hersteller. Gibt man die Mac in die Datenbank http://standards.ieee.org/develop/regauth/oui/public.html ein ergibt das keinen Treffer.
Das lässt darauf schliessen das die OUI sprich Mac am Telefon mal verändert wurde.
Komisch auch das das Telefon nicht mit den Macs umgehen kann denn im Grunde ist es Wurscht ob die OUI bekannt ist oder nicht, denn an der Kommunikation ändert das nichts.
Es ist natürlich mögölich das lancom irgendeinen Mechanismus drin hat der eine Kommunikation nur mit Lancom Macs erzwingt. Das wäre dann allerdings mehr als frech....
Bitte warten ..
Mitglied: NetBoi
02.03.2014 um 22:33 Uhr
Also für die Adressen des LANCOM (00a057) und PI (b827eb) bekommt man schon Einträge da.
Wer weiss, was die Typen da verwurstelt haben.
Das LANCOM VP-100 akzeptiert ja auch andere MACs, die nicht von LANCOM stammen. Bislang hatte ich mit den Dingern auch nie (solche) Probleme.

Sehr seltsam.
Vielleicht verrät ja Pjordorf noch, welche Vermutung er hegt.
Bitte warten ..
Mitglied: MrNetman
03.03.2014 um 00:59 Uhr
Auf dem Draht passieren manchmal Dinge, die keiner voraus gesehen hat.

Das ist ein Fall für LANCOM und sollte von deren Service überprüft werden können. Danach gibt es ein firmware update, das den Käfer nicht mehr hat. Details gibt es ja jetzt.
Bitte warten ..
Mitglied: Pjordorf
03.03.2014, aktualisiert um 14:39 Uhr
Hi Aqui,

Zitat von aqui:
Das lässt darauf schliessen das die OUI sprich Mac am Telefon mal verändert wurde.
Könnte auch ein nachgebautes Gerät sein Daher habe ich auch nochmals etwas gesucht "MAC Vendor" und die ersten Treffer sind allerdings grün. Hmmm.? Wadenu?

Sagen das es LANCOM sei:
http://standards.ieee.org/develop/regauth/oui/oui.txt
http://www.wireshark.org/tools/oui-lookup.html
http://www.coffer.com/mac_find/?string=00-a0-57

Hmmm. Vermutlich sich genauso Datenbanken finden wo eben unbekannt heruaskommt. Coffer. com sagt sogar noch Lancom bzw. www.elsa,ag

Un hätte NetBoi sich mal die 5 (Fiktiven) MACs vergenommen, wüssten wir ob es tatsächlich an der MAC liegt und LANCOM dort einen Käfer gebaut hat.....un er somit auch eine Lösung von LANCOM bekommen könnte....

Gruß,
Peter
Bitte warten ..
Mitglied: NetBoi
03.03.2014, aktualisiert um 15:24 Uhr
Also ich hab dem PI ja jetzt einfach eine fiktive MAC gegeben und die Verbindung funktioniert nun anstandslos.

Ich hab ja auch ARP-Anfragen (an das Telefon) mit verschiedenen MACs gemacht - es antwortet halt nicht auf alle.
Für deine angegebenen Adressen gibt es folgende Resultate:
BC:27:EB:00:00:01 - keine Antwort
80:27:EB:00:00:01 - keine Antwort
FC:27:EB:00:00:01 - keine Antwort
00:1E:68:00:00:01 - Antwort
00:1F:3C:00:00:01 - Antwort


Ich hab heute auch mal eine Anfrage an LANCOM gestellt. (Die letzte Softwareversion ist bei denen leider nicht im Supportformular gelistet - auch ein "bug"). Mal sehen, was die dazu sagen.

LANCOM beschäftigt übrigens auch nur Menschen. Wenn auch sehr teure anscheinend.

Was das Telefon angeht: Das ist zwar teuer im Verkauf, aber an sich nur ziemlich billig. Das Ding ist aus China (da gibt es also in dem Sinne nichts zu fälschen) und ein ähnliches (oder gleiches?) Modell im selben Gehäuse gibt es auch wesentlich billiger von Siemens. Vielleicht funktioniert bei dem sogar die Weiterleitung an einem Standard-SIP-Server.

Von 3 VP-100 ist bei einem hier nach 3 Jahren das (übrigens unbeleuchtete) Display ausgefallen. Naja.

Ich würde jedenfalls keines dieser Dinger nochmal kaufen.
Bitte warten ..
Mitglied: Pjordorf
03.03.2014, aktualisiert um 15:38 Uhr
Hallo,

Zitat von NetBoi:
Für deine angegebenen Adressen gibt es folgende Resultate:
BC:27:EB:00:00:01 - keine Antwort
80:27:EB:00:00:01 - keine Antwort
FC:27:EB:00:00:01 - keine Antwort
00:1E:68:00:00:01 - Antwort
00:1F:3C:00:00:01 - Antwort
Und genauso habe ich mir das Resultat auch vorgestellt. Die MACs von den zwei Funktioniertende sind echte Hersteller, nur mit einer von miur genannten Seriennummer. Die anderen 3 sind eben Unknown OUIs aber mit einer 0 an Bit 1 und 0.des Ersten Bytes (von links nach rechtes also MSB) oder halt Bit 17 und 18 von den ersten 3 Bytes des Vendor Teils der MAC. Siehe schon genannte Links. Und da deine selbst ausgesuchten MACs eben mit 00 anfingen war dort auch das Bit 0 und 1 eben eine 0. Ob es auch funktioniert wenn dort das Bit 0 UND / ODER 1 eine 1 ist bliebe noch zu erforschen (was weitere tests mit eben einer solchen MAC 01- oder 02- oder einer 03- ) um zu sehen ob es wirklich nur wegen Unkonwn OUI oder eben deren Bits sei,

BC und 90 und FC und 00 haben alle bei Bit 0 und 1 (MSB = von rechts nach links) eine 0 stehen

Da es ja bei dir Reproduzierbar ist, lass LANCOM daran teilhaben mal wieder eine Käfer geboren zu haben

Gruß,
Peter
Bitte warten ..
Mitglied: aqui
03.03.2014 um 16:58 Uhr
War da nicht auch noch was mit Multicast ?? MC Mac Adressen gehen von 01-00-5e-00-00-00 bis 01-00-5e-7f-ff-ff.
Das damit natürlich weder Ping noch sontwas funktioniert ist auch klar.
Und in OUI Datenbanken dürften die logischerweise auch nicht auftauchen...
Bitte warten ..
Mitglied: NetBoi
07.03.2014 um 12:33 Uhr
LANCOM schreibt:

Uns ist dieses Problem nicht bekannt.
Problematisch bei diesem Gerät ist, dass es seit mehreren Jahren
"End-of-live".
Deswegen wird es für dieses Produkt auch keine neueren Firmwareversionen
geben.
Der Support wurde aus dem gleichen Grund auch eingestellt.

Falls ich wieder mal Telefone kaufen werde, werden das wahrscheinlich Snom sein.
Was ist denn noch empfehlenswert (insbesondere im Umgang mit Asterisk)?
Bitte warten ..
Neuester Wissensbeitrag
Windows 10

Powershell 5 BSOD

(8)

Tipp von agowa338 zum Thema Windows 10 ...

Ähnliche Inhalte
Router & Routing
gelöst Routing - Netzwerk Problem - zwischen Filiale und Zentrale (12)

Frage von clonex zum Thema Router & Routing ...

Voice over IP
Problem mit Telekom-VoIP und Lancom-Router (8)

Frage von Benjam1n zum Thema Voice over IP ...

Netzwerkprotokolle
gelöst Problem bei VLAN Trunk mit LACP zwischen HP und Cisco (11)

Frage von markuswo zum Thema Netzwerkprotokolle ...

DSL, VDSL
Problem mit variernder Internetgeschwindigkeit (12)

Frage von schaurian zum Thema DSL, VDSL ...

Heiß diskutierte Inhalte
Microsoft
Ordner mit LW-Buchstaben versehen und benennen (21)

Frage von Xaero1982 zum Thema Microsoft ...

Netzwerkmanagement
gelöst Anregungen, kleiner Betrieb, IT-Umgebung (18)

Frage von Unwichtig zum Thema Netzwerkmanagement ...

Windows Update
Treiberinstallation durch Windows Update läßt sich nicht verhindern (17)

Frage von liquidbase zum Thema Windows Update ...