Current status of freeradius v4

Alan DeKok aland at deployingradius.com
Wed Jul 24 19:26:17 CEST 2019


On Jul 24, 2019, at 11:13 AM, Jan-Frederik Rieckers <rieckers+freeradius-devel at uni-bremen.de> wrote:
> Thanks for the quick reply!

  Try getting that level of support from Cisco. :)

> I assume the fix was pushed in the commit "handle Access-Challenge
> responses" ?

  Yes.

> If so, it still has problems proxying Access-Challenge packets. See
> debug output and configuration below.

  If you're running that code, you don't need to manually set the reply packet type.  It should just work.

> Regarding the linelog module: If I use %{reply:Packet-Type} as message
> selector, this variable seems to be empty. (I haven't tested that with
> the current master, only the one from yesterday)

  Hmm.. I'll have to try that.  We're using the linelog module a lot, and it seems to work fine.

> (PS: Whenever I shoud stop using freeradius-devel for this and use
> freeradius-users or Github Issues, please tell me.)

  It's fine to talk here.

>> Debug : (0)      Received Access-Challenge ID 11 length 73 reply packet on connection proto udp local 0.0.0.0 port 56773 remote 10.11.
>> 0.216 port 2084
>> Debug : (0)        &EAP-Message = 0x010100061520
>> Debug : (0)        &Message-Authenticator = 0xaa2410363e4546fcad585a1bb568af94
>> Debug : (0)        &State = 0x57487590574960fe50542e3cd559b240
>> Debug : (0)        &Proxy-State = 0x30
>> Debug : (0)        &Proxy-State = 0x45ad4539
>> Debug : radsec1 - Setting idle timeout to +300.000 for connection proto udp local 0.0.0.0 port 56773 remote 10.11.0.216 port 2084
>> Debug : (0)      running request
>> Debug : (0)      radsec1 - Resuming execution
>> Debug : (0)      radsec1 (updated)
>> Debug : (0)    } # group (updated)

  That's good

>> Debug : (0)    if (updated) {
>> Debug : (0)      update reply {
>> Debug : (0)        &Packet-Type := Access-Challenge
>> Debug : (0)      } # update reply (noop)
>> Debug : (0)    } # if (updated) (noop)
>> Debug : (0)  } # authenticate proxy-to-radsec (noop)

  That's bad.  The "noop' return code shouldn't over-ride the "updated" one.

  In the short term, you can do:

authenticate proxy-to-radsec {
       redundant {
               radsec1
               radsec2
       }
       if (updated) {
               update reply {
                       &Packet-Type := Access-Challenge
               }
		ok
       }
}

  And that should fix it.

  Alan DeKok.




More information about the Freeradius-Devel mailing list