UMTS
in [Linux Networking]
|
From: Moe Trin on 16 Mar 2010 22:33 On Tue, 16 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in article <hno0v6$g8v$1(a)news1.tnib.de>, Marc Haber wrote: >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). Which version of ppp are you using? >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): All of the actual logs I've been able to find show these addresses being proposed by the peer ("rcvd [IPCP ConfReq") rather than being proposed by pppd. pppd only knows about three IPv4 addresses in the 10.x.x.x range - 10.0.0.0 identifying the network, 10.64.64.64 and 10.112.112.112 used internally in 'demand' mode (they are coded in hex rather than decimal) and these should only be used when the link is down but in demand mode. >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 Look a few lines earlier in the log and review the IPCP negotiations. I think you'll find these nameserver and remote addresses being proposed or offered by the peer, much as Eric shows: ]] 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: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>] Here, his system proposed using 178.92.14.159 as it's address, and by proposing zeros for DNS is asking the peer to suggest values. The peer came back with a ConfNak (RFC1661 Section 5.3) and suggests using the 10.11.12.1[34] addresses in place of 0.0.0.0 - that's how it's supposed to work. Old guy
From: Moe Trin on 16 Mar 2010 22:34 On 16 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in article <80a6vtF7krU2(a)mid.individual.net>, G�nther Schwarz wrote: >Moe Trin wrote: >> Which version of ppp are you using? >pppd version 2.4.4 on Debian Lenny 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. 2.4.5 was released back in November. You should be aware that the Debian version is significantly altered from what the authors (Paul Mackerras of samba.org and James Carlson of Sun) supply. >> 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. That's true, and the other solution is to run your own resolving server. I do this because I have several ISPs that I use on a regular basis (one of which provides DNS from both world reachable _or_ RFC1918 addresses depending on chance), and they tend to not like non-customers using their servers to resolve other names/addresses. This also gets around the RFC4074 IPv6 problems. >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. Before this microsoft concept of auto-configuring DNS was added to ppp-2.3.7 back in 1999, I used to look at the peer IP address ($5 passed to /etc/ppp/ip-{up-down}) and based on the address, selected "the correct" resolv.conf file to copy over /etc/resolv.conf. As that script is run-as root, permissions/ownership were no problem. When the link was brought down, /etc/resolv.conf was reset to "normal". I finally bit the bullet and set up a local nameserver able to do it's own resolution. Old guy
From: Chris Davies on 17 Mar 2010 05:03 Marc Haber <mh+usenetspam1002(a)zugschl.us> 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
From: Marc Haber on 17 Mar 2010 07:10 ibuprofin(a)painkiller.example.tld.invalid (Moe Trin) wrote: >On Tue, 16 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in >article <hno0v6$g8v$1(a)news1.tnib.de>, Marc Haber wrote: >>Negative. I regularly get these addresses assigned if I start the >>dialup process too early (when the UMTS device has not fully >>registered). > >Which version of ppp are you using? 2.4.4rel-10.1 from Debian unstable, I have been seeing this behavior ever since I started using mobile Internet access years ago. >>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 > >Look a few lines earlier in the log and review the IPCP negotiations. >I think you'll find these nameserver and remote addresses being proposed >or offered by the peer, much as Eric shows: Since I have changed over to wvdial, my pppd doesn't log the IPCP/LCP conversations any more. I cannot verify this. >Here, his system proposed using 178.92.14.159 as it's address, and >by proposing zeros for DNS is asking the peer to suggest values. The >peer came back with a ConfNak (RFC1661 Section 5.3) and suggests using >the 10.11.12.1[34] addresses in place of 0.0.0.0 - that's how it's >supposed to work. Since the PPP Peer in this case is the UMTS device and I have seen this behavior with a lot of different UTMS devices - is proposing 10.11.12.13 and 10.11.12.14 an official standard, or just a convention among all vendors? 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: Marc Haber on 17 Mar 2010 07:15
Günther Schwarz <strap(a)gmx.de> 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. 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 |