returning a HEX String as a HEX String (bit string) instead of the decimal equivalent - FreeRADIUS 2.1.10
Hello, This is my first post here so please excuse any missed etiquette. I have read through the wiki's and googled a lot and not found anything. I have been trying configure our switch ports (HP 2910al) with Tagged VLANs via Egress-VLANID and Egress-VLAN-Name. The Radius backend is OpenLDAP, and I have tried setting the data type in OpenLDAP to binary, UTF-8 and IA5, but no matter what I do, the value returned by RADIUS is the decimal equivalent of the HEX bit string I enter :( For example I'm trying to store and send 0x31000012 to indicate a tagged VLAN (0x31) on VLAN 12. But looking at freeradius -X output I can see it sending the decimal number, when the switch wants the bit string as it was stored, and hence throws an error! Is this a FreeRADIUS thing or an OpenLDAP data type thing? Any help and advice would be greatly appreciated as I'm stuck. Thanks in advance, Andy.
On 5 Aug 2013, at 23:39, Andy <andy@brandwatch.com> wrote:
Hello,
This is my first post here so please excuse any missed etiquette.
I have read through the wiki's and googled a lot and not found anything.
http://wiki.freeradius.org/vendor/HP#RFC-4675-(multiple-tagged/untagged-VLAN... *sigh*
I have been trying configure our switch ports (HP 2910al) with Tagged VLANs via Egress-VLANID and Egress-VLAN-Name.
The Radius backend is OpenLDAP, and I have tried setting the data type in OpenLDAP to binary, UTF-8 and IA5, but no matter what I do, the value returned by RADIUS is the decimal equivalent of the HEX bit string I enter :(
For example I'm trying to store and send 0x31000012 to indicate a tagged VLAN (0x31) on VLAN 12. But looking at freeradius -X output I can see it sending the decimal number, when the switch wants the bit string as it was stored, and hence throws an error!
No. The HP switch does not care that FreeRADIUS displayed (but later encoded correctly) your hex string as an integer. It does care that you don't seem to understand how to convert decimal numbers to hex and are actually specifying VLAN 18 tagged, which probably doesn't exist if you're getting errors. You want 0x3100000C for VLAN 12 tagged. -Arran
Hi, yes thank you, that is the guide I have been following.. And as that guide highlights the switch needs a 'bit string', not a decimal number; "The value of Egress-VLANID is a bit string, the first 8 bits specify whether the VLAN is tagged or untagged and must be either 0x31 (tagged) or 0x32 (untagged). The next 12 bits are padding 0x000, and the final 12 bits are the VLAN ID as an integer value.." Thus I need; 'Egress-VLANID = 0x31000013' in the FreeRADIUS reply But FreeRADIUS is NOT sending that bit string, it is sending; Sending Access-Accept of id 41 to 10.0.0.242 port 1812 Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Egress-VLANID = 822083602 HP-Cos = "3" Finished request 18. I have stored the HEX String in OpenLDAP with various data types, but the FreeRADIUS always converts the number to the decimal equivalent (822083602) which is out of range for the switch? How can I stop this conversion? HPO switch debug; 0049:03:34:00.18 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd new client detected on vid: 11. 0049:03:34:00.18 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd RADIUS CHAP authentication started, session: 2985. 0049:03:34:00.20 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd vid attribute error during RADIUS processing. 0049:03:34:00.20 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd client rejected, session: 2985, invalid attributes. 0049:03:34:00.20 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd client authentication failed, login retry count: 1 >= max-retires: 0, no unauth-vid configured, entering quiet-period: 30 seconds. W 08/06/13 09:45:58 02400 dca: macAuth client, RADIUS-assigned VID validation error. MAC 080027E4B2CD port 29 VLAN-Id 0 or unknown. Thanks, Andy. On Mon 05 Aug 2013 23:59:36 BST, Arran Cudbard-Bell wrote:
On 5 Aug 2013, at 23:39, Andy <andy@brandwatch.com <mailto:andy@brandwatch.com>> wrote:
Hello,
This is my first post here so please excuse any missed etiquette.
I have read through the wiki's and googled a lot and not found anything.
http://wiki.freeradius.org/vendor/HP#RFC-4675-(multiple-tagged/untagged-VLAN...
*sigh*
I have been trying configure our switch ports (HP 2910al) with Tagged VLANs via Egress-VLANID and Egress-VLAN-Name.
The Radius backend is OpenLDAP, and I have tried setting the data type in OpenLDAP to binary, UTF-8 and IA5, but no matter what I do, the value returned by RADIUS is the decimal equivalent of the HEX bit string I enter :(
For example I'm trying to store and send 0x31000012 to indicate a tagged VLAN (0x31) on VLAN 12. But looking at freeradius -X output I can see it sending the decimal number, when the switch wants the bit string as it was stored, and hence throws an error!
No. The HP switch does not care that FreeRADIUS displayed (but later encoded correctly) your hex string as an integer.
It does care that you don't seem to understand how to convert decimal numbers to hex and are actually specifying VLAN 18 tagged, which probably doesn't exist if you're getting errors.
You want 0x3100000C for VLAN 12 tagged.
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 6 Aug 2013, at 10:50, Andy <andy@brandwatch.com> wrote:
Hi, yes thank you, that is the guide I have been following..
And as that guide highlights the switch needs a 'bit string', not a decimal number; "The value of Egress-VLANID is a bit string, the first 8 bits specify whether the VLAN is tagged or untagged and must be either 0x31 (tagged) or 0x32 (untagged). The next 12 bits are padding 0x000, and the final 12 bits are the VLAN ID as an integer value.."
Thus I need; 'Egress-VLANID = 0x31000013' in the FreeRADIUS reply
But FreeRADIUS is NOT sending that bit string, it is sending;
Sending Access-Accept of id 41 to 10.0.0.242 port 1812 Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Egress-VLANID = 822083602
You're still sending the wrong binary string. 822083602 == 0x31000012 The RFC specifies that Egress-VLANID has a 4 octet value, whoever wrote the dictionary decided to represent it as a 32bit unsigned integer, but that should be OK.
HP-Cos = "3" Finished request 18.
OK. First, you're not doing PPP, remove the default entries in the users file for Framed-Protocol and Framed-Compression. Second there's no special encoding for an unsigned integer. Chances are, the on the wire format of the value matches the hex string. Look at a dump in wireshark if you don't believe me. If it doesn't, that's a problem, and we can look at fixing it.
I have stored the HEX String in OpenLDAP with various data types, but the FreeRADIUS always converts the number to the decimal equivalent (822083602) which is out of range for the switch?
*sigh*, no.
How can I stop this conversion?
The on the wire raw format will be the same for the integer and for the binary string.
HPO switch debug; 0049:03:34:00.18 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd new client detected on vid: 11. 0049:03:34:00.18 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd RADIUS CHAP authentication started, session: 2985. 0049:03:34:00.20 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd vid attribute error during RADIUS processing. 0049:03:34:00.20 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd client rejected, session: 2985, invalid attributes. 0049:03:34:00.20 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd client authentication failed, login retry count: 1 >= max-retires: 0, no unauth-vid configured, entering quiet-period: 30 seconds. W 08/06/13 09:45:58 02400 dca: macAuth client, RADIUS-assigned VID validation error. MAC 080027E4B2CD port 29 VLAN-Id 0 or unknown.
Because you're still sending the wrong value? -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
HPO switch debug; 0049:03:34:00.18 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd new client detected on vid: 11. 0049:03:34:00.18 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd RADIUS CHAP authentication started, session: 2985. 0049:03:34:00.20 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd vid attribute error during RADIUS processing. 0049:03:34:00.20 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd client rejected, session: 2985, invalid attributes. 0049:03:34:00.20 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd client authentication failed, login retry count: 1 >= max-retires: 0, no unauth-vid configured, entering quiet-period: 30 seconds. W 08/06/13 09:45:58 02400 dca: macAuth client, RADIUS-assigned VID validation error. MAC 080027E4B2CD port 29 VLAN-Id 0 or unknown.
Because you're still sending the wrong value?
...and why the hell couldn't they include the VLAN ID that the switch thinks it received. Nathan Jenne, if you read the list, your code sucks :P -Arran
Ahh, "No. The HP switch does not care that FreeRADIUS displayed (but later encoded correctly) your hex string as an integer. It does care that you don't seem to understand how to convert decimal numbers to hex and are actually specifying VLAN 18 tagged, which probably doesn't exist if you're getting errors. You want 0x3100000C for VLAN 12 tagged." I apologise! I can't believe I did that! How stupid of me to not actually convert the VLAN number! I just got thrown when I saw the base 16 to base 10 conversion and got stuck on that.. Serves me right for trying to figure these things out after mid night when I should have been sleeping.. Thanks, Andy. On Mon 05 Aug 2013 23:59:36 BST, Arran Cudbard-Bell wrote:
On 5 Aug 2013, at 23:39, Andy <andy@brandwatch.com <mailto:andy@brandwatch.com>> wrote:
Hello,
This is my first post here so please excuse any missed etiquette.
I have read through the wiki's and googled a lot and not found anything.
http://wiki.freeradius.org/vendor/HP#RFC-4675-(multiple-tagged/untagged-VLAN...
*sigh*
I have been trying configure our switch ports (HP 2910al) with Tagged VLANs via Egress-VLANID and Egress-VLAN-Name.
The Radius backend is OpenLDAP, and I have tried setting the data type in OpenLDAP to binary, UTF-8 and IA5, but no matter what I do, the value returned by RADIUS is the decimal equivalent of the HEX bit string I enter :(
For example I'm trying to store and send 0x31000012 to indicate a tagged VLAN (0x31) on VLAN 12. But looking at freeradius -X output I can see it sending the decimal number, when the switch wants the bit string as it was stored, and hence throws an error!
No. The HP switch does not care that FreeRADIUS displayed (but later encoded correctly) your hex string as an integer.
It does care that you don't seem to understand how to convert decimal numbers to hex and are actually specifying VLAN 18 tagged, which probably doesn't exist if you're getting errors.
You want 0x3100000C for VLAN 12 tagged.
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
It still doesn't work :( Sorry but I have been working on RFC 4675 for a long time before I emailed this list, which is why I was a bit short in my first reply (sorry) and jumped the gun before reading all of your email. I /really/ have trawled every page I can find.. I have changed OpenLDAP to 0x3100000C (thanks for pointing that silly mistake out), and I get a reply from FreeRADIUS with; Sending Access-Accept of id 48 to 10.0.0.242 port 1812 Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP Egress-VLAN-Name = "VLAN12" Egress-VLANID = 822083596 HP-Cos = "3" Finished request 1. And on the switch I have defined the VLAN; vlan 12 name "VLAN12" ip address 10.2.46.242 255.255.255.0 ip helper-address 10.0.0.1 ip igmp exit But I still get the error on the switch; 0049:03:54:30.02 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd new client detected on vid: 1. 0049:03:54:30.02 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd RADIUS CHAP authentication started, session: 2991. 0049:03:54:30.04 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd vid attribute error during RADIUS processing. 0049:03:54:30.04 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd client rejected, session: 2991, invalid attributes. 0049:03:54:30.04 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd client authentication failed, login retry count: 1 >= max-retires: 0, no unauth-vid configured, entering quiet-period: 30 seconds. W 08/06/13 10:06:28 02400 dca: macAuth client, RADIUS-assigned VID validation error. MAC 080027E4B2CD port 29 VLAN-Id 0 or unknown. I can get RFC 3580 to work fine with the following; Sending Access-Accept of id 50 to 10.0.0.242 port 1812 Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP HP-Cos = "3" Tunnel-Private-Group-Id:0 = "11" Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN Finished request 3. But I really need to get Tagged VLAN working! If no one has any ideas I'll try and raise a support call with HP.. Wish me luck I may never return and be lost in their 'support system' forever...! ;) On 05/08/13 23:59, Arran Cudbard-Bell wrote:
On 5 Aug 2013, at 23:39, Andy <andy@brandwatch.com <mailto:andy@brandwatch.com>> wrote:
Hello,
This is my first post here so please excuse any missed etiquette.
I have read through the wiki's and googled a lot and not found anything.
http://wiki.freeradius.org/vendor/HP#RFC-4675-(multiple-tagged/untagged-VLAN... <http://wiki.freeradius.org/vendor/HP#RFC-4675-%28multiple-tagged/untagged-VLAN%29-Assignment>
*sigh*
I have been trying configure our switch ports (HP 2910al) with Tagged VLANs via Egress-VLANID and Egress-VLAN-Name.
The Radius backend is OpenLDAP, and I have tried setting the data type in OpenLDAP to binary, UTF-8 and IA5, but no matter what I do, the value returned by RADIUS is the decimal equivalent of the HEX bit string I enter :(
For example I'm trying to store and send 0x31000012 to indicate a tagged VLAN (0x31) on VLAN 12. But looking at freeradius -X output I can see it sending the decimal number, when the switch wants the bit string as it was stored, and hence throws an error!
No. The HP switch does not care that FreeRADIUS displayed (but later encoded correctly) your hex string as an integer.
It does care that you don't seem to understand how to convert decimal numbers to hex and are actually specifying VLAN 18 tagged, which probably doesn't exist if you're getting errors.
You want 0x3100000C for VLAN 12 tagged.
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Works here just fine. Once you've created the correctly formatted value for the radius attribute FR displays it as an integer but whatever happens in the background the HP switch just "does its stuff " Rgds A Sent from my iPhone On 6 Aug 2013, at 00:39, Andy <andy@brandwatch.com> wrote:
Hello,
This is my first post here so please excuse any missed etiquette.
I have read through the wiki's and googled a lot and not found anything.
I have been trying configure our switch ports (HP 2910al) with Tagged VLANs via Egress-VLANID and Egress-VLAN-Name.
The Radius backend is OpenLDAP, and I have tried setting the data type in OpenLDAP to binary, UTF-8 and IA5, but no matter what I do, the value returned by RADIUS is the decimal equivalent of the HEX bit string I enter :(
For example I'm trying to store and send 0x31000012 to indicate a tagged VLAN (0x31) on VLAN 12. But looking at freeradius -X output I can see it sending the decimal number, when the switch wants the bit string as it was stored, and hence throws an error!
Is this a FreeRADIUS thing or an OpenLDAP data type thing?
Any help and advice would be greatly appreciated as I'm stuck. Thanks in advance, Andy. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 7 Aug 2013, at 10:56, Alex Sharaz <alex.sharaz@york.ac.uk> wrote: > Works here just fine. Once you've created the correctly formatted value for the radius attribute FR displays it as an integer but whatever happens in the background the HP switch just "does its stuff " Yes the HP switch correctly parses the 4byte octet string sent by the RADIUS server. There's no magic here, the RADIUS server does not communicate to the NAS that the value was once treated as an integer. I've already sent you a screenshot of the raw value off list, I'm not sure what else I can do to convince you that this is expected and non-magical behaviour. I'm honestly not entirely sure why the freeradius dictionary has the attribute as an unsigned int. Possibly for efficiency or for use with systems that already deal with VLAN IDs as native width integers (almost all interpreted languages use integers of a width >= 32bits by default). > Rgds > A > > Sent from my iPhone > > On 6 Aug 2013, at 00:39, Andy <andy@brandwatch.com> wrote: > >> Hello, >> >> This is my first post here so please excuse any missed etiquette. >> >> I have read through the wiki's and googled a lot and not found anything. >> >> I have been trying configure our switch ports (HP 2910al) with Tagged VLANs via Egress-VLANID and Egress-VLAN-Name. >> >> The Radius backend is OpenLDAP, and I have tried setting the data type in OpenLDAP to binary, UTF-8 and IA5, but no matter what I do, the value returned by RADIUS is the decimal equivalent of the HEX bit string I enter :( >> >> For example I'm trying to store and send 0x31000012 to indicate a tagged VLAN (0x31) on VLAN 12. But looking at freeradius -X output I can see it sending the decimal number, when the switch wants the bit string as it was stored, and hence throws an error! >> >> Is this a FreeRADIUS thing or an OpenLDAP data type thing? >> >> Any help and advice would be greatly appreciated as I'm stuck. >> Thanks in advance, Andy. >> - >> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Arran Cudbard-Bell wrote:
I'm honestly not entirely sure why the freeradius dictionary has the attribute as an unsigned int
That's what the RFCs say. And the server doesn't really have a way of packing arbitrary structures from attributes. Alan DeKok.
On 7 Aug 2013, at 13:46, Alan DeKok <aland@deployingradius.com> wrote:
Arran Cudbard-Bell wrote:
I'm honestly not entirely sure why the freeradius dictionary has the attribute as an unsigned int
That's what the RFCs say. And the server doesn't really have a way of packing arbitrary structures from attributes.
It says the value is 4 octets. That's not quite saying it's an integer, was there a later one? I think it's arguably more useful as an integer though, for the reasons listed previously, and because you can use expr to build the bit string easily. For example: update reply { Egress-VLANID += "%{expr:822083584 + %{Tagged-VID}}" } With hex you need to manually pad the VID out to 12 bits. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Thank you everyone so much :) Wow, what a great list :D "OK. First, you're not doing PPP, remove the default entries in the users file for Framed-Protocol and Framed-Compression." I have commented this out now. And again thank you for your wireshark capture, and perfect explanations of the expected data type. I never doubted your credentials or the value of your suggestions ;) I just got myself into a mess with it, BUT, its working now :) NB; your extremely well written website says RFC 4765 isn't in the W branch. I'm running the W branch and its working; brdswitch02(config)# 0050:11:24:55.01 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd new client detected on vid: 1. 0050:11:24:55.01 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd RADIUS CHAP authentication started, session: 3055. 0050:11:24:55.02 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd RADIUS Attributes, priority: 11111111, tagged vid: 12. 0050:11:24:55.02 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd client accepted, session: 3055. 0050:11:24:55.02 MAC mWebAuth:Port: 29 MAC: 080027-e4b2cd client successfully placed into vid: 0. The last message about being placed into vid: 0 is strange, but after running 'show vlans 12', I now see; Port Information Mode Unknown VLAN Status ---------------- -------- ------------ ---------- 1 No Learn Up 2 No Learn Up 5 No Learn Up 6 No Learn Up 7 No Learn Up 8 No Learn Up 20 No Learn Up 22 No Learn Up 29 MACAUTH Learn Up 41 No Learn Up 43 No Learn Up A1 Tagged Learn Up NB; the mac was on port 29. Just need to now test that the MAC on tagged 12 can communicate, AND, the untagged MAC on the same port can also communicate still on VLAN 1. Thank you again for your help :) PS; And sorry again for my initial fast reply. It annoys me when people *sigh* and point you to a page you've already read every word of very closely.. We're not all lazy ;) Andy On Wed 07 Aug 2013 11:21:21 BST, Arran Cudbard-Bell wrote: > > > > > On 7 Aug 2013, at 10:56, Alex Sharaz <alex.sharaz@york.ac.uk> wrote: > >> Works here just fine. Once you've created the correctly formatted value for the radius attribute FR displays it as an integer but whatever happens in the background the HP switch just "does its stuff " > > Yes the HP switch correctly parses the 4byte octet string sent by the RADIUS server. There's no magic here, the RADIUS server does not communicate to the NAS that the value was once treated as an integer. > > I've already sent you a screenshot of the raw value off list, I'm not sure what else I can do to convince you that this is expected and non-magical behaviour. > > I'm honestly not entirely sure why the freeradius dictionary has the attribute as an unsigned int. Possibly for efficiency or for use with systems that already deal with VLAN IDs as native width integers (almost all interpreted languages use integers of a width >= 32bits by default). > > > >> Rgds >> A >> >> Sent from my iPhone >> >> On 6 Aug 2013, at 00:39, Andy <andy@brandwatch.com> wrote: >> >>> Hello, >>> >>> This is my first post here so please excuse any missed etiquette. >>> >>> I have read through the wiki's and googled a lot and not found anything. >>> >>> I have been trying configure our switch ports (HP 2910al) with Tagged VLANs via Egress-VLANID and Egress-VLAN-Name. >>> >>> The Radius backend is OpenLDAP, and I have tried setting the data type in OpenLDAP to binary, UTF-8 and IA5, but no matter what I do, the value returned by RADIUS is the decimal equivalent of the HEX bit string I enter :( >>> >>> For example I'm trying to store and send 0x31000012 to indicate a tagged VLAN (0x31) on VLAN 12. But looking at freeradius -X output I can see it sending the decimal number, when the switch wants the bit string as it was stored, and hence throws an error! >>> >>> Is this a FreeRADIUS thing or an OpenLDAP data type thing? >>> >>> Any help and advice would be greatly appreciated as I'm stuck. >>> Thanks in advance, Andy. >>> - >>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html >> - >> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
Alan DeKok -
Alex Sharaz -
Andy -
Arran Cudbard-Bell