Re: freeradius proxy can't recognize Delegated-IPv6-Prefix attribute
thanks Alan. (i couldn't get your reply to my mailbox. so, i made a new mail. sorry...)
Fix the proxy so that it's using the dictionaries from 2.1.10. The debug *claims* it's 2.1.10, but the Delegated-IPv6-Prefix attribute *is* defined in the dictionaries for 2.1.10.
Alan DeKok.
My freeradius proxy already includes "dictionary.rfc4818". Do I need something? [[ radiusd -X ]] including configuration file /tmp/radius/etc/raddb/sites-enabled/default including configuration file /tmp/radius/etc/raddb/sites-enabled/inner-tunnel including dictionary file /tmp/radius/etc/raddb/dictionary main { prefix = "/tmp/radius" localstatedir = "/tmp/radius/var" [[ /tmp/radius/etc/raddb/dictionary ]] $INCLUDE /tmp/radius/share/freeradius/dictionary [[ /tmp/radius/share/freeradius/dictionary ]] $INCLUDE dictionary.rfc4679 $INCLUDE dictionary.rfc4818 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ $INCLUDE dictionary.rfc4849 [[ dictionary.rfc4818 ]] ATTRIBUTE Delegated-IPv6-Prefix 123 ipv6prefix
Thanks Alan.
ichiro tanaka wrote:
My freeradius proxy already includes "dictionary.rfc4818". Do I need something?
No idea. Maybe the attribute isn't in the correct format.
I see. Auth-server is freeradius-2.1.10. I captuared radius packet by wireshark, and compared to rfc4818(sec.3) format. "Delegated-IPv6-Prefix" attribute that auth-server replied and reply_log looks correct. http://tools.ietf.org/html/rfc4818 Proxy-Server recognition was repaired, if proxy-server did not include "dictionary.ascend". --- auth-server [[ users ]] --- user@example.jp Cleartext-Password := password Delegated-IPv6-Prefix := 1234:5678:90ab:cdef::/64 --- auth-server [[ radiusd -X ]] --- Sending Access-Accept of id 250 to 10.233.36.101 port 11814 Delegated-IPv6-Prefix := 1234:5678:90ab:cdef::/64 Proxy-State = 0x34 Thu Oct 21 19:00:08 2010 : Info: Finished request 0. --- auth-server [[ reply_log ]] --- Wed Oct 20 16:56:18 2010 Packet-Type = Access-Accept Delegated-IPv6-Prefix := 1234:5678:90ab:cdef::/64 --- proxy-server [[ radiusd -X ]] --- rad_recv: Access-Accept packet from host 10.233.36.100 port 1812, id=76, length= 44 Attr-123 = 0x00401234567890abcdef0000000000000000 Proxy-State = 0x3135 --- proxy-server [[ post_proxy_log ]] --- Fri Oct 22 11:07:20 2010 Packet-Type = Access-Accept Attr-123 = 0x00401234567890abcdef0000000000000000 Proxy-State = 0x37 --- proxy-server [[ not inlucde "dictionary.ascend" radiusd -X ]] --- rad_recv: Access-Accept packet from host 10.233.36.100 port 1812, id=118, length =44 Delegated-IPv6-Prefix = 1234:5678:90ab:cdef::/64 Proxy-State = 0x3134 --- proxy-server [[ not inlucde "dictionary.ascend" post_proxy_log ]] --- Fri Oct 22 11:26:41 2010 Packet-Type = Access-Accept Delegated-IPv6-Prefix = 1234:5678:90ab:cdef::/64 Proxy-State = 0x3133 ichiro tanaka
ichiro tanaka <i_tanaka@hotmail.co.jp> writes:
Proxy-Server recognition was repaired, if proxy-server did not include "dictionary.ascend".
I believe it is time to revisit the Ascend dictionary fixup. This was done once, and then reverted for between 2.1.7 and 2.1.8: commit e23e4754f755e6fe82a28e53ccc1b9ffcaf53fda Author: Alan T. DeKok <aland@freeradius.org> Date: Wed Dec 2 11:54:23 2009 +0100 Revert "Moved Ascends illegal attributes to their own file" This reverts commit 0241615ea5e98a13c92c266daab356e057d6a27d. While these dictionaries are unfortunate, making this change in a point release is likely a bad idea. commit 0241615ea5e98a13c92c266daab356e057d6a27d Author: Alan T. DeKok <aland@freeradius.org> Date: Tue Sep 29 10:10:59 2009 +0200 Moved Ascends illegal attributes to their own file Yes, I can see the point that this will break existing setups. But I will argue that such setups have *always* been broken. At least when we are discussing the FreeRADIUS 2.x era. You cannot support them without breaking RFC conformance, which should have a higher priority even in the stable tree. Or just rename the next 2.1.x release "2.2.0" if that makes you feel better :-) Bjørn
Bjørn Mork wrote:
I believe it is time to revisit the Ascend dictionary fixup.
I think so, yes.
Yes, I can see the point that this will break existing setups. But I will argue that such setups have *always* been broken. At least when we are discussing the FreeRADIUS 2.x era. You cannot support them without breaking RFC conformance, which should have a higher priority even in the stable tree.
Pretty much, yes.
Or just rename the next 2.1.x release "2.2.0" if that makes you feel better :-)
No... 2.2.0 is a different branch in git, and has major new features, like TCP transport, and many more which are waiting for certain things to happen. For 2.1.11, the safer alternative is to move the "illegal" attributes to their own dictionaries, and then include those *before* the RFC dictionaries. People will still be able to create/send attributes using the illegal names. But when attributes are received, the new names will be used by default. That *is* a change in behavior. But it's time for 10-year-old equipment to be deprecated. Alan DeKok.
Thanks a lot Bjørn and Alan.
I believe it is time to revisit the Ascend dictionary fixup.
I think so, yes.
Yes, I can see the point that this will break existing setups. But I will argue that such setups have *always* been broken. At least when we are discussing the FreeRADIUS 2.x era. You cannot support them without breaking RFC conformance, which should have a higher priority even in the stable tree.
Pretty much, yes.
Or just rename the next 2.1.x release "2.2.0" if that makes you feel better :-)
No... 2.2.0 is a different branch in git, and has major new features, like TCP transport, and many more which are waiting for certain things to happen.
For 2.1.11, the safer alternative is to move the "illegal" attributes to their own dictionaries, and then include those *before* the RFC dictionaries. People will still be able to create/send attributes using the illegal names. But when attributes are received, the new names will be used by default.
That *is* a change in behavior. But it's time for 10-year-old equipment to be deprecated.
I confirmed that this problem was solved by not "Don't include Ascend dictionary" but "Include Ascend dictionary before RFC dictionary". Thanks for your help. ichiro tanaka
participants (3)
-
Alan DeKok -
Bjørn Mork -
ichiro tanaka