Version 5.02 funktioniert nicht mit P2P 5Ghz Verbindung

alf29 · Beitrag von **alf29** » 21 Sep 2005, 08:11

Moin,

der Alive-Test hat niemals zu den offiziell dokumentierten Features
gehört. Solche Sachen wandern schon mal im Menübaum oder
verchwinden auch ganz oder werden durch allgemeinere Lösungen
ersetzt.

Das Problem mit der Doku ist bekannt, aber im Moment sind einfach
keine Resourcen vorhanden, um das aufzuarbeiten. Die Leute sind
voll beschäftigt, die Features einzubauen, nach denen die Kunden
schreien, und soll man eine Firmware zurückhalten, weil das
Referenzmanual noch nicht angepaßt ist?

Gruß Alfred

SeG · Beitrag von **SeG** » 21 Sep 2005, 17:25

prinzipiell nicht. es gibt aber auch zahlreiche probleme die schon seit mehreren versionen auftreten die schlichtweg ignoriert werden. z.b. das DHCPACK ab version 4.02 nicht mehr durchgeleitet wird und damit dhcp forwarding an unseren ap's nicht mehr geht (mit ab 4.02 mein ich, das es bei neueren als 4.02 nicht mehr geht)
allerdings kann ich auch bei den lancom 4.14 firmware basierten geräte auch nicht mehr zu der firmware downgraden, wo sich die katze in den schwanz beißt, weil wir nur noch diese geräte auf dem tisch haben.
ich bin generell immer für schnelle fixes. aber der aufbau eines manuals für das expertensetup wäre wirklich mal notwendig. es muß ja nicht von heute auf morgen geschehen, aber das problem wird ja nun schon seit sehr langer zeit verschleppt

alf29 · Beitrag von **alf29** » 21 Sep 2005, 18:04

prinzipiell nicht. es gibt aber auch zahlreiche probleme die schon seit mehreren versionen auftreten die schlichtweg ignoriert werden. z.b. das DHCPACK ab version 4.02 nicht mehr durchgeleitet wird und damit dhcp forwarding an unseren ap's nicht mehr geht (mit ab 4.02 mein ich, das es bei neueren als 4.02 nicht mehr geht)
allerdings kann ich auch bei den lancom 4.14 firmware basierten geräte auch nicht mehr zu der firmware downgraden, wo sich die katze in den schwanz beißt, weil wir nur noch diese geräte auf dem tisch haben.

Derlei ist mir nicht bekannt. Hast Du den Bug irgendwo
gemeldet?

Gruß Alfred

SeG · Beitrag von **SeG** » 21 Sep 2005, 18:20

hatte ich schon mal vor ein paar monaten hier im forum verkündet. es wurde aber schlichtweg gesagt "nicht reproduzierbar"
ich habe es einmal mit einem orinocco ap alter sorte zwangsgetestet als ich beim upgrade reingefallen bin
und jetzt habe ich das problem auch mit dem normalen linux dhcp-fwd was ich in meine eigene firmware eingebaut habe.
mit 4.02 alles kein problem, dannach nur noch ärger.
bis zum betreffenden ap, kommen hierbei ausschließlich lancom 5 ghz p2p strecken zum einsatz. alle l54ag basierend. an sonsten bis auf switches keine weiteren aktiven elemente bis zum dhcp server

alf29 · Beitrag von **alf29** » 21 Sep 2005, 18:59

hatte ich schon mal vor ein paar monaten hier im forum verkündet. es wurde aber schlichtweg gesagt "nicht reproduzierbar"

Achso die Geschichte. Da habe ich 'nicht reproduzierbar'
gesagt, weil's eben genau so war. DHCP-Client war
ein Linux.

Gruß Alfred

Beitrag von **LoUiS** » 21 Sep 2005, 19:59

hatte ich schon mal vor ein paar monaten hier im forum verkündet. es wurde aber schlichtweg gesagt "nicht reproduzierbar"

Bist schon mal auf die Idee gekommen sowas ueber die "normalen" Support Wege zu kommunizieren und einfach mal dem Support zu melden und nicht ausschliesslich in das INOFFIZIELLE LANCOM Forum zu posten?

Ciao
LoUiS

alf29 · Beitrag von **alf29** » 21 Sep 2005, 23:04

Moin,

cool bleiben, Leute. Tatsache ist, irgendwo bei der 4.1x hat sich im DHCP-Bereich etwas
geändert. Das LANCOM tauscht in DHCP-Pakete, die es selber verschickt, das CHAdr-
Feld gegen seine eigene WLAN-MAC aus. Das betrifft aber nur Pakete vom BOOTPC-
an den BOOTPS-Port, also wenn das LANCOM selber DHCP-Client ist. Es betrifft keine
Pakete, die das LANCOM als DHCP-Relay verschickt (die gehen von BOOTPS an BOOTPS),
und auch keine transparent durchgebridgeten Pakete.

Ich hatte zum Testen folgenden Aufbau gemacht:

Client ----- AP1 <WLAN> AP2 -----DHCP-Server

AP1 als Relais an den DHCP-Server, AP2 DHCP aus. AP2 darf natürlich
nicht bridgen...ist das die Situation, um die's geht?

Gruß Alfred

SeG · Beitrag von **SeG** » 22 Sep 2005, 11:09

Hier gehts um die situation. DHCP Server->L54AGP2P->L54AGP2P->APWRT54GS(dhcpfwd)->client

die L54AG sind nicht im bridge modus sondern verwenden geroutete netze. mehr kann ich eigentlich nicht sagen. es ist theoretisch möglich das es bei neueren firmwares vielleicht eine neue einstellung gibt die das problem gehebt, ich konnte sie aber trotz zahlreicher experimente nicht finden. jedenfalls arbeiten die Lancoms hier dhcp technisch passiv. dhcp ist also deaktiviert

alf29 · Beitrag von **alf29** » 22 Sep 2005, 14:48

Moin,

OK. Kannst Du mal die DHCP-Pakete sniffen, die zwischen
dem DHCP-Server und dem linken AP sowie zwischen dem
rechten L-54 und dem Forwarder laufen?

Gruß Alfred

SeG · Beitrag von **SeG** » 22 Sep 2005, 16:42

das wird schwierig. der zentrale server verwaltet knapp 50 ap's und 1000 user. dementsprechend ist auch das datenaufkommen

vom dhcp logging siehts so aus. firmware versionen größte 4.02 bringen das und kriegen keine ip
Sep 22 16:38:06 sonne dhcpd: DHCPOFFER on 10.20.1.253 to 00:0b:6b:34:81:19 (Test WLAN) via 10.20.1.1
Sep 22 16:38:07 sonne dhcpd: DHCPDISCOVER from 00:0b:6b:34:ea:de (HEYNAHTSSTR8) via 10.21.1.1
Sep 22 16:38:07 sonne dhcpd: DHCPOFFER on 10.21.1.249 to 00:0b:6b:34:ea:de (HEYNAHTSSTR8) via 10.21.1.1
Sep 22 16:38:09 sonne dhcpd: DHCPDISCOVER from 00:0b:6b:34:ea:de (HEYNAHTSSTR8) via 10.21.1.1
Sep 22 16:38:09 sonne dhcpd: DHCPOFFER on 10.21.1.249 to 00:0b:6b:34:ea:de (HEYNAHTSSTR8) via 10.21.1.1
Sep 22 16:38:11 sonne dhcpd: DHCPDISCOVER from 00:0b:6b:34:ea:de (HEYNAHTSSTR8) via 10.21.1.1
Sep 22 16:38:11 sonne dhcpd: DHCPOFFER on 10.21.1.249 to 00:0b:6b:34:ea:de (HEYNAHTSSTR8) via 10.21.1.1
Sep 22 16:38:14 sonne dhcpd: DHCPDISCOVER from 00:0b:6b:34:81:19 (Test WLAN) via 10.20.1.1
Sep 22 16:38:14 sonne dhcpd: DHCPOFFER on 10.20.1.253 to 00:0b:6b:34:81:19 (Test WLAN) via 10.20.1.1

firmware versionen 4.02 bringen das ganze wie folgt

Sep 22 10:29:26 sonne dhcpd: DHCPDISCOVER from 00:12:17:d4:5a:5b via 10.22.1.1
Sep 22 10:29:27 sonne dhcpd: DHCPOFFER on 10.22.1.254 to 00:12:17:d4:5a:5b via 10.22.1.1
Sep 22 10:29:27 sonne dhcpd: DHCPREQUEST for 10.22.1.254 (192.168.0.1) from 00:12:17:d4:5a:5b via 10.22.1.1
Sep 22 10:29:27 sonne dhcpd: DHCPACK on 10.22.1.254 to 00:12:17:d4:5a:5b via 10.22.1.1

