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