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
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
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.
James Leavitt wrote:
After some compiling and configuring, I've managed to get version 3.0.0
up and running, and I seem to be having a similar issue:
I don't see that on my systems. radsniff, radclient, and pcap all
show that the WiMAX attributes are correct.
Data: 1a 17 00 00
HI Alan,
Still no dice. I've disabled the database and used the file as suggested
(which is something that I had yet to try, but as you recommended I've
done so). I have tried with and without the Session-Timeout and
Acct-Interim-Interval without any effect.
Here's the hex output (from the
You've done something to the dictionaries. What is it?
Alan DeKok.
On 2013-07-31, at 10:57 AM, James Leavitt james.leav...@corp.xplornet.com
wrote:
HI Alan,
Still no dice. I've disabled the database and used the file as suggested
(which is something that I had yet to try, but as you
See the hex output. The 00 00 60 b5 is the WiMAX forum vendor ID. Your
debug output has 00 01 04 45 in the same place. So either the dictionaries
are broken, or the binaries are broken.
Either way, this problem doesnt appear in a stock install with the stock
dictionaries.
So what
Sorry Alan,
I left that part out since it is coming through ok, here's the whole
thing (you can see the 00 00 60 b5 after the 1a 17):
1a 17 00 00 60 b5 1c 11 00 01 04 45 b7 02 04 cf b7 03 06 cf b7 01 00
1a 17 00 00 60 b5 1c 11 00 01 04 45 b7 02 04 d2 b7 03 06 d0 b7 00 00
Interesting theory
If you're asking for help, it's a good idea to be honest about it. Editing
the hex output and *not* saying so is rude
The reason I asked for the hex output is because I wanted the hex output. I
didn't want a butchered version of he hex output.
On 2013-07-31, at 1:19 PM, James Leavitt
Understood Alan,
As I admitted I should have followed your example and copied the whole
VSA, not just the TLV section, again mea culpa.
I did however include the PCAP as you had requested, which has the works.
James
On 07/31/2013 02:34 PM, Alan DeKok wrote:
Re: WiMAX TLV value correct in
I havent looked at the pcap file, but I'm sure it says the same thing. The
WiMAX VSA is wrong. I don't know why. It works for me, using the default
configuration.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Strange indeed.
I just rebuilt a new server on a newer os (and 64 bit vs 32), and I am
still seeing the same issue.
I must have something messed up somewhere. Only thing is order of the
whole structure is different from my prod, but that shouldn't matter.
Here's my eap.conf just in case there
I've just tried other TLVs and the same problem, meanwhile everything
that is not a TLV works.
Thanks,
James
On 07/31/2013 05:10 PM, James Leavitt wrote:
Re: WiMAX TLV value correct in debug but not correct in packet capture
Strange indeed.
I just rebuilt a new server on a newer os (and
James Leavitt wrote:
I just rebuilt a new server on a newer os (and 64 bit vs 32), and I am
still seeing the same issue.
Weird...
I must have something messed up somewhere. Only thing is order of the
whole structure is different from my prod, but that shouldn't matter.
It's hard to mess
James Leavitt wrote:
I've probably missed something or buggered an option, but I've searched
and searched and cannot find an answer to this. This is for a WiMAX
deployment and am using the built in dictionaries. The issue is with the
WiMAX-Packet-Flow-Descriptor tlv .
...
Everything looks
Don't forget if the hardware is Alvarion or Runcom you cannot use the
standard dictionaries.
Alvarion (now Telrad) is proprietary but similar to the standard dictionary
and Runcom only uses their own.
David
-Original Message-
From:
Thank you Gentlemen,
I am working with Alvarion CPEs but a WiChorus ASN, which I have setup
on a commercial AAA without issues. I also have Freeradius working with
WiChorus on another instance also but not for receiving these particular
TLVs.
I initially performed a tcpdump and this was where I
Ok,
After some compiling and configuring, I've managed to get version 3.0.0
up and running, and I seem to be having a similar issue:
Radsniff on the wire (verified that it is the same in tcpdump and
wireshark):
Access-Accept Id 20410.199.10.14:1812 - 10.199.20.240:6217+3.541
Version info:
radiusd: FreeRADIUS Version 2.2.0, for host i686-redhat-linux-gnu, built
on Oct 9 2012 at 17:47:30
Copyright (C) 1999-2011 The FreeRADIUS server project and contributors.
Hello Everyone,
I've probably missed something or buggered an option, but I've searched
and searched and
19 matches
Mail list logo
