1793VA mit LTE Backup bintec 4Ge-LE

[schiffeg]

Trace:

[DHCP] 2023/09/25 21:04:25,844 [info] : DHCP Client Tx (WAN, 4GE-LE)
DHCP Client Message (request): DHCPDISCOVER
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = 52e03864 | Secs = 01e4 | Flags = 0000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 02 a0 57 46 ac b0 00 00 00 00 00 00 00 00 00 00
Message-Type (53): discover (1)
Client-ID (61): IAID : f3f9e24a
DUID-Type : 3 (link-layer-address, DUID-LL)
Hardware-Type: 1 (ethernet)
MAC-Address : 02:a0:57:46:ac:b0
Message-Size (57): 1280
Hostname (12): 1793VAW
Vendor-Class-ID (60): 4c 41 4e 43 4f 4d 20 31 37 39 33 56 41 57
Option List (55): 1, 121, 3, 6, 15, 43, 212


[DHCP] 2023/09/25 21:04:53,342
DHCP Aging
DHCP Aging complete

[DHCP] 2023/09/25 21:04:58,428 [info] : DHCP Client: set state idle (0) for 4GE-LE

[DHCP] 2023/09/25 21:04:58,532 [info] : DHCP Client: set state init (1) for 4GE-LE

[DHCP] 2023/09/25 21:04:58,632 [info] : DHCP Client: set state selecting (2) for 4GE-LE

[DHCP] 2023/09/25 21:04:58,632 [info] : DHCP Client Tx (WAN, 4GE-LE)
DHCP Client Message (request): DHCPDISCOVER
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = 9e34a752 | Secs = 0221 | Flags = 0000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 02 a0 57 46 ac b0 00 00 00 00 00 00 00 00 00 00
Message-Type (53): discover (1)
Client-ID (61): IAID : f3f9e24a
DUID-Type : 3 (link-layer-address, DUID-LL)
Hardware-Type: 1 (ethernet)
MAC-Address : 02:a0:57:46:ac:b0
Message-Size (57): 1280
Hostname (12): 1793VAW
Vendor-Class-ID (60): 4c 41 4e 43 4f 4d 20 31 37 39 33 56 41 57
Option List (55): 1, 121, 3, 6, 15, 43, 212


[DHCP] 2023/09/25 21:05:03,822 [info] : DHCP Client Tx (WAN, 4GE-LE)
DHCP Client Message (request): DHCPDISCOVER
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = 9e34a752 | Secs = 0221 | Flags = 0000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 02 a0 57 46 ac b0 00 00 00 00 00 00 00 00 00 00
Message-Type (53): discover (1)
Client-ID (61): IAID : f3f9e24a
DUID-Type : 3 (link-layer-address, DUID-LL)
Hardware-Type: 1 (ethernet)
MAC-Address : 02:a0:57:46:ac:b0
Message-Size (57): 1280
Hostname (12): 1793VAW
Vendor-Class-ID (60): 4c 41 4e 43 4f 4d 20 31 37 39 33 56 41 57
Option List (55): 1, 121, 3, 6, 15, 43, 212


[DHCP] 2023/09/25 21:05:10,614
DHCP Rx (LAN-2, DMZ):
DHCP Client Message (request) from 172.16.66.2: DHCPINFORM
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = 649EBF40 | Secs = 0228 | Flags = 0000
CIAdr = 172.16.66.2 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 00 a0 26 ac 62 49 00 00 00 00 00 00 00 00 00 00

Option List 1 3 6 43
Client-ID:
Hardware-Type: 116 (unknown)
HW-Address : 65:6c:64:61:74
=> Tx DHCPACK

[DHCP] 2023/09/25 21:05:10,614
DHCP Tx (LAN-2, DMZ):
DHCP Server Message (reply) to 172.16.66.2: DHCPACK
Op = 02 | HType = 01 | HLen = 06 | Hops = 00
XId = 649EBF40 | Secs = 0228 | Flags = 0000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 00 a0 26 ac 62 49 00 00 00 00 00 00 00 00 00 00
Server-ID: 172.16.66.1
Client-ID:
Hardware-Type: 116 (unknown)
HW-Address : 65:6c:64:61:74
Netmask: 255.255.255.252
Gateway: 172.16.66.1
DNS-Server: 172.16.66.1
Domain: intern
Broadcast: 172.16.66.3
NBNS-Server: (none)
Option 43/ 0: antenna&routertyp=generic&apn=internet.telekom&pin=0000

