UMTS

Let me concentrate on the problem on hands (that's why I'm talking about
UMTS modem (Novatel Wireless Ovation MC990D, to the point)). My
understanding is:

* Whatever happens between USB cable and keyboard (inclusive) is my
problem;
* Whatever happens between USB plug and antenna (inclusive) is vendors
problem (Novatels' in this case);
* Whatever happens after radio link (inclusive) is ISP's problem.

Any comments?

If me's not that wrong than I would like to spit yet another
speculation. I observe that my (and I suppose any other) UMTS modem
heats hardly when working. That brings me to conclusion that the modem
is, in fact, a so called 'embeded' with topical OS on board (and since
Torvalds is that fscking asshole I have no way to access source
(whatever I could achieve with this)). Then, I think that peers 'pppd'
I'm talking to from my router is in fact on the modem (in contrary with
ole' cable ISP's).

Any comments?

Now to least problem (it's solved brutally (gone for roots)):

Mar 12 10:56:55 agentsmith pppd[5974]: Starting link
Mar 12 10:56:59 agentsmith pppd[5974]: Serial connection established.
Mar 12 10:56:59 agentsmith pppd[5974]: using channel 1284
Mar 12 10:56:59 agentsmith pppd[5974]: Connect: ppp0 <--> /dev/MC990D
Mar 12 10:57:00 agentsmith pppd[5974]: sent [LCP ConfReq id=0xcc <asyncmap 0x0> <magic 0x8d94ceb9> <pcomp> <accomp>]
Mar 12 10:57:00 agentsmith pppd[5974]: rcvd [LCP ConfReq id=0x1e <asyncmap 0x0> <auth chap MD5> <magic 0x7b690ee> <pcomp> <accomp>]
Mar 12 10:57:00 agentsmith pppd[5974]: No auth is possible
Mar 12 10:57:00 agentsmith pppd[5974]: sent [LCP ConfRej id=0x1e <auth chap MD5>]
Mar 12 10:57:00 agentsmith pppd[5974]: rcvd [LCP ConfAck id=0xcc <asyncmap 0x0> <magic 0x8d94ceb9> <pcomp> <accomp>]
Mar 12 10:57:00 agentsmith pppd[5974]: rcvd [LCP ConfReq id=0x1f <asyncmap 0x0> <magic 0x7b690ee> <pcomp> <accomp>]
Mar 12 10:57:00 agentsmith pppd[5974]: sent [LCP ConfAck id=0x1f <asyncmap 0x0> <magic 0x7b690ee> <pcomp> <accomp>]
Mar 12 10:57:00 agentsmith pppd[5974]: sent [LCP EchoReq id=0x0 magic=0x8d94ceb9]
Mar 12 10:57:00 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xa3 <compress VJ 0f 01> <addr 178.92.14.159> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Mar 12 10:57:00 agentsmith pppd[5974]: rcvd [LCP DiscReq id=0x20 magic=0x7b690ee]
Mar 12 10:57:00 agentsmith pppd[5974]: rcvd [LCP EchoRep id=0x0 magic=0x7b690ee 8d 94 ce b9]
Mar 12 10:57:01 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xa3 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:01 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xa4 <compress VJ 0f 01> <addr 178.92.14.159> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mar 12 10:57:02 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xa4 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:02 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xa5 <compress VJ 0f 01> <addr 178.92.14.159> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mar 12 10:57:03 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xa5 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:03 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xa6 <compress VJ 0f 01> <addr 178.92.14.159> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mar 12 10:57:04 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xa6 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:04 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xa7 <compress VJ 0f 01> <addr 178.92.14.159> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mar 12 10:57:05 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xa7 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:05 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xa8 <compress VJ 0f 01> <addr 178.92.14.159>]
Mar 12 10:57:06 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xa8 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:06 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xa9 <compress VJ 0f 01> <addr 178.92.14.159>]
Mar 12 10:57:07 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xa9 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:07 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xaa <compress VJ 0f 01> <addr 178.92.14.159>]
Mar 12 10:57:08 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xaa <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:08 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xab <compress VJ 0f 01> <addr 178.92.14.159>]
Mar 12 10:57:09 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xab <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:09 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xac <compress VJ 0f 01> <addr 178.92.14.159>]
Mar 12 10:57:10 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xac <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:10 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xad <compress VJ 0f 01> <addr 178.92.14.159>]
Mar 12 10:57:11 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xad <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:11 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xae <compress VJ 0f 01> <addr 178.92.14.159>]
Mar 12 10:57:12 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xae <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:12 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xaf <compress VJ 0f 01> <addr 178.92.14.159>]
Mar 12 10:57:13 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xaf <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:13 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xb0 <compress VJ 0f 01> <addr 178.92.14.159>]
Mar 12 10:57:14 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xb0 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:14 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xb1 <compress VJ 0f 01> <addr 178.92.14.159>]
Mar 12 10:57:15 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xb1 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:15 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xb2 <compress VJ 0f 01> <addr 178.92.14.159>]
Mar 12 10:57:16 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xb2 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 12 10:57:16 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xb3 <compress VJ 0f 01> <addr 178.92.14.159>]
Mar 12 10:57:16 agentsmith pppd[5974]: rcvd [IPCP ConfReq id=0x17]
Mar 12 10:57:16 agentsmith pppd[5974]: sent [IPCP ConfNak id=0x17 <addr 10.112.112.112>]
Mar 12 10:57:16 agentsmith pppd[5974]: rcvd [IPCP ConfRej id=0xb3 <compress VJ 0f 01>]
Mar 12 10:57:16 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xb4 <addr 178.92.14.159>]
Mar 12 10:57:16 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xb4 <addr 178.92.53.84>]
Mar 12 10:57:16 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xb5 <addr 178.92.53.84>]
Mar 12 10:57:16 agentsmith pppd[5974]: rcvd [IPCP ConfAck id=0xb5 <addr 178.92.53.84>]
Mar 12 10:57:17 agentsmith pppd[5974]: rcvd [IPCP ConfReq id=0x18]
Mar 12 10:57:17 agentsmith pppd[5974]: sent [IPCP ConfAck id=0x18]
Mar 12 10:57:17 agentsmith pppd[5974]: Local IP address changed to 178.92.53.84
Mar 12 10:57:18 agentsmith pppd[5974]: Open TCP 178.92.53.84:59638 -> 171.64.65.111:8080
Mar 12 10:57:18 agentsmith pppd[5974]: sent [IP data] 45 00 00 3c ba bd 40 00 ...
Mar 12 10:57:18 agentsmith pppd[5974]: Script /etc/ppp/ip-up started (pid 3941)
Mar 12 10:57:19 agentsmith pppd[5974]: Script /etc/ppp/ip-up finished (pid 3941), status = 0x0

