Re: Regression regarding 0af0:7211 from NM-0.7.0 to NM-0.7.1-rc1
- From: Dan Williams <dcbw redhat com>
- To: Kenneth Mokkelbost <kmokk yahoo no>
- Cc: networkmanager-list gnome org
- Subject: Re: Regression regarding 0af0:7211 from NM-0.7.0 to NM-0.7.1-rc1
- Date: Thu, 26 Feb 2009 12:56:44 -0500
On Thu, 2009-02-26 at 17:54 +0000, Kenneth Mokkelbost wrote:
>
> > From: Dan Williams
> > On Wed, 2009-02-25 at 22:37 +0000, Kenneth Mokkelbost wrote:
> ...
> > >
> > > 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
>
> A username and a password made the difference. Thanks.
>
> But what puzzles me a bit now is that 0.7.0 worked with the fdi pointing to HS2
> while 0.7.1rc1 needed HS0. Since I was the one who supplied the entry in the
> fdi in the first place, I would like to get this right and not make a mess out of it. :)
It's always actually been the first USB tty that is required; otherwise
you'll never get a connection response. It could be that HAL's
properties changed somewhat, and depending on what key was used in
10-modem.fdi to pick the right port (serial.port or usb.interface) you
may have ended up with the right one selected by chance. That's the
problem with 10-modem.fdi; the ports are not guaranteed to be the same
all the time. Thus probing the ports explicitly in combination with
driver hints for the "control" port (or whatever port does emit
unsolicited replies which is what we require) do the trick.
Dan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]