[DHCP] 2023/09/25 21:05:11,103 [info] : DHCP Client Tx (WAN, 4GE-LE)
DHCP Client Message (request): DHCPDISCOVER
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = 9e34a752 | Secs = 0221 | Flags = 0000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 02 a0 57 46 ac b0 00 00 00 00 00 00 00 00 00 00
Message-Type (53): discover (1)
Client-ID (61): IAID : f3f9e24a
DUID-Type : 3 (link-layer-address, DUID-LL)
Hardware-Type: 1 (ethernet)
MAC-Address : 02:a0:57:46:ac:b0
Message-Size (57): 1280
Hostname (12): 1793VAW
Vendor-Class-ID (60): 4c 41 4e 43 4f 4d 20 31 37 39 33 56 41 57
Option List (55): 1, 121, 3, 6, 15, 43, 212


[DHCP] 2023/09/25 21:05:28,396 [info] : DHCP Client Tx (WAN, 4GE-LE)
DHCP Client Message (request): DHCPDISCOVER
Op = 01 | HType = 01 | HLen = 06 | Hops = 00
XId = 9e34a752 | Secs = 0221 | Flags = 0000
CIAdr = 0.0.0.0 | YIAdr = 0.0.0.0
SIAdr = 0.0.0.0 | GIAdr = 0.0.0.0
CHAdr = 02 a0 57 46 ac b0 00 00 00 00 00 00 00 00 00 00
Message-Type (53): discover (1)
Client-ID (61): IAID : f3f9e24a
DUID-Type : 3 (link-layer-address, DUID-LL)
Hardware-Type: 1 (ethernet)
MAC-Address : 02:a0:57:46:ac:b0
Message-Size (57): 1280
Hostname (12): 1793VAW
Vendor-Class-ID (60): 4c 41 4e 43 4f 4d 20 31 37 39 33 56 41 57
Option List (55): 1, 121, 3, 6, 15, 43, 212

[Dr.Einstein]

Geht in einem Timeout, du bekommst keinerlei Antwort von dem Bintec. Irgendwas haut in deiner Konfiguration nicht hin. Ich tippe weiterhin auf das VLAN Tagging, entweder im Lancom, oder im Switch.

[schiffeg]

Irgendeine Idee was die Ursache sein könnte?

Den Switch habe ich schon getauscht .... gleiches Resultat

[schiffeg]

Hi Dr.Einstein,

anbei zum Vergleich der Trace der Digibox Smart mit bintec 4Ge-LE (Internet über LTE funktioniert) mit dem DHCP DISCOVER, auf den der bintec 4Ge-LE antwortet.
Dazwischen ist der selbe Switch (TP-Link unmanaged, TL-SF1008P) geschaltet; der bintec bekommt PoE vom Switch.
Also gleicher Aufbau wie beim LANCOM mit Switch dazwischen. Den Switch kann man damit (fast) ausschließen.

Könnte es an den MAC-Adressen vom LANCOM liegen?

[Dr.Einstein]

Im Wireshark ist kein VLAN Header zu sehen. Entweder hast du den durch die Netzwerkkarte entfernt, oder es existiert keiner. Entsprechend müsstest du dann im Lancom in der WAN Schnittstelle das VLAN entfernen, da es wohl der Switch übernimmt.

[schiffeg]

Vielen Dank Dr.Einstein!

Den Trace hat die DigiBox selbst aufgezeichnet (Trace Funktion der DigiBox), also VOR dem Switch.

Ich probier’s mal mit dem LANCOM ohne Vlan 463

[schiffeg]

Hi Dr.Einstein,

anbei (nur) ein DISCOVER der DigiBox, der funktioniert.
Es liegt wohl am DISCOVER des WAN-Port (Eth4 = DSL-1) des LANCOM 1793VA. Irgendwas ist anders als bei der DigiBox ...

Wo fehlt der VLAN-Header? I

Danke und viele Grüße

[GrandDixence]

Wo fehlt der VLAN-Header? I

In der Spalte "VLAN" fehlt die Angabe des VLAN-Tag. Somit ist dieses DHCP DISCOVER-Telegramm vom bintec 4Ge-LE ohne VLAN-Tag. Wäre das eine Datenverkehrsaufzeichnung am LAN-Port vom LANCOM-Router (=> Packet Capture auf ETH-1) wäre das OK (gemäss Dr. Einstein).

Gemäss dem Beitrag von Dr. Einstein am 29.08.2023 um 16:06 Uhr müsste das DHCP DISCOVER-Telegramm vom LANCOM-Router ein VLAN-Tag mit der Nummer 463 tragen. Somit sollte im Wireshark in der Spalte "VLAN" die Zahl 463 auf der Höhe des DCHP Discover-Telegramms ersichtlich sein für die Datenverkehrsaufzeichnungen am WAN-Port vom LANCOM-Router (=> Packet Capture auf ETH-2).

