Re: USR5637 USB modem setup (2)
- From: ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin)
- Date: Tue, 13 Jan 2009 21:11:13 -0600
On Wed, 14 Jan 2009, in the Usenet newsgroup comp.os.linux.networking, in
article <CFabl.669$xY.158@xxxxxxxxxxxxxxxxxxxxxxxxxx>, oldreader wrote:
Moe Trin wrote:
That's because wvdial is stupid, not the peer.
I'll re-evaluate this gem when I understand it better, though I am
getting a drift. I think maybe switching to stupid would not help,
The concept of logging in, then issuing a command to start ppp on the
remote is old, and actually went out of favor in the early 1990s. The
"standard" configuration today is to fire off the modem, and as soon
as the modems connect, start slinging ppp frames - that is the "some
garbled characters" you mentioned in your initial post. This mode is
sometimes called 'Autoppp' and this is the default mode that windoze
uses. Can you imagine microsoft explaining to a user that they have
to log in and supply a password when they try to connect? That's
way to complicated - just give 'em an icon (Dial Up Networking) to
click on, and they'll be happy. What that 'stupid' mode is talking
about is that some ISPs don't _disable_ the login prompt, and if you
search for it, you'll find it - and won't be able to do anything
because it's not configured on the server. Why should they, because
no windoze user knows to look for a login. It's only those weirdos
using non-microsoft O/S that run into a problem, and "who cares about
them?". The slightly less brain-dead tools supplied by the various
Linux distributions don't have this fixation with a login prompt, and
don't run into the 'stupid mode' problem.
per below on routing.
Below
Does the 'primary' and 'secondary' DNS server data make it into the
file where the kernel expects it - /etc/resolv.conf ?
Yes.
Good - not having those in that file breaks DNS for you.
This works for me this way:
$ /sbin/ifconfig ppp0 | grep inet
inet addr:63.131.35.181 P-t-P:64.179.23.98
Mask:255.255.255.255
Good
And this shows me this (bit more abstruse with the line wrap):
$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
64.179.23.98 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
That's OK (besides, I can fix the line-wrap) ;-)
This is Debian based Ubuntu 8.10, and does what you said. I notice
the absence of an entry for interface lo.
which I believe is also a Debian peculiarity - not a problem.
If /sbin/ifconfig and /sbin/route are showing the ``correct'' data, I
wouldn't worry about the modules.
The /sbin/ifconfig shows ``correct'' data for ppp0. The/sbin/route
output is suspicious to me due to the absence of the ``lo'' interface.
So think you I should worry about the modules to get the route right,
or just hack it?
The reason I say not to worry about the modules, is that the link is
up and running - the fact that you were able to negotiate IP addresses
and so on means that "whatever" is needed by the modem/kernel is there
and that's not the problem. You're almost certainly having (browser)
application problems, rather than networking or being able to talk to
the modem.
The /etc/resolv.conf seems OK.
Good. Comment: three nameserver entries max, and I don't like to see
a 'domain' or 'search' line, which _can_ be a security concern.
[compton ~]$ grep host /etc/nsswitch.conf hosts: files dns
[compton ~]$
No idea what this means, but it has everything your output does, and
more.
$ grep host /etc/nsswitch.conf hosts
/etc/nsswitch.conf:hosts: files mdns4_minimal [NOTFOUND=return]
dns mdns4
Oh, that %#@**&! Avahi program. There is a man page for this file, and
what this line is saying is "for hostname/IP lookups, look first in the
files (meaning /etc/hosts) - if it's not there, try using the Avahi
security hole (multicast DNS - an application that asks ``who wants to
claim to be host $FOO'' and accepts any answer as truth), and if Avahi
says someone claims that address doesn't exist, bail, otherwise check
using real DNS (ask the name servers) and if _that_ doesn't work, ask
Avahi to guess".
OK, obviously you've been able to find a command line, so after you
dial in, and the routing table looks as above, run the command
ping -nc2 152.46.7.80
and you should see something like
[compton ~]$ ping -nc2 152.46.7.80
PING 152.46.7.80 (152.46.7.80): 56 data bytes
64 bytes from 152.46.7.80: icmp_seq=0 ttl=48 time=252.8 ms
64 bytes from 152.46.7.80: icmp_seq=1 ttl=48 time=250.2 ms
--- 152.46.7.80 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 250.2/251.5/252.8 ms
[compton ~]$
That's a server in North Carolina. Did it work? If so, try the
command 'ping -c2 ibiblio.org' and you should see similar results,
with only the first line differing
PING ibiblio.org (152.46.7.80): 56 data bytes
Now, if this works, your setup is fine, and it's the browser that's
mis-configured. If this _doesn't_ work, you need to become root and
edit that line in /etc/nsswitch.conf. You would do that by making a
copy of the current file
cp /etc/nsswitch.conf /etc/nsswitch.conf.original
and then using your favorite text editor to change the line, to read
hosts: files dns
(deleting the Avahi references). I don't know that this will be needed
but I'm including the data just in case,
Some of the "let me help you - I know what I'm doing" browsers can
be a problem, as are similar applications like wvdial. More
details?
Details. Details. I have an idea (as much as they are appreciated)
that you just might be able to give me details until the cows come
home.
You've made a good start - the details needed would be "what
distribution and release (you told me that now), what browser (not my
strong point)" so people know where to start. There are something like
a thousand Linux distributions, and I don't want to think how many
different versions of those distros (most of which make a new release
every six months). The browsers - might only be twenty or thirty of
those ;-) The problem is that each distribution and browser knows
the One True Way To Do Things(tm) - and each one of them calls it
differently. But that's why we have a hundred different makes of cars
and beers and... you get the idea.
I get your clear message about "I know what I'm doing" browsers, but
there are seemingly few options to let me know what they are doing, or
not.
Don't feel bad - most of us have no idea what they are doing either ;-)
Already, I must issue the command ``# ln /dev/ttyACM0 /dev/modem''
each restart just to get wvdial to see this modem. It can go into a
file later as other issues resolve.
I think that's the udev filesystem Ubuntu is using. Yes, there is a
trick to this, but I'm not a Ubuntu user. I hesitate to send you to
the Usenet newsgroup 'alt.os.linux.ubuntu' as it has a poor signal to
noise ratio (I scan it, but I also killfile about 40% of the posts as
trolls/noise). That may be an option to consider however.
I can manually modify the routing table to include the `lo' interface,
if that is the hangup, and put that into a file as well.
That's not the problem. The 'lo' interface is the "loopback" and is
how the computer talks to itself (don't laugh - that's a normal mode
of operating things like X).
I wonder why the sleek slick assembled softwares are not doing this
all for me automagically.
Do you like my pretty ten foot pole that allows me not to touch that?
Yeah, some of the things are brain-dead, some others are traditions,
and still others are an appropriate version of magic. Some of this
is handled in the documentation and help functions. Ubuntu should be
working more or less out of the box, and it does have a fairly good
reputation for that.
The native network manager software on this systen is the GUI
NetworkManager Applet 0.7.0. I was never able to get this right with
earlier iterations, and went back to wvdial, which worked fine in
previous times. Perhaps I should spend another few hours with nm.
Let's see if the two ping tests run. If they do, I'm not sure that
the NetworkManager Applet is going to improve things.
I think I know that mine is not a normal routing table, can fix it
manually each time (I think but have not tried) and wonder why the
MES (Mysterious Electronic Softwares) didn't do this all for me
automagically.
It's not the routing table - that's merely a confusion factor. You
may now understand why I'm not thrilled with the GUI tools. This isn't
an indictment of Ubuntu/Debian/what-ever - it's something that has been
around for decades. The GUIs do what they have been configured to do
and don't bother you with details. That's fine when they work, or when
what you need to do is one of their functions. It gets to be a problem
with ANY such GUI when the unexpected or unplanned-for happens.
Your answer is appreciated. Thanks Old guy
You're welcome.
Old guy
.
- Follow-Ups:
- Re: USR5637 USB modem setup (2)
- From: Günther Schwarz
- Re: USR5637 USB modem setup (2)
- References:
- USR5637 USB modem setup (2)
- From: oldreader
- Re: USR5637 USB modem setup (2)
- From: Moe Trin
- Re: USR5637 USB modem setup (2)
- From: oldreader
- USR5637 USB modem setup (2)
- Prev by Date: Re: getting tcp packets larger than MTU, how is that possible??
- Next by Date: Re: Cannot ping other servers
- Previous by thread: Re: USR5637 USB modem setup (2)
- Next by thread: Re: USR5637 USB modem setup (2)
- Index(es):