UMTS
in [Linux Networking]
|
From: Marc Haber on 16 Mar 2010 09:27 ibuprofin(a)painkiller.example.tld.invalid (Moe Trin) wrote: >Which version of ppp are you using? I've seen some reports that >wireless setups getting strange values for both DNS and WINS addresses >(10.11.12.13 and 10.11.12.14 is mentioned, but doing a search for >these addresses always turns up people using the addresses as examples >(instead of using the address range specifically reserved for such >examples) but not much in the case of ppp actually getting those values.. Negative. I regularly get these addresses 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 is a verbatim, unchanged syslog excerpt |Mar 3 11:21:07 swivel pppd[5295]: local IP address 10.230.235.69 |Mar 3 11:21:07 swivel pppd[5295]: remote IP address 10.64.64.64 |Mar 3 11:21:07 swivel pppd[5295]: primary DNS address 10.11.12.13 |Mar 3 11:21:07 swivel pppd[5295]: secondary DNS address 10.11.12.14 Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
From: Eric Pozharski on 16 Mar 2010 08:18 with <8079ebFhhvU1(a)mid.individual.net> 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
From: Günther Schwarz on 16 Mar 2010 16:10 Eric Pozharski wrote: > with <8079ebFhhvU1(a)mid.individual.net> 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
From: Günther Schwarz on 16 Mar 2010 16:11 Moe Trin wrote: > On 15 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in > article <8079ebFhhvU1(a)mid.individual.net>, 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
From: Moe Trin on 16 Mar 2010 22:31
On Tue, 16 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in article <slrnhpve9b.hkh.whynot(a)orphan.zombinet>, Eric Pozharski wrote: >Moe Trin wrote: >> Which version of pppd are you using? >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?) What's new in ppp-2.4.5. ************************ * Under Linux, pppd can now operate in a mode where it doesn't request the peer's IP address, as some peers refuse to supply an IP address. Since Linux supports device routes as well as gateway routes, it's possible to have no remote IP address assigned to the ppp interface and still route traffic over it. * Pppd now works better with 3G modems that do strange things such as sending IPCP Configure-Naks with the same values over and over again. You may want to check with the Debian mailing lists, as I know that Debian has made substantial changes to the ANU source. >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 That's pppd running in demand mode with the link not up. From the file Changes-2.3 in the ppp tarball: * Pppd no longer requires a remote address to be specified for demand dialling. If none is specified, it will use a default value of 10.112.112.112+unit_number. (It will not propose this default to the peer.) >> '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. That's not what the log shows. You are not asking the peer to authenticate to you ]Mar 14 15:38:28 agentsmith pppd[16321]: sent [LCP ConfReq id=0x1 ] <asyncmap 0x0> <magic 0xdff64f92> <pcomp> <accomp>] Notice there is no 'auth' option here. Instead, the peer wants you to authenticate to it ]Mar 14 15:38:28 agentsmith pppd[16321]: rcvd [LCP ConfReq id=0x57 ]<asyncmap 0x0> <auth chap MD5> <magic 0x1304fd4d> <pcomp> <accomp>] notice it asking^^^here^^^. The 'noauth' does nothing for you, and is only needed when there is a pre-existing default route using another interface. Pppd then assumes you are acting as an ISP. >'novj' bears no difference. OK >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? The key is what does things look like when the link is up. The 10.112.112.112 is used to give the kernel _something_ to use when the link isn't up in demand mode. If the kernel didn't have this false default route when the link is down, it would tell your applications "host unreachable" immediately, rather than waiting until the link is brought up. >> 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. That's why I'm suggesting the ppp-2.4.5. Old guy |