Don't find a working auth_mode='radius' configuration. Any ideas?

[AIexBV]

I am running freeradius3 on OpenWRT (same machine) as an auth server for WiFi clients, which works well. Also uspot works well with the auth_mode "credentials". My idea is, to switch over to auth_mode "radius" to have the same list of credentials for the captive portal available.

Unfortunately the captive portal denies all login attempts. Monitoring the local ip traffic with tcpdump I figured out so far, that uspot does not send any requests to the radius server neither on port 1812 nor 1813 (UDP). The log does not show helpful messages. So I guess there is something wrong or missing in /etc/config/uspot.

Any ideas here?

config uspot 'captive'
        option auth_mode 'radius'       # one of 'uam', 'radius', 'credentials', 'click-to-continue'
        option idle_timeout '600'       # client is kicked when idle for more than N seconds, defaults to 600, option used if not provided by radius
        option session_timeout '0'      # client is kicked if connected for more than N seconds, defaults to 0, option used if not provided by radius
        option disconnect_delay '0'     # if set, a disconnected client will only be actually kicked after disconnect_delay seconds
        option interface 'captive'      # network interface (from config/network) on which captive clients will be managed
        option setname 'uspot'          # firewall ipset name for client management
        option debug '1'                # turn on debugging output in logs

        option auth_server '127.0.0.1'  # radius authentication server name or address
        option auth_port '1812'         # radius authentication server port
        option auth_secret 'testing123' # radius authentication server password
        option auth_proxy ''            # radius authentication server proxy
        option acct_server '127.0.0.1'  # radius accounting server name or address
        option acct_port '1813'         # radius accounting server port
        option acct_secret 'testing123' # radius accounting server password
        option acct_proxy ''            # radius accounting server proxy
        option acct_interval ''         # radius accounting interim interval override
        option das_secret ''            # radius DAS secret
        option das_port '3799'          # radius DAS listen port
        option nasid ''                 # radius NAS-Identitifer, UAM '&nasid='
        option nasmac ''                # radius Called-Station, UAM '&called='
        option mac_format ''            # MAC format specifier: 'aabbccddeeff', 'aa-bb-cc-dd-ee-ff', 'aa:bb:cc:dd:ee:ff' or the equivalent uppercase
        option location_name ''         # radius WISPr-Location-Name

[f00b4r0]

Pretty sure nasid and nasmac are mandatory for radius operation. Can you try setting both and checking if radius requests are sent?

[AIexBV]

radius-client does not create traffic, but radtest with the same parameters does and accepts the credentials. radtest is mentioned here.

[AIexBV]

I checked the RADIUS setup and the content of /etc/radcli, which should be fine now. Unfortunatelly radius-client is a binary. So taking a look at the source is all I can do now. The current status is, that radclient runs successful, but radius-client does not. At the moment, I don`t have any idea how to move forward.
Have you had successful tests with radius-client running against a FreeRADIUS3 daemon?

[f00b4r0]

Sorry I realize I skipped a beat on the radius-client usage. You need to dump your request json into a file, e.g. /tmp/test and then call radius-client /tmp/test.

For what it's worth, I've done just that on a test OpenWrt 24.10 device with the request you provided, while having tcpdump running as described previously and it "works" (it sends a request, obviously there is no reply since I do not run a RADIUS server on the device):

tcpdump -i lo -v udp port 1812
tcpdump: listening on lo, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:50:03.638092 IP (tos 0x0, ttl 64, id 60174, offset 0, flags [DF], proto UDP (17), length 156)
    localhost.53438 > localhost.1812: RADIUS, length: 128
	Access-Request (1), id: 0x0b, Authenticator: e8dd4c048c2df33768af89a2bf35eafd
	  User-Name Attribute (1), length: 9, Value: myuser3
	  User-Password Attribute (2), length: 18, Value: 
	  Acct-Session-Id Attribute (44), length: 18, Value: 16b0b376048c120c
	  Framed-IP-Address Attribute (8), length: 6, Value: 10.0.0.79
	  Called-Station-Id Attribute (30), length: 19, Value: EA:68:DF:E1:D0:5D
	  Calling-Station-Id Attribute (31), length: 19, Value: 2E:A5:0F:E1:F8:A6
	  NAS-Identifier Attribute (32), length: 7, Value: uspot
	  NAS-Port Attribute (5), length: 6, Value: 0
	  NAS-IP-Address Attribute (4), length: 6, Value: localhost

[AIexBV]

Thank you so much! That was very helpful!
So I could easily run the client in the command line and debug at the same time. Due to several changes, I don't remember exactly what the main issue was, but now it runs fine! I suspect the dictionary file was incomplete.

I noticed that it is not simply possible to use special characters in the password field, because the input will be passed hex-coded to the radius server. Thats not a big deal, because the workaround is simple. But is that issue on the bug or feature list?

[f00b4r0]

I don't understand what you mean about the last part of your sentence. The password is transmitted according to RFC 2865:

 When a User-Password is present, it is hidden using a method based
      on the RSA Message Digest Algorithm MD5

The (cleartext) password can contain special characters.

[AIexBV]

As an example, having the user and password "abc!", the exclamation mark will be encoded and the auth will fail.

[f00b4r0]

ah got it, that's percent-encoding from the browser that's not properly handled by the backend. That's a legit bug indeed :)