Hi Alan, Arran, After an upgrade to FR 3.0.15 on a test system, I suddenly have an unknown attribute 'Attr-26.135.22.100' in the debug output. It appears that EAP-Channel-Binding-Message is no longer recognised as such in the debug output? When I downgrade to 3.0.14 the issue persists, but when I drop back to 3.0.10 it recovers itself to say 'EAP-Channel-Binding-Message' in the debug output... Can someone else reproduce this with 3.0.15? I know this doesn't affect operations, but... it's irksome? *puzzled face* With Regards Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net 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 Jul 21, 2017, at 11:16 AM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
After an upgrade to FR 3.0.15 on a test system, I suddenly have an unknown attribute 'Attr-26.135.22.100' in the debug output. It appears that EAP-Channel-Binding-Message is no longer recognised as such in the debug output? When I downgrade to 3.0.14 the issue persists, but when I drop back to 3.0.10 it recovers itself to say 'EAP-Channel-Binding-Message' in the debug output... Can someone else reproduce this with 3.0.15?
I know this doesn't affect operations, but... it's irksome?
What is the raw data from that attribute? Perhaps it actually is malformed... EAP-Channel-Binding is a Ukerna attribute, of number 135. So if it *is* malformed, it should come across as: Attr-26.25622.135 = 0x.... I don't see any issue here... Alan DeKok.
What is the raw data from that attribute? Perhaps it actually is malformed...
EAP-Channel-Binding is a Ukerna attribute, of number 135. So if it *is* malformed, it should come across as:
Attr-26.25622.135 = 0x....
That's what I thought... But it isn't malformed. Something else goes wrong in FR. The two outputs are here: https://www.dropbox.com/sh/tonkqtbxloyzb8d/AAAUWbTS1xzvsnPWY9gk6KR2a?dl=0 Specifically, the following changes were made in the config: In 3.0.10's inner-tunnel, the copy-to-outer.session-state unlang was enabled, and in abfab-tr-idp, the same bits were enabled to get the contents of the outer session-state, and in 3.0.14, the configuration was updated to make the same available. Specifically, look at lines 2385-2390 in the 3.0.10-Default.txt and lines 2395-2399 in the 3.0.14-Updated.txt. That's where the inner-tunnel ends. 3.0.10: (15) update { (15) &outer.session-state::EAP-Channel-Binding-Message += &reply:EAP-Channel-Binding-Message[*] -> 0x02001101a406686f7374a50b6c6f63616c686f7374 (15) &outer.session-state::EAP-Message += &reply:EAP-Message[*] -> 0x03010004 (15) &outer.session-state::Message-Authenticator += &reply:Message-Authenticator[*] -> 0x00000000000000000000000000000000 (15) &outer.session-state::Stripped-User-Name += &reply:Stripped-User-Name[*] -> 'steve' (15) } # update = noop (15) } # post-auth = noop (15) } # server inner-tunnel 3.0.14: (15) update { (15) &outer.session-state::Attr-26.135.22.100 += &reply:Attr-26.135.22.100[*] -> 0x02001101a406686f7374a50b6c6f63616c686f7374 (15) &outer.session-state::Stripped-User-Name += &reply:Stripped-User-Name[*] -> 'steve' (15) } # update = noop (15) } # if (1) = noop (15) } # post-auth = noop (15) } # server inner-tunnel The value of EAP-Channel-Binding-Message and 'Attr-26.135.22.100' are identical. In 3.0.14, the session-state copy unlang strips out EAP-Message and Message-Authenticator (which is correct, because the unlang in inner-tunnel explicitly strips it). So. What's happened to 'EAP-Channel-Binding-Message' and why is it either mangled or being misinterpreted by radiusd as attribute 26.135.22.100? :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net 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 Jul 21, 2017, at 12:23 PM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
3.0.14:
(15) update { (15) &outer.session-state::Attr-26.135.22.100 += &reply:Attr-26.135.22.100[*] -> 0x02001101a406686f7374a50b6c6f63616c686f7374
Huh? If you have EAP-Channel-Binding-Message in the config files, that's what should get printed out here. The "Attr-26..." format is really only used when sending and receiving packets. Having it here is... weird.
The value of EAP-Channel-Binding-Message and 'Attr-26.135.22.100' are identical. In 3.0.14, the session-state copy unlang strips out EAP-Message and Message-Authenticator (which is correct, because the unlang in inner-tunnel explicitly strips it).
So. What's happened to 'EAP-Channel-Binding-Message' and why is it either mangled or being misinterpreted by radiusd as attribute 26.135.22.100?
Hmm... the issue would seem to be when the attribute is *created*. I've pushed a fix. Alan DeKok.
So. What's happened to 'EAP-Channel-Binding-Message' and why is it either mangled or being misinterpreted by radiusd as attribute 26.135.22.100?
Hmm... the issue would seem to be when the attribute is *created*.
I've pushed a fix.
Ahh, excellent. Much appreciated! :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net 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.
participants (2)
-
Alan DeKok -
Stefan Paetow