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.

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'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.

freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to