Alright, Thanks mate. : ) Regards, Mail: 8zero2.in@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@deployingradius.com> wrote:
On Dec 29, 2018, at 12:08 AM, 8zero2 operations <8zero2ops@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