As you can see, 'pppd' at my side finishes with no DNS assigned at all
(in fact, it logs those vulgar 10.11.12.13 and 10.11.12.14 what don't
have DNS running, obviously).

Now I would like to see community's opinion on -- is a problem (if there
is any) on modem part (blame vendor) or ISP side (blame operator)?

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

with <(E-Mail Removed)> Moe Trin wrote:
> On Sat, 13 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in
> article <(E-Mail Removed)>, Eric Pozharski wrote:
>
>>Then, I think that peers 'pppd' I'm talking to from my router is in
>>fact on the modem (in contrary with ole' cable ISP's).
>
> It's not really different from cable or dial-in - the other end of the
> link is a terminal server at the ISP. Try doing a traceroute

Have you meant the one that has no IP (remote IP)?

*SKIP*
> Oh, but you don't have /etc/ppp/chap-secrets set up with the username
> and password needed. That probably kills everything from here on.

Sad but true -- I have no authentication tokens to put there. And none
have. I"ve investigated linux connectivity issues with my probably next
ISP before buying modem. I has found out that none instruction (for any
modem) has any meaning of any '*-secrets' (for my present ISP). TBH,
I'm not that motivated to call ISP's support. Because I know what
solution they have for me. Although may be, if I would be in good
enough mood, I could make that call -- for lulz.

