Discussion:
?What is ppp-trace: ~^?}#@!}!} }
(too old to reply)
Lew Pitcher
2011-09-27 01:42:43 UTC
Permalink
On September 26, 2011 20:59, in comp.os.linux.networking,
I vaguely remember the explanation ten years ago for a ppp-trace
You could confirm it by decoding the bits -- or something?
I'm very enthusiastic and optimistic that I can finally use
my fixed-wireless-modem from linux instead of the pain of
M$-Win7.
=================== Here's a log of my tests:-
-> edit my old chap-script from 199? to:---
pppd lcp-echo-interval 300 lcp-echo-failure 4 connect '
chat -v "" ATZ OK ATX OK ATM2DT#777 CONNECT "" TIMEOUT 99 ' \
/dev/ttyUSB1 115200 debug crtscts modem \
-> run Slak13:pppsetup which sets /etc/ppp/chap-secrets
but doesn't know about ttyUSB1
-> re-run chap-script == '/dev/modem unrecognised'
-> ls -l /dev/modem == No such file or directory
-> ln -s /dev/ttyUSB1 /dev/modem
-> re-run chap-script == Wireless-modem LCD indicates <connecting>
-> tail -f /var/log/messages ==
Sep 26 23:43:58 labeas pppd[6513]: pppd 2.4.4 started by root, uid 0
Sep 26 23:43:59 labeas chat[6514]: send (ATZ^M)
Sep 26 23:43:59 labeas chat[6514]: expect (OK)
}!}"} }9}!}$}%\}"}&} } } } }#}%B#}%}%}&F^ZOc\U~~^?}
Sep 26 23:44:44 labeas chat[6514]: alarm
Sep 26 23:44:44 labeas chat[6514]: Failed
Sep 26 23:44:45 labeas pppd[6513]: Exit.
============= end of trace log:--------
OK, if you haven't touched PPP since the 1990's, then you might be forgiven
this problem.

Your PPP configuration is ancient, and expects to talk to a Hayes-compatable
internal modem. You don't have one of those.

Instead, your "fixed-wireless-modem" just converts from "serial" (on the
computer side) to wifi or phone (on the wireless side). That hash you see
at the expect is the PPP negotiation signal from the other end.

Get rid of the expect scripts. In fact, use something like the setup for
pppoe, which doesn't talk to a "modem" at all.
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------
NoHtmlMailsPlease
2011-09-27 08:52:21 UTC
Permalink
Post by Lew Pitcher
On September 26, 2011 20:59, in comp.os.linux.networking,
I vaguely remember the explanation ten years ago for a ppp-trace
You could confirm it by decoding the bits -- or something?
I'm very enthusiastic and optimistic that I can finally use
my fixed-wireless-modem from linux instead of the pain of
M$-Win7.
=================== Here's a log of my tests:-
-> edit my old chap-script from 199? to:---
pppd lcp-echo-interval 300 lcp-echo-failure 4 connect '
chat -v "" ATZ OK ATX OK ATM2DT#777 CONNECT "" TIMEOUT 99 ' \
/dev/ttyUSB1 115200 debug crtscts modem \
-> run Slak13:pppsetup which sets /etc/ppp/chap-secrets
but doesn't know about ttyUSB1
-> re-run chap-script == '/dev/modem unrecognised'
-> ls -l /dev/modem == No such file or directory
-> ln -s /dev/ttyUSB1 /dev/modem
-> re-run chap-script == Wireless-modem LCD indicates <connecting>
-> tail -f /var/log/messages ==
Sep 26 23:43:58 labeas pppd[6513]: pppd 2.4.4 started by root, uid 0
Sep 26 23:43:59 labeas chat[6514]: send (ATZ^M)
Sep 26 23:43:59 labeas chat[6514]: expect (OK)
}!}"} }9}!}$}%\}"}&} } } } }#}%B#}%}%}&F^ZOc\U~~^?}
Sep 26 23:44:44 labeas chat[6514]: alarm
Sep 26 23:44:44 labeas chat[6514]: Failed
Sep 26 23:44:45 labeas pppd[6513]: Exit.
============= end of trace log:--------
OK, if you haven't touched PPP since the 1990's, then you might be forgiven
this problem.
Your PPP configuration is ancient, and expects to talk to a
Hayes-compatable
internal modem. You don't have one of those.
Instead, your "fixed-wireless-modem" just converts from "serial" (on the
computer side) to wifi or phone (on the wireless side). That hash you see
at the expect is the PPP negotiation signal from the other end.
I don't believe it uses wifi.
I managed to get my friend's older model working.
Post by Lew Pitcher
Get rid of the expect scripts. In fact, use something like the setup for
pppoe, which doesn't talk to a "modem" at all.
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------
It's being tested on Slak13 currently.
I'm looking at the log, while I'm typing in this Win7 crap:
"CHAP authentication succeeded: welcome to pdsn
local IP..
remote IP..
LCP terminated by peer
...
Sent 71 bytes, received 0 bytes"

