[Aironet] wavelan aironet adhoc interoperability

[Jinyang Li <jinyang@ne...>]

hi there,

   Has anyone tried to make wavelan and aironet card talk to each other in ad hoc mode?
   I've tried with my airo and wavelan cards, but am unsuccessful. Specifically, I set both card to ad hoc mode and to be on same channel, e.g. 5.  I set
the SSID of aironet and ESSID of wavelan card to be the same.  (no WEP in airocard)  But they could not see each other's packets.  I wonder if anybody out there
has tried similiar things and would like to share his experiences. :-)
Many thanks in advance!

jinyang

Re: [Aironet] meaning of card generated interrupt

[<breed@al...>]

> Since I am running in ad hoc mode, I think the way to determine that the
> node to who I am trying to transmit is gone is to use the Rf layer
> transmit failure... correct??

Unfortunately, I don't have the 802.11 spec here, so I may be wrong.  (I'm
sure I'll be corrected if so...)

Before the ping is unicast, you will broadcast an ARP looking for the MAC
address of the target.  Since the node does not exist, there will be no
answer.  But, I believe that in adhoc mode broadcasts are not ACKed.  And
even if they were, an ACK of the broadcast would mean that someone received
it, not necessarily the node with the desired IP address.

ben

Re: [Aironet] meaning of card generated interrupt

[<breed@al...>]

> So basically what you are saying is that the interrupt that is triggered
> is either the results of a successful transmission (EV_TX) or failure due
> to too many failed transmissions (EV_TXEXC)???

Yes.

> Also, what is the meaning of the FID bits in the FID? It seems to me that
> the value is 32 bits, the higher end 16 meaning something and the lower
> end meaning something else.

Yeah, The low 16 bits is the FID identifier, the high 16 bits is the length
of the packet, or zero if the FID is not in use.  I need the packet length
to keep some stats up to date.

> What I am thinking about doing here is possibly adding an array to the
> driver where I could link ip addresses with the FIDs, so that when a
> packet is assigned to an FID, I assign the destination address of that
> packet to the array position corresponding to that FID. That way, when a
> EV_TXEXC event happens, I can determine to which destination that packet
> failed.. does this sound good?

Yep, the array just has to be of size MAX_FIDS.  And you can just shadow
the
fids[] array.

ben

Re: [Aironet] meaning of card generated interrupt

[Matthew Impett <mimpett@Glue.umd.edu>]

On Wed, 16 Aug 2000, Jim Veneskey wrote:

> > When the card receives a data packet to send, it will retry the send up to
> > (Long/Short)RetryLimit. Is this EV_TXEXC event a notification of one
> > failed retransmission or the whole RetryLimit failure? Also, how come this
> > event isn't generated when I try to ping an ipaddress which does not
> > exist?? I would assume this would be a transmission error also.
> 
> You're confusing a lowlevel Rf layer transmit failure with an upper layer
> ICMP failure.
> 
> If you ping a non-existant IP address wirelessly - the ping packet goes out to the
> AP and is ack'd by the AP as received. REGARDLESS of whether or not the endpoint

I forgot to mention that I am running in ad hoc mode, and I also am only
trying to send a packet one hop.

> you are pinging actually exists or not.
> As far as the client radio is concerned - it's job is done as soon as it hands the
> icmp packet over to the AP - and the AP consider's it's job done as soon as it
> spits the icmp packet out over the wire.

Since I am running in ad hoc mode, I think the way to determine that the
node to who I am trying to transmit is gone is to use the Rf layer
transmit failure... correct??

Matt

> 
> Jim
> 
> -- 
>      |          |         Jim Veneskey
>     :|:        :|:        Software Test Engineer
>    :|||:      :|||:       3875 Embassy Pkwy, Akron OH 44334
> .:|||||||:..:|||||||:.    Email: jvene@...
> 

Re: [Aironet] meaning of card generated interrupt

[Matthew Impett <mimpett@Glue.umd.edu>]

On Wed, 16 Aug 2000 breed@... wrote:

