Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.networking > #790

Re: Interpret trace/log please.

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.

Show all headers | View raw


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


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