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