Tinkerforge mit Ethernet Extension rebootet bei einem LAN Loop/Broadcast Spam

[adrianer]

Wir haben hier einen Tinkerforge bestehend aus:

 

Step-Down Power Supply

Master Brick 2.0

Master Brick 2.0

Master Brick 2.1

Ethernet Extension

Servo Brick

+ 14 Bricklets

 

Im Netzwerk werden verschiedene Geräte Prototypen verwendet und es kommt deshalb manchmal zu Ethernet Loops oder die Geräte spammen das Netzwerk mit Broadcasts zu. Jedes mal wenn es dazu kommt, bootet der Tinkerforge praktisch sofort neu. Ist das Reboot Problem bereits bekannt?

 

Als Workaround habe ich den Tinkerforge jetzt hinter einen Router gesetzt, der so zu sagen dem Tinkeforge vor den "Paketfluten" schützt. Schöner wäre es aber, auf diesem Workaround verzichten zu können

[borg]

Das Problem ist neu, das kenne ich noch nicht . Die Broadcasts kommen per UDP? Falls per TCP (gibt es das überhaupt?), kommen die Pakete dann auf dem Port 4223 an?

[adrianer]

Nein, auf Port kommen 4223 kommen die nicht. Deshalb kann der Workaround mit dem Router und dem Port Forwarding des 4223 Ports funktionieren.

 

Reproduzieren lässt sich das Problem im übrigen in den meisten Fällen einfach: man nehme ein LAN Kabel und schließe beide Enden an den selben Switch an an dem auch der Tinkerforge hängt (und auch noch was anderes das Traffic produziert der dann im Kreis laufen kann). Danach auf den Reboot des Tinkerforge warten.

[borg]

Sorry, ich werde immer noch nicht ganz schlau draus. Wir haben hier einen 32-Port Switch in der Firma an dem alle Rechner usw hängen. Da laufen durchgängig viele Mbit/s drüber und ich kann beliebig Ethernet Extensions anschließe ohne das es zu ausfällen kommen würde.

 

Die Ethernet Extension selbst nimmt nur Pakete auf Port 4223 und 4280 entgegen (Pakete die andere Ports gehen werden direkt im den Ethernet IC  den wir verwenden verworfen). Falls ein Paket ankommt welches nicht unserem Protokoll entspricht (Prüfsummen passen nicht etc.) wird der Socket sofort geschlossen.

[adrianer]

borg: bei einem Switch ohne das man einen Loop baut (siehe: https://en.wikipedia.org/wiki/Switching_loop ) oder Broadcaststurm als Folge des Loops hat (siehe: https://en.wikipedia.org/wiki/Switching_loop#Broadcasts ) verursacht, wird das Problem nicht auftreten, denn es kommen keine Pakete am Switch Port des Tinkerforge an, die nicht an dem adressiert sind (mit der Ausnahme von wenigen Broadcasts).

Höchstens könnte der selbe Effekt passieren, wenn man einen Ethernet Hub statt Switch verwendet (der dann ja jedes Paket an jedem Port des Hubs schickt) und die komplette Bandbreite des Hubs frisst - das habe ich aber nicht getestet.

[Novae]

vllt mal Wireshark mitlaufen lassen um zu sehen was da an Paketen ankommt, kurz bevor der Stack neu startet?