> 
> 
> The transmission refers to the transmission of an 802.11 packet to the AP
> or other 802.11 node in adhoc.  To transmit a packet we need a buffer to
> stick the packet in on the card.  This buffer is called a fid.  I
> preallocate a few and reuse them.  Once the packet is copied to a FID, I
> tell the card to transmit it.  It does its thing until the card has been
> transmitted, it arrived at the next hop in the 802.11 layer or it failed.
> Failure could be because of too many retries, not being associated to an
> AP, WEP mismatches, etc.  Either way, an interrupt is triggered.  I find
> out which FID was successfully or unsuccessfully transmitted, I update the
> stats and mark the FID as usable again.

So basically what you are saying is that the interrupt that is triggered
is either the results of a successful transmission (EV_TX) or failure due
to too many failed transmissions (EV_TXEXC)???

Also, what is the meaning of the FID bits in the FID? It seems to me that
the value is 32 bits, the higher end 16 meaning something and the lower
end meaning something else.

What I am thinking about doing here is possibly adding an array to the
driver where I could link ip addresses with the FIDs, so that when a
packet is assigned to an FID, I assign the destination address of that
packet to the array position corresponding to that FID. That way, when a
EV_TXEXC event happens, I can determine to which destination that packet
failed.. does this sound good?

> 
> The reason the ping does not produce an error is that you end up
> broadcasting (successfully) ARPs.  The fact that they are unanswered is
> meaningless to 802.11.

ok... this makes sense, thanks for the clarification.

Matt

> 
> ben
> 
> 
> Matthew Impett <mimpett@...>@csl.cse.ucsc.edu on 08/16/2000
> 12:33:26 PM
> 
> Sent by:  aironet-admin@...
> 
> 
> To:   aironet@...
> cc:
> Subject:  [Aironet] meaning of card generated interrupt
> 
> 
> 
> I am using Benjamin Reed's aironet driver and I have a question about
> something in the airo_interrupt function. I have noticed that when a
> transmission fails, the card generates an interrupt of type
> EV_TXEXC. However, I am not sure what sort of transmission failure this
> represents.
> 
> When the card receives a data packet to send, it will retry the send up to
> (Long/Short)RetryLimit. Is this EV_TXEXC event a notification of one
> failed retransmission or the whole RetryLimit failure? Also, how come this
> event isn't generated when I try to ping an ipaddress which does not
> exist?? I would assume this would be a transmission error also.
> 
> What I ideally want to do is put a hook into the driver which
> would determine when at attempted send has failed RetryLimit times, then
> determine the destination to which this send failed, and then pass this
> information up to a user space process.
> 
> Finally, I am curious as the what the FIDs are and what they are used for
> in the driver.
> 
> Thanks a lot,
> 
> Matthew Impett
> <mimpett@...>
> 
> 
> _______________________________________________
> Aironet mailing list  -  Aironet@...
> http://csl.cse.ucsc.edu/mailman/listinfo/aironet
> 
> 
> 
> 

Re: [Aironet] meaning of card generated interrupt

[Jim Veneskey <jvene@bi...>]

> When the card receives a data packet to send, it will retry the send up to
> (Long/Short)RetryLimit. Is this EV_TXEXC event a notification of one
> failed retransmission or the whole RetryLimit failure? Also, how come this
> event isn't generated when I try to ping an ipaddress which does not
> exist?? I would assume this would be a transmission error also.

You're confusing a lowlevel Rf layer transmit failure with an upper layer
ICMP failure.

If you ping a non-existant IP address wirelessly - the ping packet goes out to the
AP and is ack'd by the AP as received. REGARDLESS of whether or not the endpoint
you are pinging actually exists or not.
As far as the client radio is concerned - it's job is done as soon as it hands the
icmp packet over to the AP - and the AP consider's it's job done as soon as it
spits the icmp packet out over the wire.

Jim

-- 
     |          |         Jim Veneskey
    :|:        :|:        Software Test Engineer
   :|||:      :|||:       3875 Embassy Pkwy, Akron OH 44334
