**** BEGIN LOGGING AT Mon Jun 07 02:59:56 2010 Jun 07 05:40:40 holtmann: ok, I'll test Jun 07 09:38:54 denkenz: So for the Novatel driver, it now re-opens the TTY for GPRS context setup. So I can open/close PPP sessions multiple times. Jun 07 09:39:07 Works nicely with ConnMan now (besides the routing setup). Jun 07 09:40:14 Missing piece is just the Technology property update. And if we work it out the NITZ update. Then this support is done. Jun 07 09:40:40 ofonod[24423]: 1st:< \r\nCONNECT HSDPA 7.2\r\n Jun 07 09:40:41 L Jun 07 09:40:41 �Z Jun 07 09:40:41 L Jun 07 09:40:43 �ZEntering new phase: 1 Jun 07 09:40:50 I am still curious where this debug string crap comes from. Jun 07 09:41:21 Anyhow, we get these now: Jun 07 09:41:23 Entering new phase: 0 Jun 07 09:41:23 ofonod[24423]: 1st:< \r\nNO CARRIER\r\n Jun 07 09:41:23 ofonod[24423]: 2nd:< \r\nNO CARRIER\r\n Jun 07 09:41:23 ofonod[24423]: Reopened GPRS context channel Jun 07 09:41:52 And the the driver can handle them proper via disconnect callback of the chat object. Jun 07 09:42:28 kvalo: Btw. for your Huawei modem. What does AT+CLAC gives you? Jun 07 09:43:00 Something like $QCDMAT or similar? Jun 07 09:54:06 kvalo: How screwed up is your Huawei dongle really? Jun 07 10:19:54 holtmann: I'll test CLAC soon Jun 07 10:20:19 holtmann: this is my first and only modem, so I can't comment :) Jun 07 10:21:36 As I said, I have the Novatel working. Only missing piece is the current tech reporting. Otherwise even tech preference selection works. Jun 07 10:22:11 However you need two full AT command channels. Otherwise you are screwed. Jun 07 10:22:52 kvalo: And did you ever test SMS with your Huawei device? Jun 07 10:23:40 nope, I haven't tested SMS at all Jun 07 10:28:47 Hah. It was utterly broken. At least with my E160. Jun 07 10:28:54 Now it works :) Jun 07 10:32:59 cool Jun 07 11:17:46 holtmann: at least ofono was able to show one incoming sms. it was an ad :? Jun 07 11:17:50 :/ Jun 07 11:18:22 And then the device hang itself. Jun 07 11:19:50 yeah, it didn't work after that. but I have other problems as well, I'll investigate Jun 07 11:22:19 ofonod[3511]: plugins/huawei.c:huawei_enable() 0x1d77100 m Jun 07 11:22:21 odem /dev/ttyUSB0 event /dev/ttyUSB1 Jun 07 11:22:37 but it should use ttyUSB2 for event. Jun 07 11:23:10 I assume ofono_modem_register() is now called too early for my modem and "03" is not set as it should be Jun 07 11:23:26 for SecondaryDevice I mean Jun 07 11:27:04 So how screwed up is your modem? Jun 07 11:27:38 Please check the AT+CLAC list and see if we have a chance to turn QCDM port into something useful. Jun 07 11:27:48 sorry, forgot that one Jun 07 11:27:55 Also what happens if you ^PORTSEL the event port into the QCDM port. Jun 07 11:28:12 Does actually gatchat/test-qcdm /dev/ttyUSB1 work for you on this card. Jun 07 11:36:11 $ gatchat/test-qcdm Jun 07 11:36:11 Device: /dev/ttyUSB1 Jun 07 11:36:20 and that's it Jun 07 11:36:43 should I send commands from ttyUSB0 first? Jun 07 11:37:39 AT+CLAC Jun 07 11:37:39 +CLAC:&C,&D,&E,&F,&S,&V,&W,E,I,L,M,Q,V,X,Z,T,P,\Q,\S,\V,%V,D,A,H,O,S0,S2,S3,S4,, Jun 07 11:37:40 OK Jun 07 11:37:55 that was from minicom Jun 07 11:38:57 on ttyUSB0 Jun 07 11:41:54 What about AT&V Jun 07 11:42:14 So not even QCDM is working on that dongle. Jun 07 11:44:29 What Huawei dongle is this? I might have to get one of them. Jun 07 11:44:53 holtmann: Huawei E1552 Jun 07 11:45:17 AT^PORTSEL=? Jun 07 11:45:18 ^PORTSEL:(0-1) Jun 07 11:45:24 AT^PORTSEL? Jun 07 11:45:24 ^PORTSEL:0 Jun 07 11:45:32 AT^PORTSEL=1 Jun 07 11:45:34 OK Jun 07 11:45:51 and no difference :( Jun 07 11:47:09 AT&V: http://paste.ubuntu.com/446056/ Jun 07 11:48:10 Do you have /proc/bus/usb/devices for that one for me please. Jun 07 11:48:43 ^CVOICE: ??? Jun 07 11:49:59 heh, I don't have /proc/bus/usb, but here's lsusb: Jun 07 11:50:01 Bus 001 Device 030: ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem Jun 07 11:50:39 I think this modem is simlocked for finnish saunalahti/elisa operator Jun 07 11:51:20 Just mount it. Jun 07 11:52:13 What does AT^VOICE=? say. Just for fun. Jun 07 11:52:33 Sorry AT^CVOICE=? of course. Jun 07 11:52:33 AT^VOICE=? Jun 07 11:52:35 ERROR Jun 07 11:52:43 ah Jun 07 11:53:00 AT^CVOICE=? Jun 07 11:53:00 ^CVOICE:(0) Jun 07 11:53:01 OK Jun 07 11:53:24 AT^CVOICE? Jun 07 11:53:24 ^CVOICE:0,8000,16,20 Jun 07 11:53:26 OK Jun 07 11:54:00 voice capability would be cool :) Jun 07 11:58:13 holtmann: ubuntu kernels have usbfs disabled, that's why I don't have /proc/bus/usb Jun 07 11:58:41 Then run usbdevices.sh script. Jun 07 12:04:10 holtmann: never heard of that one. where is it? Jun 07 12:04:34 hmm, maybe it's usb-devices Jun 07 12:05:07 yeah, that has to be it Jun 07 12:05:22 T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 30 Spd=480 MxCh= 0 Jun 07 12:05:22 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 Jun 07 12:05:22 P: Vendor=12d1 ProdID=1001 Rev=00.00 Jun 07 12:05:22 S: Manufacturer=HUAWEI Technology Jun 07 12:05:22 S: Product=HUAWEI Mobile Jun 07 12:05:24 C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA Jun 07 12:05:27 I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option Jun 07 12:05:29 I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option Jun 07 12:05:32 I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option Jun 07 12:05:34 I: If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Jun 07 12:05:37 I: If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Jun 07 12:06:47 It misses the endpoints, but so be it. Jun 07 12:07:10 C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA Jun 07 12:07:10 I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option Jun 07 12:07:13 e-yes: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=128ms Jun 07 12:07:13 e-yes: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms Jun 07 12:07:14 e-yes: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Jun 07 12:07:15 I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option Jun 07 12:07:16 e-yes: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms Jun 07 12:07:18 e-yes: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Jun 07 12:07:21 Stuff like this. Jun 07 12:07:40 hmm, let me find that for you Jun 07 12:07:53 Anyhow. So you are saying that ttyUSB0 is standard AT. ttyUSB1 unclear. And ttyUSB2 is receive event only. Jun 07 12:07:59 Nevermind. Jun 07 12:08:19 yes, exactly Jun 07 12:08:40 or I have been sending commands through ttyUSB2 Jun 07 12:08:55 but I can't create PPP connection through ttyUSB2 Jun 07 12:10:17 So AT commands on ttyUSB2 are working. Jun 07 12:11:02 I tested few commands some time ago Jun 07 12:11:09 manually from minicom Jun 07 12:12:11 Test again. Jun 07 12:12:15 If that works then that is just fine. Jun 07 12:12:39 So the Novatel driver only puts GPRS context atom on ttyUSB0. All the other ones are running on ttyUSB1. Jun 07 12:12:47 ok Jun 07 12:14:22 If you can send AT commands on ttyUSB2 for SMS, devinfo, netreg etc. then we are just fine. Jun 07 12:14:27 A Jun 07 12:14:29 ^RSSI:21 Jun 07 12:14:29 T+CFUN Jun 07 12:14:29 ^RSSI:21 Jun 07 12:14:29 ? Jun 07 12:14:29 +CFUN: 1 Jun 07 12:14:53 AT+CFUN=1 is a bad example. Jun 07 12:15:04 Since that one is not part of an atom an always goes on ttyUSB0. Jun 07 12:15:16 Try AT+CREG? Jun 07 12:15:22 +CGREG: 0,1 Jun 07 12:15:31 seems to work Jun 07 12:15:37 at&v worked Jun 07 12:15:59 So you need to redo the Huawei driver to have PrimaryDevice and SecondaryDevice and have it match what the Novatel driver does. Jun 07 12:16:12 AT+COPS? Jun 07 12:16:14 +COPS: 0,0,"Saunalahti",2 Jun 07 12:16:28 Most likely we can have a generic Qualcomm based plugin. Jun 07 12:16:42 ok, I'll do that at some point Jun 07 12:16:44 Only the quirk and special atom selection is different. Jun 07 12:16:51 but what about the tty port problem? Jun 07 12:17:00 And the init part with the $NWDMAT stuff for Qualcomm. Jun 07 12:17:10 The HUP issue. Jun 07 12:17:35 I mean ttyUSB1 or ttyUSB2 problem Jun 07 12:17:49 That is an issue with the udev plugin. Jun 07 12:17:50 I guess we need to hardcode ports? Jun 07 12:18:06 It needs to set PrimaryDevice and SecondaryDevice correctly. Jun 07 12:18:26 sure, but how? :) Jun 07 12:18:27 Most likely you need to count the number of interface. Jun 07 12:19:08 or do it like MM and wait for ^RSSI events Jun 07 12:19:23 No. Jun 07 12:19:51 not even huawei plugin? Jun 07 12:19:57 *even in Jun 07 12:20:26 We don't wanna open ports that don't concern us. Jun 07 12:21:46 Btw. with putting GPRS and netreg atoms on the second channel. The hack for CGREG should not be needed anymore. Jun 07 12:22:34 true, that's very good Jun 07 12:24:29 So you have work to do now ;) Jun 07 12:25:49 I have :) I can't do it today, have to finish something else first Jun 07 12:26:31 denkenz: So sending AT+CSCB=1 to clear the previous CBS topics makes this work on Qualcomm devices. Jun 07 12:26:46 Now I can set topic lists easily and enable cell broadcast. Jun 07 12:26:52 How do you wanna deal with this? Jun 07 12:27:03 Also why can we only set topics 0-999? Jun 07 12:27:51 1000 Location Service, E-OTD Assistance Data message Jun 07 12:27:51 1001 Location Service, DGPS Correction Data message Jun 07 12:27:51 1002 Location Service, GPS Ephemeris and Clock Correction Data message Jun 07 12:27:51 1003 Location Service, GPS Almanac and Other Data message Jun 07 12:27:58 What about these for example. Jun 07 14:48:43 holtmann: Do you sleep? Jun 07 14:49:03 holtmann: Few comments, the disconnect_function hack is nice, but not enough Jun 07 14:49:20 holtmann: There's still a race between gatchat & ppp stack getting the hup Jun 07 14:49:42 denkenz: apparently he doesn't sleep ;) Jun 07 14:50:17 holtmann: For CBS, we send CSCB=1,"0-65536" Jun 07 14:50:23 That should clear out any old channels Jun 07 14:50:38 If the huawei needs CSCB=1, then quirk is needed Jun 07 14:52:53 holtmann: And nobody said we can't handle topics > 999, the cbs range is a full unsigned short Jun 07 14:53:26 holtmann: Just the user-settable range is 0-999, so I thought maybe the firmware doesn't allow to set anything outside that range Jun 07 15:13:58 denkenz: hi, i've just send an update on the option technology patch. I have spend the complete day rewriting this patch. The option firmware is really fancy... Jun 07 15:27:02 wagi: This doesn't do what you think it does: Jun 07 15:27:03 + g_at_chat_send(nd->chat, "AT_OCTI?", creg_prefix, Jun 07 15:27:05 + at_octi_cb, cbd, NULL); Jun 07 15:27:06 + g_at_chat_send(nd->chat, "AT_OWCTI?", creg_prefix, Jun 07 15:27:08 + at_owcti_cb, cbd, g_free); Jun 07 15:27:22 you mean the g_free thing, right? Jun 07 15:27:45 nope, the creg_prefix Jun 07 15:28:09 You're actually ending up processing the result lines in the unsolicited callback Jun 07 15:28:34 the prefix part tells gatchat which command lines belong to this command Jun 07 15:28:39 ah, okay Jun 07 15:29:04 this is meant to separate stuff like RING appearing in the middle of command execution Jun 07 15:29:15 so NULL should be used? Jun 07 15:29:27 no, NULL means gobble everything Jun 07 15:29:51 Just look at the definition of creg_prefix, you'll get it Jun 07 15:29:59 thanks Jun 07 15:30:03 I'll do htat Jun 07 15:31:08 fixed Jun 07 15:33:56 do I have to do the same thing for the _notify part of octi/owcti? Jun 07 15:34:36 the register works similarly, but afaik that already has the prefix setup Jun 07 15:40:31 the "_OCTI:" is registered in at_creg_set_cb with otpion_octi_notify cb. Won't that intefier with the prefix registration for at_octi_cb? Jun 07 15:40:50 nope, gatchat is smart Jun 07 15:41:08 a very good Jun 07 15:41:10 it gives preference to currently executed commands Jun 07 15:41:24 However, bizarre situations can still happen Jun 07 15:41:33 e.g. CREG unsolicited notification firing while in CREG? Jun 07 15:41:58 +static void option_ossysi_notify(GAtResult *result, gpointer user_data) Jun 07 15:42:00 +{ Jun 07 15:42:01 + struct ofono_netreg *netreg = user_data; Jun 07 15:42:03 + struct netreg_data *nd = ofono_netreg_get_data(netreg); Jun 07 15:42:04 + GAtResultIter iter; Jun 07 15:42:06 + Jun 07 15:42:07 + g_at_result_iter_init(&iter, result); Jun 07 15:42:09 + Jun 07 15:42:10 + if (!g_at_result_iter_next(&iter, "_OSSYSI:")) Jun 07 15:42:12 + return; Jun 07 15:42:13 + Jun 07 15:42:15 + if (!g_at_result_iter_next_number(&iter, &nd->ossysi)) Jun 07 15:42:16 return; Jun 07 15:42:18 Jun 07 15:42:19 - ofono_info("OCTI mode: %d", mode); Jun 07 15:42:21 + switch (nd->ossysi) { Jun 07 15:42:22 + case 0: Jun 07 15:42:24 + g_at_chat_send(nd->chat, "AT_OCTI?", none_prefix, Jun 07 15:42:25 + NULL, NULL, NULL); Jun 07 15:42:27 + break; Jun 07 15:42:28 + case 2: Jun 07 15:42:30 + g_at_chat_send(nd->chat, "AT_OWCTI?", none_prefix, Jun 07 15:42:31 + NULL, NULL, NULL); Jun 07 15:42:33 + break; Jun 07 15:42:34 + } Jun 07 15:42:36 } Jun 07 15:42:37 I don't get the need for this one Jun 07 15:43:03 + if (!g_at_result_iter_next_number(&iter, &nd->octi)) Jun 07 15:43:05 + return; Jun 07 15:43:06 + Jun 07 15:43:08 + option_octi_owcti_to_tech(nd); Jun 07 15:43:09 + ofono_netreg_status_notify(netreg, Jun 07 15:43:11 + nd->status, nd->lac, nd->ci, nd->tech); Jun 07 15:43:12 + Jun 07 15:43:14 +} Jun 07 15:43:15 + Jun 07 15:43:18 according to MM the OSSYSI gives you addition information abouth the current technology Jun 07 15:43:42 so if OCTI and OWCTI is set Jun 07 15:43:50 OSSYSI tells which one to use Jun 07 15:44:06 I agree it looks rather nasty Jun 07 15:44:14 its not necessary Jun 07 15:44:23 you always query both anyway Jun 07 15:44:28 yes Jun 07 15:44:39 but how can I tell which one I should use? Jun 07 15:44:42 And in octi/owcti notify, you might want to not fire ofono_netreg_status_notify if the mode is 0 Jun 07 15:45:25 If octi=0, no 2G tech is used Jun 07 15:45:30 if owcti=0 no 3G tech is used Jun 07 15:46:09 yep, I'll test this Jun 07 15:46:25 I can remember if the modem did that in the past Jun 07 15:46:44 s/can/can't/ Jun 07 15:47:00 so I should drop the whole OSSYSI thing? Jun 07 15:47:09 pretty much Jun 07 15:47:34 Also, at least on my 452, the OCTI/OWCTI arrive before CREG Jun 07 15:47:40 So you don't actually need to query Jun 07 15:47:49 same here Jun 07 15:48:14 so I could completely rely on the notifications? Jun 07 15:48:29 That would be cleaner and more efficient Jun 07 15:48:35 totaly agree Jun 07 15:48:44 but we need to test whether that actually works in all cases Jun 07 15:48:46 let me fix this up Jun 07 15:48:49 yep Jun 07 16:10:28 as it seems there is no update on OCTI & OWCTI when the modem decides to switch from UTMS to GPRS due low signal strength. Only OSSYSI is there Jun 07 16:14:46 as it seems there is no update on OCTI & OWCTI when the modem decides to switch from UTMS to GPRS due low signal strength. Only OSSYSI is there Jun 07 16:15:15 Ok Jun 07 16:15:34 Its not what I see from newer dongles Jun 07 16:15:47 You have the iCon 225 right? Jun 07 16:15:58 I have a icon 451 here Jun 07 16:17:16 hm, interesting, we don't see this on the 452 Jun 07 16:17:32 Does your 451 have a retractable USB slot? Jun 07 16:17:38 Or is it the rectangular flip out one? Jun 07 16:18:12 it's one of thos retractable USB slot thingies Jun 07 16:18:35 ok, so you have the 'new' version as well Jun 07 16:18:43 In that case we must poll Jun 07 16:19:01 let me do some changes to the core, since holtmann's Novatel requires the same Jun 07 16:19:13 okay Jun 07 16:28:32 enough for today. see you. **** BEGIN LOGGING AT Mon Jun 07 18:28:14 2010 Jun 07 18:39:33 denkenz: oh! sorry. I'll resend them all. Jun 07 18:46:40 denkenz: So about CBS again. Jun 07 18:55:21 It seems I have to send a AT+CSCB=1 before every call. So essentially programming the whole list again. Jun 07 18:56:32 dbus.exceptions.DBusException: org.ofono.Error.InvalidFormat: Argument format is not recognized Jun 07 18:56:40 Only topics 0-999 can be set from user. Jun 07 18:58:05 while (next_range(ranges, &offset, &min, &max) == TRUE) { Jun 07 18:58:05 if (min < 0 || min > 999) Jun 07 18:58:05 return NULL; Jun 07 18:58:05 if (max < 0 || max > 999) Jun 07 18:58:06 return NULL; Jun 07 18:58:06 if (max < min) Jun 07 18:58:09 return NULL; Jun 07 18:58:09 } Jun 07 18:58:11 In src/smsutil.c Jun 07 19:01:46 holtmann: User yes, but not to the modem Jun 07 19:02:15 holtmann: Sounds like we need to quirk the qualcomm cbs driver to send a clear command before setting it Jun 07 19:02:40 Do you want a new atom driver for this or just a quirk. Jun 07 19:02:58 Btw. I haven't received any CBS since Rogers here is not sending them. Jun 07 19:03:16 quirk should do it Jun 07 19:03:30 So how about having some extra properties for the Location ones and the Emergency ones. Or should these be always on? Jun 07 19:03:58 ofonod[3341]: 2nd:> AT+CSCB=1\r Jun 07 19:03:58 ofonod[3341]: 2nd:< \r\nOK\r\n Jun 07 19:03:58 ofonod[3341]: 2nd:> AT+CSCB=0,"4352-4356,0-999"\r Jun 07 19:03:58 ofonod[3341]: 2nd:< \r\nOK\r\n Jun 07 19:04:05 I've no idea about the Location ones, where did you find those? Jun 07 19:04:06 And I really hope the order doesn't make a difference. Jun 07 19:04:10 the ETWS should be always on Jun 07 19:04:16 http://www.nobbi.com/wiki/doku.php/cell_broadcast Jun 07 19:05:06 And what about the Language encoding? Jun 07 19:05:16 Language is a PoS Jun 07 19:05:22 We ignore it for now Jun 07 19:06:16 Also, I'm pretty sure the core should be sorting the ranges for CSCB Jun 07 19:08:17 It at least doesn't sort them. Jun 07 20:08:27 holtmann: Actually yes, it doesn't, fixed now Jun 07 20:09:41 holtmann: So I examined separating tech reporting and netreg status a bit more Jun 07 20:09:54 holtmann: Its actually a bit of a pain in the ass Jun 07 20:30:41 Do you have a solution? Jun 07 20:31:05 honestly I want to keep the current solution Jun 07 20:31:21 what is the problem with delaying creg notifications until tech is queried? Jun 07 20:31:21 So how do we handle this then. Jun 07 20:32:33 I would need to do this in the core. I was actually looking forward to do this in the plugins. Jun 07 20:41:11 eh? Jun 07 20:41:42 not really, in creg_notify: if (NOVATEL_QUIRK) -> send novatel tech query Jun 07 20:41:53 novatel_tech_query_cb -> ofono_netreg_status_notify(); Jun 07 21:15:01 denkenz: I also think we need to poll CREG since this Novatel modem is not really doing updates. Or at least I don't understand when they do it. Jun 07 21:15:11 At least not when switching cell towers. Jun 07 21:15:35 the core will never poll, that is stupid Jun 07 21:15:52 I might be missing some magic, but I don't see any updates. Jun 07 21:15:53 if the modem is insane enough not to do this properly, then a custom driver with polling is needed Jun 07 21:17:22 Crap. So we only get proper tech values from CGREG. Jun 07 21:17:34 Or the CNTI just before CGREG. Jun 07 21:18:12 yep, the whole edge/umts/hspa stuff actually belongs on dcm Jun 07 21:18:22 On netreg we can simply show 2g/3g/4g Jun 07 21:18:56 So how do I report the tech from dcm. Jun 07 21:19:19 that requires core changes :( Jun 07 21:19:28 This is all fucked :( Jun 07 21:19:48 yep, the problem is that internally the data registration is handled separately Jun 07 21:20:09 if you play with +CGCLASS, you get into fun situations where CREG is never reported Jun 07 21:21:18 You need to figure out on how you wanna handle this. I am out of ideas. Jun 07 21:21:41 me too, this is completely different between device families Jun 07 21:21:47 isi handles this differently too Jun 07 21:23:08 (rather sanely unfortunately) :) Jun 07 21:29:03 For me this is the only part that is missing for the Novatel hardware (besides the CBS quirks) and then I would be done with it. Jun 07 21:29:19 I gave up on NITZ updates since for some reason the AT commands don't do anything properly. Jun 07 21:33:09 And we need proper current tech reporting. Otherwise our UI will not be able to work properly. Jun 07 21:33:35 the stupid thing is this all works properly on voice capable modems Jun 07 21:33:37 denkenz: So should we just start with reporting the GPRS tech in DCM. Jun 07 21:33:57 its only the hacked data-only dongles that do this improperly Jun 07 21:34:18 I know, but then again, we have to make these work as well. Jun 07 21:34:33 For ConnMan it would be fine to just listen to tech changes from DCM. Jun 07 21:34:51 work sure, but tech reporting is a nice to have feature Jun 07 21:35:03 even most vendor UIs don't support it Jun 07 21:35:24 Actually all the ones I have seen do support it. Jun 07 21:37:17 I've seen ones from Option and Huawei that don't Jun 07 21:37:53 Huawei does. At least the stuff they deliver for O2. Jun 07 22:21:52 grr, i hate udev Jun 07 22:22:02 What now? Jun 07 22:22:20 Tell me wtf is wrong with this: Jun 07 22:22:21 ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1003", ATTRS{bInterfaceNumber}=="00", ENV{OFONO_HUAWEI_TYPE}="Modem" Jun 07 22:29:43 Looks fine to me. Jun 07 22:29:50 yeah, and doesn't work Jun 07 22:30:38 I don't even wanna do it this way in the end. Companies tend to re-use product ids and that would complicate things. Jun 07 22:31:22 personally I don't see any other way Jun 07 22:31:38 at least it works better than the current way Jun 07 22:34:50 I will work on this one next week or so. I wanna get Huawei and Novatel working. Jun 07 22:35:55 if only I could get udev to cooperate I'd work on this too Jun 07 22:36:15 Just fake it with modemconf. Jun 07 22:36:35 that's the point, I want udev too Jun 07 22:39:09 Different topic. You read the backlog from Kalle and me? Jun 07 22:39:31 So his second (or third) port accepts AT commands just fine. It just doesn't do PPP. Jun 07 22:39:33 not particularly carefully Jun 07 22:39:46 yeah, this is why I'm doing what I'm doing ;) Jun 07 22:39:47 So we have even two ports on his card. Jun 07 22:40:13 So just GPRS context atom on ttyUSB0 and then all the rest on ttyUSB2 like the Novatel driver does and we are good. Jun 07 22:40:34 yep Jun 07 22:40:49 except the huawei driver is all fucked up now Jun 07 22:41:02 Why they have a non AT port in the middle of it is still a question mark, but whatever. Jun 07 22:41:44 And it is not even talking QCDM. Jun 07 22:41:57 Maybe it can be used for a high speed Ethernet device. Jun 07 22:43:10 it might be yet another diagnostic protocol Jun 07 22:43:17 They do refer to it as Diag port Jun 07 22:53:40 Where is that? Windows driver or where? Jun 07 22:54:08 docs Jun 07 22:54:15 Which docs? Jun 07 22:54:20 huawei docs Jun 07 22:54:29 Link please. Jun 07 22:54:43 dunno, some google foo got it for me Jun 07 22:54:53 Then send me a copy. Jun 07 22:55:07 twas last week, don't think I kept it Jun 07 23:58:49 holtmann: so my E160G seems to be working with my changes Jun 08 00:03:46 The E160 should have been working already. At least mine was. Just needed a bit more work to get to the state of the Novatel one. Jun 08 00:08:12 holtmann: I know, but I moved rssi handling into netreg and a few other changes Jun 08 00:08:25 holtmann: we still need to solve the hup reliably Jun 08 00:09:54 holtmann: pushed, have a look Jun 08 00:12:49 I have to redo all the udev stuff at some point, but right now I couldn't care less. Jun 08 00:13:59 "Pcui" Why? Jun 08 00:14:17 Might as well use the same bloody terminology as Huawei Jun 08 00:14:21 Just call it "PCUI". Modem string and debug string. Way easier to read. Jun 08 00:15:20 Feel free to change it, I'm still in Trolltech CamelCase mode Jun 08 00:16:29 And udev stuff now isn't too bad, not sure what else you can change Jun 08 00:16:55 The plugins/udev.c is getting crappy though Jun 08 00:17:22 Hence we have to do some changes. I will look into that eventually. Jun 08 00:17:52 And btw. the disconnect callback magic with the TTY HUP works, because the NO CARRIER and the HUP comes just a bit later after we already resumed GAtChat. Jun 08 00:18:16