UDP Hole Punching, Router schmiert ab

Jodocus

Hi, ich entwickle gerade etwas an einer NAT-Traversal-Technik, basierend auf UDP-Holepunching rum. Ein Kunde beobachtete jedoch ein sehr merkwürdiges Problem in Verbindung mit meiner Software:

Der Kunde fungiert als passiver Partner, also es soll jemand anders an ihn UDP-Pakete schicken. Von einem Rendezvous-Server bekommt er die externe IP und Port vom aktiven Partner, die er zur Kommunikation mit dem Server benutzte. (Klassisches UDP Hole punching eben).

Jetzt will ich aber für den Fall, dass der aktive Partner ein symmetrisches NAT besitzt (also sein Router einen anderen externen Port für die Kommunikation mit dem passiven Partner benutzt als mit dem Rendezvous-Server) gleich mehrere Holes "punchen", sequentiell also den Port erraten, den der aktive Partner benutzen könnte.
So sieht der Algo quasi aus:

set_socket_option(TTL, 5); // setze das IP-TTL auf 5, damit die Pakete nicht weit kommen
std::vector<std::uint8_t> dummy(32, 1); // Dummy-Packet voll mit 32 einsen
for(int i = 0; i < 100; ++i)
   udp_send(dummy, port + i); // punche holes

Dabei schmiert das Internet ab. Den Router kann er erreichen (also z.B. die Config-Seite), also kann man irgendwelche Antivirenprogramme auf dem Computer aussschließen. Erst nach einem Routerneustart funktioniert das Internet wieder.

Hat jemand Erfahrung mit so einem Verhalten? Ist das eine Art Sicherheitsvorkehrung? Was kann man machen? Wird das durch das Low-TTL verursacht? Oder versucht der Router, eine Art Portscan-Attacke von innen (?) abzuwehren?

Der Router ist ein Huawei EchoLife HG532, ich vermute Full Cone NAT.

Shade Of Mine

Auf Routern läuft idR Schrottsoftware. Die wird einfach abschmieren weil sie Schrott ist.

Firmware update machen, sehen ob Fehler behoben ist. Wenn nicht, selbes Modell wie Kunde kaufen und dumm rumprobieren.

So ein Quatsch Shade Of Mine. Auf Routern läuft meistens Linux.