October 2013 - Freeradius-Devel - lists.freeradius.org

Commit report for v2.x.x branch
by announce＠freeradius.org 03 Oct '13

03 Oct '13

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Mark request as NO_SUCH_CHILD_PID on request done Alan T. DeKok@2013-10-03T16:19:44Z Files modified: * src/main/event.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/0dd1060cdbedede3242c… ====== -- This commit summary was generated @2013-10-04T00:00:02Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0

Commit report for master branch
by announce＠freeradius.org 02 Oct '13

02 Oct '13

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== IPv6_RECVPKTINFO isn't defined unless the advanced API is available, IPV6_2292PKTINFO is the 'legacy' socket option but should work just as well. Arran Cudbard-Bell@2013-10-02T19:15:27Z Files modified: * src/lib/udpfromto.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/cfb454bf4e7211b87038… ====== Ignore editor projects Arran Cudbard-Bell@2013-10-02T14:41:49Z Files modified: * .gitignore Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/85293cd679d65c7b670b… ====== -- This commit summary was generated @2013-10-03T00:00:01Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0

Re: 2.2.1: if-block leads to reject
by Brian Candler 02 Oct '13

02 Oct '13

On 24/09/2013 13:10, Jakob Hirsch wrote: > Hi, > > another issue in 2.2.1 (and the current v2.x.x git): if-blocks in an > authenticate section cause to wrong rejects. > > Example with minimal config: > > authorize { > update control { > Auth-Type := 'Test' > } > } > > authenticate { > if (1) { > #noop > #update reply { > # Reply-Message := "bla" > #} > } > ok > } > } I queried this a while ago, and it seems to be intentional (albeit sparsely documented) behaviour. Configurable failover is described here: http://wiki.freeradius.org/config/Fail-over A sequence of modules like foo bar baz is a group, and if one of those modules gives a failure status, the entire group terminates early unless you've applied a numeric value to the failure code, in which case it will be carried forward. Now, an 'if' block is itself a failover block. So if there was a success or fail status set before the start of the block, it will cause the whole group within which the 'if' is enclosed to terminate at the end of that block - even if the 'if' block itself did nothing to set success or fail status. But this doesn't happen if the block is skipped because the condition was false. Here's an example. I want to conditionally log CHAP failures, and I also want to call additional code in policy.conf (e.g. to turn some access-rejects into access-accept with a walled garden). The config looks something like this: authenticate { Auth-Type CHAP { chap { ok = return reject = 1 } if (some condition) { update control { Tmp-String-0 += "CHAP %{%{request:CHAP-Challenge}:-%{request:Packet-Authentication-Vector}} %{request:CHAP-Password}" } # 'if' is an instance of configurable failover; # we must prevent an early return reject = 1 } handleReject } } If the second "reject = 1" is omitted, then termination occurs at the end of the 'if' block, before handleReject is called. Now, handleReject is defined in policy.conf. Suppose I want to update an attribute conditionally in there. This also has the same issue: policy { handleReject { if (some condition) { update control { SomeAttr := "somevalue" } # Behaviour of configurable failover: a reject set # earlier causes an implicit 'return' at the end of an 'if'. # We need this line to prevent it. reject = 1 } ... continue } } Furthermore, if handleReject decides to do nothing, but you want to continue after handleReject to another module in the authenticate {} block, it also needs to end with a 'reject = 1' authenticate { Auth-Type CHAP { ... handleReject doSomethingElse } } policy { handleReject { ... reject = 1 } } In this case, it has to be put at the end of the block definition in policy.conf, not at the point where it is invoked. What I expected (but is *not* the case) was: authenticate { Auth-Type CHAP { ... handleReject { reject = 1 # CAN'T BE APPLIED HERE } doSomethingElse } } I wonder if this could all be made to work in a more intuitive way - for example, once a module has set "reject = 1" this status sticks until another 'real' module is called, as opposed to just update { ... } sections. Anyway, this is just something I've had to grit my teeth and bear with. It seems really weird, but eventually makes sort of sense. I ended up having to write a test suite (invoking radclient with all the different cases) to make sure they all worked the way I wanted. Regards, Brian. P.S. In some cases there may be multiple return conditions you need to tag: Auth-Type PAP { pap { ok = return reject = 1 # password mismatch fail = 1 # no password to match in control list invalid = 1 # no password in request } ... continue In practice, if you use the 'pap' module in the authorize section, it won't set Auth-Type := PAP unless there is a User-Password in the request.

2 1

2.2.1: if-block leads to reject
by Jakob Hirsch 02 Oct '13

02 Oct '13

Hi, another issue in 2.2.1 (and the current v2.x.x git): if-blocks in an authenticate section cause to wrong rejects. Example with minimal config: authorize { update control { Auth-Type := 'Test' } } authenticate { if (1) { #noop #update reply { # Reply-Message := "bla" #} } ok } } debug output: > rad_recv: Access-Request packet from host 127.1.0.5 port 33185, id=115, length=55 > User-Name = "test-user" > User-Password = "test-password" > NAS-Port = 12345 > # Executing section authorize from file /etc/ui-freeradius/sites/test.conf > +group authorize { > ++update control { > ++} # update control = noop > +} # group authorize = notfound > Found Auth-Type = Test > # Executing group from file /etc/ui-freeradius/sites/test.conf > +group Test { > ++? if (1) > ? Evaluating (1) -> TRUE > ++? if (1) -> TRUE > ++if (1) { > ++} # if (1) = reject > +} # group Test = reject > Failed to authenticate the user. > Login incorrect: [test-user/test-password] (from client Arcor_test port 12345) > Sending Access-Reject of id 115 to 127.1.0.5 port 33185 > Finished request 0. So, for some reason, freeradius thinks that the if-block returns with a "reject", which is at least counterintuitive (though I just noticed that 2.2.0 behaved the same, so it's ok probably). If I activate the "noop" (corresponding instance of rlm_always, as the above "ok") in the if-block, it works: > +group Test { > ++? if (1) > ? Evaluating (1) -> TRUE > ++? if (1) -> TRUE > ++if (1) { > +++[noop] = noop > ++} # if (1) = noop > ++[ok] = ok > +} # group Test = ok The update section is not suffucient, though: > +group Test { > ++? if (1) > ? Evaluating (1) -> TRUE > ++? if (1) -> TRUE > ++if (1) { > +++update reply { > +++} # update reply = noop > ++} # if (1) = reject > +} # group Test = reject This is the actual issue I encountered. We use several if-blocks with update sections and this always worked (including 2.2.0). Running 2.2.1 with our live config, I even get a return value of "noop", which leads to a different problem: > ++? if (control:X-Attr-Id && (control:X-Attr-Down || control:X-Attr-Up)) > ? Evaluating (control:X-Attr-Id ) -> TRUE > ?? Evaluating (control:X-Attr-Down ) -> TRUE > ?? Skipping (control:X-Attr-Up) > ++? if (control:X-Attr-Id && (control:X-Attr-Down || control:X-Attr-Up)) -> TRUE > ++if (control:X-Attr-Id && (control:X-Attr-Down || control:X-Attr-Up)) { > +++update reply { > expand: %{control:X-Attr-ID} -> 1 > expand: %{control:X-Attr-Down} -> 2 > expand: %{control:X-Attr-Up} -> 3 > +++} # update reply = noop > ++} # if (control:X-Attr-Id && (control:X-Attr-Down || control:X-Attr-Up)) = noop > ++[ok] = ok > +} # group SP-Auth = noop The if block returns a noop, which the following "ok" cannot override, so the whole group returns with "noop", which make freeradius reject the request. This worked in 2.2.0 (and looked a bit different): ... > ++? if (control:X-Attr-Id && (control:X-Attr-Down || control:X-Attr-Up)) -> TRUE > ++- entering if (control:X-Attr-Id && (control:X-Attr-Down || control:X-Attr-Up)) {...} > expand: %{control:X-Attr-Id} -> 1 > expand: %{control:X-Attr-Down} -> 2 > expand: %{control:X-Attr-Up} -> 3 > +++[reply] returns noop > ++- if (control:SP-Drossel-DTAG-ID && (control:SP-Drossel-Down || control:SP-Drossel-Up)) returns noop > ++[ok] returns ok > Login OK: [xxxx-xxxx] (from client client_test port 12345) Regards Jakob

3 10

Commit report for master branch
by announce＠freeradius.org 01 Oct '13

01 Oct '13

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Update aruba dictionary, extra definitions from alagoutte Arran Cudbard-Bell@2013-10-01T23:44:03Z Files modified: * share/dictionary.aruba Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/5913dea50f9fd087ee71… ====== -- This commit summary was generated @2013-10-02T00:00:02Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0

freeradius 2.2.1 release date?
by Bruce Bauman 01 Oct '13

01 Oct '13

Is 2.2.1 close to release, or is no release planned because 3.0 is so close? We are using 2.2.0 and a few of the features introduced in 2.2.1 would be really useful for us. In particular expansion of the "reference" configuration item to adjust the accounting SQL queries. -- Bruce Bruce Bauman - Systems Administrator Rutgers University Office of Information Technology Campus Computing Services - Central Systems and Services Office ~ (848) 445-6363

4 6