| 03:10.30 | *** join/#maemo-ssu DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 04:40.52 | *** join/#maemo-ssu ruskie (ruskie@sourcemage/mage/ruskie) |
| 05:57.28 | *** join/#maemo-ssu arcean (~arcean@62.159.77.166) |
| 06:19.21 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 07:01.03 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-160.residential.rdsnet.ro) |
| 07:10.40 | *** join/#maemo-ssu corvinux (~hashcore@unaffiliated/corvinux) |
| 07:17.56 | *** join/#maemo-ssu futpib (~futpib@37.113.214.97) |
| 07:36.09 | xes | one little issue with cssu clock-ui: if while i'm using the phone the alarm dialog appears and i'm so quick stopping it before the audio alarm tone starts (probably the phone is a bit lagging)... once closed the dialog the tone starts and it's impossible to stop it |
| 08:24.46 | *** join/#maemo-ssu bredebid (~bredebid@es-217-129-26-160.netvisao.pt) |
| 08:25.05 | DocScrutinizer05 | LOL |
| 08:25.56 | DocScrutinizer05 | the joy of an immanently async design like dbus, I guess |
| 08:28.51 | DocScrutinizer05 | with something like dbus, you _never_ should implement state machines that transition on a signal and have no way to resync when a single signal gets lost |
| 08:30.16 | DocScrutinizer05 | iow each such design should use "keep alive" or similar techniques, and reset to sane state when those are missing |
| 08:30.39 | xes | yeah, it's a stupid issue but very annoying when my son is sleeping near me |
| 08:31.23 | DocScrutinizer05 | yeah, alas the bugs system designers and sw devels introduce are not selected for convenience in real life :-) |
| 08:32.35 | DocScrutinizer05 | I never really liked the way dbus gets used for $everything on deskops and on maemo, without proper transmission security layer |
| 08:33.32 | DocScrutinizer05 | it's sort of like UDP-only internet |
| 08:33.55 | xes | i know it's a problem hard to imagine but our "always lagging device" is a beast producing unexpected beahaviors ;) |
| 08:35.06 | DocScrutinizer05 | yep |
| 08:35.37 | DocScrutinizer05 | not a single dbus-dependent program I've seen actually takes care to recover from "packet loss" on dbus |
| 08:35.57 | DocScrutinizer05 | FSO maybe a nice exception |
| 08:49.08 | *** join/#maemo-ssu arcean (~arcean@62.159.77.166) |
| 09:09.47 | *** join/#maemo-ssu SiceloWeb (c40fd38b@gateway/web/freenode/ip.196.15.211.139) |
| 10:11.59 | *** join/#maemo-ssu jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 10:39.49 | jon_y | how do you even loose a packet on dbus? |
| 10:40.26 | jon_y | dbus probably reinvents unix sockets |
| 10:53.13 | DocScrutinizer05 | dbus easily can 'lose' packets, when e.g. receiver doesn't really listen to signals |
| 10:53.48 | DocScrutinizer05 | even messages are not warranted to get delivered to receiver when you use async |
| 10:54.24 | DocScrutinizer05 | most dbus API usage is just fire&forget |
| 10:55.08 | DocScrutinizer05 | you *could* check for reply etc, but that's not mandatory and I know many apps don't care |
| 11:16.34 | *** join/#maemo-ssu arcean (~arcean@62.159.77.166) |
| 12:36.21 | *** join/#maemo-ssu arcean (~arcean@62.159.77.166) |
| 13:13.22 | drathir | lol /me again have issue with wifi signal... |
| 13:14.58 | drathir | wonder if that could be in any way connected with app genwall... |
| 13:16.27 | drathir | few meters from router signal is weak 5-10m from router no signal at all... |
| 13:17.41 | SiceloWeb | <PROTECTED> |
| 13:33.22 | DocScrutinizer05 | poor signals *quality* doesn't necessarily mean poor signal *strength* - could also be interference |
| 13:34.03 | DocScrutinizer05 | what you see in wifi connecting apps is usually quality, not strength |
| 13:35.59 | DocScrutinizer05 | and no, if genwall is a firewall then this should be unrelated |
| 13:37.04 | DocScrutinizer05 | suggests wifieye |
| 13:38.28 | drathir | SiceloWeb: DocScrutinizer05 in past was the same behaviours no idea whats goin repaired by own... sniffed area no diff in noise... |
| 13:39.36 | DocScrutinizer05 | use wifieye to check for other APs that interfere. Make sure you got no other strong TX like BT or microwave oven nearby |
| 13:40.03 | DocScrutinizer05 | note that neither BT nor microwave show up in wifieye |
| 13:40.38 | drathir | DocScrutinizer05: the wifieye 2m see max 10% quality... |
| 13:41.00 | DocScrutinizer05 | and actually even what WLAN chipsets declare as signal strength is massively depending on signal quality aka interference too |
| 13:41.31 | DocScrutinizer05 | wifieye does show signal strength, not quality |
| 13:41.34 | drathir | aircrack checked area no diff in range... |
| 13:41.41 | DocScrutinizer05 | afaik. But... see above |
| 13:41.54 | DocScrutinizer05 | sorry you lost me |
| 13:42.11 | DocScrutinizer05 | aircrack will not change range |
| 13:43.19 | DocScrutinizer05 | all that aircrack and wifieye really can tell you is: are there other APs on same channel or channel nearby, so they would interfere |
| 13:43.26 | drathir | DocScrutinizer05: i checkin from local prepared hw intended to that things... |
| 13:43.38 | drathir | the aircrack i mean... |
| 13:43.53 | DocScrutinizer05 | I still don't get it |
| 13:44.02 | drathir | no more noise/traffic than usual in area... |
| 13:44.15 | DocScrutinizer05 | checking won't improve your range, no matter what you use for checking |
| 13:44.31 | drathir | n900 is 2meters from router anyway... |
| 13:44.40 | DocScrutinizer05 | then it's maybe noise you don't see, I.E. no WLAN noise |
| 13:45.24 | drathir | DocScrutinizer05: aircrack in monitor mode see also not connected messing stations too and their signal... |
| 13:45.24 | DocScrutinizer05 | well, sorry I can't tell more than what I already did |
| 13:46.02 | drathir | i will diggin, bc honestly wonder with what that is connected ;p |
| 13:46.32 | drathir | at least its pretty funny behaviour... |
| 13:47.52 | DocScrutinizer05 | seen all WLAN in 50m radius going down when a nasty microwave operated |
| 13:48.04 | drathir | for wifi modules are wl12xx and mac80211 correct? |
| 13:50.22 | DocScrutinizer05 | and there are even industries tempering screws etc with 2.4GHz |
| 13:50.24 | drathir | DocScrutinizer05: yea im in pretty "hole" area with distance from similar to microwave sources but correct is a fair funny thing takin down signal quality all devices in area... |
| 13:52.06 | DocScrutinizer05 | when it's a problem of N900 only (needs check against other clients on same AP), then you might have problems with wifi antenna in device, might need contacts cleaning |
| 13:53.08 | DocScrutinizer05 | or collision with N900's BT and coexistence |
| 13:53.20 | DocScrutinizer05 | only when BT enabled and active |
| 13:54.20 | DocScrutinizer05 | when a battery removal fixes the issue, it might be a problem in WLAN chip's firmware and config that got messed up in WLAN chip's RAM |
| 13:59.49 | *** join/#maemo-ssu NishanthMenon (~nmenon@unaffiliated/nishanthmenon) |
| 14:08.16 | drathir | DocScrutinizer05: bf i cleaned gen wall settings i even dont see status indicator of gsm/wifi at all ;p |
| 14:08.29 | drathir | before* |
| 14:17.45 | SiceloWeb | maybe you should just use iptables :) |
| 14:17.50 | drathir | its possible that driver wil not follow 100mW and drop down to 10mW in n900? |
| 14:19.22 | DocScrutinizer05 | this is not cssu related and no, 10mW is unrelated to poor AP signal quality at N900 end |
| 14:24.28 | *** join/#maemo-ssu NishanthMenon (~nmenon@unaffiliated/nishanthmenon) |
| 14:25.58 | drathir | in theory a little yes related bc looks like reciving is so much throtle down that n900 have a problems with comunication... even in biggest noise and w/o antenna i should be able connect device lying at router... but correct that probably isnt connected with cssu... thans a lot for ideas and have a good day... |
| 14:40.19 | *** join/#maemo-ssu freemangordon_ (~ivo@46.249.74.23) |
| 16:34.21 | *** join/#maemo-ssu futpib (~futpib@37.113.248.174) |
| 16:45.10 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 17:22.24 | *** join/#maemo-ssu gregoa (~gregoa@colleen.colgarra.priv.at) |
| 17:30.24 | *** join/#maemo-ssu ruskie (ruskie@sourcemage/mage/ruskie) |
| 20:35.14 | *** join/#maemo-ssu RedM (~redw@89-76-164-87.dynamic.chello.pl) |
| 21:54.45 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-160.residential.rdsnet.ro) |