Thanks for responding Heikki, I'll pop over the two configuration files that make up the full set.
Thank you :-) Stefan Paetow Federated Roaming Technical Specialist t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: [email protected] skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. > On 20 Feb 2020, at 11:21, Heikki Vatiainen <[email protected]> wrote: > > On 19.2.2020 0.49, Stefan Paetow wrote: > >> So I've switched on the GlobalMessageLog for RadSec (with a hook for >> the other end's IP) and turns out in our log that our NoReplyHook >> code fires as appropriate, but because it doesn't include a >> Proxy-State, it then cannot be matched to the appropriate request >> packet on the downstream (and they see a 'AuthRADSEC Could not get >> extended identifier: No Proxy-State attribute found in reply' >> message, which prompted the question. In *our* log, we then see >> *another* RADIUS packet, with the same Identifier as the packet >> created by the NoReplyHook, being fired back to the downstream, this >> time *with* a Proxy-State that matches the incoming packet. > > Thanks for the logs and the detailed look at this. Did you have AuthBy > HANDLER configured for directly picking up the right Handler for proxying? I > think I may have seen a part of your configuration but I do not recall the > details and it of course may have changed since that. > > What I'm thinking of is that having two Handlers + a hook to generate rejects > may be causing the duplicates. > > Also, Stefan noted that so far there have been no complaints. I think what > happens is that the first reject without Proxy-State simply gets discarded by > the receiver. This allows the other reject to be processed normally. > > Stefan, do you think you could send us your configuration. There's no need to > include secrets, passwords and similar and if there are parts that simply > repeat what already exists, you can leave those out. What I'm interested in > is the structure of configuration and how Hooks etc. are used. You can send > it to us directly. > > Thanks, > Heikki > > -- > Heikki Vatiainen <[email protected]> > > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, > EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, > DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. > _______________________________________________ > radiator mailing list > [email protected] > https://lists.open.com.au/mailman/listinfo/radiator > _______________________________________________ radiator mailing list [email protected] https://lists.open.com.au/mailman/listinfo/radiator
