More on RADIUS packet lengths....

Ward Willats (ward@cyno.com)
Tue, 3 Dec 1996 22:31:33 -0800

A MacRADIUS customer sent the following query to Cyno Tech Support.
Following is our answer. I thought I'd cross-post it here to see if our
answer makes sense and our assessment of the situation is correct.

Thanks,

-- Ward

=======================

Date: Tue, 3 Dec 96 08:41:42 -0600
From: nvoth@estreet.com (Nick Voth (admin))
Organization: E Street Denver
Subject: Trouble with secondary server
To: support@cyno.com
Priority: normal
MIME-Version: 1.0

Hello,

I am running MacRADIUS as our primary and secondary authentication and
accounting server for a Livingston Portmaster. When the secondary has to be
used I often get the following error in MacRADIUS when users try to log in
with their PPP account:

Invalid Request Code =1, length = 73

Once I get this error, I am never able to get users back online with using the
secondary machine.

Strangely, much of the time the secondary machine works just fine.

The secondary machine is a Quadra 630 with 12 mg of RAM, sys 7.5.5 and OT
1.1.1.

Any suggestions?? Thanks in advance.

-Nick Voth

--

***************************** Sent From Nick Voth System Administrator E Street Communications, Inc. <nvoth@estreet.com> *****************************

Hello Nick,

> Invalid Request Code =1, length = 73

MacRADIUS is receiving an access-request packet from the Portmaster with a UDP packet length not equal to the length specified in the RADIUS header. It is then rejecting the packet.

Turns out MacRADIUS is being too severe on this point -- it seems it is OK for the UDP size of a packet to be larger than the size indicated in the RADIUS header. The "garbage" at the end of the packet is to be silently ignored. There was recently some discussion about this on the portmaster mailing list. We have appended it to this email.

The next release of MacRADIUS will relax the length checking to allow UDP packet lengths that are greater than the RADIUS header length.

> Once I get this error, I am never able to get users back online with >using the > secondary machine. > > Strangely, much of the time the secondary machine works just fine.

This is a ComOS issue -- apparently once it starts sending packets with garbage at the end it keeps doing so.

Would you mind if we cross-posted your question and our response to the portmaster-radius mailing list? We'll forward any responses, but we'd like to see MegaZone or the Livingston RADIUS development team confirm this is what the PM is doing. (It *could* be sending a packet with a RADIUS header length greater than the UDP packet length, this would be an error. We think this is unlikely.)

Best Regards,

Cyno Technical Support

--------------------------------------------------------------------------- Cyno Technologies Technical Support Vox : 408.297.7766 Cyno Technologies Incorporated Fax : 408.297.7441 1082 Glen Echo Avenue Net : ward@cyno.com San Jose, California 95125 Web : http://www.cyno.com ---------------------------------------------------------------------------