> tcpdump -x -X -vv -s 250 dst host 192.168.100.10 and dst port 1646 ...
Decoding that, I get this for the RADIUS packet bytes data ----- ---- 2 040e code, ID 4 005f length 20 a71e 658b ceae 7a51 0858 a700 1b52 9381 26 0106 7465 7374 32 0406 c0a8 6465 38 2806 0000 0002 52 2c0f 7465 7374 3132 3634 3738 3336 32 58 2906 0000 0000 64 2d06 0000 0001 70 0606 0000 0006 76 0f06 0000 0000 82 1006 0000 f562 88 0e06 c0a8 6401 96 2e06 0000 001c So the packet says it's length 0x5f (95), but there are really 96 bytes of data in it. And it gets worse. The UDP header says: src port 066d dst port 066e (radius accounting) packet lenth 006d checksum 43a9 Including the RADIUS packet and 8 bytes of UDP header, the UDP packet length SHOULD be hex 0x67 (if you believe the broken RADIUS packet). Instead, it's 7 bytes longer. Looking at the packet, there IS 7 bytes of garbage at the end of it. The RADIUS implementation on your NAS is completely broken. > I understand that it's naive approach, but I do not yet understand > freeradius internals, so would you be so kind to explain me > possible consequnces from that approach and possible decision to > that. Thanks in advance Breaking the server to accept packets from a broken NAS isn't the best solution. I would recommend against making those changes, as there may be security issues. As for the NAS, I would suggest throwing it out, and buying a real one. If you can't do that, forward your previous message and this reply to their technical support people, and demand that they fix the problem. If they don't, ask for your money back. The NAS is sold as implementing RADIUS. It doesn't. That makes it a broken product, and you should be able to return it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
