I do understand that Titan's Power35 and up will incorporate the new patch, but my question is:
If I am currently running Titan's Power Kernel, do I have to downgrade back to the Nokia kernel to upgrade from PR 1.1 to PR 1.2?
After I upgrade to PR 1.2 can I immediately upgrade to the latest Titan Power Kernel, or do I have to wait for Titan to incorporate PR 1.2 into his kernel?
I realize this is not the ideal audience for this question, but I think the N900 Kismet users are more knowledgeable on these things than the regular N900 users
After I upgrade to PR 1.2 can I immediately upgrade to the latest Titan Power Kernel, or do I have to wait for Titan to incorporate PR 1.2 into his kernel?
All current versions in extras, extras-testing and extras-devel should be compatible with PR1.2. Titan has incorporated the latest minor PR1.2 updates in version 35.
(Source: http://talk.maemo.org/showthread.php?p=676177)
I have delayed my response since I wanted to test the N900 Kismet application with PR 1.2.
I installed PR 1.2 after doing a complete re-flashof the device, after that I installed the latest Power Kernel from Titan. I have done several reboots and so far Kismet seems to be working properly, I don't have the problem I had before with everything getting autogrouped. I will continue to test this for a few days to see the outcome before having you go through any more work by writing a debug driver or anything else.
The only issue I've encountered so far is after I properly exit Kismet I get a message saying "Kismet is Shutting Down" on xterm but it never drop me back to the prompt unless I press Control C.
Below I am posting lxp's response (which was via email), in case other N900 Kismet users are experiencing similar issues:
-----------------------------
I have analysed your pcap file and in combination to your bug
description, I think the problem is due to the driver somehow
misconfigures the wl1251's packet filtering in some special cases. My
patch doesn't touch that part of the driver because my tests showed it
works without modification (for me) so I haven't thought much about it.
I think the bug is triggered by either a special network type or
parameter of a network you connect to before going into monitor mode.
Maybe it is not only caused by a single network but a combination of
different networks if you usually use multiple networks before monitor mode.
It would be good if you could try to determine the network or even
better the parameter itself which causes the problem. At best you would
reboot after every network connect + monitor mode test to get a clean
state for the next try.
I would first suspect ad-hoc networks if you use any because I haven't
tested ad-hoc networking yet.
If you can determine a network which causes the problem, please tell me
the parameters of it:
* network type (infrastructure/ad-hoc),
* encryption type (open/wep/wpa-psk/wpa eap),
* hidden ssid (yes/no) and
* power management (full/half/off)
Maybe you can also suspect a network parameter for triggering the bug.
If you couldn't determine any single network which causes the problem I
think I have to build a debug driver for you, so we can tell for sure
your problem isn't caused by the packet filtering.
I have done several reboots and so far Kismet seems to be working properly, I don't have the problem I had before with everything getting autogrouped.
I like it when bugs resolve themselves. It's much less work
If anyone else experiences similar problems with PR1.2 and a recent power kernel, please tell me.
The only issue I've encountered so far is after I properly exit Kismet I get a message saying "Kismet is Shutting Down" on xterm but it never drop me back to the prompt unless I press Control C.
I already know that problem, but I haven't found the cause yet. I first didn't even noticed the bug as I am always using Ctrl+C directly in the client to exit Kismet. As far as I know this doesn't produce any corrupted logs or something, so I would also recommend it as a workaround until the other way works again.
The file "/opt/kismet/etc/kismet.conf" doesn`t exist for me.
If you used the stock file manager to search for the file, you couldn't even find it because the stock file manager doesn't show the real root fs. You have to use the terminal or a SSH/SFTP connection to your N900, so you have access to the real root fs.
If you are really sure that the config file doesn't exist, I would recommend to try uninstalling and reinstalling the kismet package through the program manager.
But remember if you can run the kismet server and it doesn't complain about a missing kismet.conf, then it does exist and you only couldn't find it.
