From owner-freebsd-isdn Sun Mar 19 3:30:33 2000 Delivered-To: freebsd-isdn@freebsd.org Received: from peedub.muc.de (peedub.muc.de [193.149.49.109]) by hub.freebsd.org (Postfix) with ESMTP id 85E0237B5EE for ; Sun, 19 Mar 2000 03:30:22 -0800 (PST) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id MAA28886; Sun, 19 Mar 2000 12:28:25 +0100 (CET) Message-Id: <200003191128.MAA28886@peedub.muc.de> X-Mailer: exmh version 2.1.0 09/18/1999 To: Martin Husemann Cc: ah@haakh.de (Andreas Haakh), freebsd-isdn@FreeBSD.ORG (ISDN-List) Subject: Re: isp0 up and running but not working Reply-To: Gary Jennejohn In-reply-to: Your message of "Sun, 19 Mar 2000 11:35:23 +0100." <200003191037.LAA28953@rumolt.teuto.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Mar 2000 12:28:25 +0100 From: Gary Jennejohn Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Martin Husemann writes: >> This doesn't work either :( I have a static IP address and the first >> packets are still being dropped (I always use a ping -c 2 to open the >> connection). > >You are both right. The error code should be changed for the dyn-ip case, >and the first-packet-sink should be debugged. > The problem is basically twofold: 1) As soon as sPPP gets into IPCP phase the routine sppp_ncp_check returns success, although the connection hasn't been fully established. This means that sppp_dequeue will also check pp_fastq and if_snd in case there aren't any packets in pp_cpq, which can easily happen. 2) In i4bisppp_start there's a while loop which calls sppp_dequeue until it returns NULL. As soon as IPCP starts and pp_cpq is empty this loop will empty out pp_fastq and if_snd. In case the PPP connection hasn't been established this means that packets queued in pp_fastq or if_and will effectively be lost. This becomes obvious if one looks at the following output from tcpdump (raw data deleted): 12:01:05.155043 ID-012 LCP: Configure-Request, Magic-Number=1575218996 12:01:05.697581 ID-001 LCP: Configure-Request, Magic-Number=1050150145, Auth-Prot PAP 12:01:05.697600 ID-001 LCP: Configure-Ack, Magic-Number=1050150145, Auth-Prot PAP 12:01:05.699795 ID-012 LCP: Configure-Ack, Magic-Number=1575218996 12:01:05.699809 ID-013 PAP: Authenticate-Request, Peer-Id=xxx, Passwd=yyy 12:01:05.734058 ID-013 PAP: Authenticate-Ack 12:01:05.734081 ID-014 IPCP: IP-Compression-Protocol 12:01:05.734083 peedub.muc.de > router.muc.de: icmp: echo request 12:01:05.734085 peedub.muc.de > router.muc.de: icmp: echo request 12:01:05.737175 ID-001 IPCP: IP-Compression-Protocol 12:01:05.737204 ID-001 IPCP: IP-Compression-Protocol 12:01:05.746048 ID-014 IPCP: IP-Compression-Protocol my 2 pings appear _before_ the IPCP negotiation is complete and therefore are discarded by the peer. How to fix this ? Probably sppp_dequeue should only look at pp_fastq and if_snd iff IPCP has successfully completed. This could be done by setting a flag in sppp_ipcp_tlu and checking it in sppp_dequeue. The flag would be cleared in sppp_ipcp_tlf. I think I'll try this out and see what happens. --- Gary Jennejohn / garyj@muc.de garyj@fkr.cpqcorp.net gj@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message