.:|||||||:..:|||||||:.    Email: jvene@...

Re: [Aironet] meaning of card generated interrupt

[<breed@al...>]

The transmission refers to the transmission of an 802.11 packet to the AP
or other 802.11 node in adhoc.  To transmit a packet we need a buffer to
stick the packet in on the card.  This buffer is called a fid.  I
preallocate a few and reuse them.  Once the packet is copied to a FID, I
tell the card to transmit it.  It does its thing until the card has been
transmitted, it arrived at the next hop in the 802.11 layer or it failed.
Failure could be because of too many retries, not being associated to an
AP, WEP mismatches, etc.  Either way, an interrupt is triggered.  I find
out which FID was successfully or unsuccessfully transmitted, I update the
stats and mark the FID as usable again.

The reason the ping does not produce an error is that you end up
broadcasting (successfully) ARPs.  The fact that they are unanswered is
meaningless to 802.11.

ben


Matthew Impett <mimpett@...>@csl.cse.ucsc.edu on 08/16/2000
12:33:26 PM

Sent by:  aironet-admin@...


To:   aironet@...
cc:
Subject:  [Aironet] meaning of card generated interrupt



I am using Benjamin Reed's aironet driver and I have a question about
something in the airo_interrupt function. I have noticed that when a
transmission fails, the card generates an interrupt of type
EV_TXEXC. However, I am not sure what sort of transmission failure this
represents.

When the card receives a data packet to send, it will retry the send up to
(Long/Short)RetryLimit. Is this EV_TXEXC event a notification of one
failed retransmission or the whole RetryLimit failure? Also, how come this
event isn't generated when I try to ping an ipaddress which does not
exist?? I would assume this would be a transmission error also.

What I ideally want to do is put a hook into the driver which
would determine when at attempted send has failed RetryLimit times, then
determine the destination to which this send failed, and then pass this
information up to a user space process.

Finally, I am curious as the what the FIDs are and what they are used for
in the driver.

Thanks a lot,

Matthew Impett
<mimpett@...>


_______________________________________________
Aironet mailing list  -  Aironet@...
http://csl.cse.ucsc.edu/mailman/listinfo/aironet

[Aironet] meaning of card generated interrupt

[Matthew Impett <mimpett@Glue.umd.edu>]

I am using Benjamin Reed's aironet driver and I have a question about
something in the airo_interrupt function. I have noticed that when a
transmission fails, the card generates an interrupt of type
EV_TXEXC. However, I am not sure what sort of transmission failure this
represents. 

When the card receives a data packet to send, it will retry the send up to
(Long/Short)RetryLimit. Is this EV_TXEXC event a notification of one
failed retransmission or the whole RetryLimit failure? Also, how come this
event isn't generated when I try to ping an ipaddress which does not
exist?? I would assume this would be a transmission error also.

What I ideally want to do is put a hook into the driver which
would determine when at attempted send has failed RetryLimit times, then
determine the destination to which this send failed, and then pass this
information up to a user space process.

Finally, I am curious as the what the FIDs are and what they are used for
in the driver.

Thanks a lot,

Matthew Impett
<mimpett@...>

[Aironet] Re : Aironet AIR-LMC342 XmitPower

[Jean Tourrilhes <jt@bo...>]

Bruce Schulte wrote :
> hey! we dropped cisco and went back to the big LU (Wavelan)...
[...]
> hey, Cisco really pissed us off with there "new improved aironets" !

	The Wavelan IEEE has been 30 mW right from the start, so
Aironet just step back to the level of the competition. In other
words, I find your complain about Tx power a bit unfair, because
nobody sells 100 mW anymore, and Cisco did improve their sensitivity
in return.
	For price and availability, that's always a bit more
contentious, but there are vendors much worse than Aironet/Cisco, and
every vendor (even Lucent) has its weakness :-(
	Anyway, the important is that you enjoy what you have. So tell
us how much you are happy ;-)

	Jean