Home servers constantly zombied, and I can't figure out how to fix it

[Adam Bultman]

OK, so some more updates:

1. I re-compiled freeradius v2.1.x from the git sources, using a
different spec file (I'm building RPMs from the source) and it's working
much better now.

2. I've tuned my detail file placer and reader to do individual files
based on attributes and a timestamp

I've noticed that:

1. I'm getting pseudo-duplicate packets from my NAS

2. The pseudo-duplicate packets are subtly different in that some items
are missing - in my case, Calling-Station-Id.

3. The "other side" tends to "zombie" on me with packets that don't
contain the Calling-Station-Id (Although it'll zombie on me

4. I'm attempting to control my detail file reader to ignore packets
that don't have a Calling-Station-Id attribute, but I'm failing.

First, in my detail file reader, I want to make it so that if certain
attributes are in the packet, that I send it on it's way to the other
servers. If they aren't there, I want to simply ignore that packet, and
make it go away.  So, I have this in my accounting {} section:

if (Calling-Station-Id > 0 && Framed-IP-Address > 0 && User-Name =~
/mydomain/i) {
                             update control {
                               Proxy-To-Realm := "my_acct"
                                }
                        }

I'll see things like this:
Mon Jul 19 12:18:52 2010 : Info: ? Evaluating (Calling-Station-Id > 0 )
-> TRUE
Mon Jul 19 12:18:52 2010 : Info: ? Evaluating (Framed-IP-Address > 0 )
-> TRUE
Mon Jul 19 12:18:52 2010 : Info: ? Evaluating (User-Name =~ /mydomain/i)
-> TRUE
Mon Jul 19 12:18:52 2010 : Info: ++? if (Calling-Station-Id > 0 &&
Framed-IP-Address > 0 && User-Name =~ /mydomain/i) -> TRUE
Mon Jul 19 12:18:52 2010 : Info: +++[control] returns noop
Mon Jul 19 12:18:52 2010 : Info: ++- if (Calling-Station-Id > 0 &&
Framed-IP-Address > 0 && User-Name =~ /mydomain/i) returns noop
Mon Jul 19 12:18:52 2010 : Info: ++[ok] returns ok

But, even when there's a packet that does NOT match, it still is trying
to send it to the home servers - directly after the part where it says
FALSE, the server is then immediately sending it on it's way.  I'm not
sure if I need to have an else {} section to do 'noop', or 'reject', or
'handled', or what, and that's where I'm stuck.  I've been googling, but
I'm not sure what I should be looking for.  I'm going to keep trying in
the meantime, and see if stripping those packets out are what I need to
do.  The other option I have is to put the realm and calling station ID
in the detail packet names, and then simply ignore those.  (I was doing
that simply for packets with calling station IDs, but that creates a
huge number of files freeRADIUS won't touch, which I then have to clean
up after the fact.)

Adam






Alan DeKok wrote:
> Adam Bultman wrote:
>> After some work getting 2.1.9, and v2.1.x from the git repository up and
>> running, I had to go back to 2.1.7-7, that is patched (hopefully,
>> anyway!) for the "zombie" problem, via the patch you sent me.  The 2.1.9
>> and 2.1.10 versions would die unexpectedly, right around the time the
>> "Info: ... ... adding new socket command file
>> /var/run/radiusd/radiusd.sock " would scroll through the debug.  I
>> couldn't figure it out for the life of me, and strace didn't give me too
>> much - it'd just segfault right around that time.
> 
>   Don't use strace to track down SEGVs.  It won't help.
> 
>   See doc/bugs for instructions on tracking down SEGVs.  Those
> instructions work.
> 
>>>   Yup.  They can upgrade to a (cough) real radius server. :)
>> Turns out, they were a bit stand-offish. They didn't like their radius
>> servers being implicated in the mix.  "It's working for 30+ clients, so
>> we have no plans to upgrade".
> 
>   Exactly... "no one else has noticed a problem, so we're not going to
> fix it."
> 
>   I guess they don't fix leaks in the roof of their house.  When it
> doesn't rain, it doesn't leak.  When it rains, it's too wet to fix the leak.
> 
>> One thing I also noticed was that it it doesn't look like freeradius is
>> giving it very many tries on a packet before marking the system down.
> 
>   FreeRADIUS doesn't retry packets when proxying.  The *NAS* retries
> packets.  FreeRADIUS retransmits only when it receives a packet from the
> NAS.
> 
>> At least, that's the way it appears.  I don't know how to use wireshark
>> filters enough to find unacked packets, so I have to do that before I'll
>> be able to piece that together.
> 
>   Why use wireshark?  The server has a debug mode...
> 
>> It is also noteworthy that upon pingscanning their network, I found two
>> IP addresses that are up - and I'm getting packet loss to them.  Between
>> 4 and 7 percent, which while not a ton, might be enough to cause a
>> problem if I'm relaying thousands of packets an hour.
> 
>   Yup.
> 
>> Thanks for the help, Alan. I appreciate it.
> 
>   It's what I do.
> 
>   Alan DeKok.

-- 
Adam