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

Hrishikesh Shelar hshelar at umich.edu
Wed Oct 8 18:09:07 EDT 2014


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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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/cd88ca1c/attachment-0002.html>


More information about the USRP-users mailing list