UMTS
in [Linux Networking]
|
From: Moe Trin on 17 Mar 2010 15:41 On 17 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in article <80chmbFkefU2(a)mid.individual.net>, G�nther Schwarz wrote: >Moe Trin wrote: >> 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. >Thanks for the hint. Though this looks promising Debian stays with >version 2.4.4 even with unstable. It might be too much work to tweak the >source code until it fits to the distribution. Yeah, when the Debian 'diff' file is ~12700 lines and the ppp source is only 91000 lines, I can't be bothered wasting my time trying to figure what/why it's so different. Old guy
From: Eric Pozharski on 18 Mar 2010 10:51 with <slrnhq0fnl.ah7.ibuprofin(a)compton.phx.az.us> Moe Trin wrote: > 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. I believe that without looking in debianization diff this point is meaningles. But wait,.. OH SHI-- maintainer is dead on the water for 2 years (one NMU 3 month ago). Quick, quick, backporting today. >>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.) No. That output was taken with link up and running. Two days later (with link idle terminated, and 'pppd' still running ondemand) 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 No difference. >>> '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>] Indeed it does not. With 'noauth' commented, and remains of authentication (options ported from the previous ISP with what I had to authenticate) setup ('name', 'user', 'remotename' set to void 'unknown' (not that clever decision afterwards)). Mar 14 15:37:09 agentsmith pppd[16306]: The remote system (unknown) is required to authenticate itself Mar 14 15:37:09 agentsmith pppd[16306]: but I couldn't find any suitable secret (password) for it to use to do so. With 'noauth' commented, 'user' and 'name' commented too; 'remotename' probably not (I'm not sure) Mar 14 15:37:48 agentsmith pppd[16313]: The remote system is required to authenticate itself Mar 14 15:37:48 agentsmith pppd[16313]: but I couldn't find any suitable secret (password) for it to use to do so. Let's put it clear -- 'noauth' is required when peers isn't going to authenticate. And it won't. > 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. 'noauth' is essential when peer isn't going to authenticate. *CUT* -- Torvalds' goal for Linux is very simple: World Domination Stallman's goal for GNU is even simpler: Freedom
From: Eric Pozharski on 18 Mar 2010 11:06 with <80a6t7F7krU1(a)mid.individual.net> Günther Schwarz wrote: *SKIP* > 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. That's scary. Just a matter of speciluation. Probably they wouldn't block on traffic content. They would do that rather on destination port, don't they? Is there any DNS proxy on port, say, 80? -- Torvalds' goal for Linux is very simple: World Domination Stallman's goal for GNU is even simpler: Freedom
From: Günther Schwarz on 18 Mar 2010 15:21 Eric Pozharski wrote: > with <80a6t7F7krU1(a)mid.individual.net> Günther Schwarz wrote: *SKIP* >> 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. > > That's scary. Just a matter of speciluation. Probably they wouldn't > block on traffic content. They would do that rather on destination > port, don't they? Is there any DNS proxy on port, say, 80? As their business is mobile phone calls and not VOIP and as their network capacity is too limited for file sharing traffic they will most definitely not rely on port numbers alone. I'm not aware of a publicly accessible proxy that listens on port 80. But a ssh tunnel to a host outside the provider's network might do the trick. Also note that I'm not saying that DNS is not allowed. It was just a guess on something that might be worth testing in case a server is not reachable. Günther
From: Moe Trin on 19 Mar 2010 16:29
On Thu, 18 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in article <slrnhq4ffc.4dm.whynot(a)orphan.zombinet>, Eric Pozharski wrote: >Let's put it clear -- 'noauth' is required when peers isn't going to >authenticate. And it won't. Make sure you are not setting the 'auth' option in /etc/ppp/options. To see what is being used from where, start pppd with the 'dump' option dryrun With the dryrun option, pppd will print out all the option values which have been set and then exit, after parsing the command line and options files and checking the option val- ues, but before initiating the link. The option values are logged at level info, and also printed to standard output unless the device on standard output is the device that pppd would be using to communicate with the peer. dump With the dump option, pppd will print out all the option values which have been set. This option is like the dryrun option except that pppd proceeds as normal rather than exiting. Some time back in the late 1990s, the Debian maintainer added 'auth' as a required setting in /etc/ppp/options. The only time I've needed the 'noauth' option is when I've been using dialin as a backup to the existing broadband link (which had some reliability problems). Old guy |