Re: Support of Tag 0x00 for Tunnel-Server-Endpoint
To clarify : I'm using free radius 2.1.9 as a client to connect to a distant server (not freeradius). I'm using API for client access not the freeradius as a server We are facing a problem for Tunnel-Server-Endpoint attribute : RFC http://www.ietf.org/rfc/rfc2868.txt indicates for Tunnel-Server-Endpoint : Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field. So, there is no explicit prohibition of use of 0x00 as a Tag value. What we see in freeradius is that this values makes as ignore the value of the atrtribute. This means : - if we receive a Tunnel-Server-Endpoint with a Tag 0x01 value and that contains an IP@, the IP is taken into consideration and its value is returned by the API. Applicative layer uses it. - But if we receive a Tunnel-Server-Endpoint with a Tag 0x00 value and that contains an IP@, the IP is just ignored, its value is not returned by the API. The call to recv_one_paquet returns an empty Tunnel-Server-Endpoint value The no tag, is may be whell managed at server part, but misused by client part ? Is there some other RFCs that show explicitely that the 0x00 tag should lead to this behavior ? Is it a freeradius bug ? Any help about where is it managed in the code ? Thanks for help - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Support of Tag 0x00 for Tunnel-Server-Endpoint
Naoufel wrote: To clarify : I'm using free radius 2.1.9 as a client to connect to a distant server (not freeradius). I'm using API for client access not the freeradius as a server I have no idea what that means. So, there is no explicit prohibition of use of 0x00 as a Tag value. There's also no way of knowing what the *right* behavior is. What we see in freeradius is that this values makes as ignore the value of the atrtribute. This means : - if we receive a Tunnel-Server-Endpoint with a Tag 0x01 value and that contains an IP@, the IP is taken into consideration and its value is returned by the API. Applicative layer uses it. - But if we receive a Tunnel-Server-Endpoint with a Tag 0x00 value and that contains an IP@, the IP is just ignored, its value is not returned by the API. The call to recv_one_paquet returns an empty Tunnel-Server-Endpoint value That looks like what the code is doing. The no tag, is may be whell managed at server part, but misused by client part ? I have no idea what that means. If the client is sending a tag of 0x00 for IP addresses, it's broken. Fix the client. No other client in the world does this. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Support of Tag 0x00 for Tunnel-Server-Endpoint
Naoufel wrote: Hi, I'm using free radius 2.1.9 as a client to connect to a distant server (not freeradius). We are facing a problem for Tunnel-Server-Endpoint attribute : RFC http://www.ietf.org/rfc/rfc2868.txt indicates for Tunnel-Server-Endpoint : ... So, there is no explicit prohibition of use of 0x00 as a Tag value. Yup. But who bothers reading the specs? sigh What we see in freeradius is that this values makes as ignore the value of the atrtribute. What does that mean? Is there some other RFCs that show explicitely that the 0x00 tag should lead to this behavior ? Is it a freeradius bug ? Any help about where is it managed in the code ? The tag 0x00 could be treated as no tag. The server does this when sending packets. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
