On Fri, 2011-06-10 at 12:15 -0400, Eric Shienbrood wrote: > According to the documentation I have, the connection state field is > '-' when not connected. To quote more specifically: > > > 4) Response to AT%NWSTATE <CR> (execute command) > %NWSTATE: <signal strength>,<MCC/MNC>,<access > technology>,<connection state>,<regulation> > . . . > <connection state> possible values: > - for 2G access technologies and 3G access technology when not > connected > R99 for 3G access technology when connected > HSDPA for 3G access technology when connected and HSDPA > resource allocated by the network > HSUPA for 3G access technology when connected and HSUPA > resource allocated by the network > HSDPA-HSUPA for 3G access technology when connected and both > HSDPA and HSUPA resources allocated > by the network > > > I interpret that to mean that if the field is not '-', it indicates > the technology that's actually in use for the connection, so that's > what should be reported for access technology. If the field is '-', > then there's no connection, so we should report what's in the <access > technology> field instead. > > > Also, sorry about missing the g_free() for the result of > g_match_info_fetch(). Do you want me to send a new patch, or do you > want to take care of it?
Done & pushed, thanks! Dan > > Eric > > On Thu, Jun 9, 2011 at 5:47 PM, Dan Williams <[email protected]> wrote: > On Tue, 2011-06-07 at 10:35 -0400, Eric Shienbrood wrote: > > Thanks Aleksander! New patch file is attached. > > > I split these up and pushed all hunks except the hunk for > processing the > match info for the NWSTATE response. Two things there... > first you need > to make sure you free the result of g_match_info_fetch() since > that's an > allocated string. Second, what does '-' mean again for the > <connected> > field? I had the docs at some point but I appear to have lost > them; > what other values can be there, and why don't we want to > update the > access technology when that field is something other than '-'? > > Thanks! > Dan > > > > Eric > > > > > > > > On Tue, Jun 7, 2011 at 2:56 AM, Aleksander Morgado > > <[email protected]> wrote: > > Hi Eric, > > > > > > > The additional error detail allows us to know that > a > > connection failed > > > because of an invalid APN. Also, when handling > access > > technology > > > changes, report the technology in use if we're > connected. > > Finally, > > > avoid using CFUN=0 when disabling the modem. > > > > > > A small thing to fix in the patch. > > > > All callbacks receiving a response from the AT > serial port > > should check > > if the modem has already been removed, so in > > query_network_error_code_done(), this check is > needed just > > before trying > > to parse any reply: > > > > /* If the modem has already been removed, return > without > > * scheduling callback */ > > if (mm_callback_info_check_modem_removed (info)) > > return; > > > > See > > > > http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=9323daec015ecad65c39b6020b62e864c027d858 > > > > Cheers! > > > > -- > > Aleksander > > > > > > > > > _______________________________________________ > > networkmanager-list mailing list > > [email protected] > > http://mail.gnome.org/mailman/listinfo/networkmanager-list > > > > _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
