<br>
<br><tt><font size=2>David Woodhouse <dwmw2@infradead.org> wrote
on 12/09/2007 11:11:50 PM:<br>
<br>
> <br>
> On Sun, 2007-12-09 at 22:20 -0500, Michail Bletsas wrote:<br>
> > The rtap interface wasn't supposed to do anything else but sniff...<br>
> <br>
> That's fair enough (well, almost. Actually it would be useful to be
able<br>
> to inject packets).</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br><tt><font size=2>Useful for things like a SoftAP or just plain experimentation
with the radio.</font></tt>
<br>
<br><tt><font size=2><br>
> <br>
> However, I cannot use the _normal_ interfaces (eth0, msh0) while the<br>
> rtap interface exists. The transmit and receive paths are both broken
--<br>
> and if I attempt to fix them, I think I crash the firmware. It doesn't<br>
> seem to like me attempting to transmit while it's in rtap mode, and<br>
> certainly doesn't seem to manage to scan or associate.</font></tt>
<br><tt><font size=2>That is a bug and it wasn't always like that.</font></tt>
<br>
<br><tt><font size=2><br>
> <br>
> It would be nice to get that working -- although it isn't a high<br>
> priority right now. But if we _can't_ get it working, then I return
to<br>
> my previous question: what's wrong with 'iwconfig eth1 mode monitor'?<br>
</font></tt>
<br><tt><font size=2>Obviously if you have to choose between monitor and
infra modes, it makes no sense to have to configure another interface instance.</font></tt>
<br>
<br><tt><font size=2>M.</font></tt>
<br>
<br>