Server Fault Asked by Matthias Wimmer on December 1, 2021
Sorry, Radius newbie here …
I try to get a FreeRadius server version 3.0.20 as packaged by NixOS running to authenticate users on a dlink access point. I’m running the server with debug logging enabled.
I started with the default configuration and followed the Getting Started guide. So I added the user testing
using testing Cleartext-Password := "password"
. I could confirm that this authentication works using radtest testing password 127.0.0.1 0 testing123
. I also see it as a successful login in the logfile. – Cool, works so far.
Next I tried to authenticate over an access point using the same user and password. So I added the IP of the access point to clients.conf
and configured the radius server and shared secret in the access point.
client ap2 {
ipaddr = 192.168.1.32
secret = testing123
}
When trying to authenticate I see the Request coming in on tcpdump, but FreeRadius is ignoring it completely: nothing gets logged.
To cross check and verify that the radius server is not only listening on localhost, I added another non-localhost-client and used radtest
again with that source IP: everything still worked.
Checking with tcpdump
again this is the working request:
192.168.1.144.57243 > 192.168.1.144.1812: [bad udp cksum 0x84d7 -> 0x44fd!] RADIUS, length: 77
Access-Request (1), id: 0x2c, Authenticator: 106b49030bec802e1bd156ff48e3589a
User-Name Attribute (1), length: 9, Value: testing
0x0000: 7465 7374 696e 67
User-Password Attribute (2), length: 18, Value:
0x0000: d112 7b01 9c70 9548 d4a1 db33 c648 739e
NAS-IP-Address Attribute (4), length: 6, Value: 127.0.1.1
0x0000: 7f00 0101
NAS-Port Attribute (5), length: 6, Value: 0
0x0000: 0000 0000
Message-Authenticator Attribute (80), length: 18, Value: &7u...s..L....|..
0x0000: 2637 75c2 ead6 73cc d64c ee9f a97c d8d7
And this is the response from FreeRadius:
192.168.1.144.1812 > 192.168.1.144.57243: [bad udp cksum 0x849e -> 0x427b!] RADIUS, length: 20
Access-Accept (2), id: 0x2c, Authenticator: 750e916c6b56f85eed550088c6cf30fc
In contrast this is request from DLink:
192.168.1.32.36759 > 192.168.1.144.1812: [udp sum ok] RADIUS, length: 103
Access-Request (1), id: 0x6a, Authenticator: e7e4df28fcd96772ffb508c4df564d
User-Name Attribute (1), length: 9, Value: testing
0x0000: 7465 7374 696e 67
User-Password Attribute (2), length: 18, Value:
0x0000: a7cb 807f a0dc fdca 8bd4 e19f cbf4 3e79
Calling-Station-Id Attribute (31), length: 19, Value: 98:f6:21:c0:cc:9d
0x0000: 3938 3a66 363a 3231 3a63 303a 6363 3a39
0x0010: 64
NAS-Identifier Attribute (32), length: 19, Value: c4:e9:0a:21:61:b0
0x0000: 6334 3a65 393a 3061 3a32 313a 3631 3a62
0x0010: 30
NAS-IP-Address Attribute (4), length: 6, Value: 192.168.1.32
0x0000: c0a8 0120
NAS-Port-Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11
0x0000: 0000 0013
NAS-Port Attribute (5), length: 6, Value: 255
0x0000: 0000 00ff
FreeRadius isn’t logging this request at all, and also sends no response to it.
The first thing I probably wonder most: Why isn’t FreeRadius logging the request from the DLink access point while it logs the other request?
Any idea what I am missing why there is no response UDP packet from FreeRadius to the access point?
One “bonus” question: in the UI of the access point the authentication mechanism is called “SPAP” but the “User-Password Attribute” looks like a normal “PAP” authentication. What is the difference between PAP and SPAP? What does SPAP stand for? I couldn’t find any protocol documentation for it.
I feel embarrassed … the problem I saw the requests with tcpdump
but not in the FreeRadius log was, that I blocked the requests in iptables
so the UDP packets never arrived at the socket of FreeRadius.
… a perfect layer 8 bug :(
Answered by Matthias Wimmer on December 1, 2021
Get help from others!
Recent Answers
Recent Questions
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP