openSUSE fails to utilize active Broadband connection

Laptop: Dell Precision M4400
openSUSE version: 11.1 x86_64
Wireless device: Novatel Ovation U727
Service provider: Sprint Nextel

For the past couple of years I have been using a USB broadband wireless modem with openSUSE 10.x (i686) on my old desktop system. Connection is done using a simple pppd script. Connections are quite fast and remain persistent for hours at a time as long as my email client is active and checking for new messages at periodic intervals.

A few months ago I traveled out of town taking along my old laptop onto which I installed openSUSE 11.0 (i686). I configured the laptop to connect using KPPP (pppd script worked also). Broadband connections in semi-rural Oklahoma were still fairly fast and persistent.

SO HERE’S MY PROBLEM:

I have purchased a new laptop - described above - to replace the old desktop system (and the old laptop, too). I have installed openSUSE 11.1 (x86_64), which is very nice, but I can’t get the system to utilize the active broadband connection. When I execute the pppd script, it opens a connection to Sprint, acquires an IP address, and then terminates after 10 minutes of inactivity:

D7BFKQH1:~ # pppd call sprint
Script /usr/sbin/chat -v -t3 -f /etc/ppp/peers/sprint_chat finished (pid 13490), status = 0x0
Serial connection established.
using channel 1
Using interface ppp0
Connect: ppp0 <–> /dev/ttyUSB0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xd663cd4f> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x9 <asyncmap 0x0> <magic 0x7b0f7664> <pcomp> <accomp>]
sent [LCP ConfAck id=0x9 <asyncmap 0x0> <magic 0x7b0f7664> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xd663cd4f> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0xd663cd4f]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
rcvd [LCP DiscReq id=0xa magic=0x7b0f7664]
rcvd [IPCP ConfReq id=0x3 <addr 68.28.185.69>]
sent [IPCP ConfAck id=0x3 <addr 68.28.185.69>]
rcvd [LCP EchoRep id=0x0 magic=0x7b0f7664 d6 63 cd 4f]
rcvd [LCP ProtRej id=0xb 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Protocol-Reject for ‘Compression Control Protocol’ (0x80fd) received
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
rcvd [IPCP ConfNak id=0x2 <addr 173.96.84.245> <ms-dns1 68.28.186.91> <ms-dns2 68.28.178.91>]
sent [IPCP ConfReq id=0x3 <addr 173.96.84.245> <ms-dns1 68.28.186.91> <ms-dns2 68.28.178.91>]
rcvd [IPCP ConfAck id=0x3 <addr 173.96.84.245> <ms-dns1 68.28.186.91> <ms-dns2 68.28.178.91>]
local IP address 173.96.84.245
remote IP address 68.28.185.69
primary DNS address 68.28.186.91
secondary DNS address 68.28.178.91
Script /etc/ppp/ip-up started (pid 13659)
Script /etc/ppp/ip-up finished (pid 13659), status = 0x0
Terminating connection due to lack of activity.
Connect time 10.0 minutes.
Sent 0 bytes, received 0 bytes.
Script /etc/ppp/ip-down started (pid 22578)
sent [LCP TermReq id=0x2 “Link inactive”]
rcvd [LCP TermAck id=0x2]
Connection terminated.
Script /etc/ppp/ip-down finished (pid 22578), status = 0x0

Although KPPP doesn’t provide the same level of detail, I can see that it, too, has acquired a remote IP address. After the initial connection is made, the activity indicator simply flatlines. In both cases the system refuses to recognize and make use of the active broadband connection.

I have considered the possibility that x86_64 is unable to utilize the connection the way i686 does, but Google hasn’t turned up anything that would support such a guess. If that was the case, it seems likely that both pppd and KPPP would fail to connect in the first place. I think it’s more likely I have failed to do something simple and obvious to tell the system, “Hey, look over there! We have an active connection; let’s start surfing!” Any ideas?

SOLVED - The solution is stunningly simple: Disable NetworkManager.

Posts in the parent forum (which is where this should have gone, apparently) indicate that the issue has perplexed a number of users. As I understand it, the new NetworkManager widget is intended to permit easy switching between wired, wifi, and broadband connections. According to at least one author, an unresolved bug in NetworkManager prevents its use in managing broadband connections AND prevents alternate applications from fulfilling the role.

The solution is to open YaST - Network Devices - Network Settings - Global Options. Select “Traditional Method with ifup”. Thereafter the broadband wireless modem can be managed with KInternet, KPPD, or a simple command line script. I’m hoping they get the kinks worked out with NetworkManager, 'cause it looks like it would be pretty darn slick! Meanwhile I’m just glad to have my broadband connection working - finally.