Thanks, Alan! This seems to have worked. I've just had an ida though, for "mirroring" radius accounting packets to an upstream radius system, which might be easier than using radiator as a proxy, as follows: (On FreeBSD), using packet mirroring functionality (e.g the pf mirroring feature) to make a copy of the incoming radius accounting packets and mirror them to an upstream radius server which requires a feed.
Would this be an advisable alternative way of sending a radius packet feed to a third party, in this case ? What would be the gotchas? Many Thanks, Traiano On 2012/02/06 6:02 PM, "Alan Buxey" <a.l.m.bu...@lboro.ac.uk> wrote: >Hi, > >> WARNING: Bad authenticator received in reply to ID 153 > >incorrect shared secret or badly munged UDP packets, or packets >received after your local RADIUS server has already decided to forget >about them (timeout) > >> I've confirmed the secret is the same between the proxying radius >>servers >> and the destination radius server, so this doesn't look like the issue. > >Secret "whatever the secret is" > > >..then you never get undone by trailing spaces etc > >> Vendor Specific Attribute (26), length: 8 (bogus, goes past >>end >> of packet) >> Vendor Specific Attribute (26), length: 12 (bogus, goes past >>end >> of packet) > >big big packets - larger than the MTU - change the size of your RADIUS >packets >to eg 1280 or so - the default in RADIATOR is big ...too big. then the >RADIUS >will break the packets up nicely. > >hmm, theres EAPTLS_MaxFragmentSize to deal with EAP - not sure about what >you tweak >with plain RADIUS accounting packets that are big. maybe change the host >MTU size? > >alan _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
