-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, We're running SQL accounting for the FR servers authenticating our 802.1X users, now. I'm seeing some annoying duplicate entries, and am wondering if anyone else has had this experience: mysql> SELECT acctsessionid, username, nasipaddress, acctstarttime, callingstationid FROM radacct WHERE acctstoptime IS NULL ORDER BY acctstarttime; +-----------------------------------+------------+-----------------+---------------------+------------------+ | acctsessionid | username | nasipaddress | acctstarttime | callingstationid | +-----------------------------------+------------+-----------------+---------------------+------------------+ ... | 4a15bfef/00:23:12:07:e9:c4/74507 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | 192.168.2.17 | | 4a15bfef/00:23:12:07:e9:c4/74505 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | w.x.38.213 | | 4a15bfef/00:23:12:07:e9:c4/74514 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | 10.250.61.133 | | 4a15bfef/00:23:12:07:e9:c4/74516 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | 192.168.1.25 | | 4a15bfef/00:23:12:07:e9:c4/74513 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | w.x.38.213 | ... I would think this to be pretty normal-looking, except: 1) in this particular group, all the usernames and MAC components of the acctsessionid are the same (i.e., this is one node causing multiple accounting starts to be sent); and 2) our 802.1X wireless clients would not have IP addresses in RFC1918 space. Ever. Most of the time, a group like this will include an address in our real wireless address range (that's what I've replaced with "w.x.38.213"), but sometimes not. If the callingstationid weren't different for each entry, I'd think "retries" or "EAP-FAST". (I think I see EAP-FAST activity going on elsewhere; or, at least, that's what I assume it is.) As far as I can tell, this occurs pretty infrequently, given the number of users we have, but it does occur consistently for a given set of users in a given day, which makes me think it's something about their location on the network. Reducing all the accounting detail to a spreadsheet, I see that this is a flurry of start and stop messages (and one Interim-Update!), and will comb through that closely tomorrow morning. Seems odd, though, that there would be a stop logged to the detail, but not to SQL, in this case. I have little- to no visibility into the networking configuration (our systems and network groups bristle at each other; a situation I'm trying to remedy), but I do know this: One department is located across the street from our main campus. It connects to the Internet by way of a commodity ISP. It is, however, close enough to pick up one of our APs, and the enterprising IT guy for that department has set up a Windows box as a wireless client, and bridged that into their LAN for access to institutional resources. (He has been duly chastised for this.) In at least that case, I've seen their LAN IPs (in a reasonably-unusual RFC1918 subnet) as the callingstationid. (Oddly, though, this is sometimes the LAN IP of their print server, or default gateway -- some artifact of bridging?) This makes me think that there are more clients out there that can see more than one subnet at a time, and just report in with whatever IP they feel like. I suppose my real question is this: Is there anything I can do, from the FR server end, to winnow out one reliable accounting entry per event? Sure, I can make my reports (like 'radwho') filter WHERE callingstationid LIKE 'w.x.%', but that runs the risk of missing entries where the group fails to include one of our "legit" addresses. Alternatively, has anyone else faced this and addressed it on the client side? ("Tell the rogue departments to comply with your network policies," is a valid answer and, frankly, my favorite.) As ever, pointers to pre-existing threads answering this are welcome; I couldn't come up with the right combination of search terms to find them myself... 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) iEYEARECAAYFAkoVzbIACgkQX8KByLv3aQ3tVQCdEOfZCztHLnmvCvfiuax1Y6Qu pA0AoLhQLZCIP/0DwXWje1PY41suMq8o =JDqP -----END PGP SIGNATURE-----