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 -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
