WiMAX TLV value correct in debug but not correct in packet capture
aland at deployingradius.com
Wed Jul 31 18:16:50 CEST 2013
You've done something to the dictionaries. What is it?
On 2013-07-31, at 10:57 AM, James Leavitt <james.leavitt at 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 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 attached pcap):
> 1c 11 00 01 04 45 b7 02 04 cf b7 03 06 cf b7 01 00
> 1c 11 00 01 04 45 b7 02 04 d2 b7 03 06 d0 b7 00 00
> And the debug snip (this is from a time I removed the other two
> *working* values):
> [ttls] Got tunneled reply code 2
> WiMAX-Packet-Data-Flow-Id := 14
> WiMAX-Service-Data-Flow-Id := 14
> WiMAX-Service-Profile-Id := 14
> WiMAX-Packet-Data-Flow-Id += 17
> WiMAX-Service-Data-Flow-Id += 17
> WiMAX-Service-Profile-Id += 17
> Attached is a pcap of the transaction indicating the TLVs are not
> consistent with the DB or the file. It has been consistent with
> radsniff, although I use tcpdump / wireshark when comparing with the
> working systems.
> One thing to note is that I am using TTLS and copying the values to the
> outer tunnel, are you performing the same in your test? I wonder if it's
> a library somewhere on the OS that's making it go awry. I keep thinking
> I've set something that would make this happen, but I cannot get over
> the fact that other values are working fine.
> On 07/31/2013 10:06 AM, Alan DeKok wrote:
>> Re: WiMAX TLV value correct in debug but not correct in packet capture
>> 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 60 b5 1c 11 00 01 04 00 0e 02 04 00 0e 03
>> 06 00 00 00 0e
>> 1a 17 00 00 60 b5 1c 11 00 01 04 00 11 02 04 00 11 03
>> 06 00 00 00 11
>> Please post a hex dump of the packets. i.e. put this into the "users"
>> bob Cleartext-Password := "bob"
>> WiMAX-Packet-Data-Flow-Id := 14,
>> WiMAX-Service-Data-Flow-Id := 14,
>> WiMAX-Service-Profile-Id := 14,
>> WiMAX-Packet-Data-Flow-Id += 17,
>> WiMAX-Service-Data-Flow-Id += 17,
>> WiMAX-Service-Profile-Id += 17
>> And run "radclient -xxxx <args>
>> to do the test. You will get a hex dump like I posted above. It
>> should be identical.
>> My guess is that you have FreeRADIUS using one WiMAX dictionary, and
>> radsniff, etc. using another. Some vendors made their own,
>> incompatible, version of the WiMAX dictionaries. Which is a stupid
>> idea, but that's what vendors do.
>> Alan DeKok.
>> List info/subscribe/unsubscribe? See
>> This message has been scanned by MailScanner
> James Leavitt
> Network Systems Architect
> Xplornet Communications Inc.
> 300 Lockhart Mill Road
> Woodstock, NB
> E7M 5C3
> Phone: (506) 324-8659
> Fax: (506) 328-1582
> Cell: (506) 324-4960
> Helpdesk: (888) 439-6511
> Email: james.leavitt at corp.xplornet.com <mailto: james.leavitt at corp.xplornet.com>
> Xplornet - Broadband Everywhere.
> GPG / SSH Public Keys in V-Card Notes
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
More information about the Freeradius-Users