It would seem that I have been able to answer my own question for this. After doing an Ethereal dump, I noticed that the Message-Authenticator is indeed set to a valid value. This means that is simply isn't displayed with a value (it gets printed before it is computed). I also figured out that the Cisco was dropping the authentication packets because it was sending to a .6.1 address (the virtual IP for that interface) and receiving the response from the .6.2 address (the primary IP for that interface). Doh! Eliot Gable Certified Wireless Network Administrator (CWNA) Certified Wireless Security Professional (CWSP) Cisco Certified Network Associate (CCNA) CompTIA Security+ Certified CompTIA Network+ Certified Network and Systems Administrator Great Lakes Internet, Inc. 112 North Howard Croswell, MI 48422 (810) 679-3395 (877) 558-8324 Now offering Broadband Wireless Internet access in Croswell, Lexington, Brown City, Yale, and Sandusky. Call for details. -----Original Message----- From: freeradius-users-bounces+support8=greatlakes.net@lists.freeradius.org [mailto:freeradius-users-bounces+support8=greatlakes.net@lists.freeradiu s.org] On Behalf Of Eliot, Wireless and Server Administrator, Great Lakes Internet Sent: Friday, March 24, 2006 3:54 PM To: freeradius-users@lists.freeradius.org Subject: Message-Authenticator Attribute Is the message authenticator attribute properly implemented in FreeRADIUS? I see this in the code: /* * EAP-Message is always associated with * Message-Authenticator but not vice-versa. * * Don't add a Message-Authenticator if it's already * there. */ vp = pairfind(request->reply->vps, PW_MESSAGE_AUTHENTICATOR); if (!vp) { vp = paircreate(PW_MESSAGE_AUTHENTICATOR, PW_TYPE_OCTETS); memset(vp->strvalue, 0, AUTH_VECTOR_LEN); vp->length = AUTH_VECTOR_LEN; pairadd(&(request->reply->vps), vp); } This indicates that anytime it adds a Message-Authenticator attribute, it simply sets it to 0. This would explain why I get: Message-Authenticator = 0x00000000000000000000000000000000 In my proxied packets. However, it could just be that the attributes are getting displayed before the authenticator is actually computed and that the authenticator is getting computed and sent out correctly in the actual packet. I read a post from a long time ago about putting the attribute (set to any value) in the response list, but that does not seem to work (unless I did it wrong): /etc/raddb/preproxy_users: DEFAULT Message-Authenticator = 1 Anyway, I think I am running into a problem with not having this in the packets. I am proxying requests from my Windows XP SP2 supplicant to my Cisco 1310 AP, then my router running FreeRADIUS, then Microsoft IAS. When the proxied reply (Access-Challenge) goes out of the router back towards the Cisco 1310 AP and the supplicant, the Cisco or the supplicant (can't tell which) is ignoring the reply and then sending a new request. Can anyone verify whether the Message-Authenticator attribute is or is not working properly? If it is not working, is it really likely to be causing this problem? Thanks for any help on this. Eliot Gable Certified Wireless Network Administrator (CWNA) Certified Wireless Security Professional (CWSP) Cisco Certified Network Associate (CCNA) CompTIA Security+ Certified CompTIA Network+ Certified Network and Systems Administrator Great Lakes Internet, Inc. 112 North Howard Croswell, MI 48422 (810) 679-3395 (877) 558-8324 Now offering Broadband Wireless Internet access in Croswell, Lexington, Brown City, Yale, and Sandusky. Call for details. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html