| Home | Register | Members | Search | Links |
 |
| Thread Tools | Display Modes |
|
Guest
Posts: n/a
|
|
|
|
||
|
|
| |
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
On Fri, 27 May 2005 12:16:01 -0500, Clifford Kite <(E-Mail Removed)> wrote:
>laura fairhead <(E-Mail Removed)> wrote: > >> Hi ppl, > >> I am experiencing a problem with the PPP setup >> connecting to my (dial-up) service/connection >> provider (btinternet). It has worked fine for >> years but recently the internet connection under >> Linux fails (Windows 98 still functions). > >Dual boot or two different computers? Hi Clifford  This is just one comp with one modem, dual linux/win98 > >> It does actually connect but I don't receive >> any packets - well an ifconfig shows the ppp >> device as having received those packets but >> most of them are getting a "frame" error. >> I wonder if it has something to do with >> the MRU, presently I don't understand what >> a frame error is. > >I suspect it means that the AHDLC frame used by PPP has a CRC error. I thought it could be something like the MRU negociation being bugged linux talking and windoze just leaving it with the default or something But that doesn't seem to be the case.... Maybe it is one of the compression protocols (ACP, PCP) or something lower level than LCP (is that what you mean by AHDLC I'm not familiar with the term ?) > >> Well I would appreciate any help, I have >> started reading RFC1661 on PPP and eventually >> maybe work out what is going on but it would >> be great if someone with more experience >> could advise me. > >If the ISP has changed it's PPP implementation or DCE and the new ><whichever> has a bug or configuration error then reading an RFC >won't help. I'd been putting off reading it for a long time, the subject really fascinates me ! > >Add the pppd option debug and the chat option -v, if chat is used >to make the serial connection. Then make a PPP connection and >after it's terminated post an exact copy, including timestamps, >of /var/log/ppp.log so we can see what happens during PPP link >negotiations. Okay I did this plus I decoded the windoze log (at least just the LCP stage maybe its not that ) > >> I suppose BT/Yahoo changed something in the >> PPP setup and it just happens that 98 >> is happy with it and Linux is not > >It is likely BT/Yahoo changed something. The alternative would seem >to be that something has gone bad on the Linux host, such as kernel >or pppd corruption, a modem or serial device problem, ect. Okay here goes ...May 27 19:59:28 bell486 pppd[474]: Perms of /dev/ttyS1 are ok, no 'mesg n' neccesary. May 27 19:59:29 bell486 chat[475]: abort on (NO CARRIER) May 27 19:59:29 bell486 chat[475]: abort on (NO DIALTONE) May 27 19:59:29 bell486 chat[475]: abort on (BUSY) May 27 19:59:29 bell486 chat[475]: send (++AT&F^M) May 27 19:59:29 bell486 chat[475]: expect (OK) May 27 19:59:29 bell486 chat[475]: ++AT&F^M^M May 27 19:59:29 bell486 chat[475]: OK May 27 19:59:29 bell486 chat[475]: -- got it May 27 19:59:29 bell486 chat[475]: send (ATM0^M) May 27 19:59:29 bell486 chat[475]: expect (OK) May 27 19:59:29 bell486 chat[475]: ^M May 27 19:59:29 bell486 chat[475]: ATM0^M^M May 27 19:59:29 bell486 chat[475]: OK May 27 19:59:29 bell486 chat[475]: -- got it May 27 19:59:29 bell486 chat[475]: send (ATDTxxxxxxxxxxxx^M) May 27 19:59:30 bell486 chat[475]: timeout set to 600 seconds May 27 19:59:30 bell486 chat[475]: expect (CONNECT 115200) May 27 19:59:45 bell486 chat[475]: ATDTxxxxxxxxxxx^M^M May 27 19:59:45 bell486 chat[475]: CARRIER 33600^M May 27 19:59:46 bell486 chat[475]: ^M May 27 19:59:46 bell486 chat[475]: PROTOCOL: LAP-M^M May 27 19:59:46 bell486 chat[475]: ^M May 27 19:59:46 bell486 chat[475]: CONNECT 115200 May 27 19:59:46 bell486 chat[475]: -- got it May 27 19:59:46 bell486 pppd[474]: Serial connection established. May 27 19:59:46 bell486 pppd[474]: Using interface ppp0 May 27 19:59:46 bell486 pppd[474]: Connect: ppp0 <--> /dev/ttyS1 May 27 19:59:47 bell486 pppd[474]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xd8d563ff> <pcomp> <accomp>] May 27 19:59:47 bell486 pppd[474]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xd8d563ff> <pcomp> <accomp>] May 27 19:59:49 bell486 pppd[474]: rcvd [LCP ConfReq id=0x34 <asyncmap 0xa0000> <auth chap MD5> <magic 0x4d848d69> <pcomp> <accomp>] May 27 19:59:49 bell486 pppd[474]: sent [LCP ConfAck id=0x34 <asyncmap 0xa0000> <auth chap MD5> <magic 0x4d848d69> <pcomp> <accomp>] May 27 19:59:49 bell486 pppd[474]: sent [LCP EchoReq id=0x0 magic=0xd8d563ff] May 27 19:59:50 bell486 pppd[474]: rcvd [CHAP Challenge id=0x2f xxxxxxxxxxxxxxxxx ] May 27 19:59:50 bell486 pppd[474]: sent [CHAP Response id=0x2f xxxxxxxxxxxxxxxx ] May 27 19:59:50 bell486 pppd[474]: rcvd [LCP EchoRep id=0x0 magic=0x4d848d69] May 27 19:59:50 bell486 pppd[474]: rcvd [CHAP Success id=0x2f ""] May 27 19:59:50 bell486 pppd[474]: sent [IPCP ConfReq id=0x1 <addr 192.168.xxxxx> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>] May 27 19:59:50 bell486 pppd[474]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] May 27 19:59:50 bell486 pppd[474]: rcvd [IPCP ConfReq id=0x79 <addr 212.140.212.63>] May 27 19:59:50 bell486 pppd[474]: sent [IPCP ConfAck id=0x79 <addr 212.140.212.63>] May 27 19:59:50 bell486 pppd[474]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>] May 27 19:59:50 bell486 pppd[474]: sent [IPCP ConfReq id=0x2 <addr 192.168.xxxxx> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>] May 27 19:59:50 bell486 pppd[474]: rcvd [LCP ProtRej id=0x17 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f] May 27 19:59:50 bell486 pppd[474]: rcvd [IPCP ConfNak id=0x2 <addr 81.131.41.46> <ms-dns1 213.120.62.97> <ms-dns3 213.120.62.104>] May 27 19:59:50 bell486 pppd[474]: sent [IPCP ConfReq id=0x3 <addr 81.131.41.46> <ms-dns1 213.120.62.97> <ms-dns3 213.120.62.104>] May 27 19:59:59 bell486 last message repeated 3 times May 27 20:00:01 bell486 pppd[474]: rcvd [IPCP ConfReq id=0x7a <addr 212.140.212.63>] May 27 20:00:01 bell486 pppd[474]: sent [IPCP ConfAck id=0x7a <addr 212.140.212.63>] May 27 20:00:01 bell486 pppd[474]: rcvd [IPCP ConfAck id=0x3 <addr 81.131.41.46> <ms-dns1 213.120.62.97> <ms-dns3 213.120.62.104>] May 27 20:00:01 bell486 pppd[474]: local IP address 81.131.41.46 May 27 20:00:01 bell486 pppd[474]: remote IP address 212.140.212.63 May 27 20:00:01 bell486 pppd[474]: primary DNS address 213.120.62.97 May 27 20:00:01 bell486 pppd[474]: secondary DNS address 213.120.62.104 May 27 20:00:01 bell486 pppd[474]: Script /etc/ppp/ip-up started (pid 478) May 27 20:00:01 bell486 pppd[474]: Script /etc/ppp/ip-up finished (pid 478), status = 0x0 May 27 20:00:19 bell486 pppd[474]: sent [LCP EchoReq id=0x1 magic=0xd8d563ff] May 27 20:00:20 bell486 pppd[474]: rcvd [LCP EchoRep id=0x1 magic=0x4d848d69] May 27 20:00:49 bell486 pppd[474]: sent [LCP EchoReq id=0x2 magic=0xd8d563ff] May 27 20:00:50 bell486 pppd[474]: rcvd [LCP EchoRep id=0x2 magic=0x4d848d69] Threebits in that worried me, the LAP, CARRIER thing at the start and the repeated NAK thing in the middle and also that Protocol reject thing (could the protocol compression be to blame?) ... I don't know about it though I also ran ifconfig after the IP came up and it reported about 4 frame errors which seemed to related directly to the echo req/rep I decoded the windows PPP log, the rfc didn't have it but I suppose ACCM in the below is async map and the LCP requests CHAP (C223) with MD5 (the 5). 05-24-2005 10:03:16.05 - Microsoft Dial Up Adapter log opened. 05-24-2005 10:03:16.05 - Server type is PPP (Point to Point Protocol). 05-24-2005 10:03:16.05 - FSA : Software compression disabled. 05-24-2005 10:03:16.05 - FSA : Protocol not bound - skipping control protocol 803f (NBFCP). 05-24-2005 10:03:16.05 - FSA : Adding Control Protocol 8021 (IPCP) to control protocol chain. 05-24-2005 10:03:16.05 - FSA : Protocol not bound - skipping control protocol 802b (IPXCP). 05-24-2005 10:03:16.05 - FSA : Adding Control Protocol c029 (CallbackCP) to control protocol chain. 05-24-2005 10:03:16.05 - FSA : Adding Control Protocol c027 (no description) to control protocol chain. 05-24-2005 10:03:16.05 - FSA : Adding Control Protocol c023 (PAP) to control protocol chain. 05-24-2005 10:03:16.05 - FSA : Adding Control Protocol c223 (CHAP) to control protocol chain. 05-24-2005 10:03:16.06 - FSA : Adding Control Protocol c021 (LCP) to control protocol chain. 05-24-2005 10:03:16.06 - LCP : Callback negotiation enabled. 05-24-2005 10:03:16.06 - LCP : Layer started. 05-24-2005 10:03:16.06 - PPP : Transmitting Control Packet of length: 25 05-24-2005 10:03:16.06 - Data 0000: c0 21 01 01 00 17 02 06 | .!..... 05-24-2005 10:03:16.06 - Data 0008: 00 0a 00 00 05 06 00 01 | ........ 05-24-2005 10:03:16.06 - Data 0010: 3a 91 07 02 08 02 0d 03 | :....... 05-24-2005 10:03:16.06 - Data 0018: 06 00 00 00 00 00 00 00 | ........ C0 21 01 01 00 17 = TRANSMIT configure request id#01 02 06 00 0A 00 00 type 02 (??->ACCM) =000A0000 05 06 00 01 3A 91 type 05 (magic no.)=00013A91 07 02 type 07 (proto field compression) 08 02 type 08 (addr + control field compression) 0D 03 06 type 0D (??->callback control option??) 05-24-2005 10:03:16.25 - PPP : Received Control Packet of length: 27 05-24-2005 10:03:16.25 - Data 0000: c0 21 01 99 00 19 02 06 | .!..... 05-24-2005 10:03:16.25 - Data 0008: 00 0a 00 00 03 05 c2 23 | .......# 05-24-2005 10:03:16.25 - Data 0010: 05 05 06 3b ef 1b ae 07 | ...;... 05-24-2005 10:03:16.25 - Data 0018: 02 08 02 00 00 00 00 00 | ........ C0 21 01 99 00 19 = RECEIVE configure request id#99 02 06 00 0A 00 00 type 02 (??->ACCM) =000A0000 03 05 C2 23 05 type 03 (auth) =C223 (chap) 05 (??) 05 06 3B EF 1B AE type 05 (magic no.)=3BEF1BAE 07 02 type 07 (proto field compression) 08 02 type 08 (addr + control field compression) [ 00 00 00 00 00 ] PAD 05-24-2005 10:03:16.25 - LCP : Received and accepted ACCM of a0000. 05-24-2005 10:03:16.25 - LCP : Received and accepted authentication protocol c223 (CHAP). 05-24-2005 10:03:16.25 - LCP : Received and accepted magic number 3bef1bae. 05-24-2005 10:03:16.25 - LCP : Received and accepted protocol field compression option. 05-24-2005 10:03:16.25 - LCP : Received and accepted address+control field compression option. 05-24-2005 10:03:16.25 - PPP : Transmitting Control Packet of length: 27 C0 21 02 99 00 19 = TRANSMIT configure ack id#99 02 06 00 0A 00 00 (ack above request #99) 03 05 C2 23 05 05 06 3B EF 1B AE 07 02 08 02 05-24-2005 10:03:16.25 - Data 0000: c0 21 02 99 00 19 02 06 | .!..... 05-24-2005 10:03:16.25 - Data 0008: 00 0a 00 00 03 05 c2 23 | .......# 05-24-2005 10:03:16.25 - Data 0010: 05 05 06 3b ef 1b ae 07 | ...;... 05-24-2005 10:03:16.25 - Data 0018: 02 08 02 00 00 00 00 00 | ........ 05-24-2005 10:03:16.25 - PPP : Received Control Packet of length: 9 05-24-2005 10:03:16.25 - Data 0000: c0 21 04 01 00 07 0d 03 | .!...... 05-24-2005 10:03:16.25 - Data 0008: 06 00 00 00 00 00 00 00 | ........ C0 21 04 01 00 07 = RECEIVE configure reject id#01 0D 03 06 type 0D (??) 05-24-2005 10:03:16.25 - LCP : Received configure reject for callback control protocol option. 05-24-2005 10:03:16.25 - PPP : Transmitting Control Packet of length: 22 05-24-2005 10:03:16.25 - Data 0000: c0 21 01 02 00 14 02 06 | .!...... 05-24-2005 10:03:16.25 - Data 0008: 00 0a 00 00 05 06 00 01 | ........ 05-24-2005 10:03:16.25 - Data 0010: 3a 91 07 02 08 02 00 00 | :....... C0 21 01 02 00 14 = TRANSMIT configure request id#02 02 06 00 0A 00 00 type 02 (??->ACCM) = 000A0000 05 06 00 01 3A 91 type 05 (magic no.)= 00013A91 07 02 type 07 (proto field compression) 08 02 type 08 (address + control field compression) 05-24-2005 10:03:16.39 - PPP : Received Control Packet of length: 22 05-24-2005 10:03:16.39 - Data 0000: c0 21 02 02 00 14 02 06 | .!...... 05-24-2005 10:03:16.39 - Data 0008: 00 0a 00 00 05 06 00 01 | ........ 05-24-2005 10:03:16.39 - Data 0010: 3a 91 07 02 08 02 00 00 | :....... C0 21 02 02 00 14 = RECEIVE configure ack id#02 02 06 00 0A 00 00 (ack above request id#02) 05 06 00 01 3A 91 07 02 08 02 05-24-2005 10:03:16.39 - LCP : Layer up. 05-24-2005 10:03:16.39 - CHAP : Layer started. bestwishesfrom laura > >-- Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13" >PPP-Q&A links, downloads: http://ckite.no-ip.net/ >/* In my book, the first poster to resort to personal abuse in a Usenet > debate loses by default. - Rod Smith */ > -- echo (E-Mail Removed) |sed 's/\(.\)\(.\)/\2\1/g' |
|
|
|
|
|||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
laura fairhead <(E-Mail Removed)> wrote:
> On Fri, 27 May 2005 12:16:01 -0500, Clifford Kite <(E-Mail Removed)> > wrote: >>laura fairhead <(E-Mail Removed)> wrote: >> >>> Hi ppl, >> >>> I am experiencing a problem with the PPP setup >>> connecting to my (dial-up) service/connection >>> provider (btinternet). It has worked fine for >>> years but recently the internet connection under >>> Linux fails (Windows 98 still functions). >> >>Dual boot or two different computers? > Hi Clifford Back at you!  > This is just one comp with one modem, dual linux/win98 That rules out hardware. >>> It does actually connect but I don't receive >>> any packets - well an ifconfig shows the ppp >>> device as having received those packets but >>> most of them are getting a "frame" error. >>> I wonder if it has something to do with >>> the MRU, presently I don't understand what >>> a frame error is. >> >>I suspect it means that the AHDLC frame used by PPP has a CRC error. > I thought it could be something like the MRU negociation being > bugged linux talking and windoze just leaving it with the default > or something But that doesn't seem to be the case.... Maybe it is one of > the compression protocols (ACP, PCP) or something lower level > than LCP (is that what you mean by AHDLC I'm not familiar with > the term ?) Asynchronous High-Level Data Link Control. See RFC 1662. >>> Well I would appreciate any help, I have >>> started reading RFC1661 on PPP and eventually >>> maybe work out what is going on but it would >>> be great if someone with more experience >>> could advise me. >> >>If the ISP has changed it's PPP implementation or DCE and the new >><whichever> has a bug or configuration error then reading an RFC >>won't help. > I'd been putting off reading it for a long time, the subject > really fascinates me ! James Carlson's book "PPP Design, Implementation, and Debugging" would be my recommendation - if you're _really_ fascinated. >>Add the pppd option debug and the chat option -v, if chat is used >>to make the serial connection. Then make a PPP connection and >>after it's terminated post an exact copy, including timestamps, >>of /var/log/ppp.log so we can see what happens during PPP link >>negotiations. > Okay I did this plus I decoded the windoze log (at least just the > LCP stage maybe its not that ) >>> I suppose BT/Yahoo changed something in the >>> PPP setup and it just happens that 98 >>> is happy with it and Linux is not >> >>It is likely BT/Yahoo changed something. The alternative would seem >>to be that something has gone bad on the Linux host, such as kernel >>or pppd corruption, a modem or serial device problem, ect. > Okay here goes ...> May 27 19:59:28 bell486 pppd[474]: Perms of /dev/ttyS1 are ok, no 'mesg > n' neccesary. > May 27 19:59:29 bell486 chat[475]: abort on (NO CARRIER) > May 27 19:59:29 bell486 chat[475]: abort on (NO DIALTONE) > May 27 19:59:29 bell486 chat[475]: abort on (BUSY) > May 27 19:59:29 bell486 chat[475]: send (++AT&F^M) > May 27 19:59:29 bell486 chat[475]: expect (OK) > May 27 19:59:29 bell486 chat[475]: ++AT&F^M^M > May 27 19:59:29 bell486 chat[475]: OK > May 27 19:59:29 bell486 chat[475]: -- got it > May 27 19:59:29 bell486 chat[475]: send (ATM0^M) > May 27 19:59:29 bell486 chat[475]: expect (OK) > May 27 19:59:29 bell486 chat[475]: ^M > May 27 19:59:29 bell486 chat[475]: ATM0^M^M > May 27 19:59:29 bell486 chat[475]: OK > May 27 19:59:29 bell486 chat[475]: -- got it > May 27 19:59:29 bell486 chat[475]: send (ATDTxxxxxxxxxxxx^M) > May 27 19:59:30 bell486 chat[475]: timeout set to 600 seconds > May 27 19:59:30 bell486 chat[475]: expect (CONNECT 115200) > May 27 19:59:45 bell486 chat[475]: ATDTxxxxxxxxxxx^M^M > May 27 19:59:45 bell486 chat[475]: CARRIER 33600^M > May 27 19:59:46 bell486 chat[475]: ^M > May 27 19:59:46 bell486 chat[475]: PROTOCOL: LAP-M^M > May 27 19:59:46 bell486 chat[475]: ^M > May 27 19:59:46 bell486 chat[475]: CONNECT 115200 > May 27 19:59:46 bell486 chat[475]: -- got it > May 27 19:59:46 bell486 pppd[474]: Serial connection established. > May 27 19:59:46 bell486 pppd[474]: Using interface ppp0 > May 27 19:59:46 bell486 pppd[474]: Connect: ppp0 <--> /dev/ttyS1 > May 27 19:59:47 bell486 pppd[474]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> > <magic 0xd8d563ff> <pcomp> <accomp>] > May 27 19:59:47 bell486 pppd[474]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> > <magic 0xd8d563ff> <pcomp> <accomp>] > May 27 19:59:49 bell486 pppd[474]: rcvd [LCP ConfReq id=0x34 <asyncmap > 0xa0000> <auth chap MD5> <magic 0x4d848d69> <pcomp> <accomp>] I'd try adding the pppd option `asyncmap a0000' in imitation of the peer. Probably not the problem here, but it is know to be a problem in some instances. It won't hurt to try it. > May 27 19:59:49 bell486 pppd[474]: sent [LCP ConfAck id=0x34 <asyncmap 0xa0000> <auth chap MD5> <magic 0x4d848d69> <pcomp> <accomp>] > May 27 19:59:49 bell486 pppd[474]: sent [LCP EchoReq id=0x0 magic=0xd8d563ff] > May 27 19:59:50 bell486 pppd[474]: rcvd [CHAP Challenge id=0x2f xxxxxxxxxxxxxxxxx ] > May 27 19:59:50 bell486 pppd[474]: sent [CHAP Response id=0x2f xxxxxxxxxxxxxxxx ] > May 27 19:59:50 bell486 pppd[474]: rcvd [LCP EchoRep id=0x0 magic=0x4d848d69] > May 27 19:59:50 bell486 pppd[474]: rcvd [CHAP Success id=0x2f ""] > May 27 19:59:50 bell486 pppd[474]: sent [IPCP ConfReq id=0x1 <addr 192.168.xxxxx> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>] Adding the pppd option noipdefault would prevent the local (Ethernet?) interface IP address from being requested as the local PPP interface IP address. Not the problem. > May 27 19:59:50 bell486 pppd[474]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] Requesting any CCP is useless here. > May 27 19:59:50 bell486 pppd[474]: rcvd [IPCP ConfReq id=0x79 <addr 212.140.212.63>] > May 27 19:59:50 bell486 pppd[474]: sent [IPCP ConfAck id=0x79 <addr 212.140.212.63>] > May 27 19:59:50 bell486 pppd[474]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>] Adding the pppd option novj would eliminate the IPCP Configure-Reject for VJ header compression. Not the problem, although the rejection of VJ compression doesn't say much for the ISP PPP implementation. > May 27 19:59:50 bell486 pppd[474]: sent [IPCP ConfReq id=0x2 <addr 192.168.xxxxx> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>] > May 27 19:59:50 bell486 pppd[474]: rcvd [LCP ProtRej id=0x17 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f] Adding the pppd option noccp would prevent the CCP request and so this CCP Protocol-Reject. But it's not the problem. > May 27 19:59:50 bell486 pppd[474]: rcvd [IPCP ConfNak id=0x2 <addr 81.131.41.46> <ms-dns1 213.120.62.97> <ms-dns3 213.120.62.104>] > May 27 19:59:50 bell486 pppd[474]: sent [IPCP ConfReq id=0x3 <addr 81.131.41.46> <ms-dns1 213.120.62.97> <ms-dns3 213.120.62.104>] > May 27 19:59:59 bell486 last message repeated 3 times > May 27 20:00:01 bell486 pppd[474]: rcvd [IPCP ConfReq id=0x7a <addr 212.140.212.63>] > May 27 20:00:01 bell486 pppd[474]: sent [IPCP ConfAck id=0x7a <addr 212.140.212.63>] > May 27 20:00:01 bell486 pppd[474]: rcvd [IPCP ConfAck id=0x3 <addr 81.131.41.46> <ms-dns1 213.120.62.97> <ms-dns3 213.120.62.104>] > May 27 20:00:01 bell486 pppd[474]: local IP address 81.131.41.46 > May 27 20:00:01 bell486 pppd[474]: remote IP address 212.140.212.63 > May 27 20:00:01 bell486 pppd[474]: primary DNS address 213.120.62.97 > May 27 20:00:01 bell486 pppd[474]: secondary DNS address 213.120.62.104 > May 27 20:00:01 bell486 pppd[474]: Script /etc/ppp/ip-up started (pid 478) > May 27 20:00:01 bell486 pppd[474]: Script /etc/ppp/ip-up finished (pid 478), status = 0x0 > May 27 20:00:19 bell486 pppd[474]: sent [LCP EchoReq id=0x1 magic=0xd8d563ff] > May 27 20:00:20 bell486 pppd[474]: rcvd [LCP EchoRep id=0x1 magic=0x4d848d69] > May 27 20:00:49 bell486 pppd[474]: sent [LCP EchoReq id=0x2 magic=0xd8d563ff] > May 27 20:00:50 bell486 pppd[474]: rcvd [LCP EchoRep id=0x2 magic=0x4d848d69] > Threebits in that worried me, the LAP, CARRIER thing at the start and the > repeated NAK thing in the middle and also that Protocol reject thing (could > the protocol compression be to blame?) ... I don't know about it though > I also ran ifconfig after the IP came up and it reported about 4 frame > errors which seemed to related directly to the echo req/rep LAP-M is error correction protocol for V.42 modem negotiation. I think. The Protocol-Reject is for the PPP software Compression Control Protocol (CCP), seldom available at ISPs. Not the problem. The errors may well be related to Echo-Request, Echo-Reply. You can remove the pppd option `lcp-echo-interval 30' and see if the frame errors go away. You'll likely also need to remove `lcp-echo-failure n' if it is present. > I decoded the windows PPP log, the rfc didn't have it but > I suppose ACCM in the below is async map and the LCP requests > CHAP (C223) with MD5 (the 5). ACCM = Asynchronous Control Character Map which, as you guessed, is what the pppd asyncmap option requests. CHAP MD5 is correct. > 05-24-2005 10:03:16.05 - Microsoft Dial Up Adapter log opened. > 05-24-2005 10:03:16.05 - Server type is PPP (Point to Point Protocol). > 05-24-2005 10:03:16.05 - FSA : Software compression disabled. ^^^^^^^^^^^^^^^^^^^^ CCP > 05-24-2005 10:03:16.05 - FSA : Protocol not bound - skipping control protocol 803f (NBFCP). > 05-24-2005 10:03:16.05 - FSA : Adding Control Protocol 8021 (IPCP) to control protocol chain. > 05-24-2005 10:03:16.05 - FSA : Protocol not bound - skipping control protocol 802b (IPXCP). > 05-24-2005 10:03:16.05 - FSA : Adding Control Protocol c029 (CallbackCP) to control protocol chain. > 05-24-2005 10:03:16.05 - FSA : Adding Control Protocol c027 (no description) to control protocol chain. > 05-24-2005 10:03:16.05 - FSA : Adding Control Protocol c023 (PAP) to control protocol chain. > 05-24-2005 10:03:16.05 - FSA : Adding Control Protocol c223 (CHAP) to control protocol chain. > 05-24-2005 10:03:16.06 - FSA : Adding Control Protocol c021 (LCP) to control protocol chain. > 05-24-2005 10:03:16.06 - LCP : Callback negotiation enabled. > 05-24-2005 10:03:16.06 - LCP : Layer started. > 05-24-2005 10:03:16.06 - PPP : Transmitting Control Packet of length: 25 > 05-24-2005 10:03:16.06 - Data 0000: c0 21 01 01 00 17 02 06 | .!..... > 05-24-2005 10:03:16.06 - Data 0008: 00 0a 00 00 05 06 00 01 | ........ > 05-24-2005 10:03:16.06 - Data 0010: 3a 91 07 02 08 02 0d 03 | :....... > 05-24-2005 10:03:16.06 - Data 0018: 06 00 00 00 00 00 00 00 | ........ > C0 21 01 01 00 17 = TRANSMIT configure request id#01 > 02 06 00 0A 00 00 type 02 (??->ACCM) =000A0000 > 05 06 00 01 3A 91 type 05 (magic no.)=00013A91 > 07 02 type 07 (proto field compression) > 08 02 type 08 (addr + control field compression) > 0D 03 06 type 0D (??->callback control option??) Yes. > 05-24-2005 10:03:16.25 - PPP : Received Control Packet of length: 27 > 05-24-2005 10:03:16.25 - Data 0000: c0 21 01 99 00 19 02 06 | .!..... > 05-24-2005 10:03:16.25 - Data 0008: 00 0a 00 00 03 05 c2 23 | .......# > 05-24-2005 10:03:16.25 - Data 0010: 05 05 06 3b ef 1b ae 07 | ...;... > 05-24-2005 10:03:16.25 - Data 0018: 02 08 02 00 00 00 00 00 | ........ > C0 21 01 99 00 19 = RECEIVE configure request id#99 > 02 06 00 0A 00 00 type 02 (??->ACCM) =000A0000 > 03 05 C2 23 05 type 03 (auth) =C223 (chap) 05 (??) > 05 06 3B EF 1B AE type 05 (magic no.)=3BEF1BAE > 07 02 type 07 (proto field compression) > 08 02 type 08 (addr + control field compression) > [ 00 00 00 00 00 ] PAD > 05-24-2005 10:03:16.25 - LCP : Received and accepted ACCM of a0000. > 05-24-2005 10:03:16.25 - LCP : Received and accepted authentication protocol c223 (CHAP). > 05-24-2005 10:03:16.25 - LCP : Received and accepted magic number 3bef1bae. > 05-24-2005 10:03:16.25 - LCP : Received and accepted protocol field compression option. > 05-24-2005 10:03:16.25 - LCP : Received and accepted address+control field compression option. > 05-24-2005 10:03:16.25 - PPP : Transmitting Control Packet of length: 27 > C0 21 02 99 00 19 = TRANSMIT configure ack id#99 > 02 06 00 0A 00 00 (ack above request #99) > 03 05 C2 23 05 > 05 06 3B EF 1B AE > 07 02 > 08 02 > 05-24-2005 10:03:16.25 - Data 0000: c0 21 02 99 00 19 02 06 | .!..... > 05-24-2005 10:03:16.25 - Data 0008: 00 0a 00 00 03 05 c2 23 | .......# > 05-24-2005 10:03:16.25 - Data 0010: 05 05 06 3b ef 1b ae 07 | ...;... > 05-24-2005 10:03:16.25 - Data 0018: 02 08 02 00 00 00 00 00 | ........ > 05-24-2005 10:03:16.25 - PPP : Received Control Packet of length: 9 > 05-24-2005 10:03:16.25 - Data 0000: c0 21 04 01 00 07 0d 03 | .!...... > 05-24-2005 10:03:16.25 - Data 0008: 06 00 00 00 00 00 00 00 | ........ > C0 21 04 01 00 07 = RECEIVE configure reject id#01 > 0D 03 06 type 0D (??) Call-back as defined by RFC 1663, rarely used. > 05-24-2005 10:03:16.25 - LCP : Received configure reject for callback control protocol option. > 05-24-2005 10:03:16.25 - PPP : Transmitting Control Packet of length: 22 > 05-24-2005 10:03:16.25 - Data 0000: c0 21 01 02 00 14 02 06 | .!...... > 05-24-2005 10:03:16.25 - Data 0008: 00 0a 00 00 05 06 00 01 | ........ > 05-24-2005 10:03:16.25 - Data 0010: 3a 91 07 02 08 02 00 00 | :....... > C0 21 01 02 00 14 = TRANSMIT configure request id#02 > 02 06 00 0A 00 00 type 02 (??->ACCM) = 000A0000 > 05 06 00 01 3A 91 type 05 (magic no.)= 00013A91 > 07 02 type 07 (proto field compression) > 08 02 type 08 (address + control field compression) > 05-24-2005 10:03:16.39 - PPP : Received Control Packet of length: 22 > 05-24-2005 10:03:16.39 - Data 0000: c0 21 02 02 00 14 02 06 | .!...... > 05-24-2005 10:03:16.39 - Data 0008: 00 0a 00 00 05 06 00 01 | ........ > 05-24-2005 10:03:16.39 - Data 0010: 3a 91 07 02 08 02 00 00 | :....... > C0 21 02 02 00 14 = RECEIVE configure ack id#02 > 02 06 00 0A 00 00 (ack above request id#02) > 05 06 00 01 3A 91 > 07 02 > 08 02 > > 05-24-2005 10:03:16.39 - LCP : Layer up. > 05-24-2005 10:03:16.39 - CHAP : Layer started. No IPCP negotiation? (IP addresses) Well, it's doubtful that anything would turn up there anyway. If you've changed the kernel and the modem is a winmodem or relative thereof then that could mess things up - and with that I'm out of suggestions. -- Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13" PPP-Q&A links, downloads: http://ckite.no-ip.net/ |
|
|
|
|
|||
|
Guest
Posts: n/a
|
On Fri, 27 May 2005 19:54:51 -0500, Clifford Kite <(E-Mail Removed)> wrote:
hiya, >>>If the ISP has changed it's PPP implementation or DCE and the new >>><whichever> has a bug or configuration error then reading an RFC >>>won't help. > >> I'd been putting off reading it for a long time, the subject >> really fascinates me ! > >James Carlson's book "PPP Design, Implementation, and Debugging" >would be my recommendation - if you're _really_ fascinated. k I'll check it out :-) > >>>Add the pppd option debug and the chat option -v, if chat is used >>>to make the serial connection. Then make a PPP connection and >>>after it's terminated post an exact copy, including timestamps, >>>of /var/log/ppp.log so we can see what happens during PPP link >>>negotiations. > >> Okay I did this plus I decoded the windoze log (at least just the >> LCP stage maybe its not that ) > >>>> I suppose BT/Yahoo changed something in the >>>> PPP setup and it just happens that 98 >>>> is happy with it and Linux is not >>> >>>It is likely BT/Yahoo changed something. The alternative would seem >>>to be that something has gone bad on the Linux host, such as kernel >>>or pppd corruption, a modem or serial device problem, ect. It seems to be something with the modem/serial device. > >> Okay here goes ...> > >> May 27 19:59:28 bell486 pppd[474]: Perms of /dev/ttyS1 are ok, no 'mesg >> n' neccesary. >> May 27 19:59:29 bell486 chat[475]: abort on (NO CARRIER) >> May 27 19:59:29 bell486 chat[475]: abort on (NO DIALTONE) >> May 27 19:59:29 bell486 chat[475]: abort on (BUSY) >> May 27 19:59:29 bell486 chat[475]: send (++AT&F^M) >> May 27 19:59:29 bell486 chat[475]: expect (OK) >> May 27 19:59:29 bell486 chat[475]: ++AT&F^M^M >> May 27 19:59:29 bell486 chat[475]: OK >> May 27 19:59:29 bell486 chat[475]: -- got it >-- >Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13" >PPP-Q&A links, downloads: http://ckite.no-ip.net/ I tried all the options you mentionned but there was no improvement I also tried another dial-up account (possibly routed to the same call centre though because it was still BT) and no joy there either. As you mentionned the kernel I noticed there was a "kdebug" option in pppd so I put that on and now see that the kernel/ppp is dropping frames all over the place because of "bad fcs" - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~ May 29 01:10:42 bell486 kernel: CSLIP: code copyright 1989 Regents of the University of California May 29 01:10:42 bell486 kernel: PPP: version 2.3.7 (demand dialling) May 29 01:10:42 bell486 kernel: PPP line discipline registered. May 29 01:10:42 bell486 kernel: registered device ppp0 May 29 01:10:42 bell486 pppd[472]: pppd 2.3.11 started by root, uid 0 May 29 01:10:42 bell486 pppd[472]: Perms of /dev/ttyS1 are ok, no 'mesg n' neccesary. May 29 01:10:43 bell486 chat[474]: abort on (NO CARRIER) May 29 01:10:43 bell486 chat[474]: abort on (NO DIALTONE) : : May 29 01:11:00 bell486 chat[474]: PROTOCOL: LAP-M^M May 29 01:11:00 bell486 chat[474]: ^M May 29 01:11:00 bell486 chat[474]: CONNECT 115200 May 29 01:11:00 bell486 chat[474]: -- got it May 29 01:11:00 bell486 pppd[472]: Serial connection established. May 29 01:11:00 bell486 kernel: ppp_ioctl: set dbg flags to 10000 May 29 01:11:00 bell486 kernel: ppp_ioctl: set flags to 10000 May 29 01:11:00 bell486 pppd[472]: Using interface ppp0 May 29 01:11:00 bell486 pppd[472]: Connect: ppp0 <--> /dev/ttyS1 May 29 01:11:00 bell486 kernel: ppp_tty_ioctl: set xasyncmap May 29 01:11:00 bell486 kernel: ppp_tty_ioctl: set xmit asyncmap ffffffff May 29 01:11:00 bell486 kernel: ppp_ioctl: set flags to 10000 May 29 01:11:00 bell486 kernel: ppp_ioctl: set mru to 5dc May 29 01:11:00 bell486 kernel: ppp_tty_ioctl: set rcv asyncmap ffffffff May 29 01:11:01 bell486 pppd[472]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xc807b34b> <pcomp> <accomp>] May 29 01:11:01 bell486 kernel: ppp: tossing frame (e0) May 29 01:11:02 bell486 kernel: ppp: frame with bad fcs, length = 19 May 29 01:11:02 bell486 kernel: ppp: bad frame, count = 19 May 29 01:11:02 bell486 kernel: FF 03 00 14 00 00 00 05 ........ May 29 01:11:02 bell486 kernel: 06 C8 07 B3 4B 07 02 08 ....K... May 29 01:11:02 bell486 kernel: 02 B2 74 ..t May 29 01:11:02 bell486 pppd[472]: rcvd [LCP ConfReq id=0x47 <asyncmap 0xa0000> <auth chap MD5> <magic 0x53c7eada> <pcomp> <accomp>] May 29 01:11:02 bell486 pppd[472]: sent [LCP ConfAck id=0x47 <asyncmap 0xa0000> <auth chap MD5> <magic 0x53c7eada> <pcomp> <accomp>] : : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~ So I thought I'd just try 'chat'ing with the modem without trying to make a connection and it seems to be losing characters there; May 30 15:56:59 bell486 pppd[485]: pppd 2.3.11 started by root, uid 0 May 30 15:56:59 bell486 pppd[485]: Perms of /dev/ttyS1 are ok, no 'mesg n' neccesary. May 30 15:57:00 bell486 chat[486]: abort on (NO CARRIER) May 30 15:57:00 bell486 chat[486]: abort on (NO DIALTONE) May 30 15:57:00 bell486 chat[486]: abort on (BUSY) May 30 15:57:00 bell486 chat[486]: send (++AT^M) May 30 15:57:00 bell486 chat[486]: expect (OK) May 30 15:57:00 bell486 chat[486]: ^M May 30 15:57:00 bell486 chat[486]: OK May 30 15:57:00 bell486 chat[486]: -- got it May 30 15:57:00 bell486 chat[486]: send (AT &F E0 &C1 &D2 V1 S0=0^M) May 30 15:57:00 bell486 chat[486]: expect (OK) May 30 15:57:00 bell486 chat[486]: ^M May 30 15:57:00 bell486 chat[486]: OK May 30 15:57:00 bell486 chat[486]: -- got it May 30 15:57:00 bell486 chat[486]: send (ATS7=60L0M1&K3N1X4^M) May 30 15:57:01 bell486 chat[486]: expect (OK) May 30 15:57:01 bell486 chat[486]: ^M May 30 15:57:01 bell486 chat[486]: K^M May 30 15:57:46 bell486 chat[486]: alarm May 30 15:57:46 bell486 chat[486]: Failed May 30 15:57:46 bell486 pppd[485]: Connect script failed May 30 15:57:54 bell486 pppd[485]: Terminating on signal 2. May 30 15:57:54 bell486 pppd[485]: Exit. Also I have noticed on occasion during a normal connection session seeing "CON115200" where obviously a few characters were dropped receiving from the modem.. bestwishesfrom laura -- echo (E-Mail Removed) |sed 's/\(.\)\(.\)/\2\1/g' |
|
|
|
|
|||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
laura fairhead <(E-Mail Removed)> wrote:
> I've had problems similar to this before now that I think of > it - booting between the 2 OS's.... Anyway I just tried an > experiment setting the baud_base down to 57600. Now the ISP > will only connect at 19200 but the thing is it is working > fine (but slow) like this. Then I reboot the machine and into You're lucky to get that. Is 19200 in the CARRIER or the CONNECT message? If it is in the CARRIER message then I agree with Bill Unruh that it is strange. If it is in the CONNECT message that your logs have shown, which seems likely to me, then you must have set the pppd speed option to 19200. > Windoze and it doesn't connect properly anymore so it seemed > to me this is because of the card itself (I'm using a serial > card, old 16450) being programmed by Linux and not unprogrammed ^^^^^ This has to be why frames were being corrupted. A 16450 UART uses a 1-byte buffer and no flow control. A 16450 can't handle today's high speed modem connections at the usual serial device's 115200 bps default base baud rate. Setting the baud base rate lower than 115200 bps with setserial is accomplished by configuring the serial device so that the default rate is effectively divided by an integer. There is then more time available for the serial port interrupts used to move a byte into and/or out of the UART buffer. So a byte in the buffer can be removed before being overwritten by the next byte moved into the buffer. If my guess that the pppd speed was set to 19200 is correct then I'd suggest you try resetting the base_baud rate to 115200, set the pppd speed to 38400 (see below), and add the send-expect AT+MS=V32,,14400,,14400 OK to chat modem initialization. No guarantee that the initialization will work since I really don't know how commonly the AT+MS= syntax is used by modem manufacturers. But if it works then the PPP link should work better. > by Windows. Sure enough, a full power-cycle reset and Windows > started working again (not the modem I tried that first) Because the card is the problem, not the modem. > It's nice to be able to connect at all under Linux now but > 19200 is not really happening if I want to download anything > so it would be nice to get to the root of the problem. Is Windows really faster? It's hard to believe that Windows could work any magic to download faster, given the same modem - but I don't know your criterion for saying it is "working fine." The Serial-HOWTO implies a 14400 bps modem connection and a PPP implementation to serial device _file_ speed of 38400 bps (set by the pppd speed option) would be about right for things to work well, given a 16450 UART. The actual download speed for a compressed file should be close to the modem connection speed minus data speed degradation caused by the presence of various overhead bytes. These comments are derived from the setserial man pages, the Serial-HOWTO, and my own experience. If I've got anything wrong then I expect someone will let me know. -- Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13" PPP-Q&A links, downloads: http://ckite.no-ip.net/ /* Speak softly and carry a +6 two-handed sword. */ |
|
|
|
|
|||
|
|
| |
|
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Strange problem: no problem with Linux, when I boot windows 2K network is down... | Santa | Linux Networking | 11 | 11-29-2004 06:46 AM |
Linear Mode
