Sepherosa Ziehau wrote:
On Jan 5, 2008 10:19 PM, Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote:
"Sepherosa Ziehau" <[EMAIL PROTECTED]> writes:
This actually brings up two things:
1) I think we should ignore seq in multicast frames; this is permitted in
802.11 standard. In dfly I did that, since one of our users
encountered a broken commercial AP which is not 802.11e but uses
different seq for data and beacon.
2) TX sequence. I think standards only mention QSTA/nQSTA, but not
AP. Currently our AP uses per node TX seq, which means beacon's seq
is difficult to choose, at least for 2560 based ral(4), whose beacons'
seq need to be set by software. I saw Linksys AP uses one seq for all
of the frames it sends. Sam, what's you opinion on this?
I think if STA counts ral(4)'s beacon seq, as what we do currently,
beacon missing will quickly happen since beacons will be discarded
after first several data frames.
OK, I *think* I understood most of that. Does this suggest a solution
to you? I will try to get the wlandebug output tonight.
I don't know whether you are still interested to track down the wired
problem you had experienced.
If you have time please try following patches:
revert the old patch at your AP side and try this one
http://people.freebsd.org/~sephe/rt2560_test.diff1
apply following patch at you STA side
http://people.freebsd.org/~sephe/ieee80211_input.c.diff
Best Regards,
sephe
[just back from holiday and only now caught your question about seq#'s]
The issue of seq# generation has mostly been ignored because many/most
devices generate them directly. I'm aware of issues w/ management
frames not getting correct seq#'s for ap mode (e.g. probe response) and
have some uncommitted changes. Beacon frames should track the seq# in
the bss node though there might be some trickiness w/ the bss node being
rebuilt too much (we may need to propagate the current seq# as we do
some other state).
On the rx side I'm not sure about ignoring seq# of mcast frames; it
would definitely be a WAR for broken ap implementations.
FWIW I took ownership of a ral bug where AP mode tx just stopped for no
apparent reason (I think it was probe response frames but can't
recall). This sounds like the same thing; can you check kern/117655?
Sam
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
