L-322agn Rev.E: LAN-Bridge + IP-Router Problem

[max.secure]

Hallo zusammen,

bei einem Accesspoint:

LANCOM L-322agn dual Wireless
HW Release: E 2012-10-17 MOD E0

mit den beiden Firmware-Versionen:

FW Ver. 8.62.0086RU5 / 07.11.2012
FW Ver. 8.80.0157RU1 / 16.04.2013

tritt reproduzierbar ein Problem mit dem IP-Router auf. Meine Vorgehensweise:

Zuerst resettet man den AP. Dann wird dem AP per DHCP eine IP aus dem 172.16er Netz (255.255.255.0) zugewiesen. Alle relevanten Bridge-Einstellungen werden via WEB-Interface geprüft, ohne jedoch etwas an der Konfiguration zu verändern, der Assistent wird abgebrochen:

Schnittstellen -> LAN -> LAN-Brigde-Einstellungen -> [X] Verbindung über eine Bridge herstellen
Schnittstellen -> LAN -> LAN-Brigde-Einstellungen -> Port-Tabelle -> LAN-1 & LAN-2 -> Bridge Gruppe: BRG-1
TCP/IP -> Allgemein -> INTRANET -> Schnittstelle: BRG-1
IP-Router -> Allgemein -> [_] Pakete von internen Diensten über den Router senden
(optional bei IP-Router -> Routing -> Routing-Tabelle alle Einträge löschen)

Von einem Konfigurationsserver aus einem anderen Netz (172.19.x.x / 255.255.255.0) wird der AP per LANconfig konfiguriert ... 46 Sekunden später erscheint das Konfigurationsfenster.

Ein Trace des IP-Routers sieht dann so aus:

Connection No.: 002 (LAN)

root@:/
> trace # ip-router
IP-Router ON

root@:/
>
[IP-Router] 2013/07/17 13:11:48,198
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 172.16.x.x, SrcIP: 172.16.x.y, Len: 56, DSCP/TOS: 0x00
Prot.: ICMP (1), fragmentation needed, new MTU is 1400
embedded IP header:
DstIP: 172.19.z.z, SrcIP: 172.16.x.x, Len: 1500, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 2821, SrcPort: 443

Filter (Port)
[IP-Router] 2013/07/17 13:11:51,199
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 172.16.x.x, SrcIP: 172.16.x.y, Len: 56, DSCP/TOS: 0x00
Prot.: ICMP (1), fragmentation needed, new MTU is 1400
embedded IP header:
DstIP: 172.19.z.z, SrcIP: 172.16.x.x, Len: 1500, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 2821, SrcPort: 443

Filter (Port)

[..]

Filter (Port)

[IP-Router] 2013/07/17 13:12:01,342
IP-Router Rx (intern, RtgTag: 0):
DstIP: 172.16.x.y, SrcIP: 172.16.x.x, Len: 79, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 53, SrcPort: 30032
Route: BRG-1 Tx (INTRANET):

[IP-Router] 2013/07/17 13:12:10,320
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 172.16.x.x, SrcIP: 172.16.x.y, Len: 56, DSCP/TOS: 0x00
Prot.: ICMP (1), fragmentation needed, new MTU is 1400
embedded IP header:
DstIP: 172.19.z.z, SrcIP: 172.16.x.x, Len: 1500, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 2822, SrcPort: 443

Leider habe ich keine Idee, wieso sich der IP-Router angesprochen fühlt. Der Netzwerkverkehr müsste doch normalerweise über die LAN-Bridge laufen, richtig? Nur wenn ich den IP-Router des APs über das WEB-Interface komplett deaktiviere, läuft der Zugriff vom Konfigurationsserver so schnell wie bei allen anderen APs (Revision B - D) auch. Und ein anderer AP Revision E steht mir nicht zur Verfügung.

Noch etwas: Kann ich im WEB-Interface irgendwo die MTU für das LAN konfigurieren? Das wäre evtl. hilfreich um das Problem zu umgehen.

