REG: Cisco-AV Pair not sent

[8zero2 operations]

Alright, Thanks mate. : )
Regards,
Mail: 8zero2.in at gmail.com
Facebook: www.facebook.com/8zero2
Twitter: @8zero2_in
Blog: blog.8zero2.in



On Sat, Dec 29, 2018 at 8:22 PM Alan DeKok <aland at deployingradius.com>
wrote:

> On Dec 29, 2018, at 12:08 AM, 8zero2 operations <8zero2ops at gmail.com>
> wrote:
> > Thanks for the reply. Appreciate it, I am using 3.0.11
>
>   You really need to upgrade.
>
> > I absolutely
> > understand the problem but what i am trying to point out here is sending
> a
> > malformed packet or not sending a reply at all might be a better option.
>
>   Sending a malformed packet is never an option.  I'm surprised that
> happens, as there are many test cases which should ensure the code is
> correct.
>
>   Never sending a reply isn't an option either.  That way the NAS thinks
> that the server is down.
>
>   It's better to just be sure that the attributes have the correct length.
>
> > As what happened in my case when it was 248 bytes it didnt write anything
> > in the reply packet(I mean this attribute was not sent in reply packet)
> and
> > client got full internet whereas it was supposed to get restricted with
> > this attribute(which is a security concern), I wasnt expecting this as
> > redirect url was a dynamic created one.
>
>   That's because you're running 3.0.11, I guess.  3.0.17 and the v3.0.x
> head just truncate the attribute.
>
> > when it greater than 248 it sends a malformed packet in return which nas
> > rejects and nothing happens, client is not given full access(which might
> be
> > better, rather than sending the attribute empty)
>
>   The server should *never* send a malformed packet.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html