Kein_VLAN-Tag.png

Bitte den Umgang mit Wireshark, "Packet Capture" (LANCOM) und "Port Mirroring" (Switch) lernen. Wireshark ist ein wichtiges Werkzeug für die "echten" Profis unter den Netzwerktechnikern. Zu Wireshark und Port Mirror gibt es genügend Youtube-Videos...

Zu Pa(c)ket Capturing siehe:
https://www.lancom-systems.de/docs/LCOS ... uring.html

Für die Darstellung von VLAN-Tags in Wireshark siehe bitte:
fragen-zur-lancom-systems-routern-und-g ... ml#p110962

Trockenübungen mit den Beispielen im Kapitel "Example capture file" unter:
https://wiki.wireshark.org/VLAN
durchführen.

Alles Einstiegs in das Thema "VLAN" bietet sich dieser Heise-Artikel an:
https://www.heise.de/ratgeber/VLAN-Virt ... 21621.html

Unmanaged Switches könnten sich an VLAN-Tags (tagged frames) verschlucken und dadurch Probleme verursachen.

Managed Switches bieten in der Regel ein Webinterface für die Konfiguration und Diagnose an. Und sind in der Regel VLAN-fähig. Meistens wird auch die Datenverkehrsaufzeichnung per "Port Mirroring" unterstützt. So ein Webinterface erlaubt dann auch den einfachen Lesezugriff auf den für die Netzwerkdiagnose wichtigen, empfangsseitigen CRC-Zähler der Ethernet-Datenpakete. Zum Thema "CRC-Zähler der Ethernet-Datenpakete" siehe auch:
fragen-zur-lancom-systems-routern-und-g ... ml#p113959

[schiffeg]

Hi Dr.Einstein,

anbei die beiden mit Pa(c)ket Capturing am 1793VA Eth3 aufgenommenen Traces:

HW: 1793VA -> unmanaged Gigibit PoE-Switch TP-Link -> 4Ge-LE

--1. File

1793VA-Trace_Eth3-LAN3_Eth4-LTE.zip

Eth3 = LAN3: DHCP-Server 192.168.43.41/.252 mit Option43; Eth4 = DSL1, selbe benutzerdefinierte MAC-Adr wie der WAN-Port der DigiBox)
Beide Ports am unmanaged Swich, an dem auch das 4Ge-LE hängt.
KEIN Internet über LTE; das 4Ge-LE beantwortet den DISCOVER mit einem OFFER, aber dann kommt kein REQUEST vom 1793VA

--2. File

1793VA-Trace_Eth3-LAN3_LTE-DigiBox.zip

1783VA Eth3 = LAN3: DHCP-Server 192.168.43.41/.252 mit Option43; 1793VA ist nur DHCP-Server
DigiBox Smart Eth4 = WAN LTE (nur den WAN-Anteil, KEIN DHCP-Server)
Beide Ports am unmanaged Switch, an dem auch das 4Ge-LE hängt.
Internet über LTE funktioniert; Trace zum Vergleich

Hast Du eine Idee, warum der 1793VA nicht den OFFER des 4Ge-LE beantwortet?

[Dr.Einstein]

Was sagt der DHCP Trace zum dem Offer 10.21.104.221? 2 Minuten Leasezeit klingen schon ziemlich wenig z.B.

[schiffeg]

Hi Dr.Einstein,

anbei der Screenshot eines neuen, längeren Traces

1793VA-mit-4Ge-LE_Trace.zip

[Dr.Einstein]

trace # dhcp im Lancom, nicht Wireshark.

[schiffeg]

Hi Dr.Einstein,

trace # dhcp im Lancom: Keine -Antwort auf den DISCOVER des Lancom

Trenne ich Eth4 (WAN LTE) des LANCOM vom Switch und verbinde Eth4 der DigiBox (Nur WAN), so dass das LTE-Modul online geht und trenne dann wieder die DibiBox Eth4 (WAN) vom Switch und verbinde Eth4 des Lancom wieder mit dem Switch, dann kommunizieren Lancom und 4Ge-Le (REQUEST und ACK, rebinding, usw.) und die Ineternetverbindung über LTE funktioniert

[Dr.Einstein]

Ich denke, ich kann dir bei dem Thema nicht weiterhelfen. Bei mir hat das immer auf Anhieb funktioniert, und das Debug-Ping-Pong über ein Forum mit geänderten MAC-Adressen etc hilft nicht wirklich weiter. Vllt kann dir wer anders helfen, der diese Lösung ebenfalls einsetzt.

[Jirka]

Hallo zusammen,

