Re: Regression regarding 0af0:7211 from NM-0.7.0 to NM-0.7.1-rc1

[Dan Williams <dcbw redhat com>]

On Wed, 2009-02-25 at 22:37 +0000, Kenneth Mokkelbost wrote:
> > From: Dan Williams
> 
> > 
> > On Sun, 2009-02-22 at 18:46 +0000, Kenneth Mokkelbost wrote:
> > > > From: Dan Williams 
> > > > 
> > > > On Sun, 2009-02-22 at 15:07 +0000, Kenneth Mokkelbost wrote: 
> > > > > Hi,
> > > > > 
> > > > > The in-built Option 3G card in Acer Aspire One is not working in 
> > NM-0.7.1rc1. 
> > > > In NM-0.7..0 i did. The card uses the hso driver.
> > > > > 
> > > > > I've tested this with both the NM-build in the latest daily Ubuntu 
> > live-cd, 
> > > > and with a locally compiled 0.7.1-rc1 with the same result.
> > > > > 
> > > > > I've attached some logs I think is relevant from both the latest live-cd 
> > > > (containing  0.7.1-rc1) and the latest live-cd that contained 0.7.0. lsusb 
> > and 
> > > > lshal is identical between versions with regards to the device.
> > > > 
> > > > The logs indicate that NM found the Option card.  But there are a few
> > > > issues here:
> > > > 
> > > > 1) It's being detected from HAL capabilities, not the built-in prober,
> > > > which is what I'd expect.  What's the output of:
> > > > 
> > > > udevinfo --query=env --path=/sys/class/tty/ttyHS0
> > > > udevinfo --query=env --path=/sys/class/tty/ttyHS1
> > > > udevinfo --query=env --path=/sys/class/tty/ttyHS2
> > > > udevinfo --query=env --path=/sys/class/tty/ttyHS3
> > > > 
> > > See attached files
> > > 
> > > > 2) Looks like it's using the wrong serial port, which is a problem in
> > > > the HAL .fdi configuration, but shouldn't be a problem with 0.7.1rc1.
> > > > Can you supply the output of the following commands?
> > > > 
> > > > cat /sys/class/tty/ttyHS0/hsotype
> > > > cat /sys/class/tty/ttyHS1/hsotype
> > > > cat /sys/class/tty/ttyHS2/hsotype
> > > > cat /sys/class/tty/ttyHS3/hsotype
> > > > 
> > > HS0: Control
> > 
> > So this is the problem; HAL is reporting that HS3 is the correct one to
> > use, but that's clearly not correct.  It should always be the "Control"
> > one.
> > 
> > > HS1: Application
> > > HS2: Diagnostic
> > > HS3: Modem
> > > 
> > > 
> > > > 3) What version of udev is the latest livecd running?
> > > > 
> > > Version 138
> > > 
> > > > 4) Which of these do you have?
> > > > 
> > > > /etc/udev/rules.d/77-nm-probe-modem-capabilities.rules
> > > > /lib/udev/rules.d/77-nm-probe-modem-capabilities.rules
> > > > 
> > > None of them, actually
> > 
> > Ok, that's an Ubuntu packaging bug that you should get the Ubuntu
> > developers to fix.  That's what actually makes the autodetection logic
> > work :)
> > 
> > It occurs to me that they may not have pulled a recent enough snapshot;
> > the code that's best is from Thursday or Friday this past week.  Not
> > sure when Alexander Sack built the Ubuntu test packages.
> > 
> > Dan
> > 
> > > > and what do they contain?
> > > > 
> > > > 5) Also, is the problem that the modem doesn't *show up*, or that it
> > > > cannot actually connect?  The logs you provided for NM 0.7.1rc1 don't
> > > > show a connection attempt, while the logs from 0..7.0 do.  Next, the
> > > > 0.7.0 logs show the is being used, which is exceptionally odd for 'hso'
> > > > devices, because the driver is written specifically to avoid PPP but
> > > > instead use a network device for better throughput..  So NM in 0.7.0
> > > > shouldn't even be using PPP at all.
> > > > 
> > > > Let me know!
> > > > Dan
> > > 
> > > Yes, the problem is that it doesn't show up. If I change the fdi to
> > >    
> > > it shows up, but can't connect. With 0.7.0 I can connect if the fdi is
> > >    
> > > which is what I wanted :)
> > > 
> > > Kenneth
> 
> Ok, so I've installed udev-extras and changed the fdi to HS0, but still no luck getting
> the connection to succeed.
> 
> I've attached the new debug log, and as you can see the AT$QCPDPP=1,1,"","" command fails.
> Might that be the culprit?

Could be, try adding at least a username to the GSM connection?  Most
providers dont' actually care what that username is.

Dan