Re: Eval not going great

Dale E. Reed Jr. ( (no email) )
Mon, 20 Apr 1998 13:48:25 -0700

Steve Luper wrote:
>
> Thanks for the help. Here is the capture. Should I try the registry entry to
> ignore malformed packets? Should I wait and followup with you/Ascend.

Either RadiusNT 2.2 (which accepts these packets) or RadiusNT 2.5 with the
AllowMalformed option will work. I'll cc Ascend support on the debug below.
You may want send forward this to them and include your AOS version.

I'm also posting this to the RadiusNT list, so other people who are seeing
this problem will be able to understand it better.


> radrecv: Request from host d129e002 code=1, id=33, length=100
> 01 21 00 64 8a 86 3e 3a b2 af 1d 32 7c 01 2a 64 e6 9c 90 7f
> Packet Information: 80 bytes:
> 01 09 73 6c 75 70 65 72 00 02 09 ea 07 62 e2 4b af a2 04 06 d1 29 e0 02 05
> 06 00
> 00 4e 85 3d 06 00 00 00 00 06 06 00 00 00 02 07 06 00 00 00 01 18 02 1f 0c
> 36 3
> 1 34 38 34 38 38 32 32 37 08 06 d1 73 11 23 2c 0c 32 35 39 36 31 36 30 36 39
> 00
>
> radrecv: Request from host d129e002 code=1, id=33, length=100
> User-Name = "sluper"
> Password = "\352\007b\342K\257\242"
> NAS-IP-Address = 209.41.224.2
> NAS-Port = 20101
> NAS-Port-Type = Async
> User-Service = Framed-User
> Framed-Protocol = PPP
> Request from 209.41.224.2 - Malformed Packet

Here is a debug of the output formatted. The numbers down the left hand
column are the attribute # (hex) and the second column is the length
(including the attribute and length byte) of the attribute/value pair.

Packet Information: 80 bytes:
01 09 73 6c 75 70 65 72 00
02 09 ea 07 62 e2 4b af a2
04 06 d1 29 e0 02
05 06 00 00 4e 85
3d 06 00 00 00 00
06 06 00 00 00 02
07 06 00 00 00 01
18 02
1f 0c 36 31 34 38 34 38 38 32 32 37
08 06 d1 73 11 23
2c 0c 32 35 39 36 31 36 30 36 39 00

7 is User-Service, and when RadiusNT comes up against the 18, with a
length of 02, that makes the packet malformed.