Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

dot11 associations table, client associated with 0.0.0.0

I'm having an issue where wireless client association seam to fail to get IP address, but acctually don't...

MAC Address    IP address      Device        Name            Parent         State    

0016.eaae.c896 0.0.0.0         unknown       -               self           EAP-Assoc

001f.e178.c6d8 192.168.27.192  unknown       -               self           EAP-Assoc

This happens only "sometimes", especially when the clients (laptops) wake up from sleep mode.

Although the association shows IP 0.0.0.0, the state is "EAP-Assoc" and I can confirm that the client passed RADIUS authentication, received IP from DHCP and can ping the gateway.

The wireless network is made up by autonomous/standalone access-points (Cisco aironet 1100, 1130, 1200, 1040).

Network access is PEAP, WPA/AES, dot1x, multiple Vlans...

All access-points have an access-list at the radio IN that is dropping all IP broadcasts.

When I remove the ACL, everything appear to be fine (at least all the times that I checked), but when the ACL is active the issue doesn't always come up.

I must understand what is going on because this ACL (although it's not very common) has proven it's value by saving 30-40% CPU usage on access-points...

Does anyone know how the "dot11 associations" table is built??

Maybe some tips on how to troubleshoot the issue.

thanks in advance

11 REPLIES
New Member

dot11 associations table, client associated with 0.0.0.0

One more thing I've noticed, it happens only when clients are on Power Save Mode...

New Member

dot11 associations table, client associated with 0.0.0.0

this is the ACL:

interface Dot11Radio0.618

encapsulation dot1Q 618

ip access-group trafficMGMT_In in

.....

!

ip access-list extended trafficMGMT_In

permit udp any eq bootpc any eq bootps

deny   ip any host 255.255.255.255

deny   ip any host 192.168.63.255

deny   ip 192.168.56.0 0.0.7.255 192.168.56.0 0.0.7.255

permit ip 192.168.56.0 0.0.7.255 any

deny   ip any any

!

after some testing, the issue is gone once I remove the deny "ip any host 192.168.63.255" rule.

A broadcast to the specific network..??

Wouldn't it make more sence if it was the "deny   ip any host 255.255.255.255" rule ???

Can anywone please explain to me how the access-points build the association table...

thanks

Re: dot11 associations table, client associated with 0.0.0.0

Hi,

Hi,

I would say that the reason this appears is because when a client comes from sleep mode it wakes up assuming it is still connected to the wireless wlan and reserving it is ip address.

I think you will see same issue if you are using static ip (please test).

I would also say if you disconnect the client before it goes to sleep mode it will not then show the issue (plz try disconnect from wireless then let a laptop sleeps then wake it up and test)

HTH

Amjad

Sent from Cisco Technical Support iPad App

Rating useful replies is more useful than saying "Thank you"
New Member

dot11 associations table, client associated with 0.0.0.0

Hi Amjad,

I tested with static IP and 2 diferent machines (Macbook Pro with Lion OS; Windows 7 machine).

Using static IP I get diferent results:

1) With Macbook I get the result you would expect (dot11 association showing 0.0.0.0)

2) With windows machine the dot11 association shows the new IP (so aperantly no issue)

Until now I have been testing with Macbook only because most cumplaints come from those users.

Could this be a Lion issue??

Still, what I would like to know is witch kind of packets the access-point uses to build the table. I can't seem to find any document describing that process...

thanks

New Member

dot11 associations table, client associated with 0.0.0.0

Rodrigo,

can you tell me if the power management of the NIC is disabled?

#DS

New Member

dot11 associations table, client associated with 0.0.0.0

Hi David,

(check my answer above...)

I can tell you that the windows machine the power management of the NIC is enabled.

As for the Macbook, I don't know how to check... I will say yes because the access-point shows the following:

AP-ap03#sh dot11 associations 28cf.dae0.3574

Address           : 28cf.dae0.3574     Name             : NONE

IP Address        : 0.0.0.0     Interface        : Dot11Radio 0

.......

Power-save        : On                Last Activity    : 0 seconds ago

Apsd DE AC(s)     : NONE

thanks

Re: dot11 associations table, client associated with 0.0.0.0

If you only notice this on mac devices it is possible it is related to information element (IE) fields in some 802.11 frames.

Check adapter on macs, is it ccx compliant?

Check also arp table on the AP, does it show correct mac/ip pairs for mac devices?

Sent from Cisco Technical Support iPad App