die Welt ist ja manchmal klein. Und wie der Zufall es wollte, hatte ich diesen Fall hier (also mit schiffeg, dem Threadstarter) vor einem Monat dann auch schon mal auf dem Tisch, wegen Zeitmangels dann aber auch nicht intensiv angehen können (alleine für die Einarbeitung und das Verständnis des Falls ist ja schon eine Stunde weg) und habe mir heute in einem gemeinsamen Telefonat noch mal die Traces angeschaut, die hier auch schon reingestellt wurden.

Vorweg, finde ich, muss man zum Verständnis auch mal sagen, dass es hier nicht um den einen LANCOM-Router mit einem bintec 4Ge-LE geht, sondern dass es halt eine mittlere zweistellige Zahl an Installationen gibt, die teils kompliziert oder aufwendig sind, und wo zukünftig ein LANCOM-Router hin soll, ein Ersatz der 4Ge-LE aber eben nicht nur mit dem Kauf anderer Geräte, z. B. von LANCOM, erledigt wäre, und selbst das wäre schon teuer. Die 4Ge-LE sollen halt vor Ort verbleiben und es gibt eben die Hoffnung, diese in Kombination mit LANCOM-Routern weiter betreiben zu können.

In den Traces zeigt sich meiner Ansicht nach folgendes Bild: Der LANCOM-Router schickt auf dem Ethernet-Port (DSL-1) ein DHCP Discover raus, wo innerhalb des Bootstrap Protocols das Bootp flags: 0x0000 (Unicast) gesetzt ist. Die bintec Digitalisierungsbox macht das nicht, sie schickt ein DHCP Discover raus, wo innerhalb des Bootstrap Protocols das Bootp flags: 0x8000, Broadcast flag (Broadcast) gesetzt ist. Mit einem DHCP-Discover, wo das Bootp flags: 0x0000 (Unicast) gesetzt ist, hat das 4Ge-LE offenbar ein Problem. Das zeigt sich darin, dass die Antwort des 4Ge-LE auf das DHCP-Discover ein DHCP-offer ist, was auf dem Ethernet wie folgt adressiert ist:
Ethernet II, Src: d2:7e:d9:28:05:08 (d2:7e:d9:28:05:08), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Richtig wäre aber:
Ethernet II, Src: d2:7e:d9:28:05:08 (d2:7e:d9:28:05:08), Dst: 02:a0:57:54:ad:a4 (02:a0:57:54:ad:a4)
Irgendwie, so scheint es jedenfalls, hat das 4Ge-LE ein Problem damit, das DHCP-Discover vom LANCOM richtig zu verarbeiten und die (DHCP-)Client-MAC-Adresse an der richtigen Stelle einzutragen. Sonst würde ja nicht die MAC-Adresse 00:00:00:00:00:00 da auftauchen. Irgendwas läuft da im 4Ge-LE schief. Klar, der Auslöser ist das Unicast-Flag, aber den Fehler macht das 4Ge-LE.
Interessant wird es, wenn man die Digitalisierungsbox "vorschickt" und - entsprechend auf die WAN-MAC-Adresse des LANCOM-Routers eingestellt - das DHCP-Discover abschicken lässt, dann kommt, wegen des Broadcast-Flags, eine ordnungsgemäße Antwort (an ff:ff:ff:ff:ff:ff auf Ethernet-Ebene). Wenn man nun wieder den LANCOM-Router einen DHCP-Discover (natürlich mit Unicast, ist ja nicht konfigurierbar) machen lässt, dann antwortet das 4Ge-LE korrekt. Warum? Ja weil es bereits ein DHCP-Lease in der DHCP-Tabelle des 4Ge-LE gibt, wo die (DHCP-)Client-MAC-Adresse des LANCOMs korrekt drin steht (aus der Adresszuweisung der Digitalisierungsbox mit eingestellter LANCOM-WAN-MAC-Adresse).

Warum das DHCP-Offer vom 4Ge-LE mit
Ethernet II, Src: d2:7e:d9:28:05:08 (d2:7e:d9:28:05:08), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
nicht im Trace auf DSL-1 zu sehen ist, sondern nur auf dem LAN-Interface, weiß ich allerdings auch nicht. Was bedeutet eine MAC-Adresse 00:00:00:00:00:00? Wo stellt ein Switch diese zu? Ich meine es ist ja kein Broadcast mit ff:ff:ff:ff:ff:ff.

Letztlich liegt aber ein falsches DHCP-Offer vom 4Ge-LE vor, was den LANCOM-Router auf WAN-Seite (DSL-1) nicht erreicht. Somit wird die Sache nicht funktional.

Viele Grüße
Jirka