By the way the custom is actually a "Debian Like" distribution on an
embedded device. Further more, I have tried without success to get kdebug
to spit out the entire HDLC frame with no luck and finally, here is my pppd
command line.

/usr/sbin/pppd /dev/tts/0 19200 novj novjccomp nopredictor1 record
/tmp/ppp_dump nopcomp noccp nobsdcomp noaccomp noipdefault auth local name
server remotename client kdebug 7 debug nodeflate nodefaultroute nopersist
lcp-echo-interval 1 lcp-echo-failure 2 maxfail 1

"MITCH BLACK" wrote in message
news:iWY%d.6866$uw6.1604@trnddc06...
> End point 1 Redhat 9.0 ppp user/kernel 2.4.2
> End point 2 custom ppp user/kernel 2.4.2
>
> The link comes up fine and LCP is transmitted/received fine. However, I
> do not receive any IP packets after the first 4.
>
> ppp0 Link encap:Point-to-Point Protocol
> inet addr:10.1.1.1 P-t-P:10.1.1.2 Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
> RX packets:4 errors:204 dropped:0 overruns:0 frame:0
> TX packets:96 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:40 (40.0 b) TX bytes:26168 (25.5 Kb)
>
>
> RX packets stays at 4 and Rx errors continues to climb as more packets are
> sent to me.
>
> Any ideas? Could the first 4 packets be part of some negotiation and the
> remaining are then corrupted based on one (my custom end) not transmitting
> properly?
>
> Thanks!
>
> Mitch Black
>

In article ,
MITCH BLACK wrote:
>End point 1 Redhat 9.0 ppp user/kernel 2.4.2
>End point 2 custom ppp user/kernel 2.4.2
>
>The link comes up fine and LCP is transmitted/received fine. However, I do
>not receive any IP packets after the first 4.
>
>ppp0 Link encap:Point-to-Point Protocol
> inet addr:10.1.1.1 P-t-P:10.1.1.2 Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
> RX packets:4 errors:204 dropped:0 overruns:0 frame:0
> TX packets:96 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:40 (40.0 b) TX bytes:26168 (25.5 Kb)
>
>
>RX packets stays at 4 and Rx errors continues to climb as more packets are
>sent to me.
>
>Any ideas? Could the first 4 packets be part of some negotiation and the
>remaining are then corrupted based on one (my custom end) not transmitting
>properly?

Can you dump the actual packet data?? The negotiations are important,
but seeing the packets that aren't getting thru would be useful too (by
logging them on the other side).

Also provide the options you're attempting to use on each side.

Patrick
============= For PPP Protocol Analysis, check out SerialView! =============
Patrick Klos Email: patrick@klos.com
Klos Technologies, Inc. Web: http://www.klos.com/
==== I don't think infinity is as big as it seems - P.Klos, 20-Mar-2005 ====

Hi Patrick,

Both side are set up like the following (except for switching client/server
on each end)

/usr/sbin/pppd /dev/tts/0 19200 novj novjccomp nopredictor1 record
/tmp/ppp_dump nopcomp noccp nobsdcomp noaccomp noipdefault auth local name
server remotename client kdebug 7 debug nodeflate nodefaultroute nopersist
lcp-echo-interval 1 lcp-echo-failure 2 maxfail 1

I have tried getting the output from kdebug (i.e. the HDLC frame dump) but
have not yet been successful at that. I made the appropriate chagnes to
syslog.conf and syslogd as well as klogd are both running.

Thanks,

Mitch

"Patrick Klos" wrote in message
news:d1pmbi$5g7$1@pyrite.mv.net...
> In article ,
> MITCH BLACK wrote:
>>End point 1 Redhat 9.0 ppp user/kernel 2.4.2
>>End point 2 custom ppp user/kernel 2.4.2
>>
>>The link comes up fine and LCP is transmitted/received fine. However, I
>>do
>>not receive any IP packets after the first 4.
>>
>>ppp0 Link encap:Point-to-Point Protocol
>> inet addr:10.1.1.1 P-t-P:10.1.1.2 Mask:255.255.255.255
>> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
>> RX packets:4 errors:204 dropped:0 overruns:0 frame:0
>> TX packets:96 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:3
>> RX bytes:40 (40.0 b) TX bytes:26168 (25.5 Kb)
>>
>>
>>RX packets stays at 4 and Rx errors continues to climb as more packets are
>>sent to me.
>>
>>Any ideas? Could the first 4 packets be part of some negotiation and the
>>remaining are then corrupted based on one (my custom end) not transmitting
>>properly?
>
> Can you dump the actual packet data?? The negotiations are important,
> but seeing the packets that aren't getting thru would be useful too (by
> logging them on the other side).
>
> Also provide the options you're attempting to use on each side.
>
> Patrick
> ============= For PPP Protocol Analysis, check out SerialView!
> =============
> Patrick Klos Email: patrick@klos.com
> Klos Technologies, Inc. Web: http://www.klos.com/
> ==== I don't think infinity is as big as it seems - P.Klos, 20-Mar-2005
> ====

MITCH BLACK wrote:
> By the way the custom is actually a "Debian Like" distribution on an
> embedded device. Further more, I have tried without success to get kdebug
> to spit out the entire HDLC frame with no luck and finally, here is my pppd
> command line.

kdebug is pretty useless for current kernels (>2.2.x). You can use
pppdump -p /tmp/ppp_dump|less
to get a hex+ascii dump of AHDLC frames.

> /usr/sbin/pppd /dev/tts/0 19200 novj novjccomp nopredictor1 record
> /tmp/ppp_dump nopcomp noccp nobsdcomp noaccomp noipdefault auth local name
> server remotename client kdebug 7 debug nodeflate nodefaultroute nopersist
> lcp-echo-interval 1 lcp-echo-failure 2 maxfail 1

"local"? What physical layer is being used?

> "MITCH BLACK" wrote in message
> news:iWY%d.6866$uw6.1604@trnddc06...
>> End point 1 Redhat 9.0 ppp user/kernel 2.4.2
>> End point 2 custom ppp user/kernel 2.4.2
>>
>> The link comes up fine and LCP is transmitted/received fine. However, I
>> do not receive any IP packets after the first 4.
>>
>> ppp0 Link encap:Point-to-Point Protocol
>> inet addr:10.1.1.1 P-t-P:10.1.1.2 Mask:255.255.255.255
>> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
>> RX packets:4 errors:204 dropped:0 overruns:0 frame:0
>> TX packets:96 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:3
>> RX bytes:40 (40.0 b) TX bytes:26168 (25.5 Kb)
>>
>>
>> RX packets stays at 4 and Rx errors continues to climb as more packets are
>> sent to me.
>>
>> Any ideas? Could the first 4 packets be part of some negotiation and the
>> remaining are then corrupted based on one (my custom end) not transmitting
>> properly?

Possibly. PPP link negotiation messages also might help to understand
why the errors happen - preferably from a log with timestamps.

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* The generation of random numbers is too important to be left
to chance. */