Semantics of !~ operator
vogt at spamcop.net
Tue Apr 28 13:36:52 CEST 2015
On 28/04/15 13:18, Alan DeKok wrote:
> On Apr 28, 2015, at 7:13 AM, Gerald Vogt <vogt at spamcop.net> wrote:
>> Both outer.Called-Station-SSID and
>> outer.request:Called-Station-SSID show the same when used in the
>> above "update request" section. I don't get the SSID into the inner
>> So any other idea how to get this attribute from the default server
>> into the inner tunnel??
> The "update" should work. If it doesn't work, it's because the
> outer:Called-Station-SSID doesn't exist. Reading the debug log
> should tell you this. Either the Called-Station-Id attribute doesn't
> exist outside of the tunnel, OR the policy to create
> Called-Station-SSID isn't called from outside of the tunnel.
See <553F52A9.8090106 at spamcop.net>
The default server has the Called-Station-Id attribute, it does
correctly extract the SSID from the Id and it correctly puts it into the
Called-Station-SSID. I even do some checks in unlang based on that SSID
in the outer server and they show results as expected.
So I suppose in that context the attribute exists. But it doesn't go
into the inner tunnel. Neither by means of the eap module
copy_request_to_tunnel=yes nor by the added "update request" in the
So I really would like to understand why it doesn't work here...
> You can always copy the Called-Station-Id from "outer" to the tunnel.
Yes. I know that. That's how I did it in the beginning. My own "ssid"
policy does not modify Called-Station-Id and thus I could extract the
SSID in the inner tunnel as well.
But then I was pointed to the "predefined" rewrite_called_station_id
which basically does the same except it strips the SSID from
Called-Station-Id causing this "problem".
I can do my own policy but generally I prefer to use what's already
there instead of reinventing the wheel...
> Then, run the "create SSID" policy there.
> Alan DeKok.
> - List info/subscribe/unsubscribe? See
More information about the Freeradius-Users