Support of Tag 0x00 for Tunnel-Server-Endpoint

[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