To your point -- that doesn't kill anything.

whynot@carpet:~$ ( zcat /var/log/syslog.[1-6].gz ; cat /var/log/syslog /var/log/syslog.0 ) | grep 'ConfAck .\+ <addr [0-9.]\+>\]' | wc
39 429 3429
whynot@carpet:~$ ( zcat /var/log/syslog.[1-6].gz ; cat /var/log/syslog /var/log/syslog.0 ) | grep 'ConfAck .\+ <addr [0-9.]\+> <ms-dns' | wc
35 525 4833

That's possible, I might have to show the other (surprise, surprise -- I
believed that (the other) is usual; me's wrong again) scenario:

Mar 14 06:46:55 agentsmith pppd[5974]: Starting link
Mar 14 06:46:59 agentsmith pppd[5974]: Serial connection established.
Mar 14 06:46:59 agentsmith pppd[5974]: using channel 1298
Mar 14 06:46:59 agentsmith pppd[5974]: Connect: ppp0 <--> /dev/MC990D
Mar 14 06:47:00 agentsmith /USR/SBIN/CRON[14348]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ))
Mar 14 06:47:00 agentsmith pppd[5974]: sent [LCP ConfReq id=0xe8 <asyncmap 0x0> <magic 0x46b50d01> <pcomp> <accomp>]
Mar 14 06:47:00 agentsmith pppd[5974]: rcvd [LCP ConfReq id=0x48 <asyncmap 0x0> <auth chap MD5> <magic 0x111e6a80> <pcomp> <accomp>]
Mar 14 06:47:00 agentsmith pppd[5974]: No auth is possible
Mar 14 06:47:00 agentsmith pppd[5974]: sent [LCP ConfRej id=0x48 <auth chap MD5>]
Mar 14 06:47:00 agentsmith pppd[5974]: rcvd [LCP ConfAck id=0xe8 <asyncmap 0x0> <magic 0x46b50d01> <pcomp> <accomp>]
Mar 14 06:47:00 agentsmith pppd[5974]: rcvd [LCP ConfReq id=0x49 <asyncmap 0x0> <magic 0x111e6a80> <pcomp> <accomp>]
Mar 14 06:47:00 agentsmith pppd[5974]: sent [LCP ConfAck id=0x49 <asyncmap 0x0> <magic 0x111e6a80> <pcomp> <accomp>]
Mar 14 06:47:00 agentsmith pppd[5974]: sent [LCP EchoReq id=0x0 magic=0x46b50d01]
Mar 14 06:47:00 agentsmith pppd[5974]: sent [IPCP ConfReq id=0x35 <compress VJ 0f 01> <addr 178.92.142.91> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Mar 14 06:47:00 agentsmith pppd[5974]: rcvd [LCP DiscReq id=0x4a magic=0x111e6a80]
Mar 14 06:47:00 agentsmith pppd[5974]: rcvd [LCP EchoRep id=0x0 magic=0x111e6a80 46 b5 0d 01]
Mar 14 06:47:01 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0x35 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 14 06:47:01 agentsmith pppd[5974]: sent [IPCP ConfReq id=0x36 <compress VJ 0f 01> <addr 178.92.142.91> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mar 14 06:47:02 carpet /USR/SBIN/CRON[511]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ))
Mar 14 06:47:02 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0x36 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 14 06:47:02 agentsmith pppd[5974]: sent [IPCP ConfReq id=0x37 <compress VJ 0f 01> <addr 178.92.142.91> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mar 14 06:47:03 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0x37 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 14 06:47:03 agentsmith pppd[5974]: sent [IPCP ConfReq id=0x38 <compress VJ 0f 01> <addr 178.92.142.91> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mar 14 06:47:04 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0x38 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Mar 14 06:47:04 agentsmith pppd[5974]: sent [IPCP ConfReq id=0x39 <compress VJ 0f 01> <addr 178.92.142.91> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mar 14 06:47:05 agentsmith pppd[5974]: rcvd [IPCP ConfReq id=0x33]
Mar 14 06:47:05 agentsmith pppd[5974]: sent [IPCP ConfNak id=0x33 <addr 10.112.112.112>]
Mar 14 06:47:05 agentsmith pppd[5974]: rcvd [IPCP ConfRej id=0x39 <compress VJ 0f 01>]
Mar 14 06:47:05 agentsmith pppd[5974]: sent [IPCP ConfReq id=0x3a <addr 178.92.142.91> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Mar 14 06:47:05 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0x3a <addr 178.92.139.62> <ms-dns1 213.179.249.133> <ms-dns3 212.113.36.14>]
Mar 14 06:47:05 agentsmith pppd[5974]: sent [IPCP ConfReq id=0x3b <addr 178.92.139.62> <ms-dns1 213.179.249.133> <ms-dns3 212.113.36.14>]
Mar 14 06:47:05 agentsmith pppd[5974]: rcvd [IPCP ConfAck id=0x3b <addr 178.92.139.62> <ms-dns1 213.179.249.133> <ms-dns3 212.113.36.14>]
Mar 14 06:47:06 carpet syslogd 1.5.0#5: restart (remote reception).
Mar 14 06:47:06 agentsmith pppd[5974]: rcvd [IPCP ConfReq id=0x34]
Mar 14 06:47:06 agentsmith pppd[5974]: sent [IPCP ConfAck id=0x34]
Mar 14 06:47:06 agentsmith pppd[5974]: Local IP address changed to 178.92.139.62
Mar 14 06:47:07 agentsmith pppd[5974]: Open UDP 178.92.139.62:25489 -> 198.41.0.4:53
Mar 14 06:47:07 agentsmith pppd[5974]: sent [IP data] 45 00 00 4a 5c 21 40 00 ...
Mar 14 06:47:07 agentsmith pppd[5974]: Script /etc/ppp/ip-up started (pid 14398)
Mar 14 06:47:08 agentsmith pppd[5974]: Script /etc/ppp/ip-up finished (pid 14398), status = 0x0

As you can see -- 'No auth is possible'!

*SKIP*
>>As you can see, 'pppd' at my side finishes with no DNS assigned at all
>>(in fact, it logs those vulgar 10.11.12.13 and 10.11.12.14 what don't
>>have DNS running, obviously).
>
> Can't say - 10.11.12.xx is an RFC1918 address not to be seen on the
> Internet at large, but _WITHIN_ a network entity (such as within your
> ISP) this is perfectly legal. Have you tried to as those IPs to
> resolve names for you? If they don't, you might try NOT setting the
> 'usepeerdns' option, and manually setting /etc/resolv.conf with the
> name servers for the domain. From outside, this seems to be 82.207.67.6
> and 195.5.6.10.

Look, I've said above (in skipped): I have no no-DNS issue -- I've gone
for roots (once I've found out that I had no DNS for a whole day; then
suddenly nothing resloves (even google!); may be I'm too hysteric?)

>>Now I would like to see community's opinion on -- is a problem (if
>>there is any) on modem part (blame vendor) or ISP side (blame operator)?
>
> Can't say from out here. Does the connection work when you try using
> IP addresses rather than hostnames?

That doesn't compile.

> Suggestions:
>
> 1. Set up /etc/ppp/chap-secrets

I can do nothing with this. I can't even request personal page
(that's translated from local IT-speek; the page where you can
enable/disable services, probably see statistics etc). To achieve such
I must be on cable. And I'm not

> 2. Add option 'novj' to /etc/ppp/options

Fixed. And BTW disabled 'noauth' -- let's see how it will end.

> 3. REMOVE 'usepeerdns' from /etc/ppp/options

Fixed. It haven't any sense anyway.

> 4. Remove '178.92.14.159:' from /etc/ppp/options

And it have no such in first place. 'pppd' runs persist+ondemand.
That's left after a previous session.

> 5. Add ':10.112.112.112' in place of suggestion 4

Why exactly this one?

> Regarding use of an RFC1918 address for _internal_ use within an ISP,
> this is acceptable. Why should the ISP waste a perfectly good world
> reachable IP for a service that may only be accessed from within the
> ISP? As of last month, RIPE has only allocated 6714048 IPv4 addresses
> to the Ukraine, and I'm sure the ISP has better things to do with
> those addresses than waste them for internal use only.

But they do! See above.

p.s. The things they do aren't, in fact, 'better'. My ISP is believed
(probably urban legend (or better FIDO legend)) to be a cash cow of
current criminal group what happens to be on the wheel (whatever
'current' means).

p.p.s. And I still insist on comunity's opinion.

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

Moe Trin wrote:

> Suggestions:
>
> 1. Set up /etc/ppp/chap-secrets
> 2. Add option 'novj' to /etc/ppp/options 3. REMOVE 'usepeerdns' from
> /etc/ppp/options 4. Remove '178.92.14.159:' from /etc/ppp/options 5.
> Add ':10.112.112.112' in place of suggestion 4
>
> Regarding use of an RFC1918 address for _internal_ use within an ISP,
> this is acceptable. Why should the ISP waste a perfectly good world
> reachable IP for a service that may only be accessed from within the
> ISP?

IME and without really deep into analyzing the issue it takes a bit of
good luck to get a correct DNS address within a ppp connection over a G3/
UMTS modem. With my provider (Telefonica) I might get 193.189.244.2, but
sometimes also just 10.11.12.13 like the OP. The latter can not be
resolved within the internal network of the terminal server.
This might or might not be a timing issue at the service provider's side.
The proper solution is not to use the DNS server as provided by the ISP
but to use a static address within or outside the providers network.
Thanks for the suggestion regarding /etc/ppp/options.

Günther

with <(E-Mail Removed)> Günther Schwarz wrote:
> Moe Trin wrote:
>
>> Suggestions:
>>
>> 1. Set up /etc/ppp/chap-secrets
>> 2. Add option 'novj' to /etc/ppp/options 3. REMOVE 'usepeerdns' from
>> /etc/ppp/options 4. Remove '178.92.14.159:' from /etc/ppp/options 5.
>> Add ':10.112.112.112' in place of suggestion 4
>>
>> Regarding use of an RFC1918 address for _internal_ use within an ISP,
>> this is acceptable. Why should the ISP waste a perfectly good world
>> reachable IP for a service that may only be accessed from within the
>> ISP?
>
> IME and without really deep into analyzing the issue it takes a bit of
> good luck to get a correct DNS address within a ppp connection over a G3/
> UMTS modem. With my provider (Telefonica) I might get 193.189.244.2, but
> sometimes also just 10.11.12.13 like the OP. The latter can not be
> resolved within the internal network of the terminal server.
> This might or might not be a timing issue at the service provider's side.
> The proper solution is not to use the DNS server as provided by the ISP
> but to use a static address within or outside the providers network.

That's how it appears now (see below):

traceroute to 212.179.249.133 (212.179.249.133), 30 hops max, 40 byte packets
1 10.211.16.106 (10.211.16.106) 1414.804 ms 1419.214 ms 1425.879 ms
2 82.207.106.249 (82.207.106.249) 1422.967 ms 1420.241 ms 1425.273 ms
3 * * *
4 dialup-212.162.26.9.frankfurt1.mik.net (212.162.26.9) 1411.441 ms 1408.804 ms 1414.639 ms
5 ae-12-12.ebr1.Frankfurt1.Level3.net (4.69.141.250) 1410.982 ms 1417.090 ms 1413.359 ms
6 ae-61-61.csw1.Frankfurt1.Level3.net (4.69.140.2) 1420.415 ms ae-81-81.csw3.Frankfurt1.Level3.net (4.69.140.10) 121.142 ms ae-91-91.csw4.Frankfurt1.Level3.net (4.69.140.14) 136.496 ms
7 ae-82-82.ebr2.Frankfurt1.Level3.net (4.69.140.25) 123.240 ms ae-62-62.ebr2.Frankfurt1.Level3.net (4.69.140.17) 130.366 ms ae-72-72.ebr2.Frankfurt1.Level3.net (4.69.140.21) 129.063 ms
8 ae-2-2.ebr1.Dusseldorf1.Level3.net (4.69.132.137) 148.340 ms 147.578 ms 147.865 ms
9 ae-1-100.ebr2.Dusseldorf1.Level3.net (4.69.141.150) 147.135 ms 119.228 ms 138.648 ms
10 ae-2-2.ebr1.Amsterdam1.Level3.net (4.69.133.89) 139.880 ms 139.174 ms 138.538 ms
11 ae-1-100.ebr2.Amsterdam1.Level3.net (4.69.141.170) 129.602 ms 136.647 ms 142.281 ms
12 ae-2-2.ebr2.London1.Level3.net (4.69.132.133) 163.342 ms 144.661 ms 142.683 ms
13 * * *
14 BEZEQ-INTER.edge3.London1.Level3.net (212.113.15.78) 143.813 ms 142.008 ms 150.632 ms
15 * * *
16 bzq-179-124-149.static.bezeqint.net (212.179.124.149) 218.606 ms 234.497 ms 232.277 ms
17 bzq-179-124-138.static.bezeqint.net (212.179.124.138) 248.808 ms 249.001 ms 267.189 ms
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

The other DNS (212.113.36.14) is unreachable

traceroute to 212.113.36.14 (212.113.36.14), 30 hops max, 40 byte packets
1 10.211.16.106 (10.211.16.106) 1489.353 ms 1475.239 ms 1481.350 ms
2 82.207.106.249 (82.207.106.249) 1478.567 ms 1483.054 ms 1480.968 ms
3 * * *

IRC, that was different when I've plugged in first time (about 5 month
ago). Both DNSes were reachable, within 5--6 hops, ~1500ms. When I
tracerout'ed my previous ISP DNS'es those where within 10--12 hops,
~700ms (sic!). Although now none of them is even pingable (at least
they speek DNS).

Then -- does that suggest that a problem could be at ISP side? (as if
it yields anything.)

*CUT*

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

with <(E-Mail Removed)> Moe Trin wrote:
> On Sun, 14 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in
> article <(E-Mail Removed)>, Eric Pozharski wrote:
>
>>Moe Trin wrote:
>
>>> It's not really different from cable or dial-in - the other end of the
>>> link is a terminal server at the ISP. Try doing a traceroute
>
>>Have you meant the one that has no IP (remote IP)?
>
> Which version of pppd are you using? It should show up in the log a bit
> before the 'Starting link' line. The reason I ask is that there is a
> 2.4.5 version (released in mid-November) that has some improvements for
> wireless setups.

2.4.4. I've inspected http://packages.qa.debian.org/p/ppp.html and
found out there's 2.4.5 in neither unstable (probably upcoming freeze
issue) nor experimental. Although (what's the problem?) I'll backport
2.4.5 in stable after upgrade to debian-squeeze (when it will be
stable). I've done such things already; let's see what that would
change.

> That's normally a brain-dead ISP, but for the most part there is no
> problem. Look at the output of /sbin/route and you will see something
> like
*SKIP*

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.112.112.112 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.240 U 0 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

*SKIP*
>>Look, I've said above (in skipped): I have no no-DNS issue
>
> Then what is the problem?
>
>>>> is a problem (if there is any) on modem part (blame vendor) or ISP
>>>> side (blame operator)?

(more verbosely) I believe (I'll check once and I won't be surprised)
the ISP's support will turn it into 'install-drivers-very-please' story
(I'm fed up with that kind of lulz). Novatel is a different beast; it
doesn't support customers (me) directly. Its customers are resellers
what, in turn, are supposed to do support for me. If I extrapolate
correctly our local IT-business realities -- I would have an option of
exchange my modem for either another of the same type or a different
brand and/or model. (What could turn out to be just another crap.)

Thus -- I would like to filter the crap they are going to feed me with
when I'll call either support.

*SKIP*
> Can you reach http://152.46.7.80/pub/linux/ as opposed to
> http://ibiblio.org/pub/linux/ which is the same page. If the
> numeric address works, and the name doesn't, you have a DNS problem, but
> NOT a ppp problem. If neither address works, what is the error message?

Sure, I do it for aprox 5 month already.

>>> 2. Add option 'novj' to /etc/ppp/options
>
>>Fixed. And BTW disabled 'noauth' -- let's see how it will end.
>
> 'noauth' tells pppd not to ask the peer to authenticate to you. It
> doesn't stop the peer from asking you to authenticate to it.

Yup. 'pppd' wants tokens (and doesn't start without them; peer is
supposed to authenticate). Reverted. 'novj' bears no difference.

>>> 5. Add ':10.112.112.112' in place of suggestion 4
>
>>Why exactly this one?
>
> This would tell pppd to suggest the peer uses that address for itself.
> You could use almost any RFC5735 or RFC1918 address. This _may_ cause
> the peer to have an IP address for it's end of the link - something
> like the first routing table I show above. The newer version of ppp
> is supposed to be more tolerant of a peer that refuses to negotiate an
> IP address for itself.

Since I've restarted 'pppd' I had an option of readling start-up logs.
'pppd' supposes peer's address is 10.112.112.112 (and see 'route -n'
output above). Should I really insist on this address or leave it for
probably better time?

Mar 14 15:38:23 agentsmith pppd[16321]: pppd 2.4.4 started by root, uid 0
Mar 14 15:38:23 agentsmith pppd[16321]: Using interface ppp0
Mar 14 15:38:23 agentsmith pppd[16321]: local IP address 192.168.0.4
Mar 14 15:38:23 agentsmith pppd[16321]: remote IP address 10.112.112.112
Mar 14 15:38:24 agentsmith pppd[16321]: Starting link
Mar 14 15:38:27 agentsmith pppd[16321]: Serial connection established.
Mar 14 15:38:27 agentsmith pppd[16321]: using channel 1303
Mar 14 15:38:27 agentsmith pppd[16321]: Connect: ppp0 <--> /dev/MC990D
Mar 14 15:38:28 agentsmith pppd[16321]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdff64f92> <pcomp> <accomp>]
Mar 14 15:38:28 agentsmith pppd[16321]: rcvd [LCP ConfReq id=0x57 <asyncmap 0x0> <auth chap MD5> <magic 0x1304fd4d> <pcomp> <accomp>]
Mar 14 15:38:28 agentsmith pppd[16321]: No auth is possible
Mar 14 15:38:28 agentsmith pppd[16321]: sent [LCP ConfRej id=0x57 <auth chap MD5>]

And then (wtf) no-DNS way. That's not fun anymore.

*SKIP*
> But I've also seen reports that wireless connections may come up with
> strange addresses if the connection to the ISP is slow to set up. I'm
> not using this type of service, so I can't say.

And that's another issue I'm going to turn up here some time later.


--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

Eric Pozharski wrote:

> with <(E-Mail Removed)> Günther Schwarz wrote:

>> IME and without really deep into analyzing the issue it takes a bit of
>> good luck to get a correct DNS address within a ppp connection over a
>> G3/ UMTS modem. With my provider (Telefonica) I might get
>> 193.189.244.2, but sometimes also just 10.11.12.13 like the OP.

> IRC, that was different when I've plugged in first time (about 5 month
> ago). Both DNSes were reachable, within 5--6 hops, ~1500ms. When I
> tracerout'ed my previous ISP DNS'es those where within 10--12 hops,
> ~700ms (sic!). Although now none of them is even pingable (at least
> they speek DNS).
>
> Then -- does that suggest that a problem could be at ISP side? (as if
> it yields anything.)