That indicates that the "AT syntax is applicable"

Thanks,

== Chris Glur.
Anssi Saari
2011-09-27 12:19:43 UTC
Permalink
Post by NoHtmlMailsPlease
It's being tested on Slak13 currently.
"CHAP authentication succeeded: welcome to pdsn
local IP..
remote IP..
LCP terminated by peer
...
Sent 71 bytes, received 0 bytes"
That indicates that the "AT syntax is applicable"
It doesn't work though, does it? From the log you actually posted, it
looks like your chat script waits for an OK response when the other end
is already talking PPP. That }!}"} }9}!}$}%\}"}&} } stuff is PPP
traffic.

From this chap stuff above, it looks like you probably need to set some
IP address negotiation options differently.
NoHtmlMailsPlease
2011-09-28 10:46:08 UTC
Permalink
Post by Anssi Saari
Post by NoHtmlMailsPlease
It's being tested on Slak13 currently.
"CHAP authentication succeeded: welcome to pdsn
local IP..
remote IP..
LCP terminated by peer
...
Sent 71 bytes, received 0 bytes"
That indicates that the "AT syntax is applicable"
It doesn't work though, does it? From the log you actually posted, it
looks like your chat script waits for an OK response when the other end
is already talking PPP.
OK, but you should 'mark' exactly in my text WHERE that is implied.
Post by Anssi Saari
That }!}"} }9}!}$}%\}"}&} } stuff is PPP
traffic.
That's important for me to note.
Post by Anssi Saari
From this chap stuff above, it looks like you probably need to set some
IP address negotiation options differently.
That sounds complex. man ppp IS complex. That's why I've kept what was
painfull to get working in 1999.

Later I'm going to my linux-dial-up-location, where instead of copying over
via USBstik, to this crappy Win7, I'll paste the substantial logs which
show:
it usually does connect,
and gets allocated a dynamic IP,
`ping <IP> ` confirms the network presence, and tells if/when unplugged,
but reports sending with NO replies.

It will be a massive contribution to linux-community, if finally,
google can find: HOW2 connect Huawei ET2252+ via linux.

Thank,
== Chris Glur.
n***@gmail.com
2011-09-28 20:23:28 UTC
Permalink
Post by Anssi Saari
Post by NoHtmlMailsPlease
It's being tested on Slak13 currently.
"CHAP authentication succeeded: welcome to pdsn
local IP..
remote IP..
LCP terminated by peer
...
Sent 71 bytes, received 0 bytes"
That indicates that the "AT syntax is applicable"
It doesn't work though, does it? From the log you actually posted, it
looks like your chat script waits for an OK response when the other end
is already talking PPP.
That }!}"} }9}!}$}%\}"}&} } stuff is PPP
traffic.
From this chap stuff above, it looks like you probably need to set some
IP address negotiation options differently.
You've snipped my important log-trace.
The traces below show that often it connects:---------

Sep 27 02:27:36 labeas pppd[7440]: remote IP address 2.2.2.2 <--- OK !!
Sep 27 02:27:52 labeas pppd[7440]: LCP terminated by peer <--- * Fail !!

With TailScript == tail -f /var/log/messages
and
<UserID> filled in, in N3840USBt0 ==
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 "<UserID>"



The following commands produce:-----
-> ./N3840USBt0 <-- try to connect
--> ./TailScript <-- and trace what's happening

