Geschrieben August 12, 2016 at 06:3412. Aug 2016 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
Geschrieben August 12, 2016 at 08:1412. Aug 2016 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?
Geschrieben August 12, 2016 at 21:2412. Aug 2016 Autor 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.
Geschrieben August 16, 2016 at 16:1416. Aug 2016 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.
Geschrieben August 16, 2016 at 20:0516. Aug 2016 Autor 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.
Geschrieben October 6, 2016 at 13:566. Okt 2016 vllt mal Wireshark mitlaufen lassen um zu sehen was da an Paketen ankommt, kurz bevor der Stack neu startet?
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.