Hello everyone,
I'm analysing the PppRouter application due to determined packet loss of about 0.8-1% in a one-hop network consisting of one base station (PppRouter) and one network node (UDPEcho or CoapBlip) using Blip2.0. I work with UCMote Mini hardware, but the problem also appears with a Tmote node as base station. In my test network I use the following shell script to ping the network node periodically (10 pings, 10 seconds break, 10 pings, ...), TestPing.sh: #!/bin/bash COUNT=10 for ((i=1;;)) do ping6 -c $COUNT fec0::7 #send 10 ping requests to destination sleep 10 done I used Wireshark to record the IP packets on the serial PPP Interface as well as an external packet Sniffer for sniffing the wireless interface. I found out that all lost packets (sent from my PC) have been dropped on the PppRouter base station before being forwarded to the network node. So there is no evidence that packets might have been lost due to interferences on the wireless channel or for some other reason on the network node. For debugging purposes I installed the tos-pppd.patch to be able to print out debug messages to my PPP daemon console. I'd like to point out that all of these problems also occur without this tos-pppd.patch. After spending a lot of time with printing out debug messages I could identify three reasons why packets have been dropped: 1) APPROX. 0.40 PERCENT OF RECEIVED PACKETS ARE DROPPED BECAUSE THEY ARE NOT "APPROVED". /apps/PppRouter/RplBorderRouterP.nc (line 32): if statement "if (pkt->ip6_inputif == ROUTE_IFACE_PPP)" is true, but it shouldn't be! This leads in /tos/lib/net/blip/IPForwardingEngineP.nc (lines 312-313) to the packet drop. I could observe that this often happens bursty, so sometimes 7 directly in series sent ping request messages are dropped. But the problem also appears with one packet out of 10. 2) FOR APPROX. 0.09 PERCENT OF RECEIVED PACKETS NO FREE BUFFER IS AVAILABLE. /tos/lib/ppp/HdlcFramingP.nc (lines 486-488): The HdlcFramingP interface tries to put received frames in a buffer, which isn't available. Did anyone notice this kind of problem before? Why does it happen? 3) Approx. 0.37 percent of received packets contain a routing header which isn't allowed. /tos/lib/net/blip/IPPacketC.nc (from line 30) the IPPacket.findHeader command returns an offset to a header which we can't handle yet in /tos/lib/net/blip/IPForwardingEngineP.nc (from line 284) so line 289 produces the packet drop. I commented out the return instruction in line 289, so every packet apparently containing a routing header anyway was forwarded and answered correctly by the network node. So for this point, I could diminish the amount of packet loss. It works fine, but I'm not sure if this is a clean solution. Furthermore I tried to find out if any of these problems also occur with CoAP. I used a script, which sends CoAP messages periodically to a network node and measures the response time. /opt/tinyos-2.x/support/sdk/c/coap/examples/TestCoap.sh: _#!/bin/bash_ _num=1_ _while true_ _do _ _ echo "Run $num"_ _ date +%d.%m.%Y-%k:%M:%S_ _ temp=$(($(date +%s%N)/1000000)) _#save start time _ ./coap-client coap://[fec0::7]/l _ _ temp2=$((($(date +%s%N)/1000000)-$temp)) #calculate response time_ _ echo "Resp-Time: $temp2"_ _ sleep 5_ _ num=$(( $num + 1 ))_ _done_ In this setting approximately 0.6 percent of sent CoAP requests are lost due to failed packet approval (see 1) above). Neither routing header problems nor buffer problems occurred in CoAP. Did anyone notice any of these problems at the PppRouter base station before? Does anyone know how to cope with these problems? Thanks for your help! Best regards, Sebastian
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
