WiMAX TLV value correct in debug but not correct in packet capture
James Leavitt
james.leavitt at corp.xplornet.com
Wed Jul 31 20:14:09 CEST 2013
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 debug but not correct in packet capture
>
> 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
> <james.leavitt at corp.xplornet.com> wrote:
>
> > 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 though, I did *try* a change in the dictionaries in a
> > vain attempt solve this issue (tried the included wimax and wichorus),
> > but I rolled them back. I also compiled 3.0.0 and installed in a new
> > location, and never touched those dictionaries at all, same bizarre
> problem.
> >
> > If the binaries are broken, then I now have two sets of broken binaries
> > (granted they are on the same platform so perhaps it's a library
> problem?).
> >
> > Perhaps I should install a whole new system / os and test on it to see
> > if a similar problem exists. What I will try now is another TLV and see
> > how it behaves.
> >
> > Thanks,
> >
> > James
> >
> >
> >
> >
> > On 07/31/2013 01:19 PM, Alan DeKok wrote:
> >> Re: WiMAX TLV value correct in debug but not correct in packet capture
> >>
> >> 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
> >>>>
> >>>
> >>> --
> >>>
> >>>
> >>
> >>> <1370_tlv_issue.pcap>
> >>> -
> >>> List info/subscribe/unsubscribe? See
> >> http://www.freeradius.org/list/users.html
> >> -
> >> List info/subscribe/unsubscribe? See
> >> http://www.freeradius.org/list/users.html
> >>
> > -
> > List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
> --
> This message has been scanned by MailScanner
>
More information about the Freeradius-Users
mailing list