Sep 28 11:11:36 labeas pppd[8259]: local IP address 41.174.2.102
Sep 28 11:11:36 labeas pppd[8259]: remote IP address 2.2.2.2
Sep 28 11:19:08 labeas pppd[8289]: pppd 2.4.4 started by root, uid 0
Sep 28 11:19:08 labeas pppd[8289]: Device ttyUSB0 is locked by pid 8259
Sep 28 11:19:08 labeas pppd[8289]: Exit.
Sep 28 11:21:43 labeas pppd[8259]: Terminating on signal 15
Sep 28 11:21:43 labeas pppd[8259]: Connect time 10.2 minutes. <-- WOW !!
Sep 28 11:21:43 labeas pppd[8259]: Sent 57776 bytes, received 13903 bytes. <- 13K:Where to?
Sep 28 11:21:43 labeas pppd[8259]: Connection terminated.
Sep 28 11:21:45 labeas pppd[8259]: Exit.

==> Current logs suggest unreliable connecting, but it *CAN* connect and transfer.
So what is the next recommended test-to-log?

!! OK< I've just noticed at the 'ping terminal' :----
ping 142.165.70.236
PING 142.165.70.236 (142.165.70.236) 56(84) bytes of data.
ping: sendmsg: Network is unreachable <--- ? when it become disconnected
ping: sendmsg: Network is unreachable
.....
ping: sendmsg: Network is unreachable
^C <---- I disabled `ping`
--- 142.165.70.236 ping statistics ---
924 packets transmitted, 0 received, 100% packet loss, time 923036ms <-- 923Sec= 15 min

=> The sudden 'ping trace' of "ping: sendmsg: Network is unreachable"
indicated that the network WAS reachable BEFORE such messages.
But why didn't the `ping` arrive and get a reply from 142.165.70.236 ??
BTW that IP is just an old record of some DNS

-> date ==
Wed Sep 28 11:30:00 UTC 2011 <-- connected from 11:11 to 11:21 = 10 minutes

=> let's try again, with `ping 2.2.2.2`
== the first time `./TailScript` showed the error:--
Sep 28 12:11:02 labeas chat[8322]: expect (OK)
Sep 28 12:11:08 labeas chat[8322]: ~^?}#@!}!} } }9}!}$}%\}

--> so disable & re-try
== again after some time 'connected', when the USB-cable is pulled:---
ping 2.2.2.2
PING 2.2.2.2 (2.2.2.2) 56(84) bytes of data.
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
^C
--- 2.2.2.2 ping statistics ---
137 packets transmitted, 0 received, 100% packet loss, time 136185ms == 2.3min see below

--> ./TailScript == ...
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
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.
Sep 28 12:15:57 labeas kernel: usb 3-2.3: new full speed USB device using ohci_hcd and address 23
Sep 28 12:15:57 labeas kernel: usb 3-2.3: New USB device found, idVendor=12d1, idProduct=1010
Sep 28 12:15:57 labeas kernel: usb 3-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 28 12:15:57 labeas kernel: usb 3-2.3: Product: Huawei Technologies
Sep 28 12:15:57 labeas kernel: usb 3-2.3: Manufacturer: Huawei, Incorporated
Sep 28 12:15:57 labeas kernel: usb 3-2.3: configuration #1 chosen from 1 choice
Sep 28 12:15:57 labeas kernel: usbserial_generic 3-2.3:1.0: generic converter detected
Sep 28 12:15:57 labeas kernel: usb 3-2.3: generic converter now attached to ttyUSB0
Sep 28 12:15:57 labeas kernel: usbserial_generic 3-2.3:1.1: generic converter detected
Sep 28 12:15:57 labeas kernel: usb 3-2.3: generic converter now attached to ttyUSB1

============== The last entries are from unplugging the USB to the wireless-modem.

So linux thinks ppp is connected via the fixed wireless modem.

Does that mean I've got passed the 'userId & password' stage?

Well I could retry with 2 false args, and see if/how it's different.
I'm away from that system, now for a few days, so can't test now.

What's the next test to do after 'userId & password' has passed?

How do I get through the ISP?

== TIA.

Loading...