> > If it's trying to send to a node that doesn't exist, that's strange. > It suggests memory corruption in the routing table. In theory, it > should not stick with such a node very long, as the ack-based > estimates will let it know that this is not a good node.
It seems that once it is stuck like this, it stays there until the node is reset. I am curious as to why it does not recover from this. > Looking at your trace, though, I'm a bit worried: node 33's data > packets say that it has a route ETX of 0! This seems very unlikely. > It also takes many packets for 33 to switch over. Are you sure there > is no node 80 in your network? Yes, there is no node 80 in my network. > If it is issue link-layer ACKs, then > 33 might stick with it for a while. > > I don't think net2 has ever seen behavior like this. It doesn't mean > that it's never happened, we've just never observed it. > > Phil I went ahead and reset the two suspect nodes yesterday and as expected, they started sending data into the network again. This morning, I discovered that one of them was trying to send through a node 2 this time. (node 2 is not in the network). It does retry 30 times every 5 minutes (that is my programmed interval for reporting). I disconnected the Root node and then powered it back up after a few minutes. I have attached a small log file showing some extra bytes in the beacon packet every once in a while. I have also noticed that I get bits shifting in the messages every once in a while (seems odd given that there is a checksum). I am wondering if there could be packet corruption causing routing corruption???? One other note is that once the node was stuck on trying to send to Node 2, I noticed it no longer sends out its routing table info every once in a while. Wondering where to look next... Best regards, Todd
45 00 FF FF 00 00 07 22 18 00 74 00 00 00 00 00 86 10 7E 7E 45 00 FF FF 00 00 07 22 18 00 75 00 00 00 00 00 26 55 7E 7E 45 00 FF FF 00 00 07 22 18 00 76 00 00 00 00 00 C6 9B 7E 7E 45 00 FF FF 00 00 07 22 18 00 77 00 00 00 00 00 66 DE 7E 7E 45 00 FF FF 00 00 07 22 18 00 78 00 00 00 00 00 65 1B 7E 7E 45 00 FF FF 00 00 07 22 18 00 79 00 00 00 00 00 C5 5E 7E 7E 45 00 FF FF 00 00 07 22 18 00 7A 00 00 00 00 00 25 90 7E 7E 45 00 FF FF 00 00 07 22 18 00 7B 00 00 00 00 00 85 D5 7E 7E 45 00 FF FF 00 00 07 22 18 00 7C 00 00 00 00 00 C4 1D 7E 7E 45 00 FF FF 00 00 07 22 18 00 7D 5D 00 00 00 00 00 64 58 7E 7E 45 00 FF FF 00 00 07 22 18 00 7D 5E 00 00 00 00 00 84 96 7E 7E 45 00 FF FF 00 00 07 22 18 00 7F 00 00 00 00 00 24 D3 7E 7E 45 00 00 00 00 22 14 22 17 00 01 00 00 00 1F D6 0B 00 1F 00 FF 0F 77 0B 69 08 05 0F FD 49 3F 7E 7E 45 00 FF FF 00 00 07 22 18 00 80 00 00 00 00 00 9B 87 7E 7E 45 00 FF FF 00 00 07 22 18 00 81 00 00 00 00 00 3B C2 7E 7E 45 00 FF FF 00 00 07 22 18 00 82 00 00 00 00 00 DB 0C 7E 7E 45 00 FF FF 00 00 07 22 18 00 83 00 00 00 00 00 7B 49 7E 7E 45 00 FF FF 00 00 07 22 18 00 84 00 00 00 00 00 3A 81 7E 7E 45 00 FF FF 00 00 07 22 18 00 85 00 00 00 00 00 9A C4 7E 7E 45 00 FF FF 00 00 07 22 18 00 86 00 00 00 00 00 7A 0A 7E 7E 45 00 FF FF 00 00 07 22 18 00 87 00 00 00 00 00 DA 4F 7E 7E
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
