1793VA DSL-1: Broadcast statt Unicast

[schiffeg]

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

1793VA_Trace_DISCOVER_Unicast.jpg

Wie kann ich das auf Broadcast ändern?

[backslash]

Hi schiffeg

Dem DISCOVER fehlt das Broadcast Flag

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.
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).

Wie kann ich das auf Broadcast ändern?

gar nicht...

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

[backslash]

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...

[schiffeg]

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 …

[schiffeg]

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

[Dr.Einstein]

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.

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.

[schiffeg]

Hi Dr.Einstein,

dumme Frage: Wo spiele ich den Code ein und wie? (Wahrscheinlich Lancom ...)

[Jirka]

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).

[schiffeg]

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?

[Dr.Einstein]

Hat irgendjemand eine Idee?

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.

[schiffeg]

Der OFFER des bintec 4Ge-LE kommt am LAN-3 des LANCOM an nur nicht am DSL-1 ....

[schiffeg]

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

[schiffeg]

DHCP: Client Identifier ist kein MUST, sondern MAY !!

DHCP Client Identifier MAY.jpg

.

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.

[Frühstücksdirektor]

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

Code: Alles auswählen

 WAN-Client-ID-Type        : MAC (0), DUID (1)

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.

[Jirka]

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. Tut das 4Ge-LE aber nicht.

(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 ....

Genau.

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 ...

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.

- 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 ....)

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.

Hat irgendjemand eine Idee?

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.

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.

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.

Viele Grüße
Jirka