I signed up with AT&T Wireless to allow me to access the
internet via my Acernote 350C laptop under Slackware linux: heres some
of the latest errors I get from PPPd 2.4.1 under Slackware 8.0. I
asked this before with Zero results. I REally have had ZERO luck with
AT&T wireless on this issue. The only thing that worked at all was
Trumpet Winsock 3.0d under Windows 3.1 (I don't have the ram for much
newer wincrap. Heres the latest error log
(editted down to Aug 16 and 17 and folded to 70 chars)
Aug 16 23:58:02 laptop pppd[171]: rcvd [CHAP Success id=0x1 "TTP Com P
PP - Password Verified OK"]
Aug 16 23:58:02 laptop pppd[171]: sent [IPCP ConfReq id=0x1 <addr 0.0.
0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 16 23:58:02 laptop pppd[171]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 16 23:58:02 laptop pppd[171]: rcvd [LCP ProtRej id=0x0 80 fd 9c 79
05 08 ef 67 0e 01 54 28 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
Aug 16 23:58:05 laptop pppd[171]: sent [IPCP ConfReq id=0x1 <addr 0.0.
0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 16 23:58:29 laptop last message repeated 8 times
Aug 16 23:58:32 laptop pppd[171]: sent [LCP TermReq id=0x2 "No network
protocols running"]
Aug 16 23:58:32 laptop pppd[171]: rcvd [LCP TermAck id=0x2]
Aug 16 23:59:07 laptop pppd[173]: sent [LCP ConfReq id=0x1 <asyncmap 0
x0> <magic 0x26253605> <pcomp> <accomp>]
Aug 16 23:59:07 laptop pppd[173]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
x0> <magic 0x26253605> <pcomp> <accomp>]
Aug 16 23:59:10 laptop pppd[173]: rcvd [LCP ConfReq id=0x4 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 16 23:59:10 laptop pppd[173]: sent [LCP ConfAck id=0x4 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 16 23:59:10 laptop pppd[173]: rcvd [CHAP Challenge id=0x2 <39009fa
2938c1ed2a77f95db17a885a2f98fa960aa56>, name = "TTP GPRS 0.01"]
Aug 16 23:59:10 laptop pppd[173]: sent [CHAP Response id=0x2 <5f480807
01dd45454d302b3c12f8682c>, name = "dummy"]
Aug 16 23:59:10 laptop pppd[173]: rcvd [CHAP Success id=0x2 "TTP Com P
PP - Password Verified OK"]
Aug 16 23:59:10 laptop pppd[173]: sent [IPCP ConfReq id=0x1 <addr 0.0.
0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 16 23:59:10 laptop pppd[173]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 16 23:59:10 laptop pppd[173]: rcvd [LCP ProtRej id=0x1 80 fd 9c 79
05 08 ef 67 0e 01 94 0b 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
Aug 16 23:59:13 laptop pppd[173]: sent [IPCP ConfReq id=0x1 <addr 0.0.
0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 16 23:59:38 laptop last message repeated 8 times
Aug 16 23:59:39 laptop pppd[173]: rcvd [IPCP ConfRej id=0x1 <compress
VJ 0f 01>]
Aug 16 23:59:39 laptop pppd[173]: sent [IPCP ConfReq id=0x2 <addr 0.0.
0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 16 23:59:39 laptop pppd[173]: rcvd [IPCP ConfReq id=0x1 <addr 255.
255.255.255>]
Aug 16 23:59:39 laptop pppd[173]: sent [IPCP ConfAck id=0x1 <addr 255.
255.255.255>]
Aug 16 23:59:39 laptop pppd[173]: rcvd [IPCP ConfNak id=0x2 <addr 10.1
12.80.227> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 16 23:59:39 laptop pppd[173]: sent [IPCP ConfReq id=0x3 <addr 10.1
12.80.227> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 16 23:59:39 laptop pppd[173]: rcvd [IPCP ConfAck id=0x3 <addr 10.1
12.80.227> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 16 23:59:40 laptop pppd[173]: sent [IPCP TermReq id=0x4 "Unauthori
zed remote IP address"]
Aug 16 23:59:40 laptop pppd[173]: rcvd [IPCP TermAck id=0x4]
Aug 16 23:59:40 laptop pppd[173]: sent [LCP TermReq id=0x2 "No network
protocols running"]
Aug 16 23:59:40 laptop pppd[173]: rcvd [LCP TermAck id=0x2]
Aug 16 23:59:57 laptop pppd[177]: sent [LCP ConfReq id=0x1 <asyncmap 0
x0> <magic 0xfa5954f1> <pcomp> <accomp>]
Aug 16 23:59:57 laptop pppd[177]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
x0> <magic 0xfa5954f1> <pcomp> <accomp>]
Aug 17 00:00:00 laptop pppd[177]: rcvd [LCP ConfReq id=0x6 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:00:00 laptop pppd[177]: sent [LCP ConfAck id=0x6 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:00:00 laptop pppd[177]: rcvd [CHAP Challenge id=0x3 <faac3d1
b7fda43cef2427c203d57be5e98b50f12b2f89b6bf790>, name = "TTP GPRS 0.01"
]
Aug 17 00:00:00 laptop pppd[177]: sent [CHAP Response id=0x3 <0096b280
7f27b2eb0089333b2b945eed>, name = "dummy"]
Aug 17 00:00:00 laptop pppd[177]: rcvd [CHAP Success id=0x3 "TTP Com P
PP - Password Verified OK"]
Aug 17 00:00:00 laptop pppd[177]: sent [IPCP ConfReq id=0x1 <addr 0.0.
0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:00:00 laptop pppd[177]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 17 00:00:00 laptop pppd[177]: rcvd [LCP ProtRej id=0x2 80 fd 9c 79
05 08 ef 67 0e 01 14 22 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
Aug 17 00:00:02 laptop pppd[177]: rcvd [IPCP ConfRej id=0x1 <compress
VJ 0f 01>]
Aug 17 00:00:02 laptop pppd[177]: sent [IPCP ConfReq id=0x2 <addr 0.0.
0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:00:02 laptop pppd[177]: rcvd [IPCP ConfReq id=0x2 <addr 255.
255.255.255>]
Aug 17 00:00:02 laptop pppd[177]: sent [IPCP ConfNak id=0x2 <addr 10.0
..0.0>]
Aug 17 00:00:02 laptop pppd[177]: rcvd [IPCP ConfNak id=0x2 <addr 10.8
0.26.198> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 17 00:00:02 laptop pppd[177]: sent [IPCP ConfReq id=0x3 <addr 10.8
0.26.198> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 17 00:00:02 laptop pppd[177]: rcvd [IPCP ConfReq id=0x3 <addr 255.
255.255.255>]
Aug 17 00:00:02 laptop pppd[177]: sent [IPCP ConfNak id=0x3 <addr 10.0
..0.0>]
Aug 17 00:00:02 laptop pppd[177]: rcvd [IPCP ConfAck id=0x3 <addr 10.8
0.26.198> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 17 00:00:02 laptop pppd[177]: rcvd [IPCP ConfReq id=0x4 <addr 255.
255.255.255>]
Aug 17 00:00:02 laptop pppd[177]: sent [IPCP ConfNak id=0x4 <addr 10.0
..0.0>]
Aug 17 00:00:02 laptop pppd[177]: rcvd [IPCP ConfReq id=0x5 <addr 255.
255.255.255>]
Aug 17 00:00:02 laptop pppd[177]: sent [IPCP ConfNak id=0x5 <addr 10.0
..0.0>]
Aug 17 00:00:02 laptop pppd[177]: rcvd [IPCP ConfReq id=0x6 <addr 255.
255.255.255>]
Aug 17 00:00:02 laptop pppd[177]: sent [IPCP ConfNak id=0x6 <addr 10.0
..0.0>]
Aug 17 00:00:02 laptop pppd[177]: rcvd [IPCP ConfReq id=0x7 <addr 255.
255.255.255>]
Aug 17 00:00:02 laptop pppd[177]: sent [IPCP ConfRej id=0x7 <addr 255.
255.255.255>]
Aug 17 00:00:02 laptop pppd[177]: rcvd [LCP ProtRej id=0x3 80 21 e9 4f
0e 01 f4 1e]
Aug 17 00:00:02 laptop pppd[177]: rcvd [LCP TermReq id=0x0 "Received C
ode/Protocol Rej"]
Aug 17 00:00:02 laptop pppd[177]: sent [LCP TermAck id=0x0]
Aug 17 00:01:41 laptop pppd[181]: sent [LCP ConfReq id=0x1 <asyncmap 0
x0> <magic 0x26601b45> <pcomp> <accomp>]
Aug 17 00:01:41 laptop pppd[181]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
x0> <magic 0x26601b45> <pcomp> <accomp>]
Aug 17 00:01:44 laptop pppd[181]: rcvd [LCP ConfReq id=0x8 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:01:44 laptop pppd[181]: sent [LCP ConfAck id=0x8 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:01:44 laptop pppd[181]: rcvd [CHAP Challenge id=0x4 <e24b83c
bc10e3d79>, name = "TTP GPRS 0.01"]
Aug 17 00:01:44 laptop pppd[181]: sent [CHAP Response id=0x4 <e6c4f01b
537cadb9114be899aa5b9e11>, name = "dummy"]
Aug 17 00:01:44 laptop pppd[181]: rcvd [CHAP Success id=0x4 "TTP Com P
PP - Password Verified OK"]
Aug 17 00:01:44 laptop pppd[181]: sent [IPCP ConfReq id=0x1 <addr 0.0.
0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:01:44 laptop pppd[181]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 17 00:01:44 laptop pppd[181]: rcvd [LCP ProtRej id=0x4 80 fd 9c 79
05 08 ef 67 0e 01 f4 28 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
Aug 17 00:01:47 laptop pppd[181]: rcvd [IPCP ConfRej id=0x1 <compress
VJ 0f 01>]
Aug 17 00:01:47 laptop pppd[181]: sent [IPCP ConfReq id=0x2 <addr 0.0.
0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:01:47 laptop pppd[181]: rcvd [IPCP ConfReq id=0x9 <addr 255.
255.255.255>]
Aug 17 00:01:47 laptop pppd[181]: sent [IPCP ConfAck id=0x9 <addr 255.
255.255.255>]
Aug 17 00:01:47 laptop pppd[181]: rcvd [IPCP ConfNak id=0x2 <addr 10.9
6.55.170> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 17 00:01:47 laptop pppd[181]: sent [IPCP ConfReq id=0x3 <addr 10.9
6.55.170> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 17 00:01:47 laptop pppd[181]: rcvd [IPCP ConfAck id=0x3 <addr 10.9
6.55.170> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 17 00:01:47 laptop pppd[181]: sent [IPCP TermReq id=0x4 "Unauthori
zed remote IP address"]
Aug 17 00:01:47 laptop pppd[181]: rcvd [IPCP TermAck id=0x4]
Aug 17 00:01:47 laptop pppd[181]: sent [LCP TermReq id=0x2 "No network
protocols running"]
Aug 17 00:01:47 laptop pppd[181]: rcvd [LCP TermAck id=0x2]
Aug 17 00:02:44 laptop pppd[185]: sent [LCP ConfReq id=0x1 <asyncmap 0
x0> <magic 0xb3b02bfc> <pcomp> <accomp>]
Aug 17 00:02:44 laptop pppd[185]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
x0> <magic 0xb3b02bfc> <pcomp> <accomp>]
Aug 17 00:02:47 laptop pppd[185]: rcvd [LCP ConfReq id=0xa <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:02:47 laptop pppd[185]: sent [LCP ConfAck id=0xa <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:02:47 laptop pppd[185]: rcvd [CHAP Challenge id=0x5 <797d029
fe6>, name = "TTP GPRS 0.01"]
Aug 17 00:02:47 laptop pppd[185]: sent [CHAP Response id=0x5 <91ed8361
0c995adcb44d92c7320cf7ba>, name = "dummy"]
Aug 17 00:02:47 laptop pppd[185]: rcvd [CHAP Success id=0x5 "TTP Com P
PP - Password Verified OK"]
Aug 17 00:02:47 laptop pppd[185]: sent [IPCP ConfReq id=0x1 <addr 10.0
..0.1> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:02:47 laptop pppd[185]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 17 00:02:47 laptop pppd[185]: rcvd [LCP ProtRej id=0x5 80 fd 9c 79
05 08 ef 67 0e 01 e4 2e 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
Aug 17 00:03:13 laptop pppd[187]: sent [LCP ConfReq id=0x1 <asyncmap 0
x0> <magic 0x5ad28693> <pcomp> <accomp>]
Aug 17 00:03:13 laptop pppd[187]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
x0> <magic 0x5ad28693> <pcomp> <accomp>]
Aug 17 00:03:16 laptop pppd[187]: rcvd [LCP ConfReq id=0xc <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:03:16 laptop pppd[187]: sent [LCP ConfAck id=0xc <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:03:16 laptop pppd[187]: rcvd [CHAP Challenge id=0x6 <1e863c0
8cbb8f565b2>, name = "TTP GPRS 0.01"]
Aug 17 00:03:16 laptop pppd[187]: sent [CHAP Response id=0x6 <31089e42
589a5c430641fbf9db97e34d>, name = "dummy"]
Aug 17 00:03:16 laptop pppd[187]: rcvd [CHAP Success id=0x6 "TTP Com P
PP - Password Verified OK"]
Aug 17 00:03:16 laptop pppd[187]: sent [IPCP ConfReq id=0x1 <addr 10.0
..0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:03:16 laptop pppd[187]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 17 00:03:16 laptop pppd[187]: rcvd [LCP ProtRej id=0x6 80 fd 9c 79
05 08 ef 67 0e 01 d4 25 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
Aug 17 00:03:53 laptop pppd[189]: sent [LCP ConfReq id=0x1 <asyncmap 0
x0> <magic 0x7d029bfb> <pcomp> <accomp>]
Aug 17 00:03:53 laptop pppd[189]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
x0> <magic 0x7d029bfb> <pcomp> <accomp>]
Aug 17 00:03:56 laptop pppd[189]: rcvd [LCP ConfReq id=0xe <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:03:56 laptop pppd[189]: sent [LCP ConfAck id=0xe <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:03:56 laptop pppd[189]: rcvd [CHAP Challenge id=0x7 <db1e9ee
1ee80e461a606c5ff6058bc99edee319e8bfd047e6e>, name = "TTP GPRS 0.01"]
Aug 17 00:03:56 laptop pppd[189]: sent [CHAP Response id=0x7 <c4733756
f111565c7b23da893972c951>, name = "dummy"]
Aug 17 00:03:56 laptop pppd[189]: rcvd [CHAP Success id=0x7 "TTP Com P
PP - Password Verified OK"]
Aug 17 00:03:56 laptop pppd[189]: sent [IPCP ConfReq id=0x1 <addr 10.2
50.250.250> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:03:56 laptop pppd[189]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 17 00:03:56 laptop pppd[189]: rcvd [LCP ProtRej id=0x7 80 fd 9c 79
05 08 ef 67 0e 01 54 2d 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
Aug 17 00:03:59 laptop pppd[189]: sent [IPCP ConfReq id=0x1 <addr 10.2
50.250.250> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:04:16 laptop pppd[191]: sent [LCP ConfReq id=0x1 <asyncmap 0
x0> <magic 0xbab83239> <pcomp> <accomp>]
Aug 17 00:04:16 laptop pppd[191]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
x0> <magic 0xbab83239> <pcomp> <accomp>]
Aug 17 00:04:19 laptop pppd[191]: rcvd [LCP ConfReq id=0x10 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:04:19 laptop pppd[191]: sent [LCP ConfAck id=0x10 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:04:19 laptop pppd[191]: rcvd [CHAP Challenge id=0x8 <8b77429
8f8518f3b8ac7ac72be425ef8febc482112e94fb5213245ff> , name = "TTP GPRS 0
..01"]
Aug 17 00:04:19 laptop pppd[191]: sent [CHAP Response id=0x8 <ec4b559a
73d0b517b4bbc001f52c2f2b>, name = "dummy"]
Aug 17 00:04:19 laptop pppd[191]: rcvd [CHAP Success id=0x8 "TTP Com P
PP - Password Verified OK"]
Aug 17 00:04:19 laptop pppd[191]: sent [IPCP ConfReq id=0x1 <addr 0.0.
0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:04:19 laptop pppd[191]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 17 00:04:19 laptop pppd[191]: rcvd [LCP ProtRej id=0x8 80 fd 9c 79
05 08 ef 67 0e 01 44 2e 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
Aug 17 00:04:22 laptop pppd[191]: sent [IPCP ConfReq id=0x1 <addr 0.0.
0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:04:25 laptop pppd[191]: sent [IPCP ConfReq id=0x1 <addr 0.0.
0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:04:28 laptop pppd[191]: rcvd [IPCP ConfRej id=0x1 <compress
VJ 0f 01>]
Aug 17 00:04:28 laptop pppd[191]: sent [IPCP ConfReq id=0x2 <addr 0.0.
0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:04:28 laptop pppd[191]: rcvd [IPCP ConfReq id=0xa <addr 255.
255.255.255>]
Aug 17 00:04:28 laptop pppd[191]: sent [IPCP ConfAck id=0xa <addr 255.
255.255.255>]
Aug 17 00:04:28 laptop pppd[191]: rcvd [IPCP ConfNak id=0x2 <addr 10.7
2.136.46> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 17 00:04:28 laptop pppd[191]: sent [IPCP ConfReq id=0x3 <addr 10.7
2.136.46> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 17 00:04:28 laptop pppd[191]: rcvd [IPCP ConfAck id=0x3 <addr 10.7
2.136.46> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 17 00:04:28 laptop pppd[191]: sent [IPCP TermReq id=0x4 "Unauthori
zed remote IP address"]
Aug 17 00:04:28 laptop pppd[191]: rcvd [IPCP TermAck id=0x4]
Aug 17 00:04:28 laptop pppd[191]: sent [LCP TermReq id=0x2 "No network
protocols running"]
Aug 17 00:04:28 laptop pppd[191]: rcvd [LCP TermAck id=0x2]
Aug 17 00:05:16 laptop pppd[197]: sent [LCP ConfReq id=0x1 <asyncmap 0
x0> <magic 0xe7e9e00b> <pcomp> <accomp>]
Aug 17 00:05:16 laptop pppd[197]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
x0> <magic 0xe7e9e00b> <pcomp> <accomp>]
Aug 17 00:05:18 laptop pppd[197]: rcvd [LCP ConfReq id=0x12 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:05:18 laptop pppd[197]: sent [LCP ConfAck id=0x12 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:05:19 laptop pppd[197]: rcvd [CHAP Challenge id=0x9 <645b693
5ab1e35161cb034da31c0ff1c4f85da86537ce44b>, name = "TTP GPRS 0.01"]
Aug 17 00:05:19 laptop pppd[197]: sent [CHAP Response id=0x9 <e06f3017
0e6ef2e3fd6fb0dbdd67ce64>, name = "dummy"]
Aug 17 00:05:19 laptop pppd[197]: rcvd [CHAP Success id=0x9 "TTP Com P
PP - Password Verified OK"]
Aug 17 00:05:19 laptop pppd[197]: sent [IPCP ConfReq id=0x1 <addr 10.2
50.250.250> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:05:19 laptop pppd[197]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 17 00:05:19 laptop pppd[197]: rcvd [LCP ProtRej id=0x9 80 fd 9c 79
05 08 ef 67 0e 01 f4 0f 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
Aug 17 00:06:07 laptop pppd[199]: sent [LCP ConfReq id=0x1 <asyncmap 0
x0> <magic 0x99ef8e76> <pcomp> <accomp>]
Aug 17 00:06:07 laptop pppd[199]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
x0> <magic 0x99ef8e76> <pcomp> <accomp>]
Aug 17 00:06:10 laptop pppd[199]: rcvd [LCP ConfReq id=0x14 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:06:10 laptop pppd[199]: sent [LCP ConfAck id=0x14 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:06:10 laptop pppd[199]: rcvd [CHAP Challenge id=0xa <04de249
8885461f6d3197823f9>, name = "TTP GPRS 0.01"]
Aug 17 00:06:10 laptop pppd[199]: sent [CHAP Response id=0xa <5fe1f2eb
abdbda80486aeb73ac5408e0>, name = "dummy"]
Aug 17 00:06:10 laptop pppd[199]: rcvd [CHAP Success id=0xa "TTP Com P
PP - Password Verified OK"]
Aug 17 00:06:10 laptop pppd[199]: sent [IPCP ConfReq id=0x1 <addr 10.2
50.250.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:06:10 laptop pppd[199]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 17 00:06:10 laptop pppd[199]: rcvd [LCP ProtRej id=0xa 80 fd 9c 79
05 08 ef 67 0e 01 24 2b 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
Aug 17 00:06:33 laptop pppd[201]: sent [LCP ConfReq id=0x1 <asyncmap 0
x0> <magic 0x812483dc> <pcomp> <accomp>]
Aug 17 00:06:33 laptop pppd[201]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
x0> <magic 0x812483dc> <pcomp> <accomp>]
Aug 17 00:06:36 laptop pppd[201]: rcvd [LCP ConfReq id=0x16 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:06:36 laptop pppd[201]: sent [LCP ConfAck id=0x16 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:06:36 laptop pppd[201]: rcvd [CHAP Challenge id=0xb <05f8234
3e9e3daa1d8daa2212d3d94bd4816b18dfa297a12d945f4>, name = "TTP GPRS 0.0
1"]
Aug 17 00:06:36 laptop pppd[201]: sent [CHAP Response id=0xb <88ae6bb3
18cd77ec21d52d357e262168>, name = "dummy"]
Aug 17 00:06:36 laptop pppd[201]: rcvd [CHAP Success id=0xb "TTP Com P
PP - Password Verified OK"]
Aug 17 00:06:36 laptop pppd[201]: sent [IPCP ConfReq id=0x1 <addr 10.0
..0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:06:36 laptop pppd[201]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 17 00:06:36 laptop pppd[201]: rcvd [LCP ProtRej id=0xb 80 fd 9c 79
05 08 ef 67 0e 01 d4 2a 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
Aug 17 00:07:23 laptop pppd[203]: sent [LCP ConfReq id=0x1 <asyncmap 0
x0> <magic 0xc3d53576> <pcomp> <accomp>]
Aug 17 00:07:23 laptop pppd[203]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
x0> <magic 0xc3d53576> <pcomp> <accomp>]
Aug 17 00:07:26 laptop pppd[203]: rcvd [LCP ConfReq id=0x18 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:07:26 laptop pppd[203]: sent [LCP ConfAck id=0x18 <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:07:26 laptop pppd[203]: rcvd [CHAP Challenge id=0xc <3651207
13ed0610a4937bf28161fefdecf>, name = "TTP GPRS 0.01"]
Aug 17 00:07:26 laptop pppd[203]: sent [CHAP Response id=0xc <d991600d
4ad29571dc20fa55822f43a6>, name = "dummy"]
Aug 17 00:07:26 laptop pppd[203]: rcvd [CHAP Success id=0xc "TTP Com P
PP - Password Verified OK"]
Aug 17 00:07:26 laptop pppd[203]: sent [IPCP ConfReq id=0x1 <addr 10.0
..0.1> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:07:26 laptop pppd[203]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 17 00:07:26 laptop pppd[203]: rcvd [LCP ProtRej id=0xc 80 fd 9c 79
05 08 ef 67 0e 01 f4 23 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
Aug 17 00:07:50 laptop pppd[205]: sent [LCP ConfReq id=0x1 <asyncmap 0
x0> <magic 0x1adb39fc> <pcomp> <accomp>]
Aug 17 00:07:50 laptop pppd[205]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
x0> <magic 0x1adb39fc> <pcomp> <accomp>]
Aug 17 00:07:53 laptop pppd[205]: rcvd [LCP ConfReq id=0x1a <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:07:53 laptop pppd[205]: sent [LCP ConfAck id=0x1a <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:07:53 laptop pppd[205]: rcvd [CHAP Challenge id=0xd <7d03e5f
f0e15>, name = "TTP GPRS 0.01"]
Aug 17 00:07:53 laptop pppd[205]: sent [CHAP Response id=0xd <44579b54
d9aab6a51ea9bb819fca3b96>, name = "dummy"]
Aug 17 00:07:53 laptop pppd[205]: rcvd [CHAP Success id=0xd "TTP Com P
PP - Password Verified OK"]
Aug 17 00:07:53 laptop pppd[205]: sent [IPCP ConfReq id=0x1 <addr 0.0.
0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:07:53 laptop pppd[205]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 17 00:07:53 laptop pppd[205]: rcvd [LCP ProtRej id=0xd 80 fd 9c 79
05 08 ef 67 0e 01 f4 2d 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
Aug 17 00:07:56 laptop pppd[205]: sent [IPCP ConfReq id=0x1 <addr 0.0.
0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:07:57 laptop pppd[205]: rcvd [IPCP ConfRej id=0x1 <compress
VJ 0f 01>]
Aug 17 00:07:57 laptop pppd[205]: sent [IPCP ConfReq id=0x2 <addr 0.0.
0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:07:57 laptop pppd[205]: rcvd [IPCP ConfReq id=0xb <addr 255.
255.255.255>]
Aug 17 00:07:57 laptop pppd[205]: sent [IPCP ConfAck id=0xb <addr 255.
255.255.255>]
Aug 17 00:07:57 laptop pppd[205]: rcvd [IPCP ConfNak id=0x2 <addr 10.1
04.115.234> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 17 00:07:57 laptop pppd[205]: sent [IPCP ConfReq id=0x3 <addr 10.1
04.115.234> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 17 00:07:57 laptop pppd[205]: rcvd [IPCP ConfAck id=0x3 <addr 10.1
04.115.234> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
Aug 17 00:07:57 laptop pppd[205]: sent [IPCP TermReq id=0x4 "Unauthori
zed remote IP address"]
Aug 17 00:07:57 laptop pppd[205]: rcvd [IPCP TermAck id=0x4]
Aug 17 00:07:57 laptop pppd[205]: sent [LCP TermReq id=0x2 "No network
protocols running"]
Aug 17 00:07:57 laptop pppd[205]: rcvd [LCP TermAck id=0x2]
Aug 17 00:08:58 laptop pppd[209]: sent [LCP ConfReq id=0x1 <asyncmap 0
x0> <magic 0x4098b9ea> <pcomp> <accomp>]
Aug 17 00:08:58 laptop pppd[209]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
x0> <magic 0x4098b9ea> <pcomp> <accomp>]
Aug 17 00:09:01 laptop pppd[209]: rcvd [LCP ConfReq id=0x1c <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:09:01 laptop pppd[209]: sent [LCP ConfAck id=0x1c <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:09:01 laptop pppd[209]: rcvd [CHAP Challenge id=0xe <2647afe
9594ae84d4ea69f69c81b6d>, name = "TTP GPRS 0.01"]
Aug 17 00:09:01 laptop pppd[209]: sent [CHAP Response id=0xe <38d32e21
740cdfadb439431870ca879d>, name = "dummy"]
Aug 17 00:09:01 laptop pppd[209]: rcvd [CHAP Success id=0xe "TTP Com P
PP - Password Verified OK"]
Aug 17 00:09:01 laptop pppd[209]: sent [IPCP ConfReq id=0x1 <addr 10.1
04.115.234> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:09:01 laptop pppd[209]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 17 00:09:01 laptop pppd[209]: rcvd [LCP ProtRej id=0xe 80 fd 9c 79
05 08 ef 67 0e 01 44 24 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
Aug 17 00:10:30 laptop pppd[212]: sent [LCP ConfReq id=0x1 <asyncmap 0
x0> <magic 0x90d5144d> <pcomp> <accomp>]
Aug 17 00:10:30 laptop pppd[212]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
x0> <magic 0x90d5144d> <pcomp> <accomp>]
Aug 17 00:10:33 laptop pppd[212]: rcvd [LCP ConfReq id=0x1e <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:10:33 laptop pppd[212]: sent [LCP ConfAck id=0x1e <mru 1600>
<auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
Aug 17 00:10:33 laptop pppd[212]: rcvd [CHAP Challenge id=0xf <a9869c0
a79c826fab5f14586ed4e398806b3af02c5391e5c08ce535db 168>, name = "TTP GP
RS 0.01"]
Aug 17 00:10:33 laptop pppd[212]: sent [CHAP Response id=0xf <5b6015f3
597c53e0bef5c47ac23abf1c>, name = "dummy"]
Aug 17 00:10:33 laptop pppd[212]: rcvd [CHAP Success id=0xf "TTP Com P
PP - Password Verified OK"]
Aug 17 00:10:33 laptop pppd[212]: sent [IPCP ConfReq id=0x1 <addr 10.1
04.115.234> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Aug 17 00:10:33 laptop pppd[212]: sent [CCP ConfReq id=0x1 <deflate 15
> <deflate(old#) 15>]
Aug 17 00:10:33 laptop pppd[212]: rcvd [LCP ProtRej id=0xf 80 fd 9c 79
05 08 ef 67 0e 01 64 1d 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]

The company will not help anyone who does not use Windows!
Being legally blind and disabled I find it frustrating that I would be
forced to use an Operating system that I cannot use due to my
disability. I work primarily in Ascii console mode with a extra large
VGA cursor. Only one of the tech people tried to help but she could
not even figure out where the problem was, she tried hard to go way
beyond the "script" mode but had no understanding of TCP/IP
networking. I cannot say the same for the hostile department she
refered my case to! I won't go into the sordid details but I will give
one warning. If you use Linux or MAC-OSX, Don't use AT&T wireless!
From what my errorlog shows. they want to use 255.255.255.255
as their own remote address! They told me that I have to run dhcpcd
AFTER I get a ppp link up! (I can't get ppp up to even try a DHCP
connection running!), I didn't need to do that with Trumpet Winsock
which had expired its shareware trial time.
How do I get this to work under Linux? Am I missing a detail?
I read all of the info I could on GPRS and PPP but I haven't found any
sucess with any of the scripts I tried. I read a note on the Linux
Untethered website in reguards to a GC82 EDGE card of patching pppd
2.4.1 to allow address of 127.0.0.3 Never saw a note on hacking it for
255.255.255.255 !
The card shows up as /dev/ttyS2 when installed in my PCMCIA
slot. It does NOT have a network card emulation mode, that I know of.
Being somewhat Unix Savvy I am not afraid to hack or apply
mods to my sourcecode if I need to. I just need to know WHERE to add
the mods as well as HOW to fire up PPPD followed by dhcdcd
afterwards.
I am sending copies of this to the lady who tried to help as
well as root of attws.com as well. I need an answer BEFORE September
8th! or baring that a crack for Trumpet Winsock 3.0d to allow it to
continue to run since my trial period for the shareware is over.


--
From the Desk of the Sysop of:
Planet Maca's Opus, a Free open BBS system.
Telephone 860-738-7176 300-33.6kbps Telnet://pinkrose.net.dhis.org
The New Cnews maintainer
B'ichela

B'ichela <mdalene@pinkrose.net.dhis.org> wrote:
> I signed up with AT&T Wireless to allow me to access the
> internet via my Acernote 350C laptop under Slackware linux: heres some
> of the latest errors I get from PPPd 2.4.1 under Slackware 8.0. I
> asked this before with Zero results. I REally have had ZERO luck with
> AT&T wireless on this issue. The only thing that worked at all was
> Trumpet Winsock 3.0d under Windows 3.1 (I don't have the ram for much
> newer wincrap. Heres the latest error log
> (editted down to Aug 16 and 17 and folded to 70 chars)
> Aug 16 23:58:02 laptop pppd[171]: rcvd [CHAP Success id=0x1 "TTP Com P
> PP - Password Verified OK"]
> Aug 16 23:58:02 laptop pppd[171]: sent [IPCP ConfReq id=0x1 <addr 0.0.
> 0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Aug 16 23:58:02 laptop pppd[171]: sent [CCP ConfReq id=0x1 <deflate 15
>> <deflate(old#) 15>]
> Aug 16 23:58:02 laptop pppd[171]: rcvd [LCP ProtRej id=0x0 80 fd 9c 79
> 05 08 ef 67 0e 01 54 28 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]

Get rid of the request for deflate data compression. You would likely
have to look high and low for any service that implemented that.

> Aug 16 23:58:05 laptop pppd[171]: sent [IPCP ConfReq id=0x1 <addr 0.0.
> 0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Aug 16 23:58:29 laptop last message repeated 8 times
> Aug 16 23:58:32 laptop pppd[171]: sent [LCP TermReq id=0x2 "No network
> protocols running"]
> Aug 16 23:58:32 laptop pppd[171]: rcvd [LCP TermAck id=0x2]

Pppd probably reached the maximum number of times to send an IPCP
request. From looking at other places in the log, it appears that
you should increase the maximum. The option is "ipcp-max-configure
<n>" where <n> is the maximum number of requests (default 10).
GPRS is weird.

> Aug 16 23:59:07 laptop pppd[173]: sent [LCP ConfReq id=0x1 <asyncmap 0
> x0> <magic 0x26253605> <pcomp> <accomp>]
> Aug 16 23:59:07 laptop pppd[173]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
> x0> <magic 0x26253605> <pcomp> <accomp>]
> Aug 16 23:59:10 laptop pppd[173]: rcvd [LCP ConfReq id=0x4 <mru 1600>
> <auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
> Aug 16 23:59:10 laptop pppd[173]: sent [LCP ConfAck id=0x4 <mru 1600>
> <auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
> Aug 16 23:59:10 laptop pppd[173]: rcvd [CHAP Challenge id=0x2 <39009fa
> 2938c1ed2a77f95db17a885a2f98fa960aa56>, name = "TTP GPRS 0.01"]
> Aug 16 23:59:10 laptop pppd[173]: sent [CHAP Response id=0x2 <5f480807
> 01dd45454d302b3c12f8682c>, name = "dummy"]
> Aug 16 23:59:10 laptop pppd[173]: rcvd [CHAP Success id=0x2 "TTP Com P
> PP - Password Verified OK"]
> Aug 16 23:59:10 laptop pppd[173]: sent [IPCP ConfReq id=0x1 <addr 0.0.
> 0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Aug 16 23:59:10 laptop pppd[173]: sent [CCP ConfReq id=0x1 <deflate 15
>> <deflate(old#) 15>]
> Aug 16 23:59:10 laptop pppd[173]: rcvd [LCP ProtRej id=0x1 80 fd 9c 79
> 05 08 ef 67 0e 01 94 0b 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
> Aug 16 23:59:13 laptop pppd[173]: sent [IPCP ConfReq id=0x1 <addr 0.0.
> 0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Aug 16 23:59:38 laptop last message repeated 8 times

The IPCP ConfRej below must have arrived just in time to prevent another
IPCP request timeout.

> Aug 16 23:59:39 laptop pppd[173]: rcvd [IPCP ConfRej id=0x1 <compress
> VJ 0f 01>]
> Aug 16 23:59:39 laptop pppd[173]: sent [IPCP ConfReq id=0x2 <addr 0.0.
> 0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Aug 16 23:59:39 laptop pppd[173]: rcvd [IPCP ConfReq id=0x1 <addr 255.
> 255.255.255>]
> Aug 16 23:59:39 laptop pppd[173]: sent [IPCP ConfAck id=0x1 <addr 255.
> 255.255.255>]

The 255.255.255.255 is the limited broadcast address not an IP address.
GPRS is weird.

> Aug 16 23:59:39 laptop pppd[173]: rcvd [IPCP ConfNak id=0x2 <addr 10.1
> 12.80.227> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
> Aug 16 23:59:39 laptop pppd[173]: sent [IPCP ConfReq id=0x3 <addr 10.1
> 12.80.227> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
> Aug 16 23:59:39 laptop pppd[173]: rcvd [IPCP ConfAck id=0x3 <addr 10.1
> 12.80.227> <ms-dns1 10.250.1.10> <ms-dns3 10.250.1.11>]
> Aug 16 23:59:40 laptop pppd[173]: sent [IPCP TermReq id=0x4 "Unauthori
> zed remote IP address"]

Pppd doesn't like the service requesting the limited broadcast
address. You can try entering 255.255.255.255 as the fourth field
of the chap-secrets line. Although I think this will work, I can't
guarantee it. See man pppd for details about the fourth field.

> Aug 16 23:59:40 laptop pppd[173]: rcvd [IPCP TermAck id=0x4]
> Aug 16 23:59:40 laptop pppd[173]: sent [LCP TermReq id=0x2 "No network
> protocols running"]
> Aug 16 23:59:40 laptop pppd[173]: rcvd [LCP TermAck id=0x2]

The rest of the log messages appear to be various cut-and-try attempts
to get the PPP link up, all generated within an amazingly short time.
....

> From what my errorlog shows. they want to use 255.255.255.255
> as their own remote address! They told me that I have to run dhcpcd
> AFTER I get a ppp link up! (I can't get ppp up to even try a DHCP
> connection running!), I didn't need to do that with Trumpet Winsock
> which had expired its shareware trial time.

It really shouldn't matter what IP address you use for the peer,
although it's usually the actual peer IP address that's negotiated.
In this case giving the service the limited broadcast address is
required by their PPP implementation. GPRS is weird.

> How do I get this to work under Linux? Am I missing a detail?
> I read all of the info I could on GPRS and PPP but I haven't found any
> sucess with any of the scripts I tried. I read a note on the Linux
> Untethered website in reguards to a GC82 EDGE card of patching pppd
> 2.4.1 to allow address of 127.0.0.3 Never saw a note on hacking it for
> 255.255.255.255 !

Bad Idea! Using an IP address in the 127.0.0.0/8 subnet should NEVER
be necessary.

> The card shows up as /dev/ttyS2 when installed in my PCMCIA
> slot. It does NOT have a network card emulation mode, that I know of.
> Being somewhat Unix Savvy I am not afraid to hack or apply
> mods to my sourcecode if I need to. I just need to know WHERE to add
> the mods as well as HOW to fire up PPPD followed by dhcdcd
> afterwards.

I don't know enough to address DHCP configuration. I'd recommend first
trying it without DHCP.

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* 97.3% of all statistics are made up. */

In article <spmagc.h93.ln@corncob.localhost.tld>, Clifford Kite wrote:
>B'ichela <mdalene@pinkrose.net.dhis.org> wrote:
>> I signed up with AT&T Wireless to allow me to access the
>> internet via my Acernote 350C laptop under Slackware linux: heres some
>> of the latest errors I get from PPPd 2.4.1 under Slackware 8.0.

>> Aug 16 23:58:02 laptop pppd[171]: rcvd [LCP ProtRej id=0x0 80 fd 9c 79
>> 05 08 ef 67 0e 01 54 28 02 08 dc 77 05 08 f8 77 05 08 bc 60 05 08]
>
>Get rid of the request for deflate data compression. You would likely
>have to look high and low for any service that implemented that.
>
>> Aug 16 23:58:32 laptop pppd[171]: rcvd [LCP TermAck id=0x2]
>
>Pppd probably reached the maximum number of times to send an IPCP
>request. From looking at other places in the log, it appears that
>you should increase the maximum. The option is "ipcp-max-configure
><n>" where <n> is the maximum number of requests (default 10).
>GPRS is weird.

I'm also concerned about the timing of some of the replies.

>> Aug 16 23:59:07 laptop pppd[173]: sent [LCP ConfReq id=0x1 <asyncmap 0
>> x0> <magic 0x26253605> <pcomp> <accomp>]
>> Aug 16 23:59:07 laptop pppd[173]: rcvd [LCP ConfAck id=0x1 <asyncmap 0
>> x0> <magic 0x26253605> <pcomp> <accomp>]
>> Aug 16 23:59:10 laptop pppd[173]: rcvd [LCP ConfReq id=0x4 <mru 1600>
>> <auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]
>> Aug 16 23:59:10 laptop pppd[173]: sent [LCP ConfAck id=0x4 <mru 1600>
>> <auth chap MD5> <magic 0x5fb8dec7> <asyncmap 0x0> <pcomp> <accomp>]

Notice the three second delaybetween the first and second exchange. I
don't think it's like the 19 second IRQ delay, but wonder what it is, as
it is pretty constant throughout this log.

>The IPCP ConfRej below must have arrived just in time to prevent another
>IPCP request timeout.

Wondering if that might be related.

>> Aug 16 23:59:39 laptop pppd[173]: rcvd [IPCP ConfReq id=0x1 <addr 255.
>> 255.255.255>]
>> Aug 16 23:59:39 laptop pppd[173]: sent [IPCP ConfAck id=0x1 <addr 255.
>> 255.255.255>]
>
>The 255.255.255.255 is the limited broadcast address not an IP address.
>GPRS is weird.

Actually, it's the global broadcast, but nonw rhw less. Would either
suggesting an RFC1918 address to the peer or using ipcp-accept-remote
get around this?

>> Aug 16 23:59:40 laptop pppd[173]: sent [IPCP TermReq id=0x4 "Unauthori
>> zed remote IP address"]
>
>Pppd doesn't like the service requesting the limited broadcast
>address. You can try entering 255.255.255.255 as the fourth field
>of the chap-secrets line. Although I think this will work, I can't
>guarantee it. See man pppd for details about the fourth field.

Wasn't aware of that trick. B'ichela, please report back on results.

>It really shouldn't matter what IP address you use for the peer,
>although it's usually the actual peer IP address that's negotiated.
>In this case giving the service the limited broadcast address is
>required by their PPP implementation. GPRS is weird.

Yeah, I'm wondering how that's going to play in the routing tables as
a gateway address.

Old guy

There is a program "GPRS Easy Connect" which might help;
you can find it with google.
Basically it has settings for Telecoms round the world.

I should say I haven't tried it,
as I had no problem accessing GPRS through a Nokia 6310.

--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland

In article <slrncii00i.sml.ibuprofin@atlantis.phx.az.us>, Moe Trin wrote:
> Actually, it's the global broadcast, but nonw rhw less. Would either
> suggesting an RFC1918 address to the peer or using ipcp-accept-remote
> get around this?
>
>>> Aug 16 23:59:40 laptop pppd[173]: sent [IPCP TermReq id=0x4 "Unauthori
>>> zed remote IP address"]
>>
>>Pppd doesn't like the service requesting the limited broadcast
>>address. You can try entering 255.255.255.255 as the fourth field
>>of the chap-secrets line. Although I think this will work, I can't
>>guarantee it. See man pppd for details about the fourth field.
>
> Wasn't aware of that trick. B'ichela, please report back on results.
Neither was I. Right now I am getting things packed to get
ready to clear out my apartment to go RVing full time. I will give som
e time to more dredging. If someone has a good options file that
might be of use I am all ears. I will be unable to read newsgroups
after the 8th of September unless I can get my laptop working with the
AT&T Novatel Merlin G100 GPRS/GSM card.

--
From the Desk of the Sysop of:
Planet Maca's Opus, a Free open BBS system.
Telephone 860-738-7176 300-33.6kbps Telnet://pinkrose.net.dhis.org
The New Cnews maintainer
B'ichela

Moe Trin <ibuprofin@painkiller.example.tld> wrote:
> In article <spmagc.h93.ln@corncob.localhost.tld>, Clifford Kite wrote:
>>B'ichela <mdalene@pinkrose.net.dhis.org> wrote:

>>The 255.255.255.255 is the limited broadcast address not an IP address.
>>GPRS is weird.

> Actually, it's the global broadcast, but nonw rhw less. Would either
> suggesting an RFC1918 address to the peer or using ipcp-accept-remote
> get around this?

I don't know where you got the "global broadcast" but Stevens 1 refers to
it as "limited broadcast" and while google got hits for "global broadcast"
there were none involving 255.255.255.255, at least not up front. A search
for "limited broadcast" turned up many hits that spoke of 255.255.255.255.
Searching for either broadcast type or 255.255.255.255 turned up nothing
at the RFC search.

Since I've never worked in IT or even taken a course related to networking
protocols it's not possible for me to say you are wrong, but it certainly
seems hard to find evidence supporting your assertion.

As to the question, I can only guess that the answer is no since at one
point pppd ACKed the 255.255.255.255 that the remote requested for itself
and then terminated the link on the grounds that the remote address was
"Unauthorized."

>>> Aug 16 23:59:40 laptop pppd[173]: sent [IPCP TermReq id=0x4 "Unauthori
>>> zed remote IP address"]
>>
>>Pppd doesn't like the service requesting the limited broadcast
>>address. You can try entering 255.255.255.255 as the fourth field
>>of the chap-secrets line. Although I think this will work, I can't
>>guarantee it. See man pppd for details about the fourth field.

> Wasn't aware of that trick. B'ichela, please report back on results.

I was wrong, the fourth field is only for IP addresses that a remote
which pppd regards as a client (a remote that must authenticate itself)
is permitted to use. At least I think that is so now, but the man pages
seem ambiguous and "Unauthorized" triggered my incorrect response.

Also pppd actually doesn't accept 255.255.255.255 when it's specified
for the remote as a valid remote IP address, period. Curious, since
I know pppd accepts any normal remote IP address.

>>It really shouldn't matter what IP address you use for the peer,
>>although it's usually the actual peer IP address that's negotiated.
>>In this case giving the service the limited broadcast address is
>>required by their PPP implementation. GPRS is weird.

> Yeah, I'm wondering how that's going to play in the routing tables as
> a gateway address.

It's not a problem for pppd if pppd doesn't accept it since there will
then be no PPP link, but it _is_ still an unresolved problem for the OP.
And I'm out of suggestions - except for modifying pppd.

I suspect, but do not *know*, that removing "|| IN_MULTICAST(addr) "
from this code in pppd/auth.c will let pppd accept 255.255.255.255
when it's requested by the remote:

/*
* bad_ip_adrs - return 1 if the IP address is one we don't want
* to use, such as an address in the loopback net or a multicast address.
* addr is in network byte order.
*/
int
bad_ip_adrs(addr)
u_int32_t addr;
{
addr = ntohl(addr);
return (addr >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET
|| IN_MULTICAST(addr) || IN_BADCLASS(addr);
}

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* On Linux be root, on Windows reboot.
-Josef Müllers */

In article <fn5dgc.9r5.ln@corncob.localhost.tld>, Clifford Kite wrote:
> As to the question, I can only guess that the answer is no since at one
> point pppd ACKed the 255.255.255.255 that the remote requested for itself
> and then terminated the link on the grounds that the remote address was
> "Unauthorized."
My question on that "Unauthorized based on what you state
below....
> I suspect, but do not *know*, that removing "|| IN_MULTICAST(addr) "
> from this code in pppd/auth.c will let pppd accept 255.255.255.255
> when it's requested by the remote:
A point of order since According to AT&T wireless I Need to
use 255.255.255.255 (based on what you see in the logs) and DHCPCD
looks for a server at 255.255.255.255 (they say I have to start pppd
followed by dhcpcd, their words... Why would it be that pppd normally
would not allow a remote address request that is listed as a
multicast. What exactly is multicast anyway.
Now is this the auth.c stuff in the Linux kernal or the pppd
source code?

--
From the Desk of the Sysop of:
Planet Maca's Opus, a Free open BBS system.
Telephone 860-738-7176 300-33.6kbps Telnet://pinkrose.net.dhis.org
The New Cnews maintainer
B'ichela

B'ichela <mdalene@pinkrose.net.dhis.org> wrote:
> In article <fn5dgc.9r5.ln@corncob.localhost.tld>, Clifford Kite wrote:
>> As to the question, I can only guess that the answer is no since at one
>> point pppd ACKed the 255.255.255.255 that the remote requested for itself
>> and then terminated the link on the grounds that the remote address was
>> "Unauthorized."
> My question on that "Unauthorized based on what you state
> below....
>> I suspect, but do not *know*, that removing "|| IN_MULTICAST(addr) "
>> from this code in pppd/auth.c will let pppd accept 255.255.255.255
>> when it's requested by the remote:
> A point of order since According to AT&T wireless I Need to
> use 255.255.255.255 (based on what you see in the logs) and DHCPCD
> looks for a server at 255.255.255.255 (they say I have to start pppd
> followed by dhcpcd, their words... Why would it be that pppd normally
> would not allow a remote address request that is listed as a
> multicast. What exactly is multicast anyway.

Perhaps you need DHCP and perhaps not. You yourself said, essentially,
that one person tried to help but didn't know much, and the people that
did (or should) know weren't very friendly toward anyone that didn't
use MS. The first step is to get pppd to accept 255.255.255.255 as the
remote's "IP address" and then worry about DHCP.

I don't know why it's disallowed. Someone on the linux-ppp mailing
list might be able to provide an answer. As I've previously said,
my knowledge of protocols is limited. I too find it strange that
255.255.255.255 is accepted during IPCP negotiation but deemed
unauthorized afterward. Only the maintainer may be able to say why
he does that.

You very likely can get a good answer to the second question on the
comp.protocols.tcp-ip newsgroup. All I can say is that broadcast
is used to send to all hosts on a given network, and multicast is
special type of broadcast that is sent to a set of hosts belonging
to a multicast group.

> Now is this the auth.c stuff in the Linux kernal or the pppd
> source code?

It's in the pppd source code. Be aware that I'm not a C programmer,
but can read it to a limited extent. So my approach to finding this
suggestion was mostly a seat-of-the-pants approach. I used grep to
find the code that appears to generate the "Unauthorized" message
and back-tracked to find the piece of code I posted. A twisty little
maze it was too.

Be aware that I do not monitor alt.os.linux.slackware.

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/

In article <fn5dgc.9r5.ln@corncob.localhost.tld>, Clifford Kite wrote:

Hi Clifford,

>I don't know where you got the "global broadcast"

I was trained to use that phrase, or "universal broadcast" an awful long
time ago - I'm guessing it was back in the mid '80s. This was to
differentiate between 255.255.255.255 and the network broadcast such as
10.255.255.255.

>but Stevens 1 refers to it as "limited broadcast"

and that's actually based on RFC1060 (Assigned Numbers). It may have
appeared earlier, but it's not in RFC0919 or 0922.

>Since I've never worked in IT or even taken a course related to networking
>protocols it's not possible for me to say you are wrong, but it certainly
>seems hard to find evidence supporting your assertion.

Broadcast stuff was not well thought out in the beginning. Stevens 1
mentions RFC0906 noting "there was no Internet standard for the broadcast
address" and that the RFC editor ack'ed this and recommended a _host_
address of all ones. (note at the end of section 12.2 in my 1994 printing.)

RFCs 0919 and 0922 attempted to straighten this mess out, although 0919
was still slightly soft. Section 4 ends

- Broadcast to the entire Internet: This is probably not useful,
and almost certainly not desirable.

and section 7 proposed:

The address 255.255.255.255 denotes a broadcast on a local hardware
network, which must not be forwarded. This address may be used, for
example, by hosts that do not know their network number and are
asking some server for it.

Things sorta got solidified in RFC1122 ("Requirements for Internet Hosts
- Communication Layers") in section 3.6.

>As to the question, I can only guess that the answer is no since at one
>point pppd ACKed the 255.255.255.255 that the remote requested for itself
>and then terminated the link on the grounds that the remote address was
>"Unauthorized."

I guess this really falls within the "GPRS is weird" defination.

>> Yeah, I'm wondering how that's going to play in the routing tables as
>> a gateway address.
>
>It's not a problem for pppd if pppd doesn't accept it since there will
>then be no PPP link, but it _is_ still an unresolved problem for the OP.

Yeah, one wonders how the GPRS people are handling this, I know under
_normal_ circumstances, there would be no reason to directly _connect_
to the peer, as all you are using it for is an intermediate routing
point (by this, I mean no reason for _you_ or _I_ to log into the peer or
equal - the peer need offer no service other than packet passing, and that
doesn't put the peers IP address in the destination field of the IP
datagram).

Like you, I'm not a C programmer, but wonder what the kernel would think
on finding 255.255.255.255 listed as the next hop. That address is an
acceptable destination, because it's used all the time by BOOTP and DHCP,
but technically, it can't be a host address based on RFC1122. Still, we
all have seen systems that don't exactly follow the rules.

>And I'm out of suggestions - except for modifying pppd.

I ran out a while ago.

>I suspect, but do not *know*, that removing "|| IN_MULTICAST(addr) "
>from this code in pppd/auth.c will let pppd accept 255.255.255.255
>when it's requested by the remote:

Hmmm, is it that, or IN_BADCLASS(addr) ? I can _sorta_ see what you
are saying here - this should prevent the rejection as an "Unauthorized"
address, but I still wonder if the address would fit into the routing
table. Of course, if I read the reply (next article) from B'ichela,
they're going to be running DHCP on top of this mess - sorta makes you
wonder if they grasp the purpose of RFC1332 section 3.3 ;-)

Old guy

Moe Trin <ibuprofin@painkiller.example.tld> wrote:
> In article <fn5dgc.9r5.ln@corncob.localhost.tld>, Clifford Kite wrote:

> Like you, I'm not a C programmer, but wonder what the kernel would think
> on finding 255.255.255.255 listed as the next hop. That address is an
> acceptable destination, because it's used all the time by BOOTP and DHCP,
> but technically, it can't be a host address based on RFC1122. Still, we
> all have seen systems that don't exactly follow the rules.

Some testing here leads me to believe that the kernel will not permit
255.255.255.255 to be used as the remote IP address for the PPP interface,
period. I can't reassign it as the remote IP address on an existing PPP
interface although I can reassign a normal IP address. That seems like
a good reason for the pppd "Unauthorized" message and link termination.

>>And I'm out of suggestions - except for modifying pppd.

> I ran out a while ago.

>>I suspect, but do not *know*, that removing "|| IN_MULTICAST(addr) "
>>from this code in pppd/auth.c will let pppd accept 255.255.255.255
>>when it's requested by the remote:

> Hmmm, is it that, or IN_BADCLASS(addr) ? I can _sorta_ see what you

Here are the results of greping /usr/include for IN_MULTICAST, IN_CLASSD,
and IN_BADCLASS (modified to 76 columns and irrelevant outputs discarded):

/usr/include/netinet/in.h:
#define IN_MULTICAST(a) IN_CLASSD(a)
#define IN_CLASSD(a) ((((in_addr_t)(a)) & 0xf0000000) == 0xe0000000)
#define IN_BADCLASS(a) ((((in_addr_t)(a)) & 0xf0000000) == 0xf0000000)

In order for bad_ip_adrs(addr) to return 1, either IN_MULTICAST(addr) or
IN_BADCLASS(addr) must be true. In light of the above, IN_BADCLASS(addr)
is true for addr ffffffff and IN_MULTICAST (aka IN_CLASSD(addr)) is not.

So you're right, it *is* IN_BADCLASS(addr) that causes pppd to terminate.

But if the kernel won't configure the PPP interface with 255.255.255.255
as the remote IP address then just changing pppd won't work. Backtracking
from the code generating the "Unauthorized" message to find bad_ip_adrs()
wasn't easy for me, and the kernel is a whole new ballgame. I'm not at
all prepared to tackle that.

BTW, it's nice to have someone who has been involved with IT as well as
networking protocols since the 80's posting answers here. Your comments
were insightful, especially as to the cloudy beginnings of "broadcast"
related terms. In time I'll look into the RFCs you mentioned.

-- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* The signal-to-noise ratio is too low in many [news] groups to make
* them good candidates for archiving.
* --- Mike Moraes, Answers to FAQs about Usenet */