TX error due to colision or erroneous TX
David Gibson
david at gibson.dropbear.id.au
Wed Feb 27 14:54:46 EST 2002
On Tue, Feb 26, 2002 at 10:13:42PM -0500, Amit Jain wrote:
>
>
> On Tue, 26 Feb 2002, Amit Jain wrote:
>
> > On Tue, Feb 26, 2002 at 07:09:00PM -0500, Amit Jain wrote:
> > >
> > > But the surprising thing is that card raised the interrupts corresponding
> > > to HERMES_EV_TX and not HERMES_EV_TXEXC. ??
> > >
> > > Since there are no other stations in the n/w, it is impossible for my
> > > laptop to recevie an ACK for the transmitted packet. So if TX is
> > > based on 802.11 ACK protocl, then in this cse function handler
> > > corresponding to EV_TXC should have been called. I do not understand
> > > I am getting "Successful transmission signal" as indicated by EV_TX.
> > > (in 802.11 succesfull packet trnasmission means that the packet was
> > > trnamitted correctly and subsequent ACK received correctly)
>
> > I think this must be because the ARP is failing. ARP requests are
> > broadcast packets, and for obvious reasons these wouldn't be ACKed.
>
> I guess I am talking about low-level(802.11) MAC Acknowledgement protocol.
> Acoording to this protocol, for every TX packet, the transmitter has to
> receive an ACK (at physical layer itself, i.e. ACK doesnot propage up the
> protocol stack when ACK is recvd by the original transmitter).
> Only, after the ACK is recvd, another packet is transmitted.
> Otherwise based on timeout and 'number of retries mechanism', same packt
> would be tried by the actual H/w (n/w card)
> Being at low-level, it doesnot care whther it is a broadcast pkt or other.
> ARP kind of thing, or for that matter broadcast packets being not ACKed
> are taken care by higher layetrs in the stack.
I realise you're talking about the MAC level protocol ACKs. However,
it *does* matter whether it's a broadcast packet or not (at least in
an ad-hoc network). It's fairly clear that ACKs couldn't be required
for broadcast packets, because the sending station doesn't know how
many stations there are, so it doesn't know how many ACKs to wait for.
IEEE 802.11, section 9.2.8:
Upon successful reception of a frame of a type that requires an
acknowledgement with the ToDS bit set, an AP shall generate an
ACK frame. An ACK frame shall be transmitted by the destination
STA that is not an AP, whenever it successfully receives a
unicast frame of a type that requires an acknowledgement, but not
if it receives a broadcast or multicast frame of such type....
In addition it appears (IEE 802.11, section 9.7) that ACKs are only
required after data frame fragments, not after data frames which are
transmitted without fragmentation.
--
David Gibson | For every complex problem there is a
david at gibson.dropbear.id.au | solution which is simple, neat and
| wrong. -- H.L. Mencken
http://www.ozlabs.org/people/dgibson
More information about the wireless
mailing list