Well, the ISP could block all DNS traffic. 3G networks are very specific
about the services they allow for. They might change their policies
without prior notice. In my case I'm able to use a public DNS server
instead of the one offered by the ISP.

Günther

Moe Trin wrote:

> On 15 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in
> article <(E-Mail Removed)>, Günther Schwarz wrote:

>>IME and without really deep into analyzing the issue it takes a bit of
>>good luck to get a correct DNS address within a ppp connection over a
>>G3/ UMTS modem. With my provider (Telefonica) I might get 193.189.244.2,
>>but sometimes also just 10.11.12.13 like the OP. The latter can not be
>>resolved within the internal network of the terminal server.
>
> Which version of ppp are you using?

pppd version 2.4.4 on Debian Lenny

>>This might or might not be a timing issue at the service provider's
>>side.
>
> I've seen some reports of this, but with no reported solutions.

Yet it seems to be common. I do not know anything about the hard- and
software in these mobile networks. The ppp implementation might be non-
standard, simply buggy, or tweaked towards Windows clients.

>>The proper solution is not to use the DNS server as provided by the ISP
>>but to use a static address within or outside the providers network.
>
> I agree that using static addresses is preferred.

> Setting up a caching name server on a local system is relatively easy,
> and fixes a LOT of problems. Many distributions provide a simple setup
> to do just this.