SeG · Beitrag von **SeG** » 22 Sep 2005, 16:44

das heißt im prinzip das die neuen 4.14 basierenden geräte für uns ein problem darstellen

alf29 · Beitrag von **alf29** » 22 Sep 2005, 18:38

Moin,

das hast Du jetzt oft genug gesagt, aber nur mit diesen Logs komme ich
nicht wirklich weiter...mir würde auch schon fürs erste reichen, wie die DHCP-
Pakete aussehen, wenn sie aus der Linksys-Buchse wieder herauskommen
(das ist ja nicht die Zentralseite...). Sofern sie dort mit Quellport BOOTPC und
Zielport BOOTPS herauskommen, ist klar was passiert, das wäre dann aber ein
Fehler der Linksys-Büchse, denn dann sind das keine korekten DHCP-Relay-
Pakete, denn die müßten von BOOTPS an BOOTPS gehen...

Gruß Alfred

REPTILE · Beitrag von **REPTILE** » 22 Sep 2005, 19:38

also so ähnliches zenario haben wir auch DHCP Server(linux) ---- L54ag ~~ L54ag -- L54g ~~ Client

funz alles prima benutzen neuste firmware.....

SeG · Beitrag von **SeG** » 22 Sep 2005, 20:48

mit nem lancom L54g geht dhcp forward bei uns auch nicht. selbes problem DHCPACK wird blockiert. erst nach downgrade der firmware gehts.
ich werde mich jetzt hinsetzen und versuchen mit nem notebook die packete einzufangen

SeG · Beitrag von **SeG** » 22 Sep 2005, 20:54

hier der ausschnitt eines funktionierenden dhcp requests an einem funktionierenden auf basis 4.02 firmware
00:01:23.013983 10.33.8.2.bootpc > 192-168-0-1.transfer-000.intranet.fbn-dd.de.bootps: hops:1 xid:0x9585930e [|bootp] (DF)
00:01:23.028814 192-168-0-1.transfer-000.intranet.fbn-dd.de.bootps > 10.33.9.1.bootps: (reply) hops:1 xid:0x9585930e flags:0x8000 Y:10.33.9.253 S:192-168-0-1.transfer-000.intranet.fbn-dd.de [|bootp] (DF)
00:01:23.056354 10.33.9.3.53405 > 10.33.8.1.telnet: . ack 12419 win 250 (DF)
00:01:23.056855 10.33.8.1.telnet > 10.33.9.3.53405: P 12419:12589(170) ack 0 win 5840 (DF)
00:01:23.260436 10.33.9.3.53405 > 10.33.8.1.telnet: . ack 12589 win 255 (DF)
00:01:23.260914 10.33.8.1.telnet > 10.33.9.3.53405: P 12589:12714(125) ack 0 win 5840 (DF)
00:01:23.453814 10.33.9.3.53405 > 10.33.8.1.telnet: . ack 12714 win 255 (DF)
00:01:23.520372 192-168-0-2.transfer-000.intranet.fbn-dd.de > 10.33.9.3: gre [KSv1] ID:cd5c S:18282 ppp: Echo-Req(182), Magic-Num=37b7dea6 (DF)
00:01:25.014992 10.33.9.15.3374 > 192-168-0-1.transfer-000.intranet.fbn-dd.de.domain: 63066+[|domain] (DF)
00:01:25.020582 192-168-0-1.transfer-000.intranet.fbn-dd.de.domain > 10.33.9.15.3374: 63066[|domain] (DF)
00:01:25.049045 10.33.9.15.4605 > pop.kundenserver.de.pop3: S 4256605567:4256605567(0) win 5840 <mss 1460,sackOK,timestamp 96076263[|tcp]> (DF)
00:01:25.103560 10.33.9.253.1380 > 192-168-0-1.transfer-000.intranet.fbn-dd.de.domain: 8682+[|domain]
00:01:25.104859 10.33.8.2.bootpc > 192-168-0-1.transfer-000.intranet.fbn-dd.de.bootps: hops:1 xid:0x8dfcd040 C:10.33.9.253 [|bootp] (DF)