[wpan-tools issue]wpan-ping: recv() function for receiving wpan-ping packets

[wpan-tools issue]wpan-ping: recv() function for receiving wpan-ping packets

[Xue Wenqian]

Hi,

Recently I find a wpan-ping problem: wpan-ping process is always
running, when there is another process runing on wpan interface, which
will also transmit packets via wpan, the non-wpanping packets will also
be received by recv() of wpan-ping, leading to the "Sequence number did
not match" problem. It seems that the recv() function can not filter out
non-wpanping packets.

To avoid the influences of packets transmitted by another process, I add
some codes to do the filtering for wpan-ping client and wpan-ping
server.

Do you consider this as a bug for wpan-ping? If yes, I'll submit the
modification as a new patch for discussion, thank you all!

Best Regards,
Xue Wenqian

Re: [wpan-tools issue]wpan-ping: recv() function for receiving wpan-ping packets

[Alexander Aring]

Hi,

On 12/14/2016 08:20 AM, Xue Wenqian wrote:
> Hi,
> 
> Recently I find a wpan-ping problem: wpan-ping process is always
> running, when there is another process runing on wpan interface, which
> will also transmit packets via wpan, the non-wpanping packets will also
> be received by recv() of wpan-ping, leading to the "Sequence number did
> not match" problem. It seems that the recv() function can not filter out
> non-wpanping packets.
> 

In my opinion:

So the currently known other upper layer protocol is 6LoWPAN. According
to 6LoWPAN dispatches [0]:

00 xxxxxx       0       NALP

so the wpan-ping dataframe should start with the bit pattern 00.

Then for extra stuff the payload should do some checksum stuff, e.g.
ICMPv6 at tail -> if it doesn't match drop it.

Then most frames will be filtered, the rest is the usual header parsing,
if it doesn't match there -> drop it.

Wait for original author Stefan, for his opinion... I do here some
suggestions only.

- Alex

[0] https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml

Re: [wpan-tools issue]wpan-ping: recv() function for receiving wpan-ping packets

[Stefan Schmidt]

Hello.

On 14/12/16 17:49, Alexander Aring wrote:
>
> Hi,
>
> On 12/14/2016 08:20 AM, Xue Wenqian wrote:
>> Hi,
>>
>> Recently I find a wpan-ping problem: wpan-ping process is always
>> running, when there is another process runing on wpan interface, which
>> will also transmit packets via wpan, the non-wpanping packets will also
>> be received by recv() of wpan-ping, leading to the "Sequence number did
>> not match" problem. It seems that the recv() function can not filter out
>> non-wpanping packets.

That is correct. Especially on the server side we do no filtering at all 
and just send back the (hopefully) wpan-ping frame.

Please go ahead and send your patch with the filtering you suggest and 
we can discuss what we can take and what not.


>
> In my opinion:
>
> So the currently known other upper layer protocol is 6LoWPAN. According
> to 6LoWPAN dispatches [0]:
>
> 00 xxxxxx       0       NALP
>
> so the wpan-ping dataframe should start with the bit pattern 00.

That is already done. The wpan-ping packet send out from the client 
already has this set.

> Then for extra stuff the payload should do some checksum stuff, e.g.
> ICMPv6 at tail -> if it doesn't match drop it.
>
> Then most frames will be filtered, the rest is the usual header parsing,
> if it doesn't match there -> drop it.

As written above nothing is checked or filtered on the server side yet. 
If there are good suggestions I happily take them in. Let's wait for the 
patch from Xue to see what he had in mind.

Stefan Schmidt

Re: [wpan-tools issue]wpan-ping: recv() function for receiving wpan-ping packets

[Alexander Aring]

Hi,

On 12/15/2016 10:18 AM, Stefan Schmidt wrote:
> Hello.
> 
> On 14/12/16 17:49, Alexander Aring wrote:
>>
>> Hi,
>>
>> On 12/14/2016 08:20 AM, Xue Wenqian wrote:
>>> Hi,
>>>
>>> Recently I find a wpan-ping problem: wpan-ping process is always
>>> running, when there is another process runing on wpan interface, which
>>> will also transmit packets via wpan, the non-wpanping packets will also
>>> be received by recv() of wpan-ping, leading to the "Sequence number did
>>> not match" problem. It seems that the recv() function can not filter out
>>> non-wpanping packets.
> 
> That is correct. Especially on the server side we do no filtering at all and just send back the (hopefully) wpan-ping frame.
> 
> Please go ahead and send your patch with the filtering you suggest and we can discuss what we can take and what not.
> 
> 
>>
>> In my opinion:
>>
>> So the currently known other upper layer protocol is 6LoWPAN. According
>> to 6LoWPAN dispatches [0]:
>>
>> 00 xxxxxx       0       NALP
>>
>> so the wpan-ping dataframe should start with the bit pattern 00.
> 
> That is already done. The wpan-ping packet send out from the client already has this set.
> 

but do you also check on 00 pattern when receiving?

At least you also need to check on ret value if you have seq number
there [0]. I don't see that.

With seq + crc, there could be some __packet__ header struct. :-/
Then check if ret from recv is at least this header long -> otherwise
drop it.

>> Then for extra stuff the payload should do some checksum stuff, e.g.
>> ICMPv6 at tail -> if it doesn't match drop it.
>>
>> Then most frames will be filtered, the rest is the usual header parsing,
>> if it doesn't match there -> drop it.
> 
> As written above nothing is checked or filtered on the server side yet. If there are good suggestions I happily take them in. Let's wait for the patch from Xue to see what he had in mind.
> 

ok.

- Alex

[0] https://github.com/linux-wpan/wpan-tools/blob/master/wpan-ping/wpan-ping.c#L305