Accounting packets not received

2013-08-01 Thread Gab Quidilla
Good day, We have several branches configured for RADIUS. We are using freeradius 2.1.12 from CentOS 6.4 repo, plus daloradius 0.9.9, and MySQL. The problem is that accounting packets are not received here in our head office when accessing other branches' switches. When we access our own

Re: Accounting packets not received

2013-08-01 Thread Phil Mayers
On 08/01/2013 08:51 AM, Gab Quidilla wrote: Good day, We have several branches configured for RADIUS. We are using freeradius 2.1.12 from CentOS 6.4 repo, plus daloradius 0.9.9, and MySQL. The problem is that accounting packets are not received here in our head office when accessing other

Re: Accounting packets not received

2013-08-01 Thread Gab Quidilla
Hi, thanks for the reply. I'm pretty sure that every NAS is sending accounting packets, because I am using the same config on the switches here and for other branches, the only difference is the shared secret used. On the first post is Pastebin links, with the accounting packet received after

Re: Accounting packets not received

2013-08-01 Thread Arran Cudbard-Bell
On 1 Aug 2013, at 09:35, Gab Quidilla gbquidill...@gmail.com wrote: Hi, thanks for the reply. I'm pretty sure that every NAS is sending accounting packets, because I am using the same config on the switches here and for other branches, the only difference is the shared secret used. On

Re: Accounting packets not received

2013-08-01 Thread Phil Mayers
On 08/01/2013 09:35 AM, Gab Quidilla wrote: office, it would not pass through the firewall. Accessing the branches passess through the firewall, but the fw WAN link is configured for accepting all packets Yeah... sorry, but we hear that a lot on this mailing list, and quite often the

Re: Accounting packets not received

2013-08-01 Thread Gab Quidilla
Hi, I ran radsniff. I had someone at our branch login to the switches, and still no accounting packets, while when I log into our switches, the accounting packet is received. This is somewhat network-related yes? If it helps, here's the pic of the radsniff's output:

Re: Accounting packets not received

2013-08-01 Thread Phil Mayers
On 01/08/13 10:02, Gab Quidilla wrote: Hi, I ran radsniff. I had someone at our branch login to the switches, and still no accounting packets, while when I log into our switches, the accounting packet is received. This is somewhat network-related yes? Entirely. If the accounting packets don't

Re: Accounting packets not received

2013-08-01 Thread Arran Cudbard-Bell
On 1 Aug 2013, at 11:21, Phil Mayers p.may...@imperial.ac.uk wrote: On 01/08/13 10:02, Gab Quidilla wrote: Hi, I ran radsniff. I had someone at our branch login to the switches, and still no accounting packets, while when I log into our switches, the accounting packet is received. This is

Re: WiMAX TLV value correct in debug but not correct in packet capture

2013-08-01 Thread James Leavitt
The last attempt was on a dedicated piece of hardware, not a VM. I also switched the OS to 64bit. As for the network card, since I get this in the VM system (v2 rpm and V3 compiled), and on the dedicated hardware (Fedora 19 rpm), and I am performing the capture on the radius server itself

Re: WiMAX TLV value correct in debug but not correct in packet capture

2013-08-01 Thread Alan DeKok
James Leavitt wrote: Radclient is a good suggestion, I will try it and see what happens, perhaps it will yield something interesting, perhaps a strange interaction that the client itself is causing. There is no possible client interaction which will cause the server to encode the packets

Re: WiMAX TLV value correct in debug but not correct in packet capture

2013-08-01 Thread Alan DeKok
James Leavitt wrote: Radclient is a good suggestion, I will try it and see what happens, perhaps it will yield something interesting, perhaps a strange interaction that the client itself is causing. I tried with eapol_test, TTLS / PAP, and radclient, on Linux and Mac. It works everywhere.