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

[Alan DeKok]

  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 changes have you made, and why?

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.
> 
> Thanks,
> 
> James
> 
> 
> 
> 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"
>> file:
>> 
>> 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
>> http://www.freeradius.org/list/users.html
>> 
>> --
>> 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
> 
> <1370_tlv_issue.pcap>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html