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

[James Leavitt]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1370_tlv_issue.pcap
Type: application/vnd.tcpdump.pcap
Size: 2107 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20130731/b69946f2/attachment.bin>