-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan DeKok wrote:

My $0.02 is that the NAS is broken (big surprise). It's likely doing DHCP snooping to determine session IP address.

Interesting. I suppose this would be the least of several evils, if they can't be guaranteed to be in the same Ethernet broadcast domain as the supplicant stations. Is there a better way?

Remember: The NAS sends accounting packets whenever it wants. The contents of the accounting packets are determined SOLELY by the NAS.

I hadn't consciously recognized it was that arbitrary; makes sense, though.

The clients MAY be requesting those IPs. e.g. The user takes a laptop home, it gets a private IP. When he shows back up at work, the OS may try to first renew that IP... and when it gets no response, ask for a different IP.

Yeah, that was one of my early theories, when I started noticing this (and before realizing the preponderance of *ahem* "unofficial" networks).

So the big question is: what NAS is causing the problem?

Cisco LWAPP controllers.

The detail module doesn't care about the contents of the packet. The SQL module does. If it doesn't like the contents, it won't log it.

Important safety tip: thanks, Egon. ;-)

Maybe suppress multiple accounting starts in the same second?

This sounds promising: How would you recommend doing it? I'm still new to the manipulation of RADIUS conversations, so hints are most welcome.

Tell the rogue department to buy an AP that works.

Well, they're using a client bridge (and must be NATting), so no rogue AP...at least not in this particular case. Although there are plenty of those, too. Thanks, Alan! Cheers, - -sth sam hooker|sth@noiseplant.com|http://www.noiseplant.com Are you satisfied? ([y]/n): -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5) iEYEARECAAYFAkoWqjgACgkQX8KByLv3aQ0MWwCfaK3kcKJDj+OeQ/3wi/mIzlxf y9kAnjjXCNMPguX3bJkkK67WDaCt5AdI =yJVA -----END PGP SIGNATURE-----