On Jan 11, 2019, at 6:06 PM, Rens Houben via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
So I'm still working on that migration I'd mentioned earlier.
One of the major issues I've encountered is that the router (Ericsson SSRs, formerly Redback) uses /two/ access requests to establish a connection: one to identify and authorize the circuit, then another to authenticate the subscriber login.
This is a problem because the 'User-Name' attribute for the circuit is constructed as 'routername.port.slot.circuit', so a Dot1Q connection with VLAN-ID 393 connecting to port 2 of the card in slot 1 of router 'rb1-am' would have the username 'rb1-am.2.1.393' -- and our setup uses a redundant pair of routers, so the 'username' would vary depending on which router picked up the connection request first.
To deal with this, I decided to insert a REST API in between the circuit requests from freeRADIUS and the database proper.
Thanks to the documentation, I figured out how to connect to said API fairly quickly, and to test the setup I configured the API to just statically send the same set of reply attributes (copied literally from the database) every time.
However, despite including an "Auth-Type": 'PAP' in the response object, the log complains about a missing Auth-Type and defaults to a reject. It does show the other attributes properly, though, so I'm not sure what I'm doing wrong.
The only difference I can see is that the SQL plugin distinguishes between "check" attributes and "reply" attributes and the REST api doesn't seem to do that. Obviously I missed something; I'd appreciate any hints.
It does distinguish Use "control:Auth-Type":"PAP" -Arran