-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
No one in London wants to go to Sussex though and from my logs it does not look like anyway from Sussex wants to go to London either ;)
If someone gives me something better to use in my RADIUS packets then I'm game. Meanwhile I keep meaning to glue 'exec' and 'fortune' together and see if anyone notices.
I've been having a lok at such packets on the national proxy and wonder if its because people are just blamming a reply-message in at an wrong stage...eg during Auth? would a default entry in use users file or SQL group reply table cause such wrongness? most likely.
# # Make Reply-Message RFC3748 2.6.5 compliant # rem_reply_message_if_eap { if("%{reply:EAP-Message}"){ update reply { Reply-Message -= "%{reply:Reply-Message}" } } else { noop } } It's not exactly hard...
crack-pipe question of the day:
could reply messages be used with some smart server-end code to provide a data communication channel? ie user A has code that attempts to use EAP with special username coding...the remote server is designed to throw responses in EAP messages...which the modified supplicant on the client can then extract? this could tunnel traffic through an 802.1X restricted network? in fact, is the inner EAP traffic limited at all? once the authentication outer layer is started i should be able to just keep throwing data back/forward through that tube?
Completely dependent on the EAP method. Though I suspect some NAS / Supplicants will set a maximum time limit on how long authentication can take to complete. Arran -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkorDw8ACgkQcaklux5oVKJWoACfXpBXQf9cbKhZ08GCv74wIc9D nKwAnjOjHQTBuixKthuFT5mhJirfMab1 =bttU -----END PGP SIGNATURE-----