Hii, I have similar problem but mine is related to sleeping state of nodes. When i set sleep time a value. After that time my nodes spend most of their time in sleep mode. I m using AODV over 802.15.4. So all packets drop becasue of the routing hole. And another question about ARP disabling. Becasue i remove all headers including ARP headers. I didnt understand why you are changing C++ code. Removing ARP headers can use to disabling ARP protocol. I confused. It should be so. If packet doesnt have ARP headers how it can use ARP protocol. Can u explain me why you need to change c++ code.Thank u in advance
Regards Bilge. On 10/23/07, Cesare M. Carretti <[EMAIL PROTECTED]> wrote: > > > 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 > > > > > > > > > > >
