Date: Sun, 19 Mar 2000 12:28:25 +0100 From: Gary Jennejohn <garyj@peedub.muc.de> To: Martin Husemann <martin@rumolt.teuto.de> Cc: ah@haakh.de (Andreas Haakh), freebsd-isdn@FreeBSD.ORG (ISDN-List) Subject: Re: isp0 up and running but not working Message-ID: <200003191128.MAA28886@peedub.muc.de> In-Reply-To: Your message of "Sun, 19 Mar 2000 11:35:23 %2B0100." <200003191037.LAA28953@rumolt.teuto.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003191128.MAA28886>