Danke schonmal im voraus für eure Antworten.



MfG Max

[backslash]

Hi max.secure

der Router fühlt sich angesprochen, weil der Client ihm das Paket explizit geschickt hat - und der hat es wohl deshalb gemacht, weil die Ziel-IP des Pakets die 172.16.z.z ist, was außerhalb den 172.16.x.x-Netzes ist (wenn ich mal davon ausgehe, daß du das z nach der 16 explizit deshalb so eingetragen hast).

Adressen auß dem privaten Adreßraum kannst du hier auch ohne Verschleierung posten, denn aus ihnen ist nichts abzuleiten... Die Verschleierung erschwert nur die Fehleranalyse

Gruß
Backslash

[max.secure]

Hallo backslash,

danke für die schnelle Antwort. Leider ist mir nicht klar welchen Client du meinst. Bridged ein Accesspoint in der Voreinstellung nicht alle Pakete an sein per DHCP zugewiesenes Gateway im LAN, wobei den ganze Rest (wie DSL, VLAN, VPN usw.) keine Rolle spielen sollte?


Hier der unverschleierte Trace:

Connection No.: 002 (LAN)

root@:/
> trace # ip-router
IP-Router ON

root@:/
>
[IP-Router] 2013/07/17 13:11:48,198
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 172.16.1.33, SrcIP: 172.16.1.1, Len: 56, DSCP/TOS: 0x00
Prot.: ICMP (1), fragmentation needed, new MTU is 1400
embedded IP header:
DstIP: 172.19.1.10, SrcIP: 172.16.1.33, Len: 1500, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 2821, SrcPort: 443

Filter (Port)
[IP-Router] 2013/07/17 13:11:51,199
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 172.16.1.33, SrcIP: 172.16.1.1, Len: 56, DSCP/TOS: 0x00
Prot.: ICMP (1), fragmentation needed, new MTU is 1400
embedded IP header:
DstIP: 172.19.1.10, SrcIP: 172.16.1.33, Len: 1500, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 2821, SrcPort: 443

Filter (Port)

[..]

Filter (Port)

[IP-Router] 2013/07/17 13:12:01,342
IP-Router Rx (intern, RtgTag: 0):
DstIP: 172.16.1.255, SrcIP: 172.16.1.33, Len: 79, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 53, SrcPort: 30032
Route: BRG-1 Tx (INTRANET):

[IP-Router] 2013/07/17 13:12:10,320
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 172.16.1.33, SrcIP: 172.16.1.1, Len: 56, DSCP/TOS: 0x00
Prot.: ICMP (1), fragmentation needed, new MTU is 1400
embedded IP header:
DstIP: 172.19.1.10, SrcIP: 172.16.1.33, Len: 1500, DSCP/TOS: 0x00
Prot.: TCP (6), DstPort: 2822, SrcPort: 443

MfG Max

[backslash]

Hi max.secure

Bridged ein Accesspoint in der Voreinstellung nicht alle Pakete an sein per DHCP zugewiesenes Gateway im LAN, wobei den ganze Rest (wie DSL, VLAN, VPN usw.) keine Rolle spielen sollte?

nein, ein AP bridged erstmal nur zwischen zwei LANs, irgendwelche Gateways interressieren einen AP nicht, da er nur auf dem Layer-2 arbeitet...
LANCOM-APs haben zusätzlich einen Router (=> Layer 3) eingebaut und wenn du auf dem AP den DHCP-Server anhast, dann weist sich der AP allen Clients als Gateway zu... Die schicken dann alle Pakete, die nicht für das lokale Netz (172.16.1.x) bestimmt sind explizit an den AP, damit er sie weiterroutet.

Leider ist mir nicht klar welchen Client du meinst.

In dem Falle des neuen Traces meine ich den Client mit der IP-Adresse 172.16.1.33, denn der will ein Paket an die IP-Adresse 172.19.1.10 schicken und ist der Meinung dein AP wäre sein Gateway. Der AP muß auch eine Route zu dem Netz haben, denn sonst könnte er keine MTU für die Strecke bestimmen (hier 1400) und somit auch keine "fragmentation needed" Fehlermeldung erzeugen...

