Wireless LAN controller und ARP requests

[Nightwalker_z 10]

Hi zusammen,

ich hätte da mal eine Frage bezüglich Cisco WLAN Controller.

Bin im Moment ein bisschen am Spielen mit der 4400 Serie von Cisco. Mich verwundert etwas das Verhalten bezüglich ARP requests aus dem kabelgebundenen Netz.

 

Das Normalverhalten ist so:

- Der WLC kennt normalerweise alle IP Adressen der Assoziierten Clients.

- Wenn ein ARP Request für die IP Adresse eines Wireless Clients kommt, wird der Request vom Controller beantwortet.

Soweit so gut.... Jetzt aber zum Problem:

Was ist mit Clients, von denen der Controller nicht die IP Adresse kennt. Es soll ja auch Clients geben (meistens Non-Windows), die einfach die Klappe halten, wenn sie nichts gefragt werden. Angenommen man hat einen Client mit statischer IP, die der WLC nicht kennt - was dann?

Sprich der ARP request vom Kabelgebundenen Netz wird nicht vom Controller beantwortet, weil er nix weiß UND der Controller forwarded den Request nicht.

--> Keine Kommunikation mit dem Client.

 

Ich hab das einfach mal getestet mit nem Windows Client und deaktiviertem IP Protokoll in der Netzwerkumgebung. Wenn man auf den Controller schaut, sieht man nen assoziierten Client mit der IP Adresse "UNKNOWN".

Jetzt mal nen Ping von nem kabelgebundenen Client in das wireless Subnetz - kein ARP Broadcast in der Luft - nix....

Hab gehofft, dass der WLC den ARP broadcastet, wenn er nen Client hat, von dem er nicht die IP Adresse kennt (Analog zum "arp cache optional" Feature bei IOS APs).

 

Hat dieses Verhalten auch schon jemand festgestellt? Wisst ihr ob das normal ist und ob man was dagegen tun kann? Am WLC hab ich das "Forward Broadcast" Feature enabled, aber das gilt wohl nur für alle Broadcasts ausser nem ARP :-(

[Otaku19 33]

also wenn die IP grade am WLC nicht anliegt damm mpsste er doch erkennen das die IP in seinem Netz zu Hause ist und broadcasten wer denn diese IP hat ?

[Nightwalker_z 10]

also wenn die IP grade am WLC nicht anliegt damm mpsste er doch erkennen das die IP in seinem Netz zu Hause ist und broadcasten wer denn diese IP hat ?

 

Nope - macht er nicht.

Da der WLC ja weiss, welches VLAN welche IP-Netzadresse hat, da er ja selbst ne IP in jedem VLAN hat (dynamic Interface), müsste er das tun - macht er aber nicht.

 

Wie gesagt, hab das ganze getestet, indem ich nen Client an ner SSID assoziiert hab. Auf dem Windows Client habe ich das IP Protokoll deaktiviert.

Sprich der Cient schickt gar kein IP Paket raus - der WLC hat keine Chance die IP Adresse zu kennen. Damit simuliere ich nen stummen Client.

Der WLC zeigt den Client auch in der Assoziationsliste mit Status "UNKNOWN IP".

 

Jetzt kann ich von nem Wired Testclient eine beliebige (unbekannte) IP Adresse in dem Subnetz pingen. Der Router in dem Subnetz broadcastet dann nen ARP request für diese IP. Der WLC forwarded diesen ARP-request aber nicht.

Hab auf zwei Art und Weisen gecaptured:

1.) Auf dem Wireless Client direkt mit Wireshark.

2.) Mit ner Cisco Aironet Karte und Backtrack. Damit kann man wunderbar auf der Luftschnittstelle capturen.

 

Btw.: Natürlich habe ich eine unverschlüsselte SSID für den Test verwendet, da ich sonst ja die ARP Pakete nur verschlüsselt capturen kann.

 

Es will aber einfach nicht klappen :-((

 

Naja - hätte ja sein können, das jemand anders auch über das Problem gestolpert ist und ggf. nen besseren Workaround als ich hab.

(Mein Workaround wäre bis jetzt, nen statischen ARP Eintrag auf dem Router machen).

[Otaku19 33]

sollte denn ein "IP stummer" Client überhaupt auf einen solchen Request antworten ? Klar spielt das keine Rolle wenn der WLC schon garnix rausschickt, ist nur interessehalber.

[Nightwalker_z 10]

sollte denn ein "IP stummer" Client überhaupt auf einen solchen Request antworten ? Klar spielt das keine Rolle wenn der WLC schon garnix rausschickt, ist nur interessehalber.

 

Naja, um komplett IP stumme Clients gehts ja auch nicht. Das war nur zur Simulation.

Also ich hab schon öfter Clients gehabt, die ne statische IP haben --> kein DHCP und nach dem Einschalten einfach mal nix von sich geben. Die warten halt nur drauf, dass mal jemand die Kommunikation initiiert. Von dem her hat der WLC und der Router noch kein einziges IP Paket von dem Client gesehen. Und schon haben wir den Salat :-)

[blackbox 10]

Hallo,

 

meines Wissens nach, gehört es aber zum WireLess Anmelde Process, das man seine IP mit an das Gerät übergibt, an dem man sich anmeldet. Ich bezweifele sehr, das ein WiFi Gerät das nicht tun sollte. Ich habe div. WLC im EInsatz wo auch div. Arten von Handhelds (nicht mit Windows) laufen und die gehen alle ohne Prob. Habe hier noch kein Gerät gefunden, was daran scheitert.

 

Ich denke du solltest deinen Test verändern und ein Gerät suchen, was mit "eingeschaltetem" IP nix ins WiFi sendet.

[Nightwalker_z 10]

Hallo,

 

meines Wissens nach, gehört es aber zum WireLess Anmelde Process, das man seine IP mit an das Gerät übergibt, an dem man sich anmeldet. Ich bezweifele sehr, das ein WiFi Gerät das nicht tun sollte. Ich habe div. WLC im EInsatz wo auch div. Arten von Handhelds (nicht mit Windows) laufen und die gehen alle ohne Prob. Habe hier noch kein Gerät gefunden, was daran scheitert.

 

Das ist meines Wissens nicht richtig - sorry.

802.11 beschreibt wie Ethernet nur den Physical und den MAC Layer.

Der Vergleich ist wie, wenn ein Ethernet HUB, die IPs der angeschlossenen Client wissen muss.

Bei einem Association Request und Response werden sicher keine IP Adressen übertragen. Er Client überträgt sog. fixed und tagged (variable) Parameter

Dazu gehören u.A. Capability checks, SSID, Supported Data Rates und noch optional Vendor Specific Stuff...

 

Bin davon überzeugt, dass mein Aufbau richtig ist.

Anbei nochmal ein Screenshot von nem Capture, der nen Association process zeigt --> Keine IPs.

[blackbox 10]

Es macht aus meiner sich mehr Sinn ein Wireless Gerät zu suchen was sich nicht meldet, anstatt die IP Protokoll zu deaktivieren. Den ich denke da werden wir nicht fündig werden. Den ein Protokoll abzuschalten ist was anderes als ein aktiviertes Protokoll zu haben was nichts meldet.

[Nightwalker_z 10]

Es macht aus meiner sich mehr Sinn ein Wireless Gerät zu suchen was sich nicht meldet, anstatt die IP Protokoll zu deaktivieren. Den ich denke da werden wir nicht fündig werden. Den ein Protokoll abzuschalten ist was anderes als ein aktiviertes Protokoll zu haben was nichts meldet.

 

Es geht ja nicht um das Gerät. Es geht ja nur darum, dass der Controller eine unvollständige Information Base hat. Sprich, dass er nen Assoziierten Client hat, von dem er nicht die IP Adresse kennt. Meiner Meinung ist das ziemlich egal wie man das erreicht. Der Controller weiss ja nicht, ob das IP Protokoll von dem Client deaktiviert ist, oder ob es ein "stummer" Client ist.

Nach dieser Theorie (Hoffnung) und wenn man das "ARP Cache optional" von IOS APs kennt, sollte der WLC dann nen ARP request auf die Luftschnittstelle broadcasten.

 

Dasselbe machen ja auch IOS AP's mit dem ARP cache feature. Wenn man den ARP cache ohne optional einschaltet, dann beantwortet der IOS AP alle ARP requests - Clients von denen die IP unbekannt ist, haben schlicht und ergreifend Pech gehabt. Deshalb gibt es das ARP cache optional Feature. Der AP beantwortet nur die ARP request von bekannten Clients - unbekannte IP's werden auf die Luftschnittstelle gebroadcastet.

 

Jetzt stellt sich eben für mich die Frage, wie oder ob es das Pendant zum ARP cache optional feature für den WLC gibt.