**** BEGIN LOGGING AT Mon Jun 14 02:59:57 2010
Jun 14 14:48:51 <holtmann> denkenz: Around?
Jun 14 14:53:45 <holtmann> denkenz: The MBM support for SIM cards with PIN enabled is broken. Modem shows up with SIM present = false.
Jun 14 14:56:10 <holtmann>         ServiceNumbers = [Voicemail] = '+31624001233' [Klantenservice] = '+31624001200'
Jun 14 14:56:22 <holtmann> denkenz: First time I saw a SIM with this ;)
Jun 14 15:11:11 <denkenz> holtmann: Don't see how, mbm inserts the sim in pre_sim
Jun 14 15:11:31 <holtmann> Take a SIM that PIN locked and try it.
Jun 14 15:11:41 <holtmann> f35xx hardware.
Jun 14 15:16:44 <denkenz> holtmann: Actually bug balrog-k1n about it
Jun 14 15:16:47 <denkenz> he messed with it last
Jun 14 15:17:02 <denkenz> I have no idea whether that trick he has in there works for PIN-enabled cards
Jun 14 15:17:17 <holtmann> balrog-k1n: There you go. Fix the MBM plugin for SIM cards with PIN enabled.
Jun 14 15:18:19 <holtmann> ofonod[904]: Modem: > AT+CSCB=0,"4352-4356"\r
Jun 14 15:18:20 <holtmann> ofonod[904]: Modem: < \r\n+CMS ERROR: 500\r\n
Jun 14 15:18:20 <holtmann> ofonod[904]: Setting Cell Broadcast topics failed
Jun 14 15:18:24 <holtmann> Hah. That is on MBM hardware.
Jun 14 15:20:27 <sameo_> denkenz: ping
Jun 14 15:22:54 <denkenz> sameo_: pong
Jun 14 15:24:29 <denkenz> holtmann: That is an unknown error, I never saw that one
Jun 14 15:32:24 <sameo_> denkenz: I'm having ppp0 disappearing when setting PrimaryDataContext Active property to 0. Ever seen that ?
Jun 14 15:33:51 <holtmann> That is normal. If you deactivate the context, then PPP will be terminated.
Jun 14 15:40:07 <sameo_> and crashing my kernel...
Jun 14 15:40:26 <sameo_> those devices are utter shit (Huawei Exxx).
Jun 14 15:43:12 <denkenz> never had the crashing kernel part
Jun 14 15:44:12 <denkenz> sameo_: ppp disappearing has nothing to do with the huawei
Jun 14 15:44:38 <denkenz> What exactly is crashing the kernel, ppp disappearance or something else?
Jun 14 15:44:50 <holtmann> What kernel are you running?
Jun 14 15:44:53 <denkenz> I frequently have kernel oopses when the tty is open and the device is removed
Jun 14 15:45:11 <holtmann> Could be that PPP disconnect and TTY HUP because of it ends up in a crash in the TTY layer.
Jun 14 15:45:16 <sameo_> holtmann: 2.6.34
Jun 14 15:45:28 <holtmann> Still on 2.6.33 and no problem.
Jun 14 15:45:42 <holtmann> So maybe you wanna check where it crashes.
Jun 14 15:45:42 <denkenz> There are also about a zillion race conditions between udev and tty layer
Jun 14 15:45:56 <holtmann> Stupid PPP modems do a TTY HUP when PPP disconnect.
Jun 14 15:46:51 <sameo_> denkenz: ppp disappearing is done by ofono's ppp layer ?
Jun 14 15:47:13 <holtmann> sameo_: Try with the gsmdial tool from ofono.git. Does that work for you?
Jun 14 15:48:13 <sameo_> holtmann: it does, and I can connect to my gsm network with ofono, it's the disconnecting part that's awful
Jun 14 15:48:37 <holtmann> I meant the ctrl-c with gsmdial. That should do the same as with ofonod.
Jun 14 15:50:06 <sameo_> holtmann: to check for kernel crashes ?
Jun 14 15:54:15 <sameo_> holtmann: gsmdial after ctrl-c: http://pastebin.com/3GvFBvvc
Jun 14 15:55:30 <denkenz> There's more that oFono does than gsmdial
Jun 14 15:55:45 <denkenz> however, removing ppp0 goes just fine there
Jun 14 16:05:19 <sameo_> denkenz: ok, so it's AT+CGDCONT who seems to be failing when I want to reconnect.
Jun 14 16:10:21 <denkenz> log? Sounds like the firmware is screwy
Jun 14 16:12:17 <sameo_> denkenz: you want -d "*" ?
Jun 14 16:14:36 <denkenz> nah
Jun 14 16:14:39 <denkenz> just the at log is fine
Jun 14 16:27:28 <sameo_> denkenz: do you need more than that: http://pastebin.com/8TL4dmcx ?
Jun 14 16:33:53 <denkenz> yeah, re-activating huawei doesn't work
Jun 14 16:34:05 <denkenz> It hups the modem channel and that one is never re-opened
Jun 14 16:35:41 <sameo_> so, I can't expect this modem to handle a reconnection ?
Jun 14 16:36:21 <denkenz> not today
Jun 14 16:36:36 <sameo_> :)
Jun 14 16:37:02 <denkenz> There's a solution on the novatel, but until we know it works I'm feeling entirely too lazy to port it to Huawei
Jun 14 16:46:08 <wagi> denkenz: hi, is my patch okay now?
Jun 14 17:16:07 <denkenz> wagi: haven't looked at it yet, lemme do it now
Jun 14 17:17:19 <denkenz> +               if (g_at_chat_send(nd->chat, "AT_OCTI?;_OUWCTI?",
Jun 14 17:17:20 <denkenz> +                       option_tech_prefix, option_tech_cb, cbd, NULL) <= 0)
Jun 14 17:17:22 <denkenz> +                       nd->tech = -1;
Jun 14 17:17:25 <denkenz> that nd->tech is pointless
Jun 14 17:18:13 <denkenz> Otherwise looks good
Jun 14 17:23:20 <wagi> yep, I see. Just call g_at_chat_send withouth the if.
Jun 14 17:28:10 <denkenz> ah I see what you're doing
Jun 14 17:28:33 <denkenz> let me modify my comment then
Jun 14 17:28:41 <denkenz> +               if (g_at_chat_send(nd->chat, "AT_OCTI?;_OUWCTI?",
Jun 14 17:28:42 <denkenz> +                       option_tech_prefix, option_tech_cb, cbd, NULL) <= 0)
Jun 14 17:28:44 <denkenz> +                       nd->tech = -1;
Jun 14 17:29:04 <denkenz> When you have something like that, the much more readable way of doing it is to indent the 2nd line of the if one more level
Jun 14 17:29:20 <wagi> ah okay
Jun 14 17:29:22 <denkenz> That way its easy to tell when the if actually begins
Jun 14 17:29:53 <wagi> will do. do you want 'break' at the end of this case too?
Jun 14 17:30:18 <denkenz> Yes, and checking for == 0 is enough
Jun 14 17:30:21 <denkenz> the id is always unsigned
Jun 14 17:30:50 <denkenz> guint g_at_chat_send_listing(GAtChat *chat, const char *cmd,
Jun 14 17:31:21 <denkenz> And since we're niggling
Jun 14 17:31:22 <denkenz> +               g_at_chat_send(nd->chat, "AT_OCTI?;_OUWCTI?",
Jun 14 17:31:24 <denkenz> +                       option_tech_prefix, option_query_tech_cb, tq, g_free);
Jun 14 17:31:25 <wagi> good catch :)
Jun 14 17:31:43 <denkenz> put an if around that one and g_free the tq if it fails
Jun 14 17:32:26 <denkenz> something like if (g_at_chat_send... > 0) return
Jun 14 17:32:32 <denkenz> otherwise g_free(tq); break;
Jun 14 17:33:17 <wagi> done
Jun 14 17:33:53 <denkenz> ok send it in
Jun 14 17:37:14 <wagi> on they way
Jun 14 18:21:59 <wagi> denkenz: thanks for the commit and fixes :)
Jun 14 20:10:12 <balrog-k1n> holtmann: seems to be working here
Jun 14 20:10:34 <balrog-k1n> http://pastebin.ca/1883141
Jun 14 20:39:24 <balrog-k1n> granted it's not always accepting the pin on the first try
Jun 14 20:41:51 <balrog-k1n> also setting powered to 0 and then back to 1 does not reset the pin state, only reconnecting the modem (to usb)
Jun 14 20:57:30 <holtmann> balrog-k1n: f36xx or f35xx?
Jun 14 20:57:57 <holtmann> balrog-k1n: Try with the f35xx hardware. I doesn't work there.
Jun 14 22:30:44 <balrog-k1n> holtmann: don't have any, but it's probably the command the plugin uses to check for sim presence
Jun 14 22:31:02 <balrog-k1n> can you find a command that tells us is there's a SIM inserted on both models?
Jun 14 22:31:38 <balrog-k1n> AT+CRSM=242 is used now
Jun 14 22:49:55 <denkenz> balrog-k1n: There is no such command
Jun 14 22:51:04 <balrog-k1n> denkenz: in general? or on mbm?
Jun 14 22:51:31 <balrog-k1n> it's in the spec and works on f36xx
Jun 14 22:52:09 <denkenz> balrog-k1n: There's no dedicated sim status command on the mbm
Jun 14 22:52:18 <denkenz> balrog-k1n: The fact that CRSM=242 works is pure luck
Jun 14 22:53:06 <balrog-k1n> then we need a different command that errors when the sim is not present, but doesn't have side effects
Jun 14 22:53:57 <denkenz> Nothing like that exists in mbm
Jun 14 22:54:04 <denkenz> I re-checked the docs
Jun 14 22:54:11 <balrog-k1n> maybe "AT+CPIN?"?
Jun 14 22:55:06 <denkenz> In theory
Jun 14 22:55:23 <denkenz> You might be able to get a CMS error of not inserted or something
Jun 14 22:56:15 <balrog-k1n> that should be what we need.. i'm sure there's some other command that will do the trick like AT+CRSM=242 does on f3607
Jun 14 22:58:08 <denkenz> perhaps, but checking the STATUS and expecting it to work without a select first is ... dangerous :)
Jun 14 23:00:12 <balrog-k1n> we don't care if card returns error
Jun 14 23:00:37 <denkenz> Yeah, but who knows what the firmware does
Jun 14 23:00:45 <denkenz> All of this is faked by the modem anyway
**** ENDING LOGGING AT Tue Jun 15 02:59:57 2010