1793VA DSL-1: Broadcast statt Unicast
Moderator: Lancom-Systems Moderatoren
1793VA DSL-1: Broadcast statt Unicast
HW:
1793VA LCOS 10.80.0155
Eth4 als DSL-1 (Internet-Zugang über DHCP) für ext. LTE-Backup
Dem DISCOVER fehlt das Broadcast Flag Wie kann ich das auf Broadcast ändern?
1793VA LCOS 10.80.0155
Eth4 als DSL-1 (Internet-Zugang über DHCP) für ext. LTE-Backup
Dem DISCOVER fehlt das Broadcast Flag Wie kann ich das auf Broadcast ändern?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Re: 1793VA DSL-1: Broadcast statt Unicast
Hi schiffeg
Es gibt mitlerweile sogar (Kabel-) Internet-Provider, die Auf DHCP-Discovers mit gesetztem Broadcast-Bit gar nicht mehr antworten (weil die Antworten an alle gehen würden, was sie als Sicherheitslücke ansehen).
wenn dein komisches LTE-Teil damit nicht umgehen kann, da hau es dem Hersteller um die Ohren, denn es verhält sich nicht RFC-Konform!
Gruß
Backslash
nein, das fehlt ihm nicht, denn der IP-Stack des LANCOMs kann damit umgehen, wenn die Antworten des DHCP-Servers bereits gerichtet kommen, noch bevor die Adresse zugewiesen wurde.Dem DISCOVER fehlt das Broadcast Flag
Es gibt mitlerweile sogar (Kabel-) Internet-Provider, die Auf DHCP-Discovers mit gesetztem Broadcast-Bit gar nicht mehr antworten (weil die Antworten an alle gehen würden, was sie als Sicherheitslücke ansehen).
gar nicht...Wie kann ich das auf Broadcast ändern?
wenn dein komisches LTE-Teil damit nicht umgehen kann, da hau es dem Hersteller um die Ohren, denn es verhält sich nicht RFC-Konform!
Gruß
Backslash
Re: 1793VA DSL-1: Broadcast statt Unicast
BTW: kommt das Paket überhaupt vom LANCOM? Wenn ich mit die Source-MAC-Adresse anschaue, die Wireshark auf "elmegt" als Hersteller auflöst, habe ich da so meine Zweifel...
Re: 1793VA DSL-1: Broadcast statt Unicast
Die MAC ist benutzdefiniert
Das Paket kommt definitiv vom LANCOM ….
Das 4Ge-LE am 1793VA ist ja nur eine Interimslösing
In den nächsten Jahren sollen die Filialen
1793BA mit 730-4G+ / 730-5G
bekommen …
Das Paket kommt definitiv vom LANCOM ….
Das 4Ge-LE am 1793VA ist ja nur eine Interimslösing
In den nächsten Jahren sollen die Filialen
1793BA mit 730-4G+ / 730-5G
bekommen …
Re: 1793VA DSL-1: Broadcast statt Unicast
Hi backslash,
im RFC 2131 heißte es hierzu:
A client that cannot receive unicast IP datagrams until its protocol
software has been configured with an IP address SHOULD set the
BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
DHCPREQUEST messages that client sends.
Ist zwar kein MUST aber ein SHOULD ..
Es scheint an diesem Flag (bit) zu scheitern.
Es geht um eine größere Anzahl von 1793VA, die noch zu bestellen wären; die bintec 4Ge-LE sind teilweise abgesetzt verbaut und schwierig kurzfristig zu ersetzen.
Vllt fällt Dir ja was ein.
VG
im RFC 2131 heißte es hierzu:
A client that cannot receive unicast IP datagrams until its protocol
software has been configured with an IP address SHOULD set the
BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
DHCPREQUEST messages that client sends.
Ist zwar kein MUST aber ein SHOULD ..
Es scheint an diesem Flag (bit) zu scheitern.
Es geht um eine größere Anzahl von 1793VA, die noch zu bestellen wären; die bintec 4Ge-LE sind teilweise abgesetzt verbaut und schwierig kurzfristig zu ersetzen.
Vllt fällt Dir ja was ein.
VG
-
- Beiträge: 2924
- Registriert: 12 Jan 2010, 14:10
Re: 1793VA DSL-1: Broadcast statt Unicast
Dein Client kann damit aber umgehen (Lancom), der Bintec jedoch nicht (DHCP-Server).
Code: Alles auswählen
If the broadcast bit is not set and 'giaddr' is zero and
'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
messages to the client's hardware address and 'yiaddr' address.
Re: 1793VA DSL-1: Broadcast statt Unicast
Hi Dr.Einstein,
dumme Frage: Wo spiele ich den Code ein und wie? (Wahrscheinlich Lancom ...)
dumme Frage: Wo spiele ich den Code ein und wie? (Wahrscheinlich Lancom ...)
Re: 1793VA DSL-1: Broadcast statt Unicast
Man merkt Du bist mal Programmierer gewesen
Das ist kein Code, das ist ein Code-Feld hier im Forum, und mehr oder weniger von Dr. Einstein genutzt als ein Zitat-Feld. Ist aus der DHCP-RFC (https://www.ietf.org/rfc/rfc2131.txt).
![Smile :)](./../images/smilies/icon_smile.gif)
Das ist kein Code, das ist ein Code-Feld hier im Forum, und mehr oder weniger von Dr. Einstein genutzt als ein Zitat-Feld. Ist aus der DHCP-RFC (https://www.ietf.org/rfc/rfc2131.txt).
Re: 1793VA DSL-1: Broadcast statt Unicast
Danke Jirka für den Hinweis!
D.h. doch übersetzt:
Wenn das Broadcast Bit NICHT gesetzt ist und die Gateway-IP-Adresse null ist und die Client-IP-Adresse null ist, dann soll der DHCP-Server DHCPOFFER und DHCPACK Messages mit Unicast zu der Client HW-Adresse (MAC Adresse (des LANCOM DSL-1) und zu der „Your-IP- Adresse“ senden.
(Das YIADDR-Feld wird mit der IP-Adresse aufgefüllt, die der Server dem Client anbietet !!) YIADDR Ist also beim DISCOVER (normalerweise) noch leer ...
Also der Client kennt nix, und der Sever sendet den DHCPOFFER dann nur an die MAC und die ZUKÜNFTIGE IP-Adresse des Clients ....
Im RFC 2131 heißt es aber auch:
If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
set, then the server broadcasts DHCPOFFER and DHCPACK messages to
0xffffffff.
Wir haben es also nicht nur mit einem Problem, wie backslash das sieht, sondern (m.E.) mit 2 Problemen zu tun:
- 1. Der bintec kann die MAC-Adresse vom LANCOM (DSL-1) im DISCOVER nicht auslesen: Daher läuft der OFFER vom bintec mit Unicast ins Leere ...
- 2. Der LANCOM kann am DSL-1 nur Unicast, obwohl der RFC 2131 auch Broadcast vorsieht. (Die DigiBox z.B. sendet am Ethernet WAN-Port mit Broadcast ....)
Hat irgendjemand eine Idee?
D.h. doch übersetzt:
Wenn das Broadcast Bit NICHT gesetzt ist und die Gateway-IP-Adresse null ist und die Client-IP-Adresse null ist, dann soll der DHCP-Server DHCPOFFER und DHCPACK Messages mit Unicast zu der Client HW-Adresse (MAC Adresse (des LANCOM DSL-1) und zu der „Your-IP- Adresse“ senden.
(Das YIADDR-Feld wird mit der IP-Adresse aufgefüllt, die der Server dem Client anbietet !!) YIADDR Ist also beim DISCOVER (normalerweise) noch leer ...
Also der Client kennt nix, und der Sever sendet den DHCPOFFER dann nur an die MAC und die ZUKÜNFTIGE IP-Adresse des Clients ....
Im RFC 2131 heißt es aber auch:
If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
set, then the server broadcasts DHCPOFFER and DHCPACK messages to
0xffffffff.
Wir haben es also nicht nur mit einem Problem, wie backslash das sieht, sondern (m.E.) mit 2 Problemen zu tun:
- 1. Der bintec kann die MAC-Adresse vom LANCOM (DSL-1) im DISCOVER nicht auslesen: Daher läuft der OFFER vom bintec mit Unicast ins Leere ...
- 2. Der LANCOM kann am DSL-1 nur Unicast, obwohl der RFC 2131 auch Broadcast vorsieht. (Die DigiBox z.B. sendet am Ethernet WAN-Port mit Broadcast ....)
Hat irgendjemand eine Idee?
-
- Beiträge: 2924
- Registriert: 12 Jan 2010, 14:10
Re: 1793VA DSL-1: Broadcast statt Unicast
Herausfinden, wieso das Ziel Frame 00:00:00:00:00:00 nicht am Lancom auf DSL-1 ankommt. Der vorgeschaltete Switche sollte dieses Frame auf alle Ports auskoppeln. Der Lancom würde es meiner Meinung nach trotzdem annehmen weil die DHCP ID zum Request passt, und wie Backslash gesagt hat, frisst der Lancom auf einer DHCPoE Verbindung nahezu alles. Da VLANs zum Einsatz kommen, evtl mal einen VLAN-fähigen Switch verwenden und die VLANs korrekt einstellen.
Re: 1793VA DSL-1: Broadcast statt Unicast
Der OFFER des bintec 4Ge-LE kommt am LAN-3 des LANCOM an nur nicht am DSL-1 ....
Re: 1793VA DSL-1: Broadcast statt Unicast
Das schreibt der Weltmarktführer Cisco:
DHCP Client Operation
When a Dynamic Host Configuration Protocol (DHCP) client requests an IP address from a DHCP server on a Cisco IOS XE platform, the default process includes:
DHCPDISCOVERY (broadcast)
DHCPOFFER (broadcast)
DHCPREQUEST (broadcast)
DHCPACK (unicast)
https://www.cisco.com/c/en/us/td/docs/r ... nt-xe.html
(Noch) Aktuelles Cisco IOS XE 17.x ...
Sooooo sollte es meines Erachtens auch Default laufen ....
Mit Cisco funktioniert das bintec 4Ge-LE auch! Nur halt ist Cisco was teurer
DHCP Client Operation
When a Dynamic Host Configuration Protocol (DHCP) client requests an IP address from a DHCP server on a Cisco IOS XE platform, the default process includes:
DHCPDISCOVERY (broadcast)
DHCPOFFER (broadcast)
DHCPREQUEST (broadcast)
DHCPACK (unicast)
https://www.cisco.com/c/en/us/td/docs/r ... nt-xe.html
(Noch) Aktuelles Cisco IOS XE 17.x ...
Sooooo sollte es meines Erachtens auch Default laufen ....
Mit Cisco funktioniert das bintec 4Ge-LE auch! Nur halt ist Cisco was teurer
Re: 1793VA DSL-1: Broadcast statt Unicast
DHCP: Client Identifier ist kein MUST, sondern MAY !!
.
Daher liegt Cisco auch richtig: Wenn der Client Identifier im DHCP nur MAY und kein MUST ist, dann muss der Client (m.E.) in der Lage sein, den DISCOVER auch mit broadcast flag raus zu senden und nicht nur mit unicast flag ..
Oder liege ich da falsch?
Der bintec 4Ge-LE (eigentlich von Teldat) berücksichtigt anscheinend den Client Identifier (überhaupt) nicht, was er auch nicht muss, da der Client Identifier nur May und kein MUST; also DHCP-konform. q.e.d.
.
Daher liegt Cisco auch richtig: Wenn der Client Identifier im DHCP nur MAY und kein MUST ist, dann muss der Client (m.E.) in der Lage sein, den DISCOVER auch mit broadcast flag raus zu senden und nicht nur mit unicast flag ..
Oder liege ich da falsch?
Der bintec 4Ge-LE (eigentlich von Teldat) berücksichtigt anscheinend den Client Identifier (überhaupt) nicht, was er auch nicht muss, da der Client Identifier nur May und kein MUST; also DHCP-konform. q.e.d.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
-
- Beiträge: 76
- Registriert: 08 Jul 2022, 12:53
- Wohnort: Aachen
Re: 1793VA DSL-1: Broadcast statt Unicast
OK, wenn du schon den Client-Identifier ins Spiel bringst:
Der ist im DHCP-Client im LCOS konfigurierbar ab LCOS 10.70. Ab LCOS 10.70 wird RFC 4361 im DHCP-Client unterstützt.
Auf der CLI oder im LCOS Menübaum kannst du dein Glück versuchen unter /Setup/DHCP/Client. Dort gibt es
Früher war der Default MAC. Damit das besser in Dual Stack Netzwerken der Provider zusammen mit DHCPv6 funktioniert ist der neue Wert DUID.
Vielleicht kann das der ***tec DHCP-Server auch nicht richtig (wäre auch nicht RFC-konform!).
Vorschlag: setzte den Wert mal auf "MAC", entweder für LAN oder WAN, je nachdem welchen Interface-Type du verwendest.
In jedem Fall ist das aber ein Problem des DHCP-Servers, denn der muss sowohl Brodcast als auch Unicast können und den Client-Identifier "opaque" behandeln.
Der ist im DHCP-Client im LCOS konfigurierbar ab LCOS 10.70. Ab LCOS 10.70 wird RFC 4361 im DHCP-Client unterstützt.
Auf der CLI oder im LCOS Menübaum kannst du dein Glück versuchen unter /Setup/DHCP/Client. Dort gibt es
Code: Alles auswählen
WAN-Client-ID-Type : MAC (0), DUID (1)
Vielleicht kann das der ***tec DHCP-Server auch nicht richtig (wäre auch nicht RFC-konform!).
Vorschlag: setzte den Wert mal auf "MAC", entweder für LAN oder WAN, je nachdem welchen Interface-Type du verwendest.
In jedem Fall ist das aber ein Problem des DHCP-Servers, denn der muss sowohl Brodcast als auch Unicast können und den Client-Identifier "opaque" behandeln.
Re: 1793VA DSL-1: Broadcast statt Unicast
Genau. Tut das 4Ge-LE aber nicht.schiffeg hat geschrieben: ↑12 Nov 2023, 10:22 D.h. doch übersetzt:
Wenn das Broadcast Bit NICHT gesetzt ist und die Gateway-IP-Adresse null ist und die Client-IP-Adresse null ist, dann soll der DHCP-Server DHCPOFFER und DHCPACK Messages mit Unicast zu der Client HW-Adresse (MAC Adresse (des LANCOM DSL-1) und zu der „Your-IP- Adresse“ senden.
Genau.schiffeg hat geschrieben: ↑12 Nov 2023, 10:22 (Das YIADDR-Feld wird mit der IP-Adresse aufgefüllt, die der Server dem Client anbietet !!) YIADDR Ist also beim DISCOVER (normalerweise) noch leer ...
Also der Client kennt nix, und der Sever sendet den DHCPOFFER dann nur an die MAC und die ZUKÜNFTIGE IP-Adresse des Clients ....
Das ist nicht korrekt. Er kann sie sehr wohl auslesen, er packt sie nur nicht ins richtige Feld! Und das ist ein billiger Bug im 4Ge-LE.
Noch mal im Detail: Das DHCP-Discover vom LANCOM enthält die 'Client MAC address: 02:a0:57:54:ad:a4 (02:a0:57:54:ad:a4)' im Kern des Bootstrap Protocols und _zusätzlich_ im _optionalen_ 'Option: (61) Client identifier'. Das verarbeitet das 4Ge-LE schon, denn sonst wäre im DHCP-Offer vom 4Ge-LE die Client MAC Address nicht enthalten! Er adressiert nur das Ethernet-Packet falsch. Punkt aus Ende.
Der LANCOM-Router müsste also, wenn das DHCP-Discover in einen Timeout läuft, mit einem DHCP-Discover mit gesetztem Broadcast-Bit daherkommen, damit auch das Zusammenspiel mit Geräten klappt, die einen DHCP-Discover ohne Broadcast-Bit nicht beherrschen? Kann man sicher machen, wäre aber ein Feature-Wunsch, genauso, wie das z. B. auch konfigurierbar zu machen. Ob das allerdings so eine hohe Prio bekommt und überhaupt gewollt ist, so dass es letztlich eine Umsetzungschance hat, weiß ich auch nicht. Ich nehme es eher nicht an.
Ja, eintüten, immerhin habe ich Dir ja jetzt schon unterstützend in dem anderen Thread und mit diesem Post ein paar Beschreibungen geliefert, die Du schön aufs Silbertablett packen kannst, und dann ab mit dem Problem zu bintec. Dann müssten sie sich eigentlich noch bei Dir bedanken, tun allerdings die meisten Hersteller nicht. Deswegen haben wir ja so einen leidigen Job.
Wo steht das? Ich habe diesbezüglich keine Ahnung, von daher sag mir doch mal bitte, ob irgendwo steht, dass die MAC-Adresse 00:00:00:00:00:00 eine spezielle MAC-Adresse ist, die Deiner Meinung nach ("alle Ports") wie die ff:ff:ff:ff:ff:ff zu behandeln ist? Ich habe dazu nichts gefunden, aber auch nicht lange gesucht, deswegen zweifel ich das an. Wie ich im anderen Thread schon schrieb, ich weiß gar nicht, wie sich so ein Switch in dem Fall verhalten muss.Dr.Einstein hat geschrieben: ↑12 Nov 2023, 10:44 Herausfinden, wieso das Ziel Frame 00:00:00:00:00:00 nicht am Lancom auf DSL-1 ankommt. Der vorgeschaltete Switche sollte dieses Frame auf alle Ports auskoppeln.
Viele Grüße
Jirka