Bug: W724V Typ A DHCP, Portweiterleitung und LeaseTime

10 years ago

Hallo liebes Telekom-Team,

 

hier habe ich einen Rechner [00:22:4d:a5:e9:b6] als Client per DHCP am o.g. Speedport 24/7 hängen. Zu diesem ist eine Portweiterleitung auf Port 22 eingerichtet und funktioniert auch. Soweit alles prima.

 

Genau dann, wenn man die Verbindung vom Internet aus benötigt, funktioniert sie nicht. Traurig

Warum? -  Der DHCP Server im Speedport teilt dem Client offenbar bereits mit Ablauf der renew Zeit - die Hälfte der rebind Zeit - einfach eine neue IP-Adresse zu. Dazu muss die Adresse noch nicht einmal einem anderen Rechner gehört haben.  Meiner Meinung nach sollte zu diesem Zeitpunkt der Client auf jeden Fall die bereits bestehende Adresse wiederbekomen.

Damit zeigt die Weiterleitung auf ein Ziel welches nie auf Port 22 antworten wird oder auf eines, welches gar nicht erst existiert.

Hier hilft es auch nicht weiter, die LeaseTime auf 3 Wochen zu stellen weil die renew Zeit ja bereits nach 1,5 Wochen vorbei wäre. Man schiebt das Problem damit nur weiter hinaus.

 

Auch wenn ich es bis hierher für einen Bug halte, zeigt es, dass die Portweiterleitung sich nicht an der MAC (Bindung) sondern an der IP orientiert. Sonst würde das Problem gar nicht erst auftreten.

 

Eine feste IP für den Clientrechner ist für mich nicht wirklich eine Option weil dieser auch ohne Umkonfiguration in einem anderem Netz funktionieren sollte.

 

Bisher hatte ich die Speedports W504V, W700V, W701V und zuletzt das W723V Typ A und B in meinen Händen. Alle machen diesbezüglich, soweit ich mich erinnere, keine Probleme.

 

Zu meinem Problem habe ich auch noch ein Log von dem Client-Rechner sowie Logs und einen Screenshot vom Speedport angefügt.

Speziell die Speedport Logs habe ich auf den DHCP Teil reduziert.

 

Können Sie mir bitte hier weiterhelfen?

 

Vielen Dank im voraus.

 

Fehler-Port-Forwarding.png

DHCP_Speedport_W_724V_25.04.2015_09:08.pdf

DHCP_Speedport_W_724V_25.04.2015_23:16.pdf

dhclient.eth1.leases.pdf

Fehler-Port-Forwarding.png

Note

This post has been closed.

Note

This post is no longer open for answers or comments and is no longer visible to community members.

1461

0

  • 10 years ago

    Es ist korrekt, wenn der Client nach der Hälfte der Lease-Dauer seine IP-Adresse beim DHCP-Server erneuert. Das ist so im DHCP-Standard vorgesehen.

     

    Es ist ein Bug des Speedport, wenn er dem Client daraufhin eine neue (d.h. andere) IP-Adresse zuweist. Im DHCP-Standard steht eindeutig, dass der Client dieselbe Adresse wieder bekommen soll, wenn es nicht ein technisches Hindernis dafür gibt. Das gilt sogar wenn die Lease abgelaufen ist, erst recht aber wenn sie noch aktiv ist. Das zu wissen nützt Dir aber nichts, denn der Bug wird natürlich nicht behoben werden.

     

    Eine feste IP für den Clientrechner wäre durchaus eine Lösung, wenn sie nicht im Client konfiguriert wird, sondern als Reservierung im DHCP-Server. Dann könnte der Client weiter auf "Adresse automatisch beziehen" eingestellt bleiben. Leider bietet das Speedport solche elementaren Funktionen nicht.

     

    Ich empfehle eine Fritzbox.Fröhlich

    0

    Answer

    from

    7 years ago

    Hallo @Ein_Siedler,

    als Workaround wurde ja im Thread schon erarbeitet, eine feste IP außerhalb des DHCP Range auf das betroffene Geräte im LAN zu setzen.

    Gruß

    Jürgen Wo.

    Answer

    from

    7 years ago

    Na ja, ganz ehrlich. Das ist keine Lösung, das ist eine peinliche Ausrede.

    Diese Lösung ist vielleicht für PC/NB noch eine Möglichkeit. Bei Smartphone/Tablet wird es schon kompliziert. Spätestens im IoT/Embedded-Bereich funktioniert dieser "Workaround" dann auch nicht mehr.

    Es wird doch wohl einer solch großen Firma wie der Telekom oder ihrem Zulieferer möglich sein, über diesen Zeitraum eine vernünftige, konkurenzfähige Firmware zu bauen. Woran hapert es denn in diesem Fall? Taugt die Hardware nicht dafür? Verstehen die Verantwortlichen nicht, worum es geht?

    Die Scriptingfähigkeit der Oberfläche mit erheblichem Denk-Aufwand per Firmwareupdate zu sabotieren - das geht; aber fehlerhafte Grundfunktionalität auf einen akzeptablen Stand zu bringen ist nicht möglich?

    Finden Sie das nicht selber arg peinlich?

     

    Aber ok, dann werde ich mir halt einen Router beschaffen, der das kann.

    Answer

    from

    7 years ago

    Hmmm, da bin ich ja jetzt noch enttäuschter.

    Hatte ja tatsächlich erwartet, dass sich mal einer der Produktverantwortlichen hier meldet ...

This could help you too