rtap mode.

[David Woodhouse]

( I approved your mails, which were rejected by the list because they're
  HTML. I'd really not make a habit of that -- please could you send
  plain text? Thanks. )

On Mon, 2007-12-10 at 10:33 -0500, Michail Bletsas wrote:
> David Woodhouse <dwmw2 at infradead.org> wrote on 12/09/2007 11:11:50 PM:
> > That's fair enough (well, almost. Actually it would be useful to be able
> > to inject packets). 
> 
> I agree and its something that we are working on it. The goal is to
> have a "thin mac" firmware that will move all operations to the host. 
> Useful for things like a SoftAP or just plain experimentation with the
> radio. 

Indeed.

> > 
> > However, I cannot use the _normal_ interfaces (eth0, msh0) while the
> > rtap interface exists. The transmit and receive paths are both broken --
> > and if I attempt to fix them, I think I crash the firmware. It doesn't
> > seem to like me attempting to transmit while it's in rtap mode, and
> > certainly doesn't seem to manage to scan or associate. 
>
> That is a bug and it wasn't always like that. 

Really? Where can I look for a working version? It seems to have been
like that from the moment it landed in the OLPC git tree, certainly:
http://dev.laptop.org/git?p=olpc-2.6;a=commitdiff;h=722a3c3d

That aborts both TX and RX paths (the latter by feeding all incoming
packets to the rtap device instead of either eth0 or msh0. And as I
said, the firmware doesn't seem to manage to scan or associate (or
remain associated) either.

I've tried to fix the RX path, at least in mesh mode, with the following
patch (on top of the other cleanups which I just sent upstream):

--- a/drivers/net/wireless/libertas/rx.c
+++ b/drivers/net/wireless/libertas/rx.c
@@ -155,8 +155,10 @@ int lbs_process_rxed_packet(struct lbs_private *priv, struct sk_buff *skb)
 
 	skb->ip_summed = CHECKSUM_NONE;
 
-	if (priv->monitormode != LBS_MONITOR_OFF)
-		return process_rxed_802_11_packet(priv, skb);
+	if (priv->monitormode != LBS_MONITOR_OFF) {
+		struct sk_buff +rtap_skb = skb_copy(skb, GFP_ATOMIC);
+		process_rxed_802_11_packet(priv, skb);
+	}
 
 	p_rx_pkt = (struct rxpackethdr *) skb->data;
 	p_rx_pd = &p_rx_pkt->rx_pd;

... and then I do indeed get packets on both rtap0 and msh0, but the
latter are nonsense. I haven't yet investigated whether the frame type
we receive from the firmware is different. I should probably avoid
getting distracted into adding new features right now, anyway.

-- 
dwmw2