Hi again, I have tried to turn off arp packets but I have still the problem. I was thinking to produce a function to reset in some way the mac if this 'get stuck' situation happen. What do you think? For be aware of blocking inside the code I could wait some attempt to send counting from application layer or from the queue...
Regards Cesare Carretti > Hi, > thank you so much for your answers! > I will try to disable ARP packet transmissions. Thank you also for the explanation, I was trying to debug p802_15_4mac but it is not so easy... I forced the queue to send packet modifying the recv function in the file > queue.cc, adding a counter and calling the resume function after a certain > number of attempts, also with the blocked flag true. It is not so elegant > but it helped me to understand something more! > > Regards > > Cesare Carretti > >> Hi there, >> this failure should most probably relate to the busy_rx state returned after the call to switch the radio to transmit. >> This happens basically in two different situations, >> one is during the association and the other one is during sending/CCA. If during the CCA a packet arrives, this packet gets falsely received and >> thus, upon the call to switch, the function to switch the radio state returns with a busy_rx, that doesn't get handled and thus the whole sending process gets stuck. As there is still the outgoing packet within >> the mac, the enforcement of an additional sending - by the way, how did you manage/implement that one? - leads to a task overflow. >> The arp only diminishes the probability of this failure happening, as it >> shortens the time for packet processing at the node... >> -------- Original-Nachricht -------- >>> Datum: Thu, 18 Oct 2007 18:11:48 +0200 >>> Von: Stefano Busanelli <[EMAIL PROTECTED]> >>> An: "Cesare M. Carretti" <[EMAIL PROTECTED]> >>> CC: ns-users@ISI.EDU >>> Betreff: Re: [ns] Bug in 802.15.4? >>> In the past I'd had noticed a similar strange behavior: in fact, during >>> some simulation runs, nodes didn't transmit packets, seemingly without no reason, while in other simulations nodes transmitted normally. I had solved the problem disabling ARP packet transmissions. >>> In the mailing list archive there are many threads that explain how to do this. >>> Regards >>> Stefano Busanelli >>> Il giorno gio, 18/10/2007 alle 12.33 +0200, Cesare M. Carretti ha scritto: >>> > Hello all, >>> > I am implementing a distributed algorithm for sensor network, and I >>> wrote >>> > an application and a transport protocol simil-UDP to send data. I have a strange problem in my simulation: >>> > at some point, one node stop to send packet, it is blocked and if I >>> try >>> to >>> > force the queue to send packet, I have a task overflow error from mac >>> > layer. >>> > I still do not know why this thing happen at some point, I am trying >>> to >>> do >>> > some debugging, maybe for some collision. Anyway I think this is not normal, because it should never happen that a node stop sending data >>> (it >>> > continues to receive) at all forever, it should maybe reset itself if >>> > there is some problem. Maybe it is waiting for something? >>> > My application works very well over 802.11, so I think it should be >>> the >>> > same with 802.15.4 (of course with a different output, number of >>> packet >>> > etc). >>> > However it shouldn't stop! >>> > >>> > What do you think? >>> > >>> > best regards >>> > >>> > Cesare Carretti >>> > >> -- >> GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. >> Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail > > >
