On Jun 10, 2019, at 10:59 AM, Duncan X Simpson <virtualdxs@gmail.com> wrote:
Yep, I double checked that. I was worried that case could be a problem, or a typo, but it's there:
(10) Received Access-Request Id 165 from 174.79.36.24:51183 to 192.168.5.51:1812 length 261 (10) User-Name = "duncan" (10) NAS-Identifier = "802AA8834B4728077AE8" (10) Called-Station-Id = "A2-2A-A8-85-4B-47:802.1X test" (10) NAS-Port-Type = Wireless-802.11 (10) Service-Type = Framed-User (10) Calling-Station-Id = "10-98-C3-A9-2C-D4"
Read the *rest* of the debug output.
Post the WHOLE debug output, and let someone else explain it.
Which shows you're running EAP. Which would have been good to know.
But odds are that the Service-Type attribute isn't in the request. There isn't a lot that can go wrong here.
See above.
Again, *read* the debug output. ALL OF IT. If it's hard to read, see: http://wiki.freeradius.org/radiusd-X You're doing EAP. And running the "inner-tunnel" virtual server. Which DOES show the request it receives. AND it shows that request doesn't contain Calling-Station-Id. The relevant lines are below: (9) eap_peap: State = 0x7d495cdf7c54466d1d9baad7442a1d1a (9) Virtual server inner-tunnel received request (9) EAP-Message = 0x021d00061a03 (9) FreeRADIUS-Proxied-To = 127.0.0.1 (9) User-Name = "duncan" (9) State = 0x7d495cdf7c54466d1d9baad7442a1d1a (9) WARNING: Outer and inner identities are the same. User privacy is compromised. (9) server inner-tunnel { (9) session-state: No cached attributes (9) # Executing section authorize from file /etc/raddb/sites-enabled/inner-tunnel See? No Calling-Station-Id in the inner tunnel. Then later in the same packet, you do: (9) update reply { (9) EXPAND %{request:Calling-Station-Id} (9) --> (9) Unix-FTP-Shell := (9) } # update reply = noop Which makes sense. If you want to access the *outer* Calling-Station-ID attribute, you can do %{outer.request:Calling-Station-Id}. See "man unlang" for details. The debug output is large and complex, but it is *all* there for a reason. If you carefully read it, it will answer most of your questions. In this case: * the update Unix-FTP-Shell is happening in packet (9), so looking at packet (10) is a waste of time * once you see the update Unix-FTP-Shell happening, look BACKWARDS in the debug output to see the "received request" line * which then shows you what packet is being received * AND where that packet came from Alan DeKok.