PacketFence - BTS - PacketFence
View Issue Details
0001373PacketFencecorepublic2012-01-31 14:432012-10-24 10:39
fgaudreault 
 
normalmajorrandom
resolvedopen 
3.1.0 
 
0001373: Non-Alphanumeric chars will make Disconnect-Message Fail
Seeing on a client server, the shared secret was containing the following chars:
- @ $

It made the RADIUS dynauth unusable, PF was complaining about a bad secret, when it was working fine using radclient.
No tags attached.
Issue History
2012-01-31 14:43fgaudreaultNew Issue
2012-01-31 14:49obilodeauStatusnew => assigned
2012-01-31 14:49obilodeauAssigned To => obilodeau
2012-01-31 14:50obilodeauNote Added: 0002562
2012-09-25 22:43obilodeauNote Added: 0003096
2012-10-19 13:44fgaudreaultAssigned Toobilodeau =>
2012-10-19 13:44fgaudreaultTarget Version => investigate
2012-10-24 10:39fgaudreaultNote Added: 0003238
2012-10-24 10:39fgaudreaultStatusassigned => resolved
2012-10-24 10:39fgaudreaultTarget Versioninvestigate =>

Notes
(0002562)
obilodeau   
2012-01-31 14:50   
Almost everything parsed by Config::IniFiles is affected by this. not only radius dyn-auth.

From what I recall SNMP communities, telnet usernames or passwords are also affected...

This lasted long enough! You time is over nasty bug! I'm coming at you!
(0003096)
obilodeau   
2012-09-25 22:43   
I just re-checked the CoA code and I don't see why these would cause failures. They are never interpolated.

Did you confirm that the conf/switches.conf file had the proper stuff in it? Because before we were bad at saving $,@,... from the web admin but that was fixed lately. Editing conf/switches.conf by hand always worked.

If you did validate that conf/switches.conf was correct, it could well be a library issue unfortunately... We use Net::Radius::Packet we should probably check its changelog from time to time (or maybe even report the bug).
(0003238)
fgaudreault   
2012-10-24 10:39   
Deauth worked fine with - @ or $.

The issue might have been something else then. Marked as resolved.