Gruß
Backslash

[max.secure]

Hallo Backslash,

entschuldige, ich glaube ich hätte mich klarer ausdrücken sollen.

172.16.1.33 => LANCOM-AP L-322agn Rev.E
172.16.1.1 => Router des 172.16.1er Netzes, der dem AP die 172.16.1.33 zuweist
172.19.1.10 => Konfigurationsserver an einem anderen Standort

1. Zurücksetzen des APs auf Werkseinstellungen
2. Verbindung mit Putty zum AP aufbauen (&Eingabe: Trace # IP-Router)
3. vom Konfigurationsserver aus mit LANconfig auf den AP zugreifen


Heraus kommt dabei der gezeigte Trace. Der Trace sieht übrigens genauso aus wenn ich versuche,
mich von 172.19.1.10 per HTTP(S) am AP 172.16.1.33 anzumelden. Das Anmeldefenster braucht
dabei mehr als 30 Sekunden zum Laden bis die LANCOM-Grafiken angezeigt werden.

Falls das wichtig ist: wenn ich dem IP-Router des APs eine Route zum Konfigurationsserver gebe,
sieht der Trace trotzdem nicht anders aus und die Konfiguration des APs vom Server aus dem anderen
Netz dauert ebenfalls unerträglich lange.

Deswegen meine Verwunderung, ob dieses Verhalten für Revision E der L-322agn Serie normal ist. (Die
Firmware spielt hierbei wohl keine Rolle.)

Revision B bis D der L-322agn Serie arbeiten in dieser Umgebung sehr zügig und zuverlässig, so wie ich
das von LANCOM gewohnt bin.

Ein Trace von den älteren Revisionen sieht sehr übersichtlich aus, da sich der IP-Router der APs nicht
zu Wort meldet, während der Konfigurationsserver auf die Geräte zugreift.



MfG Max

[max.secure]

Hallo zusammen,

die letzten Tage hatte ich etwas Zeit mir das Problem genauer anzuschauen. Beim Datenabruf mittels LANconfig geschieht
laut mitgeschnittenem Netzwerkverkehr folgendes:

172.19.1.10 (Server) sendet über 172.16.1.1 (Router) Daten an 172.16.1.33 (AP)
172.16.1.33 antwortet mit 1500 Byte-Paket an 172.16.1.1
172.16.1.1 meldet "Destination unreachable" und eine kleinere MTU an 172.16.1.33
172.16.1.33 antwortet mit 1500 Byte-Paket an 172.16.1.1
172.16.1.1 meldet "Destination unreachable" und eine kleinere MTU an 172.16.1.33
172.16.1.33 antwortet mit 1500 Byte-Paket an 172.16.1.1
172.16.1.1 meldet "Destination unreachable" und eine kleinere MTU an 172.16.1.33

Irgendwann fällt 172.16.1.33 in einen Kompatibilitätsmodus o.ä. zurück und sendet Pakete mit etwa der halben Größe.
Bei der nächsten Anfrage, bzw. beim Aufruf einer neuen Webseite des HTTP(S)-Interfaces, geht das Spiel von vorne los.

Ich habe schon alles versucht um den LANCOM-AP dazu zu bewegen, auf ICMP-Pakete, die eine neue MTU enthalten
richtig zu reagieren. Leider ohne Erfolg. Habt ihr einen Tipp für mich, was ich noch unternehmen kann oder ist der AP
möglicherweise defekt?

MfG Max

[max.secure]

Hallo,

heute konnte ich drei weitere L-322agn Revision E überprüfen. Das oben geschilderte Verhalten trat auf jedem Accesspoint auf. Scheint ein Bug in LCOS >= v8.60 bzw. in den darin enthaltenen Treibern zu sein. Oder ist das ein Feature?



MfG Max