Notices

For anyone interested, I noticed a few almost entirely inconsequential, but possibly relevant-to-someone's-code-somewhere, differences between the stock driver and this.

In /proc/net/wireless, the stock driver shows the third line (showing values for signal quality, discarded packets, etc) when the driver is loaded, but not connected. They're all zeroes, but they're there. Unloaded, the third line disappears. With lxp's driver, the third line only appears when you're connected; both loaded and unloaded result in the third line not being there.

Also, there is a difference between two aspects of the format: The stock driver's third line of /proc/net/wireless shows the link value as a "##." value, level as "-##", and noise as "-##." (Pay attention to which ones the . appears in.) In lxp's driver, they are, respectively: "##." "-##." and "-###". I'm not sure how exactly signal is measured in - dBm, so I don't know if that middle value could get into the three digits, so that's irrelevant. The two differences are that lxp's driver reports noise as -256 at all times. I haven't extensively tested, but over the time I've had it loaded that I checked, it's always -256 (normal driver has the noise value reported in /proc/net/wireless update as often as level and link values). Oh, and switching between the two, I see the noise as in the -70s to -90s in the same area the lxp driver reports noise of -256. I can't tell about accuracy of signal level and link, because I don't have two N900s from which to test simultaneously for both drivers.

The other thing is the period placement. In the stock, link and noise have a . appended to their value, in lxp's, it's link and level. Both of these issues are minor, assuming they're even omnipresent, and not just on my device. (Much appreciated if others verify.) The only reason the first matters is if applications rely on signal noise to calculate something, or the user wishes to know what it is (it's possible Maemo does something in response to different noise values with the stock driver, which may account for why some people have random battery issues when leaving the driver loaded while others don't). The only reason the latter matters, is that code that fetches that data needs to be adapted to expect those .s in either position, instead of just where they are on one driver or the other, lest they break when you switch drivers. (I noticed this because I am currently working on a python clone/improvement on cpumem and wifi-signal applets, to be used as inside a clock style for the Advanced Clock Plugin that's recently come out - mine doesn't hide like wifi signal applet does, so instead it shows different things for when the driver is unloaded, loaded-but-unconnected, and the normal 0-10 when connected - I noticed loading lxp's driver made the clock applet have a little crash whenever I connected wifi - because my code expected the value in the signal string to be a string literal that would convert to an integer - fixed and future proof'ed in like 15 minutes counting all the typing and testing in x-term and vi on the N900, but hence me saying it.)

Oh: In /proc/net/dev, (and presumably system-wide) with the stock driver, there's a wmaster0 interface. Near as I can tell it never has any packet activity, but it's there. In lxp's driver, the wmaster0 interface doesn't show up in /proc/net/dev (at least; like I said, might just not show up elsewhere too). Again, not a problem at all, I THINK. Just worth noting, I believe.

No comment to your huge post or other concerns, but as of wireless-testing from 2.6.32, wmaster0 is no longer created by the mac80211 header stack. wmaster is as it sounds, a master device that normally "controls" the udev interfaces.

What David has provided is a backport of compat-wireless to 2.6.28 so a lot of changes since then to the current version have been incorporated as well as his own wl1251 patches.

Please, leave these tags for private use and delete it here.

They aren't concerns, just information for those who may find it useful.

And I did consider the possibility that some of these changes are due to backporting from later versions where these changes may have already become standard. I don't have the knowledge to know where to check for what change was made were in what version of what package, so I didn't want to speculate about the reasons.

Thanks for explaining where one of the differences came from. (Edit: And for explaining wmaster0, and what it did. I kinda figured as much as it having 'master' in its title implied, but getting confirmation from someone more informed on the subject is always nice.)

int_ua: What tags are you talking about? The thread tags, or something else?

As long as it can inject packets (which is seems to do just fine), fragmentation should work without any trouble. What's strange is the interface just disappears. I checked dmesg and found this:
So it mentions cfg80211, but I'm not sure how that factors into things. What can I do to look into this further? I have no problem digging into the code if I'm given some pointers on which files to look at, how to get a stacktrace and how I can compile/test my changes. I really wish gdb was in the repositories :-(

The file is available here:

http://rapidshare.com/files/44030122...emo-0.1.tar.gz

alright ima give multiboot another go, heh.

lol now lxp's gonna have his daily donates cut by half unless there's an update of course(Yeah nobody wants an old version when there's a new and better one)

I've picked something up for definite.
If you look at battery graph, you'll notice it says you're connected to network all the time, even if all connections are disabled and the driver unloaded.

Intressting because im getting battery drain after usage.
The phone also gets hot.

Is there a tool to monitor the wlan (or is it the CPU?) activity`?

Edit: I might be wrong, let me come back on this.