netboi
Goto Top

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?

Content-Key: 231347

Url: https://administrator.de/contentid/231347

Ausgedruckt am: 19.03.2024 um 03:03 Uhr

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

Gruß
Netman
Mitglied: 108012
108012 01.03.2014 um 11:14:49 Uhr
Goto Top
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♬
Mitglied: NetBoi
NetBoi 01.03.2014 aktualisiert um 11:43:15 Uhr
Goto Top
@MrNetman:
Das Telefon soll sich am Asterisk des PI anmelden, was dummerweise eine Netzwerkverbindung vorraussetzt face-sad
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?
Mitglied: aqui
Lösung aqui 01.03.2014 aktualisiert um 23:18:46 Uhr
Goto Top
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.
Mitglied: NetBoi
NetBoi 01.03.2014 aktualisiert um 16:47:37 Uhr
Goto Top
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
Mitglied: Pjordorf
Pjordorf 01.03.2014 um 18:54:32 Uhr
Goto Top
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 face-smile Zumindest kannst du dann HW Problem ausschließen.

Gruß,
Peter
(der sein PI auch zerlegt hatte face-smile)
Mitglied: aqui
aqui 01.03.2014 aktualisiert um 20:18:10 Uhr
Goto Top
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 face-wink
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 !
Mitglied: NetBoi
NetBoi 01.03.2014 aktualisiert um 20:51:54 Uhr
Goto Top
@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 face-sad

@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)
Mitglied: NetBoi
NetBoi 01.03.2014 aktualisiert um 21:21:17 Uhr
Goto Top
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):
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 responded
->TCPDump dazu:
20: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 46

Wenn 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 responded
und im TCPDump gibt es auch nur die Anfrage und keine Antwort:
20: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 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.
Mitglied: 108012
108012 01.03.2014 aktualisiert um 21:45:51 Uhr
Goto Top
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
Mitglied: NetBoi
NetBoi 01.03.2014 aktualisiert um 21:45:04 Uhr
Goto Top
@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:

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!
Mitglied: Pjordorf
Pjordorf 01.03.2014 um 21:47:46 Uhr
Goto Top
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 face-smile

(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
Mitglied: Pjordorf
Pjordorf 01.03.2014 um 22:06:48 Uhr
Goto Top
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
Mitglied: NetBoi
NetBoi 01.03.2014 aktualisiert um 23:39:03 Uhr
Goto Top
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)
Mitglied: Pjordorf
Pjordorf 02.03.2014 um 00:55:47 Uhr
Goto Top
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
Mitglied: NetBoi
NetBoi 02.03.2014 um 01:04:29 Uhr
Goto Top
> 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 face-smile
Mitglied: aqui
aqui 02.03.2014 um 12:49:29 Uhr
Goto Top
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....
Mitglied: NetBoi
NetBoi 02.03.2014 um 22:33:27 Uhr
Goto Top
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.
Mitglied: MrNetman
MrNetman 03.03.2014 um 00:59:39 Uhr
Goto Top
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.
Mitglied: Pjordorf
Pjordorf 03.03.2014 aktualisiert um 14:39:40 Uhr
Goto Top
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 face-smile 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
Mitglied: NetBoi
NetBoi 03.03.2014 aktualisiert um 15:24:25 Uhr
Goto Top
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.
Mitglied: Pjordorf
Pjordorf 03.03.2014 aktualisiert um 15:38:00 Uhr
Goto Top
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 habenface-smile

Gruß,
Peter
Mitglied: aqui
aqui 03.03.2014 um 16:58:30 Uhr
Goto Top
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...
Mitglied: NetBoi
NetBoi 07.03.2014 um 12:33:44 Uhr
Goto Top
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)?