From: Vahis on
EeePC 900, openSUSE 11.2
I had a working setup where wired and wireless nics were controlled by
KnetworkManager and Huawei USB stick was used via wvdial.

Everything was _so_ well.

Zypper up updated the networkmanager and now wvdial does not work at
all.

Everything starts fine, authentication is success and then:
The ppp daemon has died. A modem hung up the phone (exit code = 16)

This is just what I didn't need: Updates that break a working system.

Vahis
--
"Sunrise 9:03am (EET), sunset 3:16pm (EET) at Espoo, Finland (6:12 hours daylight)"
http://waxborg.servepics.com
Linux 2.6.25.20-0.5-default #1 SMP 2009-08-14 01:48:11 +0200 x86_64
6:45pm up 33 days 23:46, 9 users, load average: 0.32, 0.41, 0.36
From: Moe Trin on
On Thu, 03 Dec 2009, in the Usenet newsgroup alt.os.linux.suse, in article
<20091203184451(a)usenet.waxborg.local>, Vahis wrote:

>Zypper up updated the networkmanager and now wvdial does not work at
>all.
>
>Everything starts fine, authentication is success and then:
>The ppp daemon has died. A modem hung up the phone (exit code = 16)

Normally, I'd be complaining about wvdial as a program written by
idiots, but the lack of information here is from pppd. If you read
the man page for pppd and look at the 'EXIT STATUS' section, the
exit codes are not very informative. This is mainly due to the fact
that the ppp protocol itself doesn't include much in the way of
failure messages, and the daemon has to guess. What _does_ help is
looking at the rest of the codes. Codes 1 to 9 were not the reason,
and that means you were able to dial OK. Codes 11, 14, 17-19 were not
the reason, and that means authentication succeeded. Code 10, 12, 13
or 15 did not occur, which rules out just about everything else. The
fact that 10 did not occur suggests that the link came up with some
network configuration (IP? IPv6? IPX? AppleTalk?), AND THEN the peer
broke it down. So what I'd question is "what network protocol came
up" and "were the parameters (IP address for example) reasonable".
One means of doing this would be to temporarily add two lines to the
/etc/ppp/*up files (/etc/ppp/ip-up, /etc/ppp/ipv6-up, /etc/ppp/ipx-up)

/bin/date >> /tmp/some.file.name
echo $* >> /tmp/some.file.name

and see what parameters and protocol were negotiated. FOR EXAMPLE,
you may have demanded to use an IP address that the peer doesn't
want, and ignored hints to try another. The peer finally says OK
(bringing up the link thus satisfying EXIT CODE 10), and immediately
dropping the link (RFC1661 says you can't _terminate_ a link until
the negotiations have succeeded).

>This is just what I didn't need: Updates that break a working system.

Yup.

Old guy
From: Vahis on
On 2009-12-04, Moe Trin <ibuprofin(a)painkiller.example.tld> wrote:
> On Thu, 03 Dec 2009, in the Usenet newsgroup alt.os.linux.suse, in article
><20091203184451(a)usenet.waxborg.local>, Vahis wrote:
>
>>Zypper up updated the networkmanager and now wvdial does not work at
>>all.
>>
>>Everything starts fine, authentication is success and then:
>>The ppp daemon has died. A modem hung up the phone (exit code = 16)

<snipped and saved grat information about ppp>

You've got great knowledge, thanks on my own as well as probably many
others' behalf :)

I was able to fix the problem a bit later without really knowing which
particular change broke and then fixed it.

There's networkmanager which wants to generate /etc/resolv/conf
dynamically. This one works fine for eth0 and wireless

There's wvdial which seems to need nameservers in /etc/resolv/conf

There's "/etc/resolv/conf has been modified, leaving it untouched" stuff
There's "my version can be found here" stuff.

I kept adding and removing nameservers back and forth before I got it
working the first time, so It was obviously a dirty way of doing it.

After the patch to networkmanager this failure occurred.
Then I got it back and it's fine again :)
>
>>This is just what I didn't need: Updates that break a working system.
>
> Yup.
>
Probably it hadn't if it had been a 100 per cent working one. Or at
least then it shouldn't have.

But it worked and I was cool...

I installed umtsmon afterwards and that one seems to work quite
nicely...

Thanks again, your reply is saved for potential future occurrences :)

Vahis
--
"Sunrise 9:07am (EET), sunset 3:14pm (EET) at Espoo, Finland (6:07 hours daylight)"
http://waxborg.servepics.com
Linux 2.6.25.20-0.5-default #1 SMP 2009-08-14 01:48:11 +0200 x86_64
8:09am up 35 days 13:10, 10 users, load average: 0.15, 0.20, 0.25
From: Moe Trin on
On Sat, 05 Dec 2009, in the Usenet newsgroup alt.os.linux.suse, in article
<slrnhhjvqj.3cq.waxborg(a)a88-114-155-254.elisa-laajakaista.fi>, Vahis wrote:

><snipped and saved grat information about ppp>

>You've got great knowledge, thanks on my own as well as probably many
>others' behalf :)

Glad to help. The ppp protocol is relatively confusing, and the
language used is strange and mis-leading. Once you realize what it
is trying to do, the concepts are fairly simple.

>There's networkmanager which wants to generate /etc/resolv/conf
>dynamically. This one works fine for eth0 and wireless

Except it drives me nuts because I don't use DHCP, and the helper
program wants to do things the way it was programmed. I wound up
using '/usr/bin/chattr +i /etc/resolv.conf' to prevent the helper
from overwriting my static setup.

>There's wvdial which seems to need nameservers in /etc/resolv/conf

Hmmm... I don't use that piece of dehydrated donkey droppings (it was
written for the way ppp _was_ used 15+ years ago, and the authors have
not discovered things changed in 1995), but think /etc/wvdial.conf
should have "Auto DNS" set to "on".

>There's "/etc/resolv/conf has been modified, leaving it untouched"
>stuff There's "my version can be found here" stuff.

I really hate these "you're to st00pid to be doing this, let me fix
things for you" helper tools that insist on overwriting all of my
configurations, and yet are tightly integrated into the system
which makes them hard to rip out by the roots.

Old guy
 | 
Pages: 1
Prev: Boot
Next: Anyone but me using these apps?