[USRP-users] USRP x310 does not reply to IP packets of odd length?

Matt Ettus matt at ettus.com
Wed Oct 8 18:30:11 EDT 2014


And you are using it with 1G ethernet?

On Wed, Oct 8, 2014 at 3:09 PM, Hrishikesh Shelar <hshelar at umich.edu> wrote:

> Hi Matt,
>
> I'm using the x310. My logic reacts to ip packets destined to address X. I
> can see it react to even length packets but not to odd length packets.
> They don't seem to come out from the simple_gemac.
>
> Thanks,
> Hrishi
>
>
> On Wednesday, October 8, 2014, Matt Ettus <matt at ettus.com> wrote:
>
>>
>> The USRP should be able to deal with odd length packets, but this is a
>> capability which is almost never used.  Which USRP are you using?
>>
>> Matt
>>
>> On Wed, Oct 8, 2014 at 2:53 PM, Hrishikesh Shelar via USRP-users <
>> usrp-users at lists.ettus.com> wrote:
>>
>>> Hi Marcus,
>>>
>>> Thanks! This definitely helps me in my debugging process. I found this
>>> article
>>> http://www.cisco.com/c/en/us/support/docs/field-notices/610/fn61087.html
>>> that describes my problem exactly. Also the USRP uses a GMII interface
>>> right? (looking at the source code) I think I have to sniff some more to
>>> see if that pad byte is being sent or not from my end and change/configure
>>> my NIC accordingly. Is it safe to assume then that the USRP cannot decode
>>> odd length packets and expects even length packets?
>>>
>>> Thanks again,
>>> Hrishi
>>>
>>> -----------------
>>>
>>> Hi Hrishi,
>>>
>>> you seem to be far more experienced in this matter than I could claim to
>>> be, however I have one suspicion:
>>> If I remember correctly, ICMP dictates that packets of odd length are
>>> padded with a zero byte before checksum calculation.
>>> And *if* I remember a discussion among students on a project correctly,
>>> there are default implementations employing lwip (which happens to be
>>> the IP stack on USRPs, at least on the N2x0 series) that simply "round
>>> down" to the next multiple of 2, because no one ever uses odd packet
>>> lengths...
>>>
>>> Now, you would be seeing a broken package, unless your network card was
>>> smart enough to offload ICMP checksum checking. Maybe that's a feature
>>> you can disable?
>>>
>>> Greetings,
>>> Marcus
>>>
>>>
>>> On Wed, Oct 8, 2014 at 12:05 PM, Hrishikesh Shelar <hshelar at umich.edu>
>>> wrote:
>>>
>>>> Sorry I misspoke.
>>>>
>>>> For the 513 length ping packets the 60 byte reply seen on wireshark
>>>> wasn't a reply to the ping, it was an ICMP information request which the
>>>> USRP does nominally. So essentially there was no reply.
>>>>
>>>> Thanks again,
>>>> Hrishi
>>>>
>>>> On Wed, Oct 8, 2014 at 11:45 AM, Hrishikesh Shelar <hshelar at umich.edu>
>>>> wrote:
>>>>
>>>>> Hey all,
>>>>>
>>>>> I was observing some weird behavior while testing out transfer of IP
>>>>> packets to and from the USRP. It seems as though the USRP can't correctly
>>>>> parse packets that are odd in length. I was seeing odd length packets leave
>>>>> my machine (using wireshark) but failed to see my custom USRP logic react
>>>>> accordingly. Everything works if packets are even in length. At first I
>>>>> thought it was a problem with my logic but I ran extensive testbenches and
>>>>> couldn't pinpoint the error. So I decided to the USRP itself without my
>>>>> logic in it and observed the same behavior. Using wireshark to sniff the
>>>>> packets here is what I observed: (my USRP IP is 192.168.1.3)
>>>>>
>>>>> From a Windows terminal
>>>>>
>>>>> ping 192.168.1.3 works
>>>>> ping -l 512 192.168.1.3 works; reply packets are also 512 bytes long
>>>>> ping -l 513 192.168.1.3 doesn't work: wireshark reports reply packets
>>>>> are 60 bytes long
>>>>> ping -l 5 192.168.1.3 doesn't work: wireshark reports reply packets
>>>>> are 60 bytes long
>>>>>
>>>>> Any odd length doesn't work.
>>>>>
>>>>> From a Linux terminal
>>>>>
>>>>> ping 192.168.1.3 works
>>>>> ping -s 512 192.168.1.3 works: reply packets are 520 bytes long
>>>>> ping -s 513 192.168.1.3 doesn't work: wireshark reports reply packets
>>>>> are 60 bytes long
>>>>> ping -s 5 192.168.1.3 works; reply packets are 60 bytes long
>>>>>
>>>>> Any odd length above 17 doesn't work.
>>>>>
>>>>> Any clue as to why this is happening? Also it seems as though the USRP
>>>>> nominally uses packets that are even in length so this error wouldn't have
>>>>> come up before?
>>>>>
>>>>> Thanks,
>>>>> Hrishikesh Shelar
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
> --
> Sent from GMail Mobile
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141008/426bc1d9/attachment-0002.html>


More information about the USRP-users mailing list