Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.networking > #790
| Newsgroups | comp.protocols.ppp, comp.os.linux.networking |
|---|---|
| Subject | Re: Interpret trace/log please. |
| References | <j62egq$jmg$1@dont-email.me> <ebc261d2-211b-4458-8639-4868779f6f70@e15g2000vba.googlegroups.com> <slrnjbipcp.1bk.grahn+nntp@frailea.sa.invalid> <40016aa3-52e7-464b-b171-7bc88f91b021@u6g2000vbg.googlegroups.com> <slrnjblbfl.1bk.grahn+nntp@frailea.sa.invalid> |
| From | James Carlson <carlsonj@workingcode.com> |
| Message-ID | <xoavd3d12h0q.fsf@workingcode.com> (permalink) |
| Organization | http://www.NewsDemon.com |
| Date | 2011-11-09 15:11 -0500 |
Cross-posted to 2 groups.
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > On Wed, 2011-11-09, James Carlson wrote: >> The short answer is that 3GPP is broken by design. If you must use >> it, you have to resign yourself to its behavior. Or seek out >> alternatives. > > OK, I see that you know the area, and I've taken a quick look at 27.060. > What I don't quite understand is what forces manufacturers to follow > this broken sequence. Can't they say "fsck it, 27.060 defines broken PPP > between TE and MT, but we'll use normal PPP instead" ? That's certainly what we would do out in the IETF world, where interoperability is the rule of the day, and specifications are merely a means to an end -- a way to document what we think works. The telecom world is quite different in its approach. One doesn't deviate from the requirements, even if they make no sense, and even if they lead to obvious incompatibility problems. All that matters is conformance. It's definitely a different way of doing things. > What I'm really curious about is if the flaw is directly caused to > flaws in the protocols *between* the MS/UE and the internet. I'm > not familiar with the details of PPP, but I know the PDP context > activation sequence quite well from the SGSN/GGSN point of view. > From where I'm sitting it looks quite sane -- the MS sends one request > with all the required information, and in response it gets everything > it needs: a link/tunnel, an assigned IP address, DNS servers and so on. Yes. And there's no good reason at all that the MT couldn't send that request as soon as it has the first authentication request from the local peer (the user's PC). When it gets the rest of the bits (some of which it doesn't yet need), it should cache them locally until the peer asks for them. That's what RADIUS and other extremely similar mechanisms do. It is, I think, what any reasonable protocol designer would do. Except, of course, that the written specification demands otherwise: you are _required_ to lie to the local peer, fake up a "success" message, and then drive on quite a bit further before bothering to do the actual authentication check. And that's just what the 3GPP vendors do. At some point, I have to stop bashing my head against the wall. As my daughter would say, it's "a fail." > (Release 8 and upwards seems to move slowly towards address allocation > via DHCP or IPv6 autodiscovery, by the way.) There's no address allocation in PPP for IPv6, so you have to use neighbor discovery, "stateful" (aka DHCPv6), or some other well-known means to allocate addresses. Only Interface IDs are exchanged for sanity's sake. DHCP for IPv4 can certainly be used over PPP, most obviously in stateless (parameters only; no address allocation) mode. Even IPv4 DHCP address allocation can, in theory, be used over PPP, but in practice this isn't actually done in any implementation I know. In any event, the breakage here is quite clear: when authentication starts, you're expected to do the actual authentication, not defer it to some arbitrary time later when it's no longer possible to handle failures in any reasonable way. -- James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
Back to comp.os.linux.networking | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Interpret trace/log please. no.top.post@gmail.com - 2011-09-29 18:47 +0000
Re: Interpret trace/log please. James Carlson <james.d.carlson@gmail.com> - 2011-11-08 05:15 -0800
Re: Interpret trace/log please. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-08 17:23 +0000
Re: Interpret trace/log please. James Carlson <james.d.carlson@gmail.com> - 2011-11-09 05:06 -0800
Re: Interpret trace/log please. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-09 16:44 +0000
Re: Interpret trace/log please. James Carlson <carlsonj@workingcode.com> - 2011-11-09 15:11 -0500
Re: Interpret trace/log please. ibuprofin@painkiller.example.tld.invalid (Moe Trin) - 2011-11-08 20:29 -0600
Re: Interpret trace/log please. James Carlson <carlsonj@workingcode.com> - 2011-11-09 15:12 -0500
Re: Interpret trace/log please. ibuprofin@painkiller.example.tld.invalid (Moe Trin) - 2011-11-09 19:38 -0600
csiph-web