is there any way to change the NAS-Identifier field that is sent through RADIUS hotspot requests? At first glance tt appears to be hardcoded to be the router identity, according to the ROS Wiki.
I need to be able to control this somehow in order to run multiple different hotspots on the same machine. My commercial hotspot backend uses NAS-Identifier as the main distinction between different locations, and that also appears to be hardcoded. It’d be a real hassle to add several small routers (hEX or something) to the setup with different identities just to get this separation working. Also the firewalls would be much less streamlined.
There’d be more than enough optional fields like WISPr-Location-Name to submit a custom string, but sadly the server won’t understand that.
Definitely, however the external service uses only Nas-Identifier and they likely won’t change that just for me. I did ask, though
So it’s an unfortunate case of “hardcoded on both ends”. Honestly it wouldn’t be very hard for MikroTik to get this parametrizable in the software. Some arcane CLI option would suffice. Sadly the RADIUS client as is is super simple.
Then it’s a lack of functionality on the external service, unfortunately.
Install a AAA proxy in the middle (freeradius comes to mind), and re-write the attribute to the value of your choosing. NAS-Identifier is the hostname of the router, this is not only on Mikrotik, but on most network devices.
This Attribute contains a string identifying the NAS originating
the Access-Request. It is only used in Access-Request packets. Either NAS-IP-Address or NAS-Identifier SHOULD be present in an
Access-Request packet.
A summary of the NAS-Identifier Attribute format is shown below. The
fields are transmitted from left to right.
The String field is one or more octets, > and should be unique to
the NAS within the scope of the RADIUS server> . For example, a
fully qualified domain name would be suitable as a NAS-Identifier.
The actual format of the information is site or application
specific, and a robust implementation SHOULD support the field as
undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
That seems like a good idea. Just looked up the proxy function in FreeRADIUS which I wasn’t aware of. It should be doable using some combination of realms, domains and custom fields on the ROS side, and some Unlang conversion scripting on the proxy side.
I might actually try that at some point. However even if I make it work, I’ll probably run into problems with MAC cookies (this is about hotspots). That’s another feature that seems to be more or less bound to the one router. According to the Wiki, apparently a MAC cannot appear twice in the cookies. Will have to look into login by “MAC”, not “MAC cookie”.
Would this be a work-around? Add the SSID to the called format.
WLAN driver : “radius-called-format (mac | mac:ssid | ssid; Default: mac:ssid)”
Wifi driver: “called-format (format-string) Format for the value of the Called-Station-Id RADIUS attribute, in AP’s messages to RADIUS servers. Default: II-II-II-II-II-II:S”
Oh yes, I do use wifi authentication (EAP) , not hotspot.