Interpret trace/log please.

This is from a Huawei ET2252+ FixedWirelessTerminal, where
I've previously driven the earlier model ET2252 from linux
with my old script slightly modified and renamed N3840USBt0

So ./N3840USBt0
calls
pppd lcp-echo-interval 300 lcp-echo-failure 4 connect '
chat -v "" ATZ OK ATX OK ATM2DT0113407501 CONNECT "" TIMEOUT 99 ' \
/dev/ttyUSB0 38400 debug crtscts modem defaultroute : name "(E-Mail Removed)"

And /etc/ppp/*secret* has got my password

And ./TailScript
calls
tail -f /var/log/messages

Which gave the following log/trace:---
Sep 28 12:13:25 labeas pppd[8381]: Connect: ppp0 <--> /dev/ttyUSB0
Sep 28 12:13:26 labeas pppd[8381]: CHAP authentication succeeded: Welcome to pdsn.
Sep 28 12:13:26 labeas pppd[8381]: CHAP authentication succeeded
Sep 28 12:13:27 labeas pppd[8381]: local IP address 41.174.19.150
Sep 28 12:13:27 labeas pppd[8381]: remote IP address 2.2.2.2
---So the ISP allocated an IP.
Does that prove I passed the User & password stage?

Then later I tried `ping <someIP>` and then I pulled out the USB-connection
and the trace became:---
Sep 28 12:15:39 labeas kernel: usb 3-2.3: USB disconnect, address 22 <-- pull USB ?
Sep 28 12:15:39 labeas kernel: generic ttyUSB0: generic converter now disconnected from ttyUSB0
Sep 28 12:15:39 labeas kernel: usbserial_generic 3-2.3:1.0: device disconnected
Sep 28 12:15:39 labeas kernel: generic ttyUSB1: generic converter now disconnected from ttyUSB1
Sep 28 12:15:39 labeas kernel: usbserial_generic 3-2.3:1.1: device disconnected
Sep 28 12:15:40 labeas pppd[8381]: Hangup (SIGHUP)
Sep 28 12:15:40 labeas pppd[8381]: Modem hangup <-- ?!
Sep 28 12:15:40 labeas pppd[8381]: Connect time 2.3 minutes. <-- ping-time: "time 136185ms"
Sep 28 12:15:40 labeas pppd[8381]: Sent 11166 bytes, received 0 bytes. <-- ? multiple pings ?
Sep 28 12:15:40 labeas pppd[8381]: Connection terminated.
Sep 28 12:15:41 labeas pppd[8381]: Exit.

When I tried:
ping 142.165.70.236
I got:--
PING 142.165.70.236 (142.165.70.236) 56(84) bytes of data.

And when I unpluggged the PC to FWT I got
ping: sendmsg: Network is unreachable
....
ping: sendmsg: Network is unreachable

So it seems that ping thought it was 'getting out'?

But [IIRC] ping's log showed:
924 packets transmitted, 0 received, 100% packet loss, time 923036ms
==> that's 15 min?!


Q. what is the sequence of steps to dialout and get a ping-bounce?
Eg. a,b,c, confirm UserID, confirm Password, d,e ...

Q. what is the next step that I need to confirm/test and how?

Q. does ping eliminate the need for DNS access?

Q. what happened to the-man-who-wrote-the-book
(from Sun microsystems) that I borrowed from the library N years ago?

== TIA.

On Sep 29, 1:47*pm, no.top.p...@gmail.com wrote:
> pppd *lcp-echo-interval 300 lcp-echo-failure 4 *connect '
> chat -v "" ATZ OK ATX OK ATM2DT0113407501 CONNECT "" TIMEOUT 99 ' \
> /dev/ttyUSB0 38400 debug crtscts modem defaultroute : name "2...@neomail.co.za"
[...]
> Sep 28 12:13:25 labeas pppd[8381]: Connect: ppp0 <--> /dev/ttyUSB0
> Sep 28 12:13:26 labeas pppd[8381]: CHAP authentication succeeded: Welcometo pdsn.
> Sep 28 12:13:26 labeas pppd[8381]: CHAP authentication succeeded
> Sep 28 12:13:27 labeas pppd[8381]: local *IP address 41.174.19.150
> Sep 28 12:13:27 labeas pppd[8381]: remote IP address 2.2.2.2

It looks like your syslog daemon is not correctly configured for pppd
debug.
You need to direct "daemon.debug" to a file. The above are only the
"notice"
messages.

> ---So the ISP allocated an IP.
> Does that prove I passed the User & password stage?

Actually, no. You have the great misfortune to be using 3GPP/GSM for
dial-up access.
That system doesn't follow the RFCs correctly, so the error messages
you get are
*HIGHLY* misleading.

Internally, what happens is that the phone itself will accept and
return "success" for any
identification at all, even the wrong user name and wrong password.
It then goes to the
network and gets an IP address. At this point, the protocols don't
allow any error
messages to be returned, so if the account information is wrong (or if
your account
isn't authorized to use PPP), you get back either a fake IP address or
the line just
disconnects without warning.

It's not at all well-designed. It's a darned shame.

One thing you should do is remove the "name" option. You're the
client (authenticatee),
so you don't want "name". You want "user" instead. And add the
"noauth" option to
your configuration; you shouldn't demand authentication from your ISP.

And re-verify that you've got all of those magic "AT" sequences right
and that your
name and password are specified exactly correctly. You should have
something like
this in your configuration:

noauth user "(E-Mail Removed)"

And then something like this in /etc/ppp/pap-secrets (or chap-secrets,
if they use that):

(E-Mail Removed) * "my password"

Note the "*" in the second field to designate the name of the server
-- you don't
care about the server name.

> Q. *what is the sequence of steps to dialout and get a ping-bounce?
> Eg. a,b,c, confirm UserID, confirm Password, d,e ...

General sequence is:

- chat with "modem" to dial the line, usually with "AT" commands
- PPP LCP starts negotiation
- PPP Authentication runs (usually PAP or CHAP)
- PPP Network layer protocols (e.g., IPCP) negotiate
- link is ready for use

> Q. what is the next step that I need to confirm/test and how?

Fix your syslog configuration so that you can get detailed debug
information. Or use "updetach" so
you can see it on your console.

> Q. does ping eliminate the need for DNS access?

I don't think the question makes sense. DNS translates between
network
names and numbers. Ping is a tool that allows you to send a low-level
(ICMP) request across the network to see if the IP stack on a peer
machine can respond.

Ping (like all network applications) can make use of DNS, if your
system
is configured to use DNS for name services. Having ping certainly
doesn't alter then need for DNS.

> Q. what happened to the-man-who-wrote-the-book
> (from Sun microsystems) that I borrowed from the library N years ago?

He's still around, but doesn't read these news groups as often
anymore. ;-}

On Tue, 2011-11-08, James Carlson wrote:
> On Sep 29, 1:47*pm, no.top.p...@gmail.com wrote:
>> pppd *lcp-echo-interval 300 lcp-echo-failure 4 *connect '
>> chat -v "" ATZ OK ATX OK ATM2DT0113407501 CONNECT "" TIMEOUT 99 ' \
>> /dev/ttyUSB0 38400 debug crtscts modem defaultroute : name "2...@neomail.co.za"
> [...]
>> Sep 28 12:13:25 labeas pppd[8381]: Connect: ppp0 <--> /dev/ttyUSB0
>> Sep 28 12:13:26 labeas pppd[8381]: CHAP authentication succeeded: Welcome to pdsn.
>> Sep 28 12:13:26 labeas pppd[8381]: CHAP authentication succeeded
>> Sep 28 12:13:27 labeas pppd[8381]: local *IP address 41.174.19.150
>> Sep 28 12:13:27 labeas pppd[8381]: remote IP address 2.2.2.2
....
>
>> ---So the ISP allocated an IP.
>> Does that prove I passed the User & password stage?
>
> Actually, no. You have the great misfortune to be using 3GPP/GSM for
> dial-up access.
> That system doesn't follow the RFCs correctly, so the error messages
> you get are
> *HIGHLY* misleading.
>
> Internally, what happens is that the phone itself will accept and
> return "success" for any
> identification at all, even the wrong user name and wrong password.
> It then goes to the
> network and gets an IP address. At this point, the protocols don't
> allow any error
> messages to be returned, so if the account information is wrong (or if
> your account
> isn't authorized to use PPP), you get back either a fake IP address or
> the line just
> disconnects without warning.
>
> It's not at all well-designed. It's a darned shame.

Do you mean that's inherent in 3GPP, or that it's a common way of
(mis)implementing it? I can't see why 3GPP must mandate broken
behavior on the PPP side of the "modem" or "phone" (here, really a
gateway with PPP on one side and some 3GPP tunneling protocol on the
other).

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Tue, 8 Nov 2011, in the Usenet newsgroup comp.os.linux.networking
and comp.protocols.ppp, in article
<ebc261d2-211b-4458-8639-(E-Mail Removed)>,
James Carlson wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

>> Does that prove I passed the User & password stage?

>Actually, no. You have the great misfortune to be using 3GPP/GSM for
>dial-up access.
>That system doesn't follow the RFCs correctly, so the error messages
>you get are *HIGHLY* misleading.

>Internally, what happens is that the phone itself will accept and
>return "success" for any identification at all, even the wrong user
>name and wrong password.

Ah, OK - there was a post on comp.os.linux.networking back on 30 August
with these symptoms. The poster was using an empty username/password
(*secrets contained `"" * ""'), and pppd was reporting success - I was
able to convince him to try "username@isp" and that got it working. I
was wondering why. Thread subject line was "PPP hangs up before
completing T-Mobile connection"

>It then goes to the network and gets an IP address. At this point, the
>protocols don't allow any error messages to be returned, so if the
>account information is wrong (or if your account isn't authorized to
>use PPP), you get back either a fake IP address or the line just
>disconnects without warning.

In this case, he got a hangup - peer disappeared at start if IPCP stage.

>It's not at all well-designed. It's a darned shame.

When have we heard _that_ one before ;-)

>> Q. what happened to the-man-who-wrote-the-book

>He's still around, but doesn't read these news groups as often
>anymore. ;-}

Yup - also gone missing is Clifford Kite and Bill Unruh (though Bill is
still active in other groups). It's getting lonely here!

Old guy

On Nov 8, 12:23*pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Tue, 2011-11-08, James Carlson wrote:
> > On Sep 29, 1:47*pm, no.top.p...@gmail.com wrote:
> >> pppd *lcp-echo-interval 300 lcp-echo-failure 4 *connect '
> >> chat -v "" ATZ OK ATX OK ATM2DT0113407501 CONNECT "" TIMEOUT 99 ' \
> >> /dev/ttyUSB0 38400 debug crtscts modem defaultroute : name "2...@neomail.co.za"
> > [...]
> >> Sep 28 12:13:25 labeas pppd[8381]: Connect: ppp0 <--> /dev/ttyUSB0
> >> Sep 28 12:13:26 labeas pppd[8381]: CHAP authentication succeeded: Welcome to pdsn.
> >> Sep 28 12:13:26 labeas pppd[8381]: CHAP authentication succeeded
> >> Sep 28 12:13:27 labeas pppd[8381]: local *IP address 41.174.19.150
> >> Sep 28 12:13:27 labeas pppd[8381]: remote IP address 2.2.2.2
> ...
>
> >> ---So the ISP allocated an IP.
> >> Does that prove I passed the User & password stage?
>
> > Actually, no. *You have the great misfortune to be using 3GPP/GSM for
> > dial-up access.
> > That system doesn't follow the RFCs correctly, so the error messages
> > you get are
> > *HIGHLY* misleading.
>
> > Internally, what happens is that the phone itself will accept and
> > return "success" for any
> > identification at all, even the wrong user name and wrong password.
> > It then goes to the
> > network and gets an IP address. *At this point, the protocols don't
> > allow any error
> > messages to be returned, so if the account information is wrong (or if
> > your account
> > isn't authorized to use PPP), you get back either a fake IP address or
> > the line just
> > disconnects without warning.
>
> > It's not at all well-designed. *It's a darned shame.
>
> Do you mean that's inherent in 3GPP, or that it's a common way of
> (mis)implementing it? *I can't see why 3GPP must mandate broken
> behavior on the PPP side of the "modem" or "phone" (here, really a
> gateway with PPP on one side and some 3GPP tunneling protocol on the
> other).

It's inherent in the way 3GPP is specified. Rather than doing the
obvious
thing -- just implementing the protocol as specified in the RFCs --
they
wrote a spec that attempts to redefine how the protocols in the RFCs
work.
The result is, as expected, a new "wheel" that's substantially less
than
round.

For the gory details, see 3GPP TS 27.060, section 9.1.1 "IPv4 over
PPP."
Note the "9. PS Attach" on the Um/Uu side that occurs _after_ LCP,
PPP Authentication, and the first NCP (IPCP) Configure-Request. Note
also the sad footnote:

"The MT stores the necessary authentication data and sends a
locally
generated positive acknowledgement of the authentication to the
TE."

(Text above copyright ETSI, original publication date unknown.)

It's a design flaw, and it's entirely intentional. Years ago, when I
was more
involved with the IETF standards process, I tried to talk the authors
out of
this mess. I wasn't successful.

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.

On Wed, 2011-11-09, James Carlson wrote:
> On Nov 8, 12:23*pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> On Tue, 2011-11-08, James Carlson wrote:
>> > On Sep 29, 1:47*pm, no.top.p...@gmail.com wrote:
>> >> pppd *lcp-echo-interval 300 lcp-echo-failure 4 *connect '
>> >> chat -v "" ATZ OK ATX OK ATM2DT0113407501 CONNECT "" TIMEOUT 99 ' \
>> >> /dev/ttyUSB0 38400 debug crtscts modem defaultroute : name "2...@neomail.co.za"
>> > [...]
>> >> Sep 28 12:13:25 labeas pppd[8381]: Connect: ppp0 <--> /dev/ttyUSB0
>> >> Sep 28 12:13:26 labeas pppd[8381]: CHAP authentication succeeded: Welcome to pdsn.
>> >> Sep 28 12:13:26 labeas pppd[8381]: CHAP authentication succeeded
>> >> Sep 28 12:13:27 labeas pppd[8381]: local *IP address 41.174.19.150
>> >> Sep 28 12:13:27 labeas pppd[8381]: remote IP address 2.2.2.2
>> ...
>>
>> >> ---So the ISP allocated an IP.
>> >> Does that prove I passed the User & password stage?
>>
>> > Actually, no. *You have the great misfortune to be using 3GPP/GSM for
>> > dial-up access.
>> > That system doesn't follow the RFCs correctly, so the error messages
>> > you get are
>> > *HIGHLY* misleading.
>>
>> > Internally, what happens is that the phone itself will accept and
>> > return "success" for any
>> > identification at all, even the wrong user name and wrong password.
>> > It then goes to the
>> > network and gets an IP address. *At this point, the protocols don't
>> > allow any error
>> > messages to be returned, so if the account information is wrong (or if
>> > your account
>> > isn't authorized to use PPP), you get back either a fake IP address or
>> > the line just
>> > disconnects without warning.
>>
>> > It's not at all well-designed. *It's a darned shame.
>>
>> Do you mean that's inherent in 3GPP, or that it's a common way of
>> (mis)implementing it? *I can't see why 3GPP must mandate broken
>> behavior on the PPP side of the "modem" or "phone" (here, really a
>> gateway with PPP on one side and some 3GPP tunneling protocol on the
>> other).
>
>
> It's inherent in the way 3GPP is specified. Rather than doing the
> obvious thing -- just implementing the protocol as specified in the
> RFCs -- they wrote a spec that attempts to redefine how the protocols
> in the RFCs work. The result is, as expected, a new "wheel" that's
> substantially less than round.
>
> For the gory details, see 3GPP TS 27.060, section 9.1.1 "IPv4 over
> PPP." Note the "9. PS Attach" on the Um/Uu side that occurs _after_
> LCP, PPP Authentication, and the first NCP (IPCP) Configure-Request.
> Note also the sad footnote:
>
> "The MT stores the necessary authentication data and sends a
> locally generated positive acknowledgement of the authentication
> to the TE."
>
> (Text above copyright ETSI, original publication date unknown.)
>
> It's a design flaw, and it's entirely intentional. Years ago, when I
> was more involved with the IETF standards process, I tried to talk the
> authors out of this mess. I wasn't successful.
>
> 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" ?

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.

(Release 8 and upwards seems to move slowly towards address allocation
via DHCP or IPv6 autodiscovery, by the way.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jorgen Grahn <grahn+(E-Mail Removed)> 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 <(E-Mail Removed)>

(E-Mail Removed)d (Moe Trin) writes:

> On Tue, 8 Nov 2011, in the Usenet newsgroup comp.os.linux.networking
> and comp.protocols.ppp, in article
> <ebc261d2-211b-4458-8639-(E-Mail Removed)>,
> James Carlson wrote:
>
> NOTE: Posting from groups.google.com (or some web-forums) dramatically
> reduces the chance of your post being seen. Find a real news server.

You pushed me towards contacting tech support at newsdaemon.com in
order to get my account there working again. Better?

--
James Carlson 42.703N 71.076W <(E-Mail Removed)>

On Wed, 09 Nov 2011, in the Usenet newsgroup comp.os.linux.networking
and comp.protocols.ppp, in article <(E-Mail Removed)>,
James Carlson wrote:

>(Moe Trin) writes:

>> NOTE: Posting from groups.google.com (or some web-forums) dramatically
>> reduces the chance of your post being seen. Find a real news server.

>You pushed me towards contacting tech support at newsdaemon.com in
>order to get my account there working again. Better?

Sorry James - my news reader is configured to add that whenever I reply
to a post from groups.google.com (and several others). Google has a
pretty poor reputation for newsgroup abuse, and some people and news
providers respond by simply filtering posts from that source (relatively
trivial). For what it's worth, there are a number of inexpensive or
free news providers out there. A quick search for "free Usenet
providers" would turn up a few dozen alternatives.

In your response to Jorgen Grahn, you pointed at the 3rd Generation
Partnership Project specifications - mentioning that they decided
to re-invent the wheel. Another place they differ from the IETF is
that the specifications are in MS Word 9, rather than simple text.
I found a copy in the slightly more universal 'html' format, and am
now trying to make sense of it. ;-)

Old guy