another ppp slow modem question.... - PPP

This is a discussion on another ppp slow modem question.... - PPP ; I am connecting via kppp, according to kppp my connection rates differ between 14000 to 26000 (rounded down) and sometimes I get transfer rates of 100 to 300 bps. I have screwed around with setserial and stty, setting the speed ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: another ppp slow modem question....

  1. another ppp slow modem question....

    I am connecting via kppp, according to kppp my connection rates differ
    between 14000 to 26000 (rounded down) and sometimes I get transfer
    rates of 100 to 300 bps. I have screwed around with setserial and
    stty, setting the speed to various optons, via `stty [device] N` or
    `setserial [device] sph_high etc... but no luck. I have also adjusted
    the mru option to the recomended (man page) value of 296 for slow
    links, but it ends back at 1500, which I guess is still ok. I just
    cant figure out what the deal is. I noticed in the log that it is
    sending mrru values, which to my understanding is for shared links
    -which mine is not. Maybe this is why i'm connected so slow, because
    of an assumed shared link? Or is this always used? Im at a loss of
    ideas....


    I also sent a CPP request but never got anything back accept a
    ProtRej, but this had a different id. Is that ProtRej for the CPP??

    Thanks for any help

    Jul 19 02:05:19 localhost pppd[8389]: using channel 7
    Jul 19 02:05:19 localhost pppd[8389]: Using interface ppp0
    Jul 19 02:05:19 localhost pppd[8389]: Connect: ppp0 <--> /dev/536ep
    Jul 19 02:05:19 localhost pppd[8389]: sent [LCP ConfReq id=0x1 296> ]
    Jul 19 02:05:19 localhost pppd[8389]: rcvd [LCP ConfReq id=0x1 1500>
    ]
    Jul 19 02:05:19 localhost pppd[8389]: sent [LCP ConfRej id=0x1 1506>]
    Jul 19 02:05:19 localhost pppd[8389]: rcvd [LCP ConfNak id=0x1 1500>]
    Jul 19 02:05:19 localhost pppd[8389]: sent [LCP ConfReq id=0x2
    ]
    Jul 19 02:05:20 localhost pppd[8389]: rcvd [LCP ConfReq id=0x2 1500>
    ]
    Jul 19 02:05:20 localhost pppd[8389]: sent [LCP ConfAck id=0x2 1500>
    ]
    Jul 19 02:05:20 localhost pppd[8389]: rcvd [LCP ConfAck id=0x2
    ]
    Jul 19 02:05:20 localhost pppd[8389]: sent [PAP AuthReq id=0x1
    user="xxx" password=]
    Jul 19 02:05:23 localhost pppd[8389]: sent [PAP AuthReq id=0x2
    user="xxx" password=]
    Jul 19 02:05:26 localhost pppd[8389]: sent [PAP AuthReq id=0x3
    user="xxx" password=]
    Jul 19 02:05:29 localhost pppd[8389]: sent [PAP AuthReq id=0x4
    user="xxx" password=]
    Jul 19 02:05:32 localhost pppd[8389]: sent [PAP AuthReq id=0x5
    user="xxx" password=]
    Jul 19 02:05:32 localhost pppd[8389]: rcvd [PAP AuthAck id=0x5 ""]
    Jul 19 02:05:32 localhost pppd[8389]: sent [IPCP ConfReq id=0x1 0.0.0.0> ]
    Jul 19 02:05:32 localhost pppd[8389]: sent [CCP ConfReq id=0x1
    ]
    Jul 19 02:05:32 localhost pppd[8389]: rcvd [LCP ProtRej id=0x2 80 fd
    01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
    Jul 19 02:05:32 localhost pppd[8389]: rcvd [IPCP ConfRej id=0x1
    ]
    Jul 19 02:05:32 localhost pppd[8389]: sent [IPCP ConfReq id=0x2 0.0.0.0> ]
    Jul 19 02:05:32 localhost pppd[8389]: rcvd [IPCP ConfReq id=0x1 121.67.0.54>]
    Jul 19 02:05:32 localhost pppd[8389]: sent [IPCP ConfAck id=0x1 121.67.0.54>]
    Jul 19 02:05:32 localhost pppd[8389]: rcvd [IPCP ConfNak id=0x2 121.64.12.45> ]
    Jul 19 02:05:32 localhost pppd[8389]: sent [IPCP ConfReq id=0x3 121.64.12.45> ]
    Jul 19 02:05:32 localhost pppd[8389]: rcvd [IPCP ConfAck id=0x3 12.64.12.45> ]
    Jul 19 02:05:32 localhost pppd[8389]: local IP address 121.64.12.45
    Jul 19 02:05:32 localhost pppd[8389]: remote IP address 121.67.0.54
    Jul 19 02:05:32 localhost pppd[8389]: primary DNS address
    214.127.160.1
    Jul 19 02:05:32 localhost pppd[8389]: secondary DNS address
    121.102.240.1
    Jul 19 02:05:32 localhost pppd[8389]: Script /etc/ppp/ip-up started
    (pid 8405)
    Jul 19 02:05:33 localhost pppd[8389]: Script /etc/ppp/ip-up finished
    (pid 8405), status = 0x0

  2. Re: another ppp slow modem question....

    dutone@hotmail.com (dutone) writes:
    > I am connecting via kppp, according to kppp my connection rates differ
    > between 14000 to 26000 (rounded down)


    Just to be clear: pppd has nothing to do with this part. It's the
    telephone line quality between your site and the dial-in server, plus
    the capabilities and robustness of the modem you're using, that
    generally determine the modem's communication rate.

    > and sometimes I get transfer
    > rates of 100 to 300 bps.


    That's awful. Something is terribly wrong with the configuration.

    > `setserial [device] sph_high etc... but no luck. I have also adjusted
    > the mru option to the recomended (man page) value of 296 for slow
    > links, but it ends back at 1500, which I guess is still ok.


    Yes; it's ok. In general, you probably don't want anything less than
    1500 for any modern connection. That man page comment greatly
    predates modern times. ;-}

    > I just
    > cant figure out what the deal is. I noticed in the log that it is
    > sending mrru values, which to my understanding is for shared links
    > -which mine is not. Maybe this is why i'm connected so slow, because
    > of an assumed shared link? Or is this always used? Im at a loss of
    > ideas....


    No, it has nothing to do with MRRU, which is used for Multilink PPP,
    not "shared links" (whatever those might be).

    > I also sent a CPP request but never got anything back accept a
    > ProtRej, but this had a different id. Is that ProtRej for the CPP??


    Yes. This is perfectly normal protocol negotiation. If it bothers
    you, you can add "noccp" to your configuration. The peer obviously
    doesn't support it anyway.

    > Jul 19 02:05:19 localhost pppd[8389]: rcvd [LCP ConfReq id=0x1 > 1500>
    > ]


    Here's the first warning sign that the peer is junk: he's sending an
    MRU of 1500. That's the default, and there's never a reason to add a
    configuration option specifying the default.

    The peer does offer Multilink PPP service.

    > Jul 19 02:05:19 localhost pppd[8389]: sent [LCP ConfRej id=0x1 > 1506>]


    Your side correctly rejects MRRU. This disables Multilink PPP.

    > Jul 19 02:05:19 localhost pppd[8389]: rcvd [LCP ConfNak id=0x1 > 1500>]


    The peer asks you to change your MRU to 1500. Note that if the peer
    really wanted 1500, he could just as well have sent Configure-Reject.

    > Jul 19 02:05:20 localhost pppd[8389]: sent [PAP AuthReq id=0x1
    > user="xxx" password=]
    > Jul 19 02:05:23 localhost pppd[8389]: sent [PAP AuthReq id=0x2
    > user="xxx" password=]
    > Jul 19 02:05:26 localhost pppd[8389]: sent [PAP AuthReq id=0x3
    > user="xxx" password=]
    > Jul 19 02:05:29 localhost pppd[8389]: sent [PAP AuthReq id=0x4
    > user="xxx" password=]
    > Jul 19 02:05:32 localhost pppd[8389]: sent [PAP AuthReq id=0x5
    > user="xxx" password=]
    > Jul 19 02:05:32 localhost pppd[8389]: rcvd [PAP AuthAck id=0x5 ""]


    Wow. It took him 12 seconds to perform a simple PAP authentication.

    Any chance you can find another ISP?

    > Jul 19 02:05:32 localhost pppd[8389]: sent [CCP ConfReq id=0x1
    > ]
    > Jul 19 02:05:32 localhost pppd[8389]: rcvd [LCP ProtRej id=0x2 80 fd
    > 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]


    This part is normal. The peer is rejecting CCP (Compression Control
    Protocol).

    > Jul 19 02:05:32 localhost pppd[8389]: rcvd [IPCP ConfRej id=0x1
    > ]


    Yuck. This is legal, but not good. It means that the peer doesn't
    suppport TCP/IP header compression, and it's often a sign that the
    peer is lame.

    There's nothing else obviously wrong in the log, so this isn't really
    a PPP problem.

    Some possible problems include a misconfigured modem (you didn't show
    how you set up your modem at all), broken serial cable (missing pins
    or physically damaged), serial port problems (incorrect IRQ setting,
    bad options), a pathetic peer, or even a broken-as-designed modem
    (such as a "winmodem").

    If that doesn't help, then post again and please include your actual
    configuration.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  3. Re: another ppp slow modem question....

    dutone wrote:
    > I am connecting via kppp, according to kppp my connection rates differ
    > between 14000 to 26000 (rounded down) and sometimes I get transfer
    > rates of 100 to 300 bps. I have screwed around with setserial and
    > stty, setting the speed to various optons, via `stty [device] N` or
    > `setserial [device] sph_high etc... but no luck. I have also adjusted
    > the mru option to the recomended (man page) value of 296 for slow
    > links, but it ends back at 1500, which I guess is still ok. I just
    > cant figure out what the deal is. I noticed in the log that it is
    > sending mrru values, which to my understanding is for shared links
    > -which mine is not. Maybe this is why i'm connected so slow, because
    > of an assumed shared link? Or is this always used? Im at a loss of
    > ideas....



    > I also sent a CPP request but never got anything back accept a
    > ProtRej, but this had a different id. Is that ProtRej for the CPP??


    > Thanks for any help


    > Jul 19 02:05:19 localhost pppd[8389]: using channel 7
    > Jul 19 02:05:19 localhost pppd[8389]: Using interface ppp0
    > Jul 19 02:05:19 localhost pppd[8389]: Connect: ppp0 <--> /dev/536ep


    A google search reveal a 536ep modem and it is "controllerless," i.e.
    needs a software driver. Dump it and get a real modem. Dump the ISP
    too, if you can.

    -- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* Slogan appropriate for a certain well-known software company:
    FAILURE IS NOT AN OPTION - it is built into the operating system
    and comes bundled with the software. And it attracts maggots. */

  4. Re: another ppp slow modem question....

    Clifford Kite wrote in message news:...
    > dutone wrote:
    > > I am connecting via kppp, according to kppp my connection rates differ
    > > between 14000 to 26000 (rounded down) and sometimes I get transfer
    > > rates of 100 to 300 bps. I have screwed around with setserial and
    > > stty, setting the speed to various optons, via `stty [device] N` or
    > > `setserial [device] sph_high etc... but no luck. I have also adjusted
    > > the mru option to the recomended (man page) value of 296 for slow
    > > links, but it ends back at 1500, which I guess is still ok. I just
    > > cant figure out what the deal is. I noticed in the log that it is
    > > sending mrru values, which to my understanding is for shared links
    > > -which mine is not. Maybe this is why i'm connected so slow, because
    > > of an assumed shared link? Or is this always used? Im at a loss of
    > > ideas....

    >
    >
    > > I also sent a CPP request but never got anything back accept a
    > > ProtRej, but this had a different id. Is that ProtRej for the CPP??

    >
    > > Thanks for any help

    >
    > > Jul 19 02:05:19 localhost pppd[8389]: using channel 7
    > > Jul 19 02:05:19 localhost pppd[8389]: Using interface ppp0
    > > Jul 19 02:05:19 localhost pppd[8389]: Connect: ppp0 <--> /dev/536ep

    >
    > A google search reveal a 536ep modem and it is "controllerless," i.e.
    > needs a software driver. Dump it and get a real modem. Dump the ISP
    > too, if you can.
    >
    > -- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    > PPP-Q&A links, downloads: http://ckite.no-ip.net/
    > /* Slogan appropriate for a certain well-known software company:
    > FAILURE IS NOT AN OPTION - it is built into the operating system
    > and comes bundled with the software. And it attracts maggots. */


    Yes, yes, it is indeed a Winmodem. But aside from that, the connection
    rate should be higher than I am getting -one would hope. After viewing
    the output from lspci

    01:08.0 Communication controller: Intel Corporation: Unknown device
    1040
    Subsystem: Intel Corporation: Unknown device 1000
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
    ParErr- Stepping- SERR+ FastB2B+
    Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium
    >TAbort- SERR-
    Latency: 64, cache line size 08
    Interrupt: pin A routed to IRQ 10
    Region 0: Memory at f4400000 (32-bit, non-prefetchable)
    [size=4M]
    Capabilities: [e0] Power Management version 2
    Flags: PMEClk- DSI- D1- D2+ AuxCurrent=375mA
    PME(D0-,D1-,D2+,D3hot+,D3cold+)
    Status: D0 PME-Enable- DSel=0 DScale=0 PME-i:


    and /etc/sysconfig/hwconfig:
    -
    class: MODEM
    bus: PCI
    detached: 0
    driver: unknown
    desc: "Intel Corporation|unknown device 8086:1040"
    vendorId: 8086
    deviceId: 1040
    subVendorId: 8086
    subDeviceId: 1000
    pciType: 1
    -


    I see that (from lspci) I/O is off. I tried to turn it on but it
    froze up. Also setserial is reporting that the IRQ is 1073918616, but
    /proc reports 10 so I am assuming that its correct.

    I am going to try this crap in windows and see if I get better
    numbers.


    Thanks for the help

  5. Re: another ppp slow modem question....

    dutone wrote:

    > Yes, yes, it is indeed a Winmodem. But aside from that, the connection
    > rate should be higher than I am getting -one would hope.

    ....

    > and /etc/sysconfig/hwconfig:
    > -
    > class: MODEM
    > bus: PCI
    > detached: 0
    > driver: unknown

    ^^^^^^^^^^^^^^^^^
    > desc: "Intel Corporation|unknown device 8086:1040"
    > vendorId: 8086
    > deviceId: 1040
    > subVendorId: 8086
    > subDeviceId: 1000
    > pciType: 1
    > -


    > I see that (from lspci) I/O is off. I tried to turn it on but it
    > froze up. Also setserial is reporting that the IRQ is 1073918616, but
    > /proc reports 10 so I am assuming that its correct.


    > I am going to try this crap in windows and see if I get better
    > numbers.


    Oh, you almost certainly will get better numbers. But drivers for
    software modems under Linux are often written by third parties and
    sometimes don't work well. And any binary a manufacturer supplies
    is often made for a kernel other than the one you are using.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* Speak softly and carry a +6 two-handed sword. */