My comments may not be strictly relevant - I've only worked on BLIP on the CC2420 but had the same issues. I have a couple of suggestions from what I saw on the CC2420. These are mostly debugging tips.
1. Debugging both routing and duplication at the same time is quite tricky. Make sure you first test with static routing alone like you did in the 2nd half of your email. Also, make sure you test by sending very few packets and tracing their path very carefully through all the modules. Printf tracing like you did is the best option. Make sure you have a stable test setup to keep your tests repeatable. 2. Do you have access to some way of sniffing packets in the air? Perhaps a network sniffer? I once found that some code I'd written was inadvertently messing up checksums. This was causing what I thought were dupes. Catching this with a sniffer is extremely simple. Using the PPPRouter like you did is tricky - the node that's sniffing is often part of the problem so it's hard to say what's wrong. 3. Do you have hardware address recognition turned on/off? Does the rest of your code make any assumptions about this? Same for hardware acks. BLIP on CC2420 works reliably only with hardware address recognition turned on (and naturally hardware ACKs turned on) Your mail is incredibly detailed (which is awesome), but I must admit I haven't gone through all the logs yet. I'm sorry if I missed something you've already covered. The Ieee154Receive fanout problem is definitely likely to be an issue. -Srikanth On Sat, May 3, 2014 at 2:26 PM, I-tek <[email protected]> wrote: > Hello everybody, > > I am working on some measurements concerning tinyos' network stack > (mainly blip). Unfortunately I have gotten into some trouble. When I > program my three test-nodes (Atmega 128RFA1) with PPPRouter (1x) and > UDPEcho (2x), the traffic those nodes produce is showing a really > strange behaviour including very many duplicates. > > Besides: I am using Mr Maroti's blip2-patch branch of tinyos > (https://github.com/mmaroti/tinyos-main.git) with some custom patches > concerning the missing const typedefs (for newer gcc versions) and the > busy wait forever loop problem (from tinyos-main github: > c30c48d863194287a5b8fb841c37de8bb9ffb85f). > > The traffic I have monitored (for the 2 UDPEcho-nodes via serial > interface and for the PPPRouter node via wireshark on the > ppp-connection) is showing packet bursts. > > > THE SCENARIO: > I have sent a single ICMP-ping request to one of the UDPEcho nodes (e.g. > ping6 fec0::2 -c 1). > After the packet traveled successfully over the ppp-Connection the radio > part begins. > The nodes, having reporting (PFLAGS += -DREPORT_DEST=\"fec0::100\") > activated, try to send a UDP packet to the host "fec0::100". Thus these > are routed by the PPP-node (since it's the default route) successfully. > Now the problem starts: Looking at wireshark's output the nodes seem to > send report packets in bursts of 15 ones (in less than 600ms) instead. > This looked strange but all had different data content. > > To take a closer look at these bursts I sent a single ICMP ping request > to one of the nodes (fec0::3) (using provided ICMP echo by blip's > standard configuration). The result was a heavy storm of packets between > the nodes and a lot of duplicates traveling through the ppp-connection > (as show in the wireshark capture). Since ICMP packets provide sequence > numbers and hop limits on their own, it was remarkable to see that the > burst's sent duplicates with decreasing hop limit number while showing > the same sequence number. > This might refer to some ping-pong ;) between the nodes and then sending > them through ppp. I guess the problem lies in a higher layer since the > UniqueLayerC assigns new low layer sequence numbers to the packets that > are sent. (Or is this resending an ack problem?) > Anyways, looking in the logs I found some "IPDispatch: IPLower.send: > Couldn't get valid sendinfo" which weren't showing up constantly. > > > REMARKS: > > For further debugging I have put some additional printfs in blip's > source. Those can be seen in the serial-logfiles of the nodes. (well the > logs look a bit messy, sry) > The wireshark capture shows the ping request as well as the reply. > ((While capturing the logs I turned off the UDP-reporting)) > > Varying the values for SOFTWARE_ACKS between 1000 and 5000 micros didn't > help either. > > When I am compiling any of the programs a warning shows up: > "nesc: calls to Ieee154Receive.receive in TinyOSNetworkLayerC__0 fan > out, but there is no combine function specified for the return type." > I have compiled the code for Iris and ucmini too and they where showing > the same warning. (Ok that's quite reasonable since they were changed in > a similar way by the blip2-patch) Only telosb didn't (CC2420 anyways). > (This might be a problem if the MessageBuffers aren't exchanged properly > or there is no return value?) > > > Static routing -> the same: > Moreover I have tried to use another scenario with static link routing. > I have turned off RPL and interfaced the ForwardTable of IPStackC to > load my routes. > They were: (3)---(2)---(1)---(PC) > > 3: fec0::3 UDPEcho > 2: fec0::2 UDPEcho > 1: fec0::1 PPPRouter > PC: fec0::100 & fec0::FFFF > > Routing table entries looked like: > > -fec0::1/128 fe80::22:ff:fe00:1 1 > -fec0::3/128 fe80::22:ff:fe00:3 1 > -fec0::ffff/128 fe80::22:ff:fe00:1 1 > > for node 2 (as an example). > > But I have experienced very similar results. > > > I barely remember I have tried a similar setting with three nodes > (1)---(2)---(3) with node 1 being a UDP packet sender and the other two > running UDPEcho. Although without ppprouter, the problems were the same. > > > > I know, this have been loads of information but I am a bit stressed out. > I just hope somebody will come up with an idea how to solve this burst > problem. If you need further data, just request it. > > > Thank you very much in advance > Jonas > > > > > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
