| 02:18.10 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.142) |
| 02:23.05 | *** join/#maemo-ssu Guest38428 (~rd@p57B486C8.dip0.t-ipconnect.de) |
| 02:34.46 | *** join/#maemo-ssu amiconn_ (quassel@rockbox/developer/amiconn) |
| 03:36.07 | *** join/#maemo-ssu LaoLang_coo_ (~LaoLang_c@221.226.175.142) |
| 03:49.03 | *** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 04:58.48 | *** join/#maemo-ssu jonwil_ (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 05:12.03 | *** join/#maemo-ssu LaoLang_coo_ (~LaoLang_c@221.226.175.142) |
| 05:14.31 | LaoLang_coo_ | DocScrutinizer, thank you for kind help, downloading madde :) |
| 05:14.51 | LaoLang_coo_ | Estel_, thank you for kind help, will try it when have time :) |
| 05:16.43 | *** join/#maemo-ssu jonwil_ (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 05:22.31 | Estel_ | no problem :) |
| 06:44.19 | *** join/#maemo-ssu tadzik (tjs@feather.perl6.nl) |
| 07:01.57 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.142) |
| 07:16.50 | *** join/#maemo-ssu ekze (~nyan@bakaekze.ru) |
| 07:29.07 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 08:06.30 | *** join/#maemo-ssu jon_y_ (~enforcer@pbz-162-87.tm.net.my) |
| 08:35.32 | kerio | freemangordon: yay for mp-fremantle-community-pr! |
| 08:35.43 | kerio | just installed, without even rebooting |
| 09:23.32 | kerio | freemangordon: why did you add the metapackage, btw? |
| 09:23.46 | kerio | every thumb package depends on the errata kernel feature |
| 09:23.58 | kerio | just upgrading will require a good kernel |
| 09:43.12 | *** join/#maemo-ssu taziff (~Taziff@cyr108.internetdsl.tpnet.pl) |
| 09:47.25 | *** join/#maemo-ssu M4rtinK (~M4rtinK@chello084112192230.11.vie.surfer.at) |
| 09:54.40 | freemangordon | kerio: the old metapackage(thumb12) was depenging on kernel-cssu = 1:2.6.28.10-cssu2 |
| 09:58.25 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 09:59.20 | *** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 10:08.24 | kerio | freemangordon: yeah but, i mean |
| 10:08.47 | kerio | why even bother with a metapackage? won't all the packages pull an appropriate kernel via dependencies? |
| 10:15.20 | *** join/#maemo-ssu NIN101 (~NIN@p5DD28025.dip0.t-ipconnect.de) |
| 10:18.47 | *** join/#maemo-ssu arcean (~Arcean@aacw149.neoplus.adsl.tpnet.pl) |
| 10:21.23 | freemangordon | kerio: because there is a new kernel, and if someone swithes tomorrow to cssu-thumb without having latest kernel-power installed, without having extras-devel enabled, he is busted |
| 10:21.54 | kerio | he's not, because no package from cssu-thumb will install without also installing a kernel with the errata |
| 10:22.00 | kerio | except for -bootimg fuckups |
| 10:22.21 | kerio | every one of your packages depends (rightfully so) on the kernel-feature-whatever-errata |
| 10:22.42 | freemangordon | kerio: the older metapackage was depending on kernel-cssu = 1:2.6.28.10-cssu2, the current kernel in cssu-thumb is kernel-cssu = 1:2.6.28.10-cssu3 |
| 10:23.04 | kerio | i'm not talking about the particular version issue, i'm talking in general |
| 10:25.05 | freemangordon | kerio: I am not sure what you are talking about, but using -mp is the way to make system upgrades in CSSU, be it thumb or not |
| 10:25.12 | *** join/#maemo-ssu NIN101 (~NIN@p5DD28025.dip0.t-ipconnect.de) |
| 10:25.49 | kerio | freemangordon: except that it worked perfectly fine for me - and i didn't have the mp- package until this morning |
| 10:26.13 | kerio | if you have cssu-testing installed, and a kernel that provides the errata, just enabling the repo and upgrading the packages that need to be upgraded will work |
| 10:26.30 | kerio | if you don't have a kernel that provides the errata, apt will want to install one, to fulfill the dependencies |
| 10:27.02 | freemangordon | kerio: STOP THAT apt-get TALKING, will you? |
| 10:27.19 | freemangordon | apt-get is not the way to make system upgrades |
| 10:27.38 | kerio | :c |
| 10:27.45 | kerio | but it has super cow powers! |
| 10:30.01 | freemangordon | And I don't give a ratshit how good *nix hacker you are, -mp is intended for those who are not |
| 11:25.33 | *** join/#maemo-ssu rd (~rd@p57B486C8.dip0.t-ipconnect.de) |
| 11:38.57 | freemangordon | merlin1991: ping |
| 12:01.16 | *** join/#maemo-ssu M4rtinK (~M4rtinK@chello084112192230.11.vie.surfer.at) |
| 12:34.46 | kerio | goddammit this opname widget sucks |
| 12:34.51 | kerio | it's... wrong |
| 12:34.53 | kerio | how |
| 12:34.55 | kerio | i don't even |
| 12:41.13 | *** join/#maemo-ssu jonwil_ (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 12:45.01 | DocScrutinizer05 | actually I always thought MP was a Nokia invention just because they didn't like to check for proper comprehensive dependencies. And I also thought CSSU originally planned to get rid of this abomination |
| 12:45.19 | *** join/#maemo-ssu asem (c587d5ee@gateway/web/freenode/ip.197.135.213.238) |
| 12:47.03 | kerio | DocScrutinizer05: wtf, i'm in 2g (so the only possible operator name is "TIM") but the operator name says "3 ITA CHIETI" ("CHIETI" is the cell broadcast) |
| 12:47.07 | kerio | it makes no sense |
| 12:49.27 | DocScrutinizer05 | please open a ticket, please attach the logs |
| 12:50.30 | kerio | enabled logging, where are the logs saved? |
| 12:51.14 | DocScrutinizer05 | (MP) I think the original problem with MP - as with any other pkg - is that there was no proper way to uninstall anything by an upgrade |
| 12:52.30 | freemangordon | qwazix, vi__: uploading fennec in thumb repo(will take maybe 15 minutes), have in mind you should manually install libqtm-12 |
| 12:52.33 | kerio | "cell id change 49713" "incoming cell tower name 3 ITA CHIETI, cell id 49713" |
| 12:52.47 | kerio | which makes no sense, because it should be "TIM CHIETI" |
| 12:52.48 | freemangordon | oops, wrong channel |
| 12:53.19 | DocScrutinizer05 | kerio: complain to the BTS owner |
| 12:53.27 | kerio | DocScrutinizer05: no u |
| 12:53.31 | kerio | if i reboot i get the correct name |
| 12:53.48 | kerio | reboot/restart hildon-home |
| 12:54.26 | DocScrutinizer05 | :shrug: |
| 12:55.02 | kerio | i wonder if it just caches the name because this is technically my "home network" but not quite |
| 12:55.03 | DocScrutinizer05 | quite probably you're not in cell id 49713 anymore, and your current cell doesn't send any CBS on that channel you selected |
| 12:55.33 | kerio | the problem isn't the CBS, the problem is the operator *name* |
| 12:56.13 | DocScrutinizer05 | please don't pester me I still got headache |
| 12:56.39 | DocScrutinizer05 | the cbswidget gives no fsck about whether there's a 'name' in the broadcast |
| 12:56.55 | DocScrutinizer05 | <kerio> "cell id change 49713" "incoming cell tower name 3 ITA CHIETI, cell id 49713" |
| 12:57.09 | DocScrutinizer05 | I gather that's from log |
| 12:57.15 | kerio | yeah but the problem is the "3 ITA" part |
| 12:57.16 | DocScrutinizer05 | so that is what you get |
| 12:57.40 | kerio | IT'S AN OPERATOR WITH NO GSM ANYWHERE |
| 12:57.50 | kerio | it can't be 3 ITA |
| 12:57.52 | DocScrutinizer05 | don't shout!!! |
| 12:58.19 | kerio | oh right, headache |
| 12:58.28 | DocScrutinizer05 | as mentioned above, complain to BTS owner for sending BS |
| 12:58.57 | kerio | "Start Operator Name" "operator 3 ITA error 0" "oper is TIM" "code 34 240 153" "service provider name empty" "set operator name TIM" |
| 12:59.07 | kerio | notice the "operator 3 ITA" part |
| 12:59.07 | DocScrutinizer05 | WE ARE NOT RESPONSIBLE FOR CONTENT OF SMSCB |
| 12:59.15 | kerio | YES YOU ARE BECAUSE YOU MADE ME INSTALL IT |
| 12:59.32 | kerio | (not you in particular) |
| 12:59.45 | DocScrutinizer05 | STFU |
| 12:59.50 | freemangordon | :nod: |
| 12:59.51 | kerio | :c |
| 13:00.33 | DocScrutinizer05 | disable the feature if you don't like what they send |
| 13:00.56 | kerio | the... feature? as in the operator *name*? |
| 13:01.49 | DocScrutinizer05 | >:-(((( it's obviously not in our discretion to do any filtering to the data that gets sent by BTS |
| 13:02.04 | kerio | the bts is sending his fucking operator name correctly |
| 13:02.05 | DocScrutinizer05 | except for not displaying SMSCB at all |
| 13:02.17 | kerio | i disabled smscb now |
| 13:02.40 | DocScrutinizer05 | open a ticket, attach the logs! |
| 13:02.47 | DocScrutinizer05 | so we can close it as invalid |
| 13:03.17 | kerio | i'm not sure you understood the problem correctly |
| 13:03.25 | kerio | operator-name-cbs-widget displays operator name incorrectly for me |
| 13:03.29 | kerio | operator *name* |
| 13:03.33 | kerio | the part that comes before any cbsms |
| 13:03.50 | kerio | the stock one displays it correctly |
| 13:05.08 | DocScrutinizer05 | open a ticket, attach the logs! |
| 13:05.16 | kerio | so you can close it as invalid? |
| 13:05.17 | DocScrutinizer05 | then we might investigate |
| 13:07.01 | *** join/#maemo-ssu jonwil_ (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 13:07.07 | kerio | forget it, i just uninstalled it |
| 13:07.28 | DocScrutinizer05 | my suspicion is that cbsmswidget doesn't properly update the name when roaming from a cell with cellbroadcast to a cell without cellbroadcast |
| 13:07.53 | kerio | yep, stock one confirmed working properly |
| 13:07.54 | DocScrutinizer05 | kerio: fine, then please never again pester me with any "bug report" |
| 13:08.46 | DocScrutinizer05 | as otherwise my answer will be: "forget it! just delete it!" |
| 13:09.28 | jonwil | whats this about operator-name-cbs-widget being broken? |
| 13:09.59 | DocScrutinizer05 | this is TESTING, you know? It's meant for YOUR testing and reporting about problems |
| 13:10.34 | kerio | jonwil: it displays the wrong operator name for me, sometimes, when i change from 2g only to 3g only (it causes a change in the operator name because my home operator is 3g-only, and uses another 2g operator for national roaming) |
| 13:10.47 | DocScrutinizer05 | if you're not willing to do proper reports, you shouldn't use T first instance. And if you do pleas edon't pester us with unproductive noise |
| 13:11.24 | jonwil | If you wont file a proper bug, dont complain here |
| 13:11.33 | DocScrutinizer05 | exactly |
| 13:12.23 | DocScrutinizer05 | well, it was kinda ok'ish until [2012-07-29 15:07:07] <kerio> forget it, i just uninstalled it |
| 13:12.33 | kerio | <DocScrutinizer05> open a ticket, attach the logs! <DocScrutinizer05> so we can close it as invalid |
| 13:13.56 | kerio | it's not exactly encouraging |
| 13:14.10 | DocScrutinizer05 | kerio: noooooo dude! |
| 13:14.13 | DocScrutinizer05 | [2012-07-29 15:05:16] <kerio> so you can close it as invalid? |
| 13:14.15 | DocScrutinizer05 | [2012-07-29 15:05:17] <DocScrutinizer05> then we might investigate |
| 13:14.16 | DocScrutinizer05 | [2012-07-29 15:07:07] <kerio> forget it, i just uninstalled it |
| 13:14.18 | DocScrutinizer05 | [ |
| 13:14.21 | DocScrutinizer05 | is the whole story |
| 13:14.42 | kerio | that's from a later point |
| 13:15.06 | freemangordon | kerio: the way you demand support is not how it should be. if you have CSSU-testing and have a problem, there is a bugtracker. period. |
| 13:15.06 | DocScrutinizer05 | get lost! |
| 13:15.52 | jonwil | as for actually fixing that problem, unless either someone with good skills shows up and reverse engineers the stock widget (to figure out the exact algorithm used and find out why my algorithm is incorrect) or we can somehow get the logic from Nokia or something, I dont see hoe it can be made better |
| 13:16.23 | kerio | jonwil: DocScrutinizer said something about not updating the name correctly when moving from a cell with cb to a cell without it |
| 13:16.27 | kerio | and/or viceversa |
| 13:16.30 | freemangordon | jonwil: bugreport with logs attached could help ;) |
| 13:16.36 | jonwil | yes it would help |
| 13:16.38 | kerio | I'M WORKING ON IT DAMMIT |
| 13:16.43 | jonwil | ok :) |
| 13:16.47 | freemangordon | shhht, do not shout |
| 13:17.03 | DocScrutinizer05 | we need to reset SMSCB display on (cell-handover + timeout-expired) |
| 13:17.30 | DocScrutinizer05 | jonwil: ^^^ |
| 13:17.48 | DocScrutinizer05 | jonwil: where timeout is ~90s |
| 13:17.53 | jonwil | I have no way to test such a change |
| 13:17.55 | jonwil | so I cant write the code |
| 13:17.56 | DocScrutinizer05 | or maybe 180 |
| 13:18.09 | kerio | component? |
| 13:18.19 | kerio | there's no operator-name-cbs-widget |
| 13:18.23 | freemangordon | general |
| 13:18.26 | kerio | i'll put it in general,y eah |
| 13:18.27 | freemangordon | CSSU |
| 13:18.29 | DocScrutinizer05 | jonwil: you don't see a change in CID? |
| 13:18.36 | jonwil | I do see a change in CID |
| 13:18.52 | jonwil | my operator has stopped sending CBSMS messages for any cells that are anywhere near me |
| 13:18.59 | DocScrutinizer05 | >>cell id 49713<< |
| 13:19.13 | jonwil | so I cant verify the case of "hey, moved to new cell and got CBSMS message |
| 13:20.10 | DocScrutinizer05 | no, but you can verify the case of "moved to new BTS and got *no* SMSCB during 90s guardtime" |
| 13:20.21 | DocScrutinizer05 | and reset to normal display in that case |
| 13:20.59 | DocScrutinizer05 | I'm more than willing to do the final tests for you, I still got proper SMSCB on chan221 here |
| 13:21.04 | jonwil | The code will reset the CBSMS if it sees a change of operator and a change of mode (2G vs 3G) |
| 13:21.26 | DocScrutinizer05 | this needs to add CID |
| 13:21.37 | DocScrutinizer05 | test for CID |
| 13:21.45 | DocScrutinizer05 | test for change in CID |
| 13:21.52 | jonwil | Where is the specific case of an operator sending CBSMS on only certain cells |
| 13:22.01 | jonwil | i.e. who is seeing the problem in question |
| 13:22.05 | DocScrutinizer05 | where kerio lives |
| 13:25.13 | jonwil | How do we know for sure that no CBSMS is being sent? Do we have logs to confirm that yes, we see a change of cell ID but no new CBSMS? |
| 13:25.46 | DocScrutinizer05 | also it's a question of design spec. Since SMSCB is BTS-specific info, it MUST get reset when handover to another BTS aka cell happens. For user convenience/experience we will want to delay that reset on cell handover by a guardtime, to allow new BTS to send SMSCB so there will be no "gaps" in display of SMSCB content |
| 13:26.19 | jonwil | My old Motorola did not reset cell tower name on handover |
| 13:27.03 | jonwil | its a pitty there is very little documentation out there in the public space about CBSMS and its workings |
| 13:27.10 | DocScrutinizer05 | jonwil: on *any* cell handover you start a guartime timer (90s). If the timer expires you simply reset the display. When a new SMSCB comes in you delete the timer |
| 13:27.56 | jonwil | as I said, my old motorola didn't do it. But then again, it may not have been doing the right thing w/r/t the specs |
| 13:28.01 | jonwil | :) |
| 13:28.19 | DocScrutinizer05 | or the guardtime been longer |
| 13:29.15 | DocScrutinizer05 | actually I guess any crappy old motorola probably will do an implicit reset when T3212 expires |
| 13:29.20 | kerio | isn't there a way to detect an operator change? CB data at that point should be considered invalid anyway |
| 13:29.26 | jonwil | we do |
| 13:29.32 | jonwil | we throw away CBSMS on operator change |
| 13:29.55 | jonwil | so therefore if you are seeing an operator change but not seeing the correct change in either operator name or CBSMS, its a bug |
| 13:35.45 | kerio | should i paste the logs in the description or should i attach them? |
| 13:36.05 | jonwil | attach them I guess |
| 13:36.11 | kerio | i can only attach one |
| 13:36.23 | jonwil | also, is this the only issue with operator-name-cbs-widget or are there others? |
| 13:36.36 | kerio | the only one i had, at least |
| 13:36.38 | jonwil | ok |
| 13:38.21 | DocScrutinizer05 | you can attach more than one attachment |
| 13:38.44 | DocScrutinizer05 | or you tar them up |
| 13:38.56 | kerio | https://bugs.maemo.org/show_bug.cgi?id=12645 |
| 13:38.57 | povbot_ | Bug 12645: operator-name-cbs-widget does not display the operator name correctly |
| 13:44.06 | jonwil | ok, in those logs I see nothing wrong with the cbsms as sent, just with the operator name. |
| 13:44.27 | jonwil | or is there some other different issue with the CBSMS? |
| 13:44.37 | kerio | i even disabled the CBSMS (it only works with TIM, which is not my main operator anyway, and only the channel 50) |
| 13:44.56 | jonwil | well the cbsms doesnt matter for the operator name |
| 13:44.57 | kerio | no, enabling CBSMS only leads to the correct CB message appended to the wrong operator name sometimes |
| 13:45.01 | kerio | yeah |
| 13:45.33 | jonwil | If you are connected to 2G only and to TIM and reboot the phone (or kill hildon-home) what do you see as the operator name? |
| 13:46.47 | kerio | i see TIM |
| 13:47.00 | kerio | but then, as i change back to 3G, the name gets stuck on TIM |
| 13:47.01 | DocScrutinizer05 | see? now that's a proper ticket where we actually understand what you're doing, what's expected outcome and how we could reproduce the problem |
| 13:47.46 | jonwil | kerio, I think this might be fixable if you are willing to reinstall the widget and run some specific tests. |
| 13:47.59 | kerio | yeah, i reinstalled it |
| 13:48.05 | jonwil | ok |
| 13:48.09 | jonwil | step 1, connect to 3G |
| 13:48.20 | jonwil | delete cbsms.log and opername.log |
| 13:48.25 | jonwil | or clear them out |
| 13:48.40 | kerio | done |
| 13:48.40 | DocScrutinizer05 | >cbsms.log |
| 13:48.40 | jonwil | then restart the phone |
| 13:48.46 | DocScrutinizer05 | is the command ;-) |
| 13:48.48 | jonwil | or restart hildon-home |
| 13:49.09 | kerio | DocScrutinizer05: > as a shorthand for touch is neat |
| 13:49.12 | kerio | er |
| 13:49.15 | kerio | for rm+touch |
| 13:49.27 | kerio | jonwil: i think that those two lead to different results |
| 13:49.36 | jonwil | yeah restart the phone |
| 13:49.38 | jonwil | thats the right answer |
| 13:49.47 | jonwil | so delete the log files and restart the phone |
| 13:50.00 | kerio | bootin' |
| 13:50.40 | kerio | k, booted, operator name is displayed correctly |
| 13:50.48 | jonwil | so it prints "3 ITA"? |
| 13:50.50 | kerio | yeah |
| 13:51.17 | jonwil | now mark in the opername.log and note "booted on 3G, name is 3 ITA" |
| 13:51.27 | DocScrutinizer05 | and you're on what? 2G or 3G? |
| 13:51.43 | kerio | i'm on 3G |
| 13:51.52 | kerio | ok, done |
| 13:51.53 | jonwil | forget cbsms.log, thats not relavent to operator name |
| 13:51.58 | jonwil | now swich to 2G |
| 13:52.14 | jonwil | and make a note in opername.log to say that you switched to 2G and what operator name you get |
| 13:52.35 | jonwil | then after that, restart the phone |
| 13:52.37 | DocScrutinizer05 | echo "note 2G" >>cbsms.log |
| 13:52.48 | DocScrutinizer05 | echo "note 2G" >>opername.log |
| 13:52.49 | DocScrutinizer05 | even |
| 13:52.50 | jonwil | and make another note about what operator name you see |
| 13:53.00 | kerio | hm, i see "3 ITA" |
| 13:53.11 | jonwil | ok, so you are on 2G and you see 3 ITA |
| 13:53.18 | jonwil | ok, make a note of that in the log file |
| 13:53.43 | kerio | sometimes it works correctly |
| 13:53.48 | jonwil | ok |
| 13:54.01 | jonwil | ok, so what you done so far is booted in 3G with empty log file |
| 13:54.05 | DocScrutinizer05 | echo "hm, i see 3 ITA" >>opername.log |
| 13:54.06 | jonwil | then made a note |
| 13:54.11 | jonwil | then switched to 2G |
| 13:54.29 | jonwil | and made another note |
| 13:54.46 | kerio | yep |
| 13:54.57 | jonwil | now reboot the phone whilst still in 2G |
| 13:55.15 | DocScrutinizer05 | echo "rebooting" >>opername.log |
| 13:55.17 | jonwil | make another note that you rebooted in 2G and what operator you see |
| 13:55.30 | jonwil | after that, switch back to 3G and make one final note |
| 13:55.34 | jonwil | then give me opername.log |
| 13:55.45 | DocScrutinizer05 | attach to ticket |
| 13:56.14 | jonwil | yeah |
| 13:56.21 | DocScrutinizer05 | prepare for doing whole sequence again, in case we missed something |
| 13:57.17 | jonwil | that sequence "boot in 3G, switch to 2G, boot again in 2G, switch to 3G" should be enough |
| 13:57.21 | kerio | my poor battery :( |
| 13:58.13 | DocScrutinizer05 | jonwil: you know about the devil and where it hides. one time echo foo >bar instead echo foo >>bar is enough to spoil things |
| 13:58.37 | kerio | hm, something changed |
| 13:58.40 | kerio | i get the correct name now |
| 13:59.06 | DocScrutinizer05 | even better!! |
| 13:59.22 | DocScrutinizer05 | so we got a proper commented log of a case where it worked |
| 13:59.31 | jonwil | yeah get me the log |
| 13:59.39 | DocScrutinizer05 | of same device user location where it failed before |
| 13:59.41 | kerio | the change i see is that it says "oper is (null)" "oper is changed to TIM" ... "oper is (null)" "oper is changed to 3 ITA" |
| 14:01.45 | kerio | https://bugs.maemo.org/attachment.cgi?id=3461 |
| 14:03.12 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 14:03.14 | kerio | anyway, the operator name changes correctly now |
| 14:03.26 | *** join/#maemo-ssu DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 14:03.29 | kerio | sometimes it does that |
| 14:09.47 | DocScrutinizer05 | your phone used different 2G BTS aiui |
| 14:10.48 | kerio | hm, really? i noticed some changes in cell in cbsms.log, but they were on the 3G side |
| 14:10.58 | DocScrutinizer05 | 34 2 1; 34 146 1 vs 34 130 1 |
| 14:11.01 | kerio | i see |
| 14:11.21 | kerio | i'm in a place with not so good coverage, sadly |
| 14:11.26 | jonwil | those numbers have nothing to do with BTS |
| 14:11.29 | jonwil | or cell ID |
| 14:11.37 | DocScrutinizer05 | sad for you, good for us ;-) |
| 14:11.48 | DocScrutinizer05 | ohh, then never mind |
| 14:14.26 | jonwil | I cant see for the life of me what my code is doing differently to the stock (and working) code |
| 14:15.24 | DocScrutinizer05 | kerio: since the opername.log doesn't contain such interesting info like CID, could you attach cbsms.log as well? (maybe next time ;-D) |
| 14:15.30 | kerio | k |
| 14:15.34 | jonwil | the cid doesn't matter |
| 14:16.05 | DocScrutinizer05 | sure it does matter, since I see if the cell changed |
| 14:16.23 | jonwil | changes in the cell ID have no effect on the operator name selection logic |
| 14:16.52 | DocScrutinizer05 | now THAT doesn't matter, since the cells themselves might behave different |
| 14:17.25 | DocScrutinizer05 | and we'll have a hard time to spot this when we don't even know which CID |
| 14:18.30 | DocScrutinizer05 | there's also quite some hidden 'logic' in modem itself. E.G. it stores last cell parameters to speed up a reboot and re-login |
| 14:20.00 | DocScrutinizer05 | that's why your phone is 'online' way faster when switching down and restarting in same location, than when switching down and moving powered down phone several miles before switching on again |
| 14:21.15 | DocScrutinizer05 | quite possible that modem behaves different regarding opername as well, when booting to same cell, than when booting to a "new" environment |
| 14:21.52 | DocScrutinizer05 | it might safely assume that opername didn't change when CID didn't change |
| 14:22.21 | DocScrutinizer05 | (well, CID and CC and Oper) |
| 14:23.18 | DocScrutinizer05 | and last not least any such logic in modem might in fact be buggy |
| 14:24.51 | jonwil | what I wouldn't give for source code to connui-cellular right now (or to pick the brains of Mikko Mehtonen who wrote connui-cellular). But since that isn't going to happen the only way to solve this is to further reverse engineer libconnui-cellular or the stock widget. |
| 14:25.20 | kerio | where does this Mikko live? |
| 14:25.25 | jonwil | no idea |
| 14:25.28 | jonwil | he is a Nokia guy :P |
| 14:25.33 | jonwil | or was at the time :P |
| 14:26.38 | jonwil | and I have used all my reverse engineering skills already so I have no further ability to find out whats wrong with this widget |
| 14:27.01 | jonwil | i.e. why my algorithm doesn't match the Nokia algortihm 100% |
| 14:32.40 | DocScrutinizer05 | then maybe find out what's not working, no matter how Nokia did it? |
| 14:33.21 | jonwil | I would but I dont know whats working because I dont know how its supposed to do it |
| 14:33.26 | kerio | where does the operator name come from? |
| 14:33.35 | jonwil | it comes from various possible sources |
| 14:34.09 | DocScrutinizer05 | I mean c'mon we got a testcase as comfortable as rarely ever, with kerio producing working and not working scenarios |
| 14:35.04 | DocScrutinizer05 | can't be that difficult to add proper debug printf to log, to find out WHAT differs between the working and the non-working ones |
| 14:35.37 | kerio | DocScrutinizer05: well, it would've been more comfortable for jonwil to actually experience the problem |
| 14:35.39 | kerio | :) |
| 14:36.11 | DocScrutinizer05 | well, alas neither he nor me can reproduce your situation |
| 14:36.42 | DocScrutinizer05 | since at least here there's no such setup where 3G differs from 2G |
| 14:38.08 | jonwil | Adding more logging wont help trust me |
| 14:38.17 | DocScrutinizer05 | but he could throw in a few dozen additional debug printf |
| 14:38.27 | DocScrutinizer05 | err, why? |
| 14:38.50 | jonwil | because there is logging in every place related to operator name that would matter |
| 14:38.51 | jonwil | trust me |
| 14:38.52 | DocScrutinizer05 | what else will help? |
| 14:39.25 | DocScrutinizer05 | obviously there isn't as you can't even tell why your code delivers diferent results |
| 14:39.32 | DocScrutinizer05 | or can you? |
| 14:40.20 | DocScrutinizer05 | I elaborated above that for example CID might matter pretty much |
| 14:41.51 | DocScrutinizer05 | since I suppose you got no random function in your code, any of the input parameters must differ to cause differing results |
| 14:42.20 | DocScrutinizer05 | only way to find out is to trace as many of those input parameters as possible |
| 14:42.43 | DocScrutinizer05 | maybe we can neglect sub-second timing issues |
| 14:43.01 | DocScrutinizer05 | maybe we find out we actually can't |
| 14:43.10 | jonwil | The main problem is that there is ZERO documentation on what connui_cell_net_status_*, connui_cell_net_get_operator_name, connui_cell_sim_get_service_provider or connui_cell_sim_is_network_in_service_provider_info actually DOES |
| 14:43.34 | DocScrutinizer05 | that's not causing the problem, that's causing your headache |
| 14:43.44 | jonwil | Thats whats causing the problem to fix this |
| 14:44.45 | jonwil | More specifically I have no clue how the code in libconnui-cell fills in the operator_name field of the net_status callback |
| 14:45.09 | DocScrutinizer05 | even kerio (no offense, kerio!) noticed a difference in logs between working and not working case |
| 14:45.22 | jonwil | yes I know there is a difference between the logs |
| 14:45.37 | jonwil | I know which code paths its following through the code in all the different cases |
| 14:46.30 | kerio | offense taken! :c |
| 14:47.00 | DocScrutinizer05 | so you say you call an undocumented function() that returns opername, and this return value differs despite you feeding the function with identical parameters? |
| 14:47.13 | jonwil | no |
| 14:47.13 | DocScrutinizer05 | or did I get it wrong? |
| 14:47.52 | jonwil | The difference has to do with how the code fills in the operator_name field in the state structure passed to the widget_net_status_cb |
| 14:48.57 | DocScrutinizer05 | sorry but that doesn't tell me much |
| 14:49.16 | jonwil | I mean how the code in libconnui-cell fills that in |
| 14:49.19 | DocScrutinizer05 | as I haven't looked into the code yet |
| 14:49.51 | jonwil | some code we dont have and know basically nothing about is filling in a structure differently when it passes it to the operator widget in different cases |
| 14:50.34 | DocScrutinizer05 | so how's that any different from my assumption >>you call an undocumented function() that returns opername, and this return value differs despite you feeding the function with identical parameters?<< |
| 14:53.06 | DocScrutinizer05 | >some code we dont have and know basically nothing about< == >you call an undocumented function()<; >is filling in a structure differently when it passes it to the operator widget< == >this return value differs despite you feeding the function with identical parameters< |
| 14:53.29 | jonwil | Let me run similar tests to what kerio ran on my own phone to see what output I get in case the output I get means loading the stock widget into GDB will help |
| 14:55.25 | jonwil | ok, I think I can do some gdb debugging to see whats going on here I hope |
| 14:55.42 | DocScrutinizer05 | you're still too focused on diffs between your code and Nokia code, when you rather should analyse what's exactly going on in your own code |
| 14:55.53 | jonwil | I know what my code is doing |
| 14:55.56 | jonwil | exactly what its doing |
| 14:56.02 | jonwil | and knowing that doesn't help |
| 14:56.12 | jonwil | because I know how its deciding which operator name to use |
| 14:56.41 | DocScrutinizer05 | so which cannel is it the differences sneak in? |
| 14:56.44 | jonwil | what I need to figure out is under which circumstances to use which of the 3 or so possible operator names |
| 14:57.04 | DocScrutinizer05 | the differences between your code working and your code not working |
| 14:57.05 | jonwil | which is why I am about to GDB the stock widget to find out |
| 14:58.07 | *** join/#maemo-ssu arcean (~arcean@aacw149.neoplus.adsl.tpnet.pl) |
| 14:59.12 | DocScrutinizer05 | you should focus on the differences between runs of your own code that yield different results, rather than on differences between your code and Nokia's |
| 15:01.03 | jonwil | the differences are because Nokia functions that we know almost nothing about return different values. The stock widget clearly handles these different results in a way mine doesn't. Finding out what the Nokia widget does differently is the only way I am going to fix this. |
| 15:01.09 | DocScrutinizer05 | if you can't tell the difference, you are missing some channels for input parameters |
| 15:02.24 | DocScrutinizer05 | that's why I suggested to log CID and other possibly relevant parameters, as it's obvious that not all input channels are logged |
| 15:03.34 | DocScrutinizer05 | and you can bet on finding in the end that Nokia's code *does* monitor those input channels you don't, as otherwise Nokia had no way to do "the right ting" where your code fails to do so |
| 15:05.21 | DocScrutinizer05 | since we have logs of both working and failing scenarios, we could spot the channel that delivers differing info |
| 15:06.18 | DocScrutinizer05 | at least if we'd bother to add logprints for allegedly unrelated stuff that in the end will turn out to be related nevertheless, like CID |
| 15:08.22 | jonwil | I can say the cell ID doesn't matter as none of the inputs the Nokia code receives include the cell ID (i.e. its not passed in to the callback nor does the code make any calls to functions that return it) |
| 15:08.30 | jonwil | nor is it making any dbus calls to obtain it either |
| 15:08.31 | DocScrutinizer05 | of course you *might* be able to spot the missing input channel by careful analysis of that closed source Nokia blobs |
| 15:12.01 | DocScrutinizer05 | jonwil: but I hope you concur that in the end it's modt likely a difference in BTS behavior that casues the problem (or at least there's a certain chance it's related), so while CID maybe isn't the missing input channel, it still may verify or falsify this hypothesis when we see one CID it always works while other CID it never works. So from this finding we might go on trace raw data delivered by cell, to find what's the difference |
| 15:12.02 | DocScrutinizer05 | in format or content of the opername relevant bits |
| 15:13.01 | DocScrutinizer05 | or we find it always works when BTS is same as before boot, while it always fails when BTS is a new one |
| 15:13.23 | DocScrutinizer05 | again we'd like to know WTF *is* the CID so we could tell apart differing BTS |
| 15:15.23 | DocScrutinizer05 | as a general rule of thumb you'll hardly learn new stuff by monitoring only those info bits you already know about |
| 15:25.11 | jonwil | Clearly my code is doing something different to the Nokia code in the "it displays wrong operator name" case. Therefore (since I can get something similar to that case locally) using gdb to find out whats different makes sense |
| 15:28.12 | jonwil | I have a lead on that, I just need to get my widget into gdb to confirm something |
| 15:34.41 | DocScrutinizer05 | some background: there's a opercode->operator-name table in modem (most likely), another one in userland of AP iirc, and there's two flavours of over-the-air message with operator name (long and short operator name) |
| 15:34.58 | *** join/#maemo-ssu M4rtinK (~M4rtinK@chello084112192230.11.vie.surfer.at) |
| 15:35.51 | DocScrutinizer05 | whenever the values in those tables differ from what the network sends, you can see the operator name change in display a short while after login |
| 15:36.14 | DocScrutinizer05 | aaaah I forgot there's also a operator name on SIM |
| 15:36.58 | jonwil | well there are 3 different operator names we are dealing with here, one comes from what gets passed into the callback, second is what we get when we call connui_cell_net_get_operator_name and third is what we see when we call connui_cell_sim_get_service_provider |
| 15:37.08 | DocScrutinizer05 | my SIM has operator name "interkom" while some tables have "o2" and other source has "O2_de" |
| 15:38.04 | *** join/#maemo-ssu Estel_ (~Estel@dbg208.neoplus.adsl.tpnet.pl) |
| 15:39.59 | DocScrutinizer05 | connui_cell_net_get_operator_name and connui_cell_sim_get_service_provider seem quite obviously matching to my above info regarding name from SIM and name from network |
| 15:41.28 | DocScrutinizer05 | where "from network" actually are three distinct sources OTA: operator-id numeric, operator-name-short ascii and operator-name-long ascii |
| 15:42.08 | DocScrutinizer05 | form operator-id numeric both the modem and the linux may find an ascii name in local databases |
| 15:42.33 | DocScrutinizer05 | s/form/from/. |
| 15:43.20 | DocScrutinizer05 | in the end this is what you'll find when analyzing the Nokia opername blobs |
| 15:44.14 | DocScrutinizer05 | nfc how Nokia is mixing and priorizing all those methods, and what they give back via function return value in the end |
| 15:45.53 | DocScrutinizer05 | but I know on some phones I see 3 opernames in sequence: 'interkom' (from SIM), 'O2', and finally 'o2_de' |
| 15:46.23 | DocScrutinizer05 | all this happens during ~20s after typing in PIN |
| 15:52.43 | jonwil | aha, I think I have a fix |
| 15:52.56 | jonwil | Let me build a new deb for kerio to test |
| 15:53.08 | kerio | jonwil: there's a problem though |
| 15:53.13 | jonwil | what problem? |
| 15:53.13 | kerio | it's currently working fine |
| 15:53.25 | jonwil | ok |
| 15:54.19 | jonwil | in that case I should just get this change into git (and hence from there into the next cssu-testing release) and then people can report any problems with this new version |
| 15:54.53 | kerio | i thought that cbs widget was going to be removed in a future version |
| 15:55.06 | jonwil | where was that said? |
| 15:55.19 | jonwil | and what reason to remove it? |
| 15:56.14 | DocScrutinizer05 | it conflicts with custom-opername-widget, so it will not get removed but go optional |
| 15:56.39 | jonwil | I can make it support a custom name easily enough |
| 15:57.02 | DocScrutinizer05 | that's been one of the suggested improvements/fixes to the issue |
| 15:57.08 | jonwil | i.e. if you give it a custom name, it overrides whatever operator name it would otherwise pull from the network |
| 15:57.21 | jonwil | any other changes that would need to be made to the widget? |
| 15:57.32 | *** join/#maemo-ssu Estel_ (~Estel@Maemo/Community/council/Estel-) |
| 15:57.35 | jonwil | or is that the only one you know of that would need to be made for people to be happy? |
| 15:58.00 | DocScrutinizer05 | atm I don't know of other major concerns |
| 15:58.23 | jonwil | ok, well I can fix that easily enough with a bit of work |
| 15:58.41 | DocScrutinizer05 | except of course the allegedly missing 100% functional compatibility to stock as rised by e.g. kerio |
| 15:58.58 | jonwil | also btw DocScritinizer05, there is already logic in there to clear out the old cell tower name if there is a change of cell tower and no new CBSMS comes in after a timeout |
| 15:59.49 | jonwil | I cant remember if it was me or pali that added it but its there |
| 16:00.52 | DocScrutinizer05 | please check out custom-operator-widget to see how it works, so any extensions to that one will work with yours as well (I heard of people [ab]using custom-opername-wdgt to display all sorts of weird stuff, like date, or RSS channels, or whatever. Seems there's a sort of "API" to change the displayed string at runtime) |
| 16:01.28 | DocScrutinizer05 | I think it's been pali after I asked him to do that |
| 16:06.18 | DocScrutinizer05 | jonwil: *I* however had a few maybe weird ideas a few hours ago: add parameters to the string to display (if you get such "constant" user defined string instead of cellbroadcast), sth like ID = cell id, B = SMSCB string as usual (but embedded into the constan string), other stuff that *might* be interesting for some users, like BCH = SMSCB channel as set in config, all the opernames, whatnot else |
| 16:06.33 | DocScrutinizer05 | dafaq |
| 16:07.00 | DocScrutinizer05 | jonwil: *I* however had a few maybe weird ideas a few hours ago: add parameters to the string to display (if you get such "constant" user defined string instead of cellbroadcast), sth like %CID = cell id, %CB = SMSCB string as usual (but embedded into the constan string), other stuff that *might* be interesting for some users, like %CBCH = SMSCB channel as set in config, all the opernames, whatnot else |
| 16:07.48 | jonwil | Lets just get it doing custom operator names for now |
| 16:08.13 | jonwil | Reading the source of custom-operator-widget, the only place it gets the string to display from is from gconf |
| 16:08.36 | jonwil | therefore anyone changing it dynamically must be setting it in gconf |
| 16:08.45 | DocScrutinizer05 | custom name: "I listened to channel %CBCH on cell %CID and got \"%CB\" as message" |
| 16:09.26 | jonwil | all that fancy stuff is way beyond what I ever intended operator-name-cbs-widget o do |
| 16:09.26 | DocScrutinizer05 | jonwil: (gconf) sounds about right |
| 16:09.29 | jonwil | to do |
| 16:10.01 | jonwil | the only reason I am adding the custom operator name thing is because lots of people seem to want it :) |
| 16:31.33 | *** join/#maemo-ssu andre__ (~andre@162.108.117.91.dynamic.mundo-r.com) |
| 16:31.33 | *** join/#maemo-ssu andre__ (~andre@Maemo/community/bugmaster/andre) |
| 16:39.32 | jonwil | ok, if this compiles, I can test it to make sure the functionality works, fix it if its broken, then commit it to git |
| 16:40.10 | jonwil | once this is done, we can push this to testers in next cssu-testing and if they want more functionality, they can ask for it and it will be added |
| 16:50.15 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 16:51.31 | freemangordon | jonwil: better push it in cssu-devel |
| 16:51.44 | freemangordon | so it'd be tested before next -testing |
| 16:52.59 | jonwil | well it will be going into the relavent git |
| 16:53.09 | jonwil | http://gitorious.org/community-ssu/operator-name-cbs-widget |
| 16:53.16 | jonwil | whatever people do with it from there is up to them |
| 16:53.37 | freemangordon | jonwil: cssu-devel is not a git repo, but debian repo ;) |
| 16:53.49 | freemangordon | git repo remains the same |
| 16:53.51 | jonwil | yes that I know |
| 16:54.06 | freemangordon | then I am unable to parse |
| 16:54.09 | jonwil | its up to someone who knows all the repos to make sure it gets from the git repo into whatever other repos it has to go into |
| 16:54.26 | jonwil | since these debian repos are not my responsibility |
| 16:54.30 | freemangordon | no, it is you to do it. though you can ask merlin or Pali |
| 16:54.41 | freemangordon | ask merlin1991 then |
| 17:08.43 | jonwil | ok, just need to find out why its not properly repainting the widget when the custom name is changed |
| 17:14.23 | amiconn_ | jonwil: I do have the problem with the cssu-provided operator name widget. |
| 17:14.53 | jonwil | ok, what problem do you have? |
| 17:17.53 | amiconn_ | My home provider sends no cell broadcasts at all. Normally this doesn't affect me, but two weeks ago I've been in Poland (i.e. international roaming). After returning to Germany (far enough from the border so I've definitely been connected to my home provider) the widget didn't show my home provider name. It still displayed the Polish provider's name |
| 17:18.36 | jonwil | I assume your phone was not restarted or turned off between leaving poland and noticing this problem? |
| 17:18.54 | amiconn_ | Stock widget does not have that problem |
| 17:19.17 | jonwil | Was your phone turned off or restarted after leaving poland and connecting to the german operator? |
| 17:19.54 | amiconn_ | no |
| 17:19.57 | jonwil | ok |
| 17:20.06 | jonwil | I have a fix that will be going into git shortly that should fix your problem if is the same one I have been seeing in logs before |
| 17:20.15 | jonwil | i.e. if its the one I am thinking it is |
| 17:20.24 | amiconn_ | I did this after noticing the problem. This fixed the display |
| 17:20.38 | jonwil | ok, that confirms that its most likely the issue I am thinking of |
| 17:21.38 | jonwil | ok, that all works, now I just have to remember how to commit to git |
| 17:21.38 | amiconn_ | would like to uninstall the widget, because he has no use for it, but I don't know whether that's possible without uninstalling other parts of cssu... |
| 17:35.11 | *** join/#maemo-ssu mase76 (~mase76@p5DD3B923.dip.t-dialin.net) |
| 17:59.53 | jonwil | ok, I committed my changes to git |
| 18:02.31 | jonwil | merlin1991: ping |
| 18:10.18 | kerio | amiconn: it's possible to remove it, the only side effect would be that it uninstalls the mp- package |
| 18:10.26 | kerio | and you'd possibly have issues if you autoremove afterwards |
| 18:11.48 | kerio | anyway, amiconn <3 |
| 18:11.54 | kerio | I AM NOT CRAZY!! ^_^ |
| 18:58.21 | *** join/#maemo-ssu arcean_ (~arcean@aaen94.neoplus.adsl.tpnet.pl) |
| 18:59.18 | DocScrutinizer05 | amiconn: you rather update to latest jonwil version ;-) |
| 18:59.59 | DocScrutinizer05 | kerio: nobody doubts you're crazy ;-) |
| 19:00.35 | DocScrutinizer05 | kerio: we knew about problems in cbsms-widget already |
| 19:00.50 | DocScrutinizer05 | I went thru all this with amicon before |
| 19:01.10 | DocScrutinizer05 | and pali implemented something I thought might fix the issue |
| 19:02.08 | DocScrutinizer05 | I just forgot I suggested that fix and pali actually implemented it, until jonwil mentioned there's already such function |
| 19:17.56 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 19:58.51 | *** join/#maemo-ssu Jade (~jade@unaffiliated/jade) |
| 19:58.58 | *** join/#maemo-ssu Guest10183 (~rd@p57B486C8.dip0.t-ipconnect.de) |
| 23:11.38 | *** join/#maemo-ssu jon_y (~enforcer@swz-175-47.tm.net.my) |