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. 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. Adrian _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"