24
ARP-Problem zwischen LANCOM VP-100 - Raspberry
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?
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?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 231347
Url: https://administrator.de/forum/arp-problem-zwischen-lancom-vp-100-raspberry-231347.html
Ausgedruckt am: 23.12.2024 um 23:12 Uhr
24 Kommentare
Neuester Kommentar
Und wo liegt jetzt dein Problem?
Geht dein Telefon nicht? Oder hat es gar aussetzer wegen der Anfragen?
Gruß
Netman
Geht dein Telefon nicht? Oder hat es gar aussetzer wegen der Anfragen?
Gruß
Netman
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♬
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♬
@MrNetman:
Das Telefon soll sich am Asterisk des PI anmelden, was dummerweise eine Netzwerkverbindung vorraussetzt
An der Fritzbox im Netz funktioniert es normal.
@108012:
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?
Das Telefon soll sich am Asterisk des PI anmelden, was dummerweise eine Netzwerkverbindung vorraussetzt
An der Fritzbox im Netz funktioniert es normal.
@108012:
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?
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.
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.
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
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
Hallo,
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)
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
)
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 !
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 !
@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)
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)
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):
->TCPDump dazu:
Wenn ich das gleiche mit der echten MAC des PI mache:
und im TCPDump gibt es auch nur die Anfrage und keine Antwort:
(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.
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):
sudo arp-scan --srcaddr=00:13:d1:fc:99:12 --destaddr=00:a0:57:12:fe:40 192.168.2.144
Starting arp-scan 1.8.1 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.2.144 00:a0:57:12:fe:40 LANCOM Systems GmbH
5 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.8.1: 1 hosts scanned in 2.178 seconds (0.46 hosts/sec). 1 responded20:03:32.312363 ARP, Request who-has LANCOM-VP-100.fritz.box tell raspberrypi.fritz.box, length 28
20:03:32.313101 ARP, Reply LANCOM-VP-100.fritz.box is-at 00:a0:57:12:fe:40 (oui Unknown), length 46Wenn ich das gleiche mit der echten MAC des PI mache:
sudo arp-scan --srcaddr=b8:27:eb:60:1f:69 --destaddr=00:a0:57:12:fe:40 192.168.2.144
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.8.1 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/)
3 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.8.1: 1 hosts scanned in 2.549 seconds (0.39 hosts/sec). 0 responded20:03:09.992407 ARP, Request who-has LANCOM-VP-100.fritz.box tell raspberrypi.fritz.box, length 28
20:03:10.092568 ARP, Request who-has LANCOM-VP-100.fritz.box tell raspberrypi.fritz.box, length 28
20:03:11.961819 ARP, Request who-has raspberrypi.fritz.box tell LANCOM-VP-100.fritz.box, length 46
20:03:11.961962 ARP, Reply raspberrypi.fritz.box is-at b8:27:eb:60:1f:69 (oui Unknown), length 28
20:03:12.961859 ARP, Request who-has raspberrypi.fritz.box tell LANCOM-VP-100.fritz.box, length 46
20:03:12.961968 ARP, Reply raspberrypi.fritz.box is-at b8:27:eb:60:1f:69 (oui Unknown), length 28
20:03:13.961867 ARP, Request who-has raspberrypi.fritz.box tell LANCOM-VP-100.fritz.box, length 46
20:03:13.961986 ARP, Reply raspberrypi.fritz.box is-at b8:27:eb:60:1f:69 (oui Unknown), length 28Ich 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.
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
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
1
@108012:
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:
Und siehe da - die LANCOM-Tussie hat plötzlich kein Problem mehr!
Dieses verfluchte Mistding hat mich Stunden gekostet. Verdammt!
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:
smsc95xx.macaddr=00:12:34:56:78:90Und siehe da - die LANCOM-Tussie hat plötzlich kein Problem mehr!
Dieses verfluchte Mistding hat mich Stunden gekostet. Verdammt!
Hallo,
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.
Gruß,
Peter
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
Hallo,
Oder nur eine kleinen Teil davon? Siehe auch http://en.wikipedia.org/wiki/MAC_address#Address_details
Gruß,
Peter
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
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).b8:27:eb:00:00:01 reichen.
Welchen sinnvollen Hintergrund kann das Verhalten des LANCOM-Telefones haben?
Das VP-100 hat die letzte Firmwareversion (3.04.0012)
Hallo,
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
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
> 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.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?
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 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 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....
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....
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.
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.
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.
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.
Hi Aqui,
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
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
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.
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.
Hallo,
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
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,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
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
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...
Das damit natürlich weder Ping noch sontwas funktioniert ist auch klar.
Und in OUI Datenbanken dürften die logischerweise auch nicht auftauchen...
LANCOM schreibt:
Falls ich wieder mal Telefone kaufen werde, werden das wahrscheinlich Snom sein.
Was ist denn noch empfehlenswert (insbesondere im Umgang mit Asterisk)?
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.
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)?
