USR5637 USB modem setup (2)

Hello, I am abandoning the (un-successful) search for the software driver
for the internal (software) hsfmodem on my Dell 1420 notebook (shame Dell
and Linuxant), have purchased and received a new USR5637 USB connected
processor modem and made some progress on using this dial-up modem.
Wvdial does now recognize the modem after linking /dev/modem to the
target /dev/ttyACM0.

# ln -T /dev/ttyACM0 /dev/modem

The USR5637 modem does now indeed connect, evidence login negotiation for
username and password and return of PPP session #, IP address, MTU.
Additional return from wvdial includes primary and secondary DNS
addresses, and some garbled characters, and does appear to exit
gracefully after ^c. ifconfig does indicate an active interface at ppp0
at the same IP address that the wvdial reports. The connection does not
work to retrieve web pages with Firefox. More primative command line
connection tests have not yet been attempted.

I found a page here which is unfortunately too arcane for me to get much
value from.

http://www.mjmwired.net/kernel/Docum...on/usb/acm.txt

The immediate obstacle I find is here:
++++++++++++++
To use the modems you need these modules loaded:
57
58 usbcore.ko
59 uhci-hcd.ko ohci-hcd.ko or ehci-hcd.ko
60 cdc-acm.ko
61
62 After that, the modem[s] should be accessible. You should be
able to use
63 minicom, ppp and mgetty with them.
++++++++++++++
I have not found these modules loaded using `lsmod | grep [appropriate]',
and I am not yet knowledgeable enough to correct these deficiencies.
Would could some knowledgeable helper clarify for me what I actually need
to do to get the appropriate modules loaded, please?

There might or may be other issues, but these are the ones I suspect
right now. Help appreciated with thanks.

On Mon, 12 Jan 2009 14:10:34 -0600, Moe Trin wrote:

> On Mon, 12 Jan 2009, in the Usenet newsgroup comp.os.linux.networking,
> in article <J1Aal.656$(E-Mail Removed)>, oldreader
> wrote:
>
>>The USR5637 modem does now indeed connect, evidence login negotiation
>>for username and password and return of PPP session #, IP address, MTU.
>
> Stupid Mode
> When wvdial is in Stupid Mode, it does not attempt to
> interpret any prompts from the terminal server. It starts
> pppd immediately after the modem connects. Apparently
> there are ISP's that actually give you a login prompt, but
> work only if you start PPP, rather than logging in. Go
> figure. Stupid Mode is (naturally) disabled by default.
>
> 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, per
below on routing.
>
>>Additional return from wvdial includes primary and secondary DNS
>>addresses, and some garbled characters, and does appear to exit
>>gracefully after ^c. ifconfig does indicate an active interface at ppp0
>>at the same IP address that the wvdial reports. The connection does not
>>work to retrieve web pages with Firefox. More primative command line
>>connection tests have not yet been attempted.
>
> Does the 'primary' and 'secondary' DNS server data make it into the file
> where the kernel expects it - /etc/resolv.conf ?

Yes.
>
> You say '/sbin/ifconfig' shows a ppp0 interface with appropriate IP
> addresses, Does '/sbin/route -n' show a route to the world using this
> interface?
>
> [compton ~]$ /sbin/ifconfig ppp0 | grep inet
> inet addr:198.18.180.190 P-t-P:192.168.195.11 Mask:255.0.0.0

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

> [compton ~]$ /sbin/route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use
> Iface 192.168.195.11 0.0.0.0 255.255.255.255 UH 0 0
> 1 ppp0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0
> 4198 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0
> 20 lo 0.0.0.0 192.168.195.11 0.0.0.0 UG 0 0
> 5 ppp0 [compton ~]$

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

>
> Notice two lines mentioning ppp0 - one being a 'host route' to the peer
> at the other end of the phone line. The other is the default route to
> the world - using the peer as a gateway. Note that Debian based systems
> may show the last line as
>
> 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 5
> ppp0
>
> because they "know" more than the authors of the ppp application, and
> "improved" it. None the less, either form should work.

This is Debian based Ubuntu 8.10, and does what you said. I notice the
absence of an entry for interface lo.
>
>>The immediate obstacle I find is here: ++++++++++++++
>>To use the modems you need these modules loaded:
>
> [...]
>
>>I have not found these modules loaded using `lsmod | grep
>>[appropriate]', and I am not yet knowledgeable enough to correct these
>>deficiencies. Would could some knowledgeable helper clarify for me what
>>I actually need to do to get the appropriate modules loaded, please?
>
> If /sbin/ifconfig and /sbin/route are showing the ``correct'' data, I
> wouldn't worry about the modules. Check also the contents of the
> /etc/resolv.conf file

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?
>
> [compton ~]$ cat /etc/resolv.conf
> nameserver 192.0.2.154
> nameserver 192.18.14.44
> [compton ~]$

The /etc/resolv.conf seems OK.
>
> (though obviously the IP addresses will be different), and as a long
> shot, the configuration of /etc/nsswitch.conf:
>
> [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
>
>>There might or may be other issues, but these are the ones I suspect
>>right now.
>
> 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. 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.
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 can manually modify the routing table
to include the `lo' interface, if that is the hangup, and put that into a
file as well. I wonder why the sleek slick assembled softwares are not
doing this all for me automagically. I just need to get this modem
running so I can get and send email when I get to east-endover-center,
where there is a telephone, I think.

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.

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.

Probably, on my own, my next step would be to try to assemble by trial
and error a routing table that works.
>
> Old guy

Your answer is appreciated. Thanks Old guy

On Mon, 12 Jan 2009 14:10:34 -0600, Moe Trin wrote:

> On Mon, 12 Jan 2009, in the Usenet newsgroup comp.os.linux.networking,
> in article <J1Aal.656$(E-Mail Removed)>, oldreader
> wrote:
>
>>The USR5637 modem does now indeed connect, evidence login negotiation
>>for username and password and return of PPP session #, IP address, MTU.
>
> Stupid Mode
> When wvdial is in Stupid Mode, it does not attempt to
> interpret any prompts from the terminal server. It starts
> pppd immediately after the modem connects. Apparently
> there are ISP's that actually give you a login prompt, but
> work only if you start PPP, rather than logging in. Go
> figure. Stupid Mode is (naturally) disabled by default.
>
> 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, per
below on routing.
>
>>Additional return from wvdial includes primary and secondary DNS
>>addresses, and some garbled characters, and does appear to exit
>>gracefully after ^c. ifconfig does indicate an active interface at ppp0
>>at the same IP address that the wvdial reports. The connection does not
>>work to retrieve web pages with Firefox. More primative command line
>>connection tests have not yet been attempted.
>
> Does the 'primary' and 'secondary' DNS server data make it into the file
> where the kernel expects it - /etc/resolv.conf ?

Yes.
>
> You say '/sbin/ifconfig' shows a ppp0 interface with appropriate IP
> addresses, Does '/sbin/route -n' show a route to the world using this
> interface?
>
> [compton ~]$ /sbin/ifconfig ppp0 | grep inet
> inet addr:198.18.180.190 P-t-P:192.168.195.11 Mask:255.0.0.0

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

> [compton ~]$ /sbin/route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use
> Iface 192.168.195.11 0.0.0.0 255.255.255.255 UH 0 0
> 1 ppp0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0
> 4198 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0
> 20 lo 0.0.0.0 192.168.195.11 0.0.0.0 UG 0 0
> 5 ppp0 [compton ~]$

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

>
> Notice two lines mentioning ppp0 - one being a 'host route' to the peer
> at the other end of the phone line. The other is the default route to
> the world - using the peer as a gateway. Note that Debian based systems
> may show the last line as
>
> 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 5
> ppp0
>
> because they "know" more than the authors of the ppp application, and
> "improved" it. None the less, either form should work.

This is Debian based Ubuntu 8.10, and does what you said. I notice the
absence of an entry for interface lo.
>
>>The immediate obstacle I find is here: ++++++++++++++
>>To use the modems you need these modules loaded:
>
> [...]
>
>>I have not found these modules loaded using `lsmod | grep
>>[appropriate]', and I am not yet knowledgeable enough to correct these
>>deficiencies. Would could some knowledgeable helper clarify for me what
>>I actually need to do to get the appropriate modules loaded, please?
>
> If /sbin/ifconfig and /sbin/route are showing the ``correct'' data, I
> wouldn't worry about the modules. Check also the contents of the
> /etc/resolv.conf file

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?
>
> [compton ~]$ cat /etc/resolv.conf
> nameserver 192.0.2.154
> nameserver 192.18.14.44
> [compton ~]$

The /etc/resolv.conf seems OK.
>
> (though obviously the IP addresses will be different), and as a long
> shot, the configuration of /etc/nsswitch.conf:
>
> [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
>
>>There might or may be other issues, but these are the ones I suspect
>>right now.
>
> 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. 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.
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 can manually modify the routing table
to include the `lo' interface, if that is the hangup, and put that into a
file as well. I wonder why the sleek slick assembled softwares are not
doing this all for me automagically. I just need to get this modem
running so I can get and send email when I get to east-endover-center,
where there is a telephone, I think.

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.

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.

Probably, on my own, my next step would be to try to assemble by trial
and error a routing table that works.
>
> Old guy

Your answer is appreciated. Thanks Old guy

Moe Trin wrote:

> 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

At this point of the interesting step-by-step instruction I would just
try a restart of Firefox and, if in use, any proxy like privoxy. At
least this is what I have to do when switching between ethernet and
ppp.

Günther

On Wed, 14 Jan 2009 19:26:46 -0600, Moe Trin wrote:

> On Tue, 13 Jan 2009, in the Usenet newsgroup comp.os.linux.networking,
> in article <(E-Mail Removed)>, Clifford Kite wrote:
>
> Hi Clifford! Hope the New Year is treating you well.
>
>>> /etc/nsswitch.conf:hosts: files mdns4_minimal [NOTFOUND=return]
>>> dns mdns4
>>
>>I'm guessing here but I think "mdns4_minimal [NOTFOUND=return]" means
>>abort the "hosts:" line search if mdns4_minimal isn't found.
>
> man 5 nsswitch.conf 'mdns4_minimal' (and the later 'mdns4') is the
> Avahi implementation of the Apple multicast DNS service. Briefly, you
> send a packet to 224.0.0.251 port 5353 asking if anyone wants to claim
> the hostname (or IP) you want to look up. If anyone answers, you
> believe them, and hope that they aren't spoofing. (There is a microsoft
> equivalent described by RFC4795 - and is incompatible because it uses
> 224.0.0.252 and port 5355.) Both services are trivial to exploit as
> neither have any actual security (Apple suggested only using it to look
> up *.local, while microsoft suggested using it only for "single-label
> names" which is win-babble for names without a 'dot'). Neither actually
> implemented these limitations possibly because they knew lusers would
> not follow these limits even if they were aware of them. Apple also
> warned about including a 'search .local' (and implied 'domain .local')
> option in the resolver configuration (/etc/resolv.conf) because of
> "unintended local resolution" of apparently global names
> (www.your_bank.com.local), but the Avahi and distribution documentation
> ignores this. The Apple proposal (draft-cheshire-dnsext-multicastdns)
> has long expired, but it was supposed to act something like a regular
> DNS daemon, and return 'RCODE' (see page 27 of RFC1035), but "only
> positive results". The '[NOTFOUND=return]' is a Debian fix for some
> other perceived problem.
>
>>Commenting out the Debian "hosts:" line in nsswitch.conf and temporarily
>>substituting Moe's
>>
>>hosts: files dns
>>
>>might be worth trying.
>
> Agreed, especially as the O/P's setup doesn't appear to have a local
> network of any kind. I'd suggest removing Avahi entirely, but there is
> some "feature" on the ubuntu-desktop-package that depends on this
> mis-service.
>
> Old guy

Thank you. It all (?) works now. The nsswitch.conf has been updated on
disk and should persist through restarts. The link to the modem device
is easy to do. The FF browser does work fine (for dialup) after a couple
of restarts. pinging does seem to work OK now, though no need with the
www browser working OK.

wvdial does still show some unrecognizable characters, but I will try
using minicom instead before anything else with wvdial.

Thank you. East-endover-center, here I come !!