But then this also requires some reachable DNS server. Since my last
posting I wrote two lines of scripts for /etc/ppp/ip-up.d/ which copy a
working resolv.conf to /etc/. Following your suggestions and simply
disabling setting a DNS server as provided by the ISP might be not the
best solution in my case because I'm using NetworkManager for wired and
WLAN networking. Thus /etc/resolv.conf is changed quite often, and I
never know what the current content of the file is.

Günther

Marc Haber <mh+(E-Mail Removed)> wrote:
> I regularly get these addresses [10.11.12.13, .14] assigned if I start the
> dialup process too early (when the UMTS device has not fully
> registered). This happens with all PPP driven UMTS devices I have ever
> seen (among them being Nokia Phones, Option Datacards of different
> generation, Novatel and Huawei products), so I guess this is some pppd
> default (although not being in the pppd source verbatim):

This also happens here (UK/local & Western Europe/roaming) with a Huwaei
E870 on the Vodafone network. It happens to me under Windows and when
using the Vodafone Mobile Connect application for Linux. Last time I
looked, the online help for VMC suggested shutting down the connection
and trying again, implying it's a known problem.

If you want references, try searching google for "vodafone mobile connect
dns 10.11.12.13 10.11.12.14" (no quotes). You'll see it's common to UMTS
devices regardless of OS.

Chris

Marc Haber wrote:

> Günther Schwarz <(E-Mail Removed)> wrote:
>>But then this also requires some reachable DNS server. Since my last
>>posting I wrote two lines of scripts for /etc/ppp/ip-up.d/ which copy a
>>working resolv.conf to /etc/.
>
> I would recommend doing so through Debian's resolvconf interface.
>
> echo "nameserver a.b.c.d" | resolvconf -i ppp0 to initialize and
> resolvconf -d ppp0 to restore the previous state.

Thanks a lot.

Günther

Marc Haber wrote:

> echo "nameserver a.b.c.d" | resolvconf -i ppp0 to initialize

resolvconf -a

> and resolvconf -d ppp0 to restore the previous state.

This is already present in /etc/ppp/ip-down.d on Lenny.
It works as intended (I'm posting over 3G network).

Günther