Re: Support of Tag 0x00 for Tunnel-Server-Endpoint

2010-09-17 Thread Alan DeKok
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

2010-09-17 Thread Naoufel

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

2010-09-16 Thread Alan DeKok
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?  

> 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


Support of Tag 0x00 for Tunnel-Server-Endpoint

2010-09-16 Thread Naoufel

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 :

   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.

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