any iwevent support in 802.11b drivers?

[Jean Tourrilhes]

On Wed, Aug 07, 2002 at 02:50:46PM -0400, Jim Kaba wrote:
> Jean Tourrilhes wrote:
> 
> >         Major drivers are done, but not fully integrated yet, check
> > status and other details at :
> >         http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html#wext
> 
> I just checked out some of the patches  --  looks good so far and very
> straight-forward!  I don't know what kind of feedback you've gotten, but I
> think these events are important from the "usability" point of view.  I'm
> doing Ad Hoc networking, and these events really hit the spot.

	Thanks. It means that I'm doing my job ;-)
	Feedback is low on iwevent, because not many people do Ad-Hoc
routing in real (everybody does ns2). People are more interested in
the scanning stuff.

> Question/suggestion:  The TXDROP event for Retry Error and lifetime
> exceeded really help handle mobility events in Ad Hoc networks, as you
> probably know, and they give a real performance boost.  What would also be
> helpful would be to actually have a copy of the skb whose transmission
> failed.  The idea is that the TXDROP event warns you that the neighbor has
> moved, which helps you route *future* packets correctly.  However, if the
> TXDROP event also returned the skb that caused the error, we would get
> another chance to transmit that packet (unicasted to another neighbor, or
> broadcasted) successfully.
> 
>   My idea would be to NOT do the kfree_skb() in the main XMIT routine of
> the driver.  Instead, the kfree_skb() would be done in the ev_tx or
> ev_txexc driver callbacks--only after the hardware has attempted and
> succeeded or failed at transmission.  In the case of failure, the skb ptr
> could be passed (using the char *extra parameter??) out with the event.

	Nope. No way. I won't let you do that.

	Problem number 1 is overhead. Events are generated even if
there is no listener, and go to all listener. And the delivery
mechanism is not super efficient. Overhead is very much a concern.
	Problem number 2 is about separations of functionality and
layering. Wireless Extensions is within the management plane of layer
2 and should not have anything to do with Tx/Rx. Don't mix signalling
and data.
	Problem number 3 is security risk. Any user can listen to
packet from other users. Actually, how do you know the packet returned
back are yours ?
	Problem number 4 is that this contradict the whole layering of
the protocol stack, where the transport (TCP) is supposed to do this
job *if needed* (and not in case of UDP/RTP). You should not do it
*outside* the transport, because the transport knows it best.
	Problem number 5 is that Alan and David would shot me dead if
I did something that ugly.

>   Having access to the skb would be meaningless for user space event
> handlers.  However, any routing protocol that works in kernel space could
> access the skb and process it intelligently.
> 
>   Having just seen the code, I'm sure there are some subtleties I'm missing
> (e.g. multiple TX queues might confuse things... And multiple readers of
> the netlink socket might cause problems...but there may be ways to work
> that out by marking skbs as cloned or shared or something.)
> 
>   Has anyone raised this idea to you, or have you considered it before?  If
> other people have asked for the TXDROP event support, they will be asking
> for the skb next.
> 
> Jim

	I think you approach the problem from the totally wrong angle,
and resending the old packet is a pretty stupid idea.

	This is IMHO what needs to be done :
		o driver generate TXDROP
		o TXDROP is propagated to routing protocol
		o routing regenerate routing tables and resend them to peers
	<There is no point is resending the dropped packet containing the
old routing table and you have everything to gain in regenerating a
new packet with the new routing tables>
		o routing send notification to transport (TCP or else)
		o transport check unacknowledge packet queue and start re-Tx
	<There is no point is resending the dropped packet, because
the transport knows perfectly well which packets need to be
retransmitted, and in which order, and can actually decide to transmit
instead a packet with higher priority, or to just drop it>

	You see that the approach described above achieve similar
results (you might have a few extra re-Tx if you are not extra
carefull), but with a much better and cleaner design, and is much more
flexible and extensible.
	For example, if you are in infrastructure mode, you may decide
to propagate the "APADDR" event through the same way, so that even if
you don't transmit you can adapt to roaming timely.

	You might wonder, why do I explain that to you in so much
details ? For some of the work I'm doing, I need to above architecture
(especially the TCP notification). If you can implement it, I would be
very grateful. Consider that the price to pay for being able to use
TXDROP ;-)

	Have fun...

	Jean