I have a NAS unit (An Osicom IQX -> read: junk) that doesn't send the
NAS-IP-Address in the authentication packet. Is there a down and dirty
way to pull that information out of the packet header and use it? The
reason I ask is that I have a Handler based on NAS address that doesn't
work from this unit because of this missing information (this is confirmed
missing via a trace 4 dump of the authenticator packet.....) I believe I
saw something similiar elsewhere in one of the radius modules, but wasn't
sure how/where I could implement this. Thanks in advance.
Here is the packet dump:
Mon Apr 19 13:48:19 1999: DEBUG: Packet dump:
*** Received from 1.1.1.1 port 1611 ....
Code: Access-Request
Identifier: 2
Authentic: F7<25>h<13>KCT<157><24><143><6><246><3><17>r
Attributes:
User-Name = "test"
Password = "<178>@.<233>0<230><224><180>R<189>$<163>.C(%"
Service-Type = Framed-User
Framed-Protocol = PPP
NAS-Port = 29
I see in Radius.pm that Socket::inet_ntoa($l[1]) can be the IP of the
sending unit. Is there a place I can setup a test to see if during the
Access-Request phase the NAS-IP-Address is set and if not, make it from
the packet? The information is there during the accounting phases but it
appears that Osicom is quite slow in implementing this change that we've
asked...... It doesn't *technically* violate the RFC but I believe it
suggests in all caps that the NAS ip be sent during this phase......
--------------------------------------------------------------------------
Aaron Holtz
ComNet Inc.
UNIX Systems Specialist
Email: [EMAIL PROTECTED]
"It's not broken, it just lacks duct tape."
--------------------------------------------------------------------------
===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
