Jim Pingle wrote:
On 2/28/2010 10:16 PM, Rui Paulo wrote:On 1 Mar 2010, at 03:05, Jim Pingle wrote:On 2/28/2010 9:41 PM, Rui Paulo wrote:On 1 Mar 2010, at 02:26, Jim Pingle wrote:Ah, I wasn't aware of wlandebug(8). However, it doesn't seem to operate on this mwl(4) card. It sets the value of the sysctl net.wlan.0.debug and that doesn't show up on my system. Another system with a ral(4) card does have that sysctl. Judging by the information in the wlandebug(8) man page it appears as though this may be a side effect of mwl doing much of the work in firmware.wlandebug takes an -i argument. I seem to recall you created your wlan interface named "mwl_wlan0", so you need to type wlandebug -i mwl_wlan0.I saw that, but that is hardcoded to expect wlan<x> (wlan0, wlan1, etc) for an interface name. Having seen that, I recompiled wlandebug without the hardcoded interface name check and it didn't work either, but it did toss an error for the sysctl it was trying to tweak.The whole system was designed for the interfaces to start with "wlan" and be named "wlan<something>".It does certainly seem to lean that way. Personally I prefer to keep the hardware name in there, but I wasn't aware that would cause other issues. Especially when VAPs come into play, I'd rather have, for example, mwl0_wlan1, mwl0_wlan2, ath0_wlan0, etc, so I can better tie what goes where. But that's more of a bikeshed of personal preference. :-)
Not following the wlanX naming convention will cause confusion for things like rc config files (I believe). Definitely any tool I touched expects vap's to be named wlanX.
sysctl net.wlan.X.%parent gives the parent ifnet of a vap; I've considered many times including this in the ifconfig status. Feel free to offer a patch that does this.
That made me look deeper at the code and see it was really just setting the debug sysctl based on flags that wlandebug was aware of. Handy, but the same thing could be done by hand with sysctl and some bitwise math in a pinch, assuming the interface has the right oids. (Which mine doesn't, for some reason...)The purpose of wlandebug is to not do any math by hand.Indeed, You're 110% right on that. I was just trying to work around the other issues I was seeing to get to the root of the issue, which seems to be the missing sysctl oid. I need to run some more tests and straighten my antenna issues out, but I'll report what I find back to the list in a few days.
mwl 11n support broke sometime near the last firmware update and I never fixed it. I know in particular there are issues with AMPDU and seq#'s but possible other things too. The fw is rather finicky in how state is managed and it's likely the host is not in sync causing problems w/ the ampdu support and rate control algorithm that both operate in the fw. You should be able to get >100 Mb/s througput on an HT40 channel but I think I was seeing more like 35-40. Turning off ampdu is usually helpful to stabilize operation.
Sam
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
