%{2} not expanding for accounting packets?
We've got some switches that don't include the MAC address in the Calling-Station-Id of accounting packets. To simplify the config, I use an unlang expression to add it: if ((!Calling-Station-Id) && (NAS-Port-Type == Ethernet) && (User-Name =~ /(..)(..)(..)(..)(..)(..)/)) { update request { Calling-Station-Id = "%{1}:%{2}:%{3}:%{4}:%{5}:%{6}" } } However, the output of that is: 00::22:33:44:55 ...which is odd: rad_recv: Accounting-Request packet from host 172.16.54.36 port 32770, id=92, length=113 Acct-Status-Type = Start User-Name = "001E0BA09F67" NAS-IP-Address = 172.16.54.36 Acct-Session-Id = "Tue Jul 29, 2008 18:54:00" Service-Type = Login-User NAS-Port = 1035 NAS-Port-Type = Ethernet Tunnel-Private-Group-Id:0 = "14" Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Acct-Delay-Time = 0 server macauth { +- entering group preacct calling-mac-1: Could not find value pair for attribute Calling-Station-Id ++[calling-mac-1] returns noop calling-mac-2: Could not find value pair for attribute Calling-Station-Id ++[calling-mac-2] returns noop called-mac-1: Could not find value pair for attribute Called-Station-Id ++[called-mac-1] returns noop called-mac-2: Could not find value pair for attribute Called-Station-Id ++[called-mac-2] returns noop ++? if ((!Calling-Station-Id) && (NAS-Port-Type == Ethernet) && (User-Name =~ /(..)(..)(..)(..)(..)(..)/)) ?? Evaluating !(Calling-Station-Id) -> FALSE ?? Evaluating (NAS-Port-Type == Ethernet) -> TRUE ?? Evaluating (User-Name =~ /(..)(..)(..)(..)(..)(..)/) -> TRUE ++? if ((!Calling-Station-Id) && (NAS-Port-Type == Ethernet) && (User-Name =~ /(..)(..)(..)(..)(..)(..)/)) -> TRUE ++- entering if ((!Calling-Station-Id) && (NAS-Port-Type == Ethernet) && (User-Name =~ /(..)(..)(..)(..)(..)(..)/)) expand: %{1}:%{2}:%{3}:%{4}:%{5}:%{6} -> 00::0B:A0:9F:67 Similar expressions in the "authorize" section appear to work. Anyone have any ideas?
Alan DeKok wrote:
Phil Mayers wrote:
Anyone have any ideas?
evaluate.c was using one buffer for two different purposes. I've fixed that, and the problem is gone.
Excellent; thanks a lot, looks like a subtle one. I'm liking this "git" thing a *lot*; I did a "git pull" of the change, git diff of the changeset, dropped it into the directory that our chroot-based RPM builder runs from, re-built the RPM and I had the fix rolled out in minutes!
participants (2)
-
Alan DeKok -
Phil Mayers