From owner-freebsd-hackers Sat Mar 7 10:52:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA04705 for freebsd-hackers-outgoing; Sat, 7 Mar 1998 10:52:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA04673 for ; Sat, 7 Mar 1998 10:52:05 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id SAA03615; Sat, 7 Mar 1998 18:21:49 +0100 From: Luigi Rizzo Message-Id: <199803071721.SAA03615@labinfo.iet.unipi.it> Subject: weird problem (lost packets) in iijppp To: hackers@FreeBSD.ORG Date: Sat, 7 Mar 1998 18:21:49 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Since i wanted to play with ppp (to implement better compression for UDP/RTP traffic, and implement "preemption" of long, non real-time packets), i decided to do some tests using ppp over tcp. Setting up everything with two ppp instances on the same machine (details at the end of this email) i tried some pings and, surprise surprise: # ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes ... 64 bytes from 10.0.0.1: icmp_seq=21 ttl=255 time=1.839 ms 64 bytes from 10.0.0.1: icmp_seq=22 ttl=255 time=1.748 ms 64 bytes from 10.0.0.1: icmp_seq=24 ttl=255 time=1.786 ms ... NOTE THE MISSING PKT 23 ... 64 bytes from 10.0.0.1: icmp_seq=30 ttl=255 time=1.716 ms 64 bytes from 10.0.0.1: icmp_seq=31 ttl=255 time=1.750 ms ^C --- 10.0.0.1 ping statistics --- 32 packets transmitted, 31 packets received, 3% packet loss round-trip min/avg/max = 1.716/1.826/3.646 ms so the packet has been lost (and not because i interrupted the ping, it is in the middle of the sequence), but presumably outside the low level (tcp) link since the ppp stats on the two sides seem to suggest that the packet has been correctly transferred over the link: Protocol in out client: COMPD : 31, 32 server: COMPD : 32, 31 Apart from some weird interaction with TCP delayed acks on the TCP circuit which carries ppp packets (since packets around 108 bytes and above 1500 will have a RTT of 300-400ms), there are some occasional packet losses (got up to 10-15 lost in some tests) and i have no idea where they occur. At first sight the losses seem to be more frequent when there is a short (<100ms) RTT. Disabling "pred1" compression seems not to make much difference -- just the effect of the predictor changes the sizes for which i get the delayed acks, but the losses remain. For what matters, i got the same loss pattern using ppp on a real modem line (frequently the losses occur at multiple of 8 pkts if that matters). I thought they were due to the modem (i.e. congestion somewhere) but that's not possible since ping is sending 1 pkt/s and the queues are 10pkts at least (i think) -- perhaps even 20 or 50 pkts. Any idea on this problem ? I am seeing it on 2.2.1 -- maybe newer relases of ppp do not have the problem. In any case something to check. For those willing to duplicate the problem, i have patched modem.c so that a negative port number will instruct ppp to open the socket in server mode. On the two sides i run [server] % ppp tcps [client] % ppp tcpc then go into "term" mode at the ppp prompt, and on one of the parties press ~p to enter packet mode. The relevant lines in ppp.conf are: #server for tcp connection tcps: set device 127.0.0.1:-2400 set ifaddr 10.0.0.1 10.0.0.2 tcpc: set device 127.0.0.1:2400 set ifaddr 10.0.0.2 10.0.0.1 while the patches for modem.c are as following cheers luigi --- ../ppp.22R/modem.c Sun Jan 12 22:52:49 1997 +++ modem.c Sat Mar 7 15:25:04 1998 @@ -334,6 +334,7 @@ struct hostent *hp; struct servent *sp; +bzero(&dest, sizeof(dest) ); dest.sin_family = AF_INET; dest.sin_addr.s_addr = inet_addr(host); if (dest.sin_addr.s_addr == INADDR_NONE) { @@ -357,6 +358,27 @@ } LogPrintf(LOG_PHASE_BIT, "Connected to %s:%s\n", host, port); + if (ntohs(dest.sin_port) & 0x8000) { + struct sockaddr_in src; +int r , l; + + bzero(&src, sizeof(src) ); + dest.sin_port = htons(- (short)(ntohs(dest.sin_port)) ) ; + dest.sin_addr.s_addr = INADDR_ANY ; + printf("using server socket at %d\n", ntohs(dest.sin_port)); + sock = socket(PF_INET, SOCK_STREAM, 0); + if (sock < 0) { + return(sock); + } + r = bind(sock, &dest, sizeof(dest) ); + printf("bind returns %d\n", r); + listen(sock, 10); + printf("listen returns %d\n", r); + l = sizeof(src) ; + sock = accept(sock, &src, &l ); + printf("accept returns %d\n", sock); + + } else { sock = socket(PF_INET, SOCK_STREAM, 0); if (sock < 0) { return(sock); @@ -364,6 +386,7 @@ if (connect(sock, (struct sockaddr *)&dest, sizeof(dest)) < 0) { printf("connection failed.\n"); return(-1); + } } return(sock); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message