Node rebootet bei Broadcast-Ping

[pberndro]

Wird in im Freifunk-Netz mit LanScan nach Geräten gesucht (Ipv4),
führt dies zu einem Absturz der Node mit Gluon 2014.3.1.

https://forum.freifunk-rheinland.net/t/node-rebootet-bei-broadcast-ping/729

[tcatm]

Ist es wirklich ein Broadcast-Ping oder werden nacheinander IPs gepingt?

[simonszu]

Hi, ich habe den Bug gestern entdeckt, und den Thread im Forum eröffnet. Vom Verhalten von LanScan scheint es ein sequentieller Ping zu sein. Ich kann nicht genau sagen, was da unter der Haube der GUI abläuft, aber die Suche in einem /16 dauert signifikant länger als in einem /24, außerdem läuft während des Scans ein Fortschrittsbalken durch.

Ich war mal so frei, und habe dem Hersteller von LanScan eine Email geschrieben, vielleicht antwortet der ja, und kann weitere Details liefern.

Hi,

i am participating in the german Freifunk project, a project where one can open his WiFi for other users with a special router. One or more routers can mesh together to repeat the Wifi or use redundant upstream connections. The Freifunk project uses generic routers which are compatible to OpenWRT, which are flashed with Gluon, a special version of OpenWRT, especially designed for the needs of Freifunk.

Yesterday i discovered a bug in this firmware. When one connects his Mac to this Wifi and executes a scan via LanScan Pro or Free, the node crashes. There is already an issue (in german) on the GitHub project of Gluon. #231

I am writing you this email to kindly ask you if you could help us to hunt down this bug, and maybe if you could reveal us some details of the technique you are using in LanScan to scan the network. Do you use broadcast pings, or do you sequentially ping each possible IP and check if the ping returns? Since LanScan also reveals the MAC and the vendor of each device, i am assuming you are using some procedures which are already built in nmap or other similar tools.

Yours, Simon

[simonszu]

ich bekam eine Antwort

Hi Simon,

I'm Thomas, founder of iwaxx and main developper of LanScan and Debookee (network analyzer which >includes a version of LanScan)

Thanks for your mail, we will help you finding this naughty bug.

LanScan can scan the local subnet by default, but also a specific IP range on the internet. I suppose you have problem when you scan the local subnet here, but it would be interesting to know if your router crashes when it sees one particular packet for him, or one that it should route: that's two different problems.
Try to scan a public IP range and tell me the result.

On a local subnet, LanScan uses the following techniques, splited in two different phases:

• Discovery phase:
• We "try" to do pings for each device on the subnet: This means that your Mac will first try to resolve the MAC address of a device with an ARP request, and if he receives an ARP answer, then he'll be able to send an ICMP packet at the layer 2 on the subnet.

From a packet point of view for a /24 network:
-> We send 254 ARP broadcast requests, asking each for a particular IP on the network: "Who has 192.168.1.1? - Who has 192.168.1.2? - etc ...."
-> When we have an answer and know the MAC address of an IP, we send an ICMP packet to each device online on the network.

• Hostname resolution phase:
• To each previously discovered device, we send 3 different kind of packet:
  -> mDNS packet on UDP/5353 (Bonjour & Apple devices)
  -> DNS packet UDP/53
  -> SMB packet UDP/137 (Windows device)

I suggest the following troubleshooting plan:

1. Scan a big non local subnet on the internet, like 90.1.1.1 -> 90.1.9.254 and tell us if it crashes
2. We can send you custom version of LanScan with some fonctionnalities disabled: discovery only / SMB only / mDNS only / DNS only

Of course these conversations and custom versions are sent to you personnally, please don't share these binaries with other people.

What do you think about it?

Waiting for your feedback,
Thomas

Ich kann mich gerne um weiteren Kontakt zu dem Hersteller kümmern, wenn dies denn gewünscht ist...ich kenn mich mit den Internas von Gluon leider noch nicht gut genug aus, um da irgendwas weiter zu machen...

[Joachim-Wolff]

Schaut doch bitte mal, ob Ihr ein "/sys/kernel/debug/crashlog" habt und ob da was von out-of-memory drin steht...

[simonszu]

Ich habe ziemlich viele <4>[ 1526.980000] ipv4: Neighbour table overflow. und dann ganz am ende <0>[ 1548.130000] Kernel panic - not syncing: Out of memory: system-wide panic_on_oom is enabled

[T-X]

@simonszu : Könntest du einen capture von deinem Mac mit tcpdump machen und hochladen? http://support.apple.com/en-us/HT202013

Mich würde insbesondere interessieren, ob LanScan wechselnde Absender MAC/IP Adressen für jedes Paket benutzt.

Außerdem noch eine weitere Frage: Stürzt nur dieser eine Freifunk-Knoten dann ab oder auch andere im Mesh?

[Joachim-Wolff]

Für das out-of-memory Phänomen gibt es schon Issue #109

[LeSpocky]

Die Meldungen

[790629.910000] ipv4: Neighbour table overflow.

sind laut @NeoRaider im IRC unkritisch und haben nichts mit dem Problem zu tun.

[neocturne]

Ganz so habe ich das nicht gesagt. Die Meldungen haben wir schon immer, und führen nicht direkt zu Problemen; sie werden in diesem Fall aber sicherlich schon durch die vielen ARP-Anfragen oder -Antworten ausgelöst.

[RubenKelevra]

Ansich sollte die ja nur überlaufen wenn genug gegenstellen im lokalen Netzwerk existieren, um das Limit zu überschreiten, sprich, ARP-Anfragen ins leere sollten ja nicht beantwortet und entsprechend nicht gespeichert werden.

Scans vom ganzen Netz sind grundsätzlich ein Problem, da sehr viel ARP-Broadcast erzeugt wird...

[RubenKelevra]

@simonszu kannst du mal versuchen, das Problem mit nmap nachzustellen, dann braucht man nicht dieses LanScan dafür, und kann vielleicht schaun ob es am ARP ansich oder am Port-Scan liegt.

[neocturne]

Has anyone tested this with a recent (CC-based) Gluon master?

[rotanid]

no updates, closing.