Sorry for late reply.

On Mon, Mar 4, 2013 at 3:11 AM, Adrian Chadd <> wrote:
> Hi,
> So this stuff breaks Monthadar's meshing code.
> The mesh forwarding stuff takes mesh frames in mesh_input() that are
> destined for another node and potentially stuffs them back into the
> parent transmit queue, bypassing the rest of the stack.
> This has a bunch of potential interesting implications, like how
> exactly sequence numbers, encryption, power save and aggregation are
> supposed to work. Since the forwarded packets are being forwarded
> direct to the driver, there's no nice place to tie in things like
> power save.

The sequence number should be set as if the meshSTA is transmitting
normal frames.

Powersave, encryption and aggregation is not implemented for mesh
right now. I am unsure about how it would be and how it could effect
the TX-serialization issue.

> I don't know what the right thing to do is - should the frames be
> de-encapsulated and then reinjected into the VAP but with an already
> resolved destination node? Or? I'm open to other suggestions.

I don't think we can de-cap the frame at all. If you decap a mesh
frame you would loose some information. Lost information could be
things like mesh TTL.

As it's done right now the frame is duplicated. After modifying
necessary fields we call ieee80211_parent_transmit(ic, mcopy);

My solutions right now: keep it as it is and create a new raw_xmit
that honors the TX-serialization framework.

> I'm happy to just "fix" the mesh code right now to not panic with the
> locking work that I'm currently doing.  But we do need to fix this.

Do that if your unsure, I will go through it when I get some time over.

> Adrian
> _______________________________________________
> mailing list
> To unsubscribe, send any mail to ""

Monthadar Al Jaberi
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to