"Chris A. Kalin" <[EMAIL PROTECTED]> wrote: > I actually saw this same problem way back in the post 0.3 CVS days (and > before), and I wasn't even involving checkrad. I would turn on > Simultaneous-Use, and I would immediately begin to get completely bogus > Client-Ip-Addresses in my accounting packets...IPs that had nothing to do > with my network (I remember 0.0.0.0 being one of the examples).
Hmm... after quickly rooting through the code, the only thing I can come up with is the session_zap() function in src/main/session.c, and it's only called from the radutmp module. If removing 'radutmp' from the list of modules makes these packets stop, then the problem is the session_zap() routine. (Which may not initialize all of the data structures it creates) I haven't looked at it for a while, but it calls rad_process(), which is the main request processing function. Unfortunately, rad_process() is designed to be called ONLY from the main thread handler, and NOT from any child thread. Arg... On closer examination of the packet in the previous message, I think the problem *is* session_zap. It SHOULD initialize all of the entries in the data structures it creates. It SHOULD NOT call rad_process(). rad_respond() is safe, and better. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
