On Thu, 7 Feb 2008, Tambet Ingo wrote: > On Feb 7, 2008 1:38 PM, Markus Becker <[EMAIL PROTECTED]> wrote: > <snip> >> However, I needed to modify nm-gsm-device to work with the Option card to >> try the registration again also for the reply "+CREG: 0,0". After the >> second or third "+CREG: 0,0" reply, it then replies with "+CREG: 0,2" as >> expected. This patch works for me: > > This doesn't look quite right to me. CREG: 0,0 means 0,"not > registered, MT is not currently searching a new operator to register > to". Or, the device isn't trying to associate so there's no point in > waiting for successful attempt. The correct thing to do in case of > that response would be to make the card start registration. At the > same time, the registration code we have is very primitive and works > only on ideal case, so if the patch makes it work for you, I wouldn't > mind committing it. The only side effect (in case of some other cards) > would be that NM just waits there doing nothing before it finally > fails.
I know that 0,0 says that the card is currently not scanning. But after a few seconds this changes for me(TM): Feb 7 20:55:46 shelbyville NetworkManager: <debug> [1202414146.183905] serial_debug(): Sending: 'AT+CPIN="1234" ' Feb 7 20:55:46 shelbyville NetworkManager: <debug> [1202414146.404885] serial_debug(): Got: ' OK ' Feb 7 20:55:46 shelbyville NetworkManager: <debug> [1202414146.405141] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:46 shelbyville NetworkManager: <debug> [1202414146.424868] serial_debug(): Got: ' +CREG: 0,0 OK ' Feb 7 20:55:47 shelbyville NetworkManager: <debug> [1202414147.424280] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:47 shelbyville NetworkManager: <debug> [1202414147.444827] serial_debug(): Got: ' +CREG: 0,0 OK ' Feb 7 20:55:48 shelbyville NetworkManager: <debug> [1202414148.444296] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:48 shelbyville NetworkManager: <debug> [1202414148.464781] serial_debug(): Got: ' +CREG: 0,0 OK ' Feb 7 20:55:49 shelbyville NetworkManager: <debug> [1202414149.464297] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:49 shelbyville NetworkManager: <debug> [1202414149.484714] serial_debug(): Got: ' +CREG: 0,2 OK ' Feb 7 20:55:50 shelbyville NetworkManager: <debug> [1202414150.484278] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:50 shelbyville NetworkManager: <debug> [1202414150.505641] serial_debug(): Got: ' +CREG: 0,2 OK ' Feb 7 20:55:51 shelbyville NetworkManager: <debug> [1202414151.508265] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:51 shelbyville NetworkManager: <debug> [1202414151.533581] serial_debug(): Got: ' +CREG: 0,2 OK ' Feb 7 20:55:52 shelbyville NetworkManager: <debug> [1202414152.536290] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:52 shelbyville NetworkManager: <debug> [1202414152.558516] serial_debug(): Got: ' +CREG: 0,2 OK ' Feb 7 20:55:53 shelbyville NetworkManager: <debug> [1202414153.560265] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:53 shelbyville NetworkManager: <debug> [1202414153.582456] serial_debug(): Got: ' +CREG: 0,2 OK ' Feb 7 20:55:54 shelbyville NetworkManager: <debug> [1202414154.585256] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:54 shelbyville NetworkManager: <debug> [1202414154.608355] serial_debug(): Got: ' +CREG: 0,2 OK ' Feb 7 20:55:55 shelbyville NetworkManager: <debug> [1202414155.608304] serial_debug(): Sending: 'AT+CREG? ' Feb 7 20:55:55 shelbyville NetworkManager: <debug> [1202414155.847324] serial_debug(): Got: ' +CREG: 0,1 OK ' Feb 7 20:55:55 shelbyville NetworkManager: <info> Registered on Home network I cross checked with gcom / comgt from pharscape, it does it similarly to NM. After sending CPIN gcom also sends CREG and retries CREG until it gets either 0,1, 0,5 or timeout. > >> Currently I am struggling with the routes and the IP configuration, setted >> after dialing in. They do not seem reasonable to me and I cannot reach the >> DNS server nor the peer (10.64.64.64). > > Are you on some suse distribution? No. Debian. It might be that I do not get the correct DNS server from the peer: Feb 7 20:55:56 shelbyville pppd[10716]: Using interface ppp0 Feb 7 20:55:56 shelbyville pppd[10716]: Connect: ppp0 <--> /dev/ttyUSB0 Feb 7 20:55:56 shelbyville pppd[10716]: PAP authentication succeeded Feb 7 20:56:34 shelbyville pppd[10716]: Could not determine remote IP address: defaulting to 10.64.64.64 Feb 7 20:56:34 shelbyville pppd[10716]: Cannot determine ethernet address for proxy ARP Feb 7 20:56:34 shelbyville pppd[10716]: local IP address 90.186.19.42 Feb 7 20:56:34 shelbyville pppd[10716]: remote IP address 10.64.64.64 Feb 7 20:56:34 shelbyville pppd[10716]: primary DNS address 10.11.12.13 Feb 7 20:56:34 shelbyville pppd[10716]: secondary DNS address 10.11.12.14 > If yes, you need to change > /etc/sysconfig/network/config and set > > MODIFY_RESOLV_CONF_DYNAMICALLY="no" > > There's a lot of magic involved with suse network scripts, don't ask... > > Tambet > _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
