ext Tomàs Jiménez Lozano <[EMAIL PROTECTED]> writes: > To reproduce the situation you only need to move away from de access > point. I've tried what Frantisek suggested, and ping fails always > before the device notifying it has lost connection.
Thanks, I think I managed to reproduce this now. Would you be kind enough to file a bug to bugzilla for easier tracking: https://maemo.org/bugzilla/ > I've checked how far from AP is raised de dbus signal notifying > disconnection and the average distance where ping starts to > definitiveley fail and ping always fails quite more near from IAP than > disconnection signal is raised. That's what I saw. Ping was failing just at the edge of AP radio coverage but N800 didn't drop from the network. After I moved few meters, only when the connection was dropped. > If, as it seems to be, it is a lower level bug I beg you to try to fix > it as soon as possible. Naturally. But it would help if you could file a bug to bugzilla. I receive way too many emails, and sometimes I loose some of them. But I have never lost a bug in bugzilla :) > In the meanwhile, we need to use the pinging workaround because for > our application it is critical to detect (and recover) from any > connectivity lost. As you feared, Kalle, the battery performance > reduces drastically (what becomes another issue for our app). We do > only ping every 15 second in order to let the device enter in PSM > between pings but the battery performance is still too poor. Are you implementing a customised application for a specific group of customers and not for the maemo community? If yes, I thinkg what you could do is to use the wlan_sleep_timeout. I wrote about it some time ago: http://maemo.org/pipermail/maemo-users/2007-February/004092.html For a temporary workaround, you could set it to zero to enable Full Power Save. That way the periodic pings would reduce the power consumption. But not without a cost, naturally. The WLAN troughput will be smaller and there are buggy APs (especially the older ones which are not Wi-Fi certified) which might not work properly with Full Power Save. > On the other hand, the pinging workaround has fixed another problem we > were detecting in our app. As I told before, our app need to be always > WLAN connected, and we have checked that the device after a given amount > of time of communication inactivity enters in what we suppose is some > kind of higher lever PSM. There's only one level of Power Save Mode in 770/N800. The wlan_sleep_timeout is the only thing controlling when the WLAN chip goes to sleep, and that's 1000 ms by default. So after a second of transmission inactivity the device would go to sleep. > When in this state, the device is still connected but it does not > answer to ping requests. When it needs to send any data it wakes up > automatically but for us it may be too late because communication > with other network devices may has been lost. I've been looking for > information about this supposed high level PSM and how to avoid it > but I've found nothing. I think that's also a bug in our WLAN stack. When you see this, could you take a look at kernel logs (for example with dmesg) and post them here. Actually, it's even better to file a bug to bugzilla. Attach the logs to the bug, if you manage to get them. > I hope you don't mind if I ask you one more question: Is there any other > way to force disconnection appart form the shutdown ICd dbus method. It > works fine but we would like to do it without prompting the user? I'm so involved with WLAN nowadays that I keep forgetting details about user-space more and more :) Patrik, can you help me here, please? -- Kalle Valo _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
