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

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. */

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