Rating useful replies is more useful than saying "Thank you"
New Member

Re: dot11 associations table, client associated with 0.0.0.0

Hi Amjad,

I'm not sure it only happens on Mac devices...What I'm sure of is that it happens more frequently on those devices.

I checked the mac and in fact it is not ccx compliant:

AP-ap03#sh dot11 associations 28cf.dae0.3574

Address           : 28cf.dae0.3574     Name             : NONE

IP Address        : 0.0.0.0     Interface        : Dot11Radio 0

Device            : unknown            Software Version : NONE

CCX Version       : NONE               Client MFP       : Off

I thought this would only be an issue if cisco aironet extensions where activated (which are turned off).

Can you share a link where I can read more about the information element and how the AP deals with it?

Also, the AP is on a different vlan than the client so the ARP table doesn't show the client ARP entry. I can tell you that, althoug the association table shows 0.0.0.0, if I turn off arp cache the client has network access.

The only issue here seams to be with the association table only.

Thanks

Re: dot11 associations table, client associated with 0.0.0.0

As an answer to your early quetsions (that I don't know why we did not answer it yet):

Assoc table is mainly built from information in association frames.

Assoc frames have no idea about IP addresses so how the APs know the IP? Not from assoc frames of course.

Each vendor may have different way to know the IP (they can look into the header of the IP traffic of that special client or they an look into dhcp communication).

summarizing the issue so far:

- The issue happens ONLY with the ACL in place.

- It does not happen with all clients.

- It happens ONLY when the clients in power save mode.

- It happens with same clients if they use static ip address even if they are not in power save mode (please confirm or amend this sentence to be more accurate).

Why power save mode do not show the IP? - > answering this quetion almost solves the problem.

what is common among the problematic clients? - > need to know this in order to isolate further.

Is it AP hardware/software related? -> helps to isolate further.

I said that it could possibly be related to information elements but not necessarily.

There are information element that transfer Power Save capability between clietns and the AP. I have no idea though how those can be related.

More information about information elements can be found in the IEEE standard downloadable from here:

http://standards.ieee.org/getieee802/download/802.11-2007.pdf

go to section :

7.3.2 Information elements

in page 99.

I tried to read about power save and tried to link that with our issue with no hope.

It could possibly a bug or so that when PS is used the AP behaves differently.

HTH

Amjad

Rating useful replies is more useful than saying "Thank you"
Bronze

Re: dot11 associations table, client associated with 0.0.0.0

Hi Rodrigo,

I feel your pain and frustration. I have experienced similar problems with MACs authenticating but not passing static IP address info, hence can't get on the network even though L2 authentication has passed. This I discovered through Debug client Mac address command. Modern MACs though do not have that problem. Luckily for me, Iwhen such problems arise, I pass it over to the Desktop support team. Usually, the problem is solved by upgrading the Service Packs of the MACs. Could you investigate if the Service Pack on the MACs could be upgraded.

Also note that enabling CCX does not affect the MACs connection even though they do not support it. I have some MACs working OK even though CCX is enabled.

New Member

dot11 associations table, client associated with 0.0.0.0

Amjad,

thank you for your help. Sorry I took so long to reply but I was out of office for a few days.

I followed your pointer, read about the technologies, analyzed the configs, captured traffic...and did some more testing.

I think it has something to do with Netbios packets!?!?!

I tested a different ACL (150 represents the ACL posted above):

....

access-list 150 deny   ip any host 192.168.63.255

....

....

access-list 151 permit udp any eq netbios-ns host 192.168.63.255 eq netbios-ns

access-list 151 deny   ip any host 192.168.63.255

....

The issue reveals only when I use ACL 150. With this ACL I can't even use static IP on Macbook (but I can on Windows).

So here is a summary:

- Windows clients sometimes get 0.0.0.0 but I'm not sure if it's the same issue, so I'll focus on Macbook

- The issue happens frequently with Macbook

- It happens only using ACL 150 (dropping all broadcast, except DHCP)

- On Macbook, using ACL 150, I can't use static IP

- Allowing Netbios broadcast on port 137 (ACL 151) seams to solve all issues.

- At this point I don't think it has something to do with Power Save

Allowing Netbios traffic (port 137) seems to solve the issue but need to learn more about it to be sure if I want to permit or deny .

Why is the association table built differently for different vendors??

Does this make sense?

thanks you all for your help

4473
Views
14
Helpful
11
Replies
CreatePlease to create content