Date: Fri, 27 Jul 2001 12:52:34 +0100 From: Brian Somers <brian@Awfulhak.org> To: Rasputin <rara.rasputin@virgin.net> Cc: stable@freebsd.org, brian@freebsd.org, brian@Awfulhak.org Subject: Re: PPP still playing up? Message-ID: <200107271152.f6RBqYc03803@hak.lan.Awfulhak.org> In-Reply-To: Message from Rasputin <rara.rasputin@virgin.net> of "Fri, 27 Jul 2001 12:24:24 BST." <20010727122423.A48668@shaft.techsupport.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Would you mind applying the attached patch and sending me the IPCP log output ? I didn't realise there were any implementations around that failed to negotiate an IP address -- shows what I know :*I Cheers. > >* Rasputin <rara.rasputin@virgin.net> [010725 10:31]: > > > >> Re: the issue with PPP falling over, I found (as others did) > >> that replacing the line: > >> > >> set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 > >> with > >> set ifaddr 0.0.0.0/0 0.0.0.0/0 0.0.0.0 0.0.0.0 > > ^^^^^^^^^ > > ??? > >> > >> works > > >Ugh, ignore me. Brain dump. > >I misread Neals' fix - will try setting only the server end to > >0.0.0.0/0 when I get back to the box and take it from there.... > > Ok, for the record, I can now get online by making a few workarounds. > > If I set: > set ifaddr 10.0.0.1/0 0.0.0.0/0 0.0.0.0 0.0.0.0 > > (I need an IP for the local side to use tun0) > > ppp -ddial isp > > but not > > ppp -auto isp > > (which refuses to accept the config without the remote side's IP > being specified) > > I believe we need to change these settings due to IPCP and LCP being > extra picky about the negotiation with the PPP server. > > Possibly related to chages in lcp.c and friends? > > ----------------------------------------------------- > http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/ppp/lcp.c?only_with_tag=RELENG_4 > Revision 1.81.2.6, Monday Jul 9 01:37:16 2001 UTC (2 weeks, 4 days ago) by brian > Branch: RELENG_4 > Changes since 1.81.2.5: +63 -18 lines > > MFC: Support stateful MPPE > Insist on correct MRU negotiation during LCP > Insist on correct IPADDR negotiation during IPCP > ----------------------------------------------------- > > Since the '/0' on the end of the IPs is supposed to mean: > > "None of the bits in the preceding IP are significant" > > this looks like a bug to me - ppp should accept that the other > end may end up being any IP and live with it, instead of repeatedly > trying to negotiate. (in the past, the remote IP has remained > 10.0.0.2 after connecting, with no side effects) > > I realise that from a standards point of view we are probably > 'doing the right thing'; however, it sounds like I'm not the only one with > an iffy ISP, and something as fundamentally important as a network connection > should be more flexible in its negotiations IMHO. > (It's difficult to roll back via cvsup when you can't get online :) ) > > That's my take on it, any comments? > > <<Logfiles showing the wierdness from the client side are available at: > http://shaft.techsupport.co.uk/~rasputin/logs > as before.>> > > -- > Rasputin :: Jack of All Trades - Master of Nuns :: -- Brian <brian@freebsd-services.com> <brian@Awfulhak.org> http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org> Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org> Index: ipcp.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/ppp/ipcp.c,v retrieving revision 1.107 diff -u -r1.107 ipcp.c --- ipcp.c 2001/06/13 21:52:16 1.107 +++ ipcp.c 2001/07/27 11:43:47 @@ -659,7 +659,7 @@ } ipcp->heis1172 = 0; - + ipcp->peer_req = 0; ipcp->peer_ip = ipcp->cfg.peer_range.ipaddr; ipcp->peer_compproto = 0; @@ -915,6 +915,7 @@ throughput_start(&ipcp->throughput, "IPCP throughput", Enabled(fp->bundle, OPT_THROUGHPUT)); fp->more.reqs = fp->more.naks = fp->more.rejs = ipcp->cfg.fsm.maxreq * 3; + ipcp->peer_req = 0; } static void @@ -1139,14 +1140,13 @@ { /* Deal with incoming PROTO_IPCP */ struct ipcp *ipcp = fsm2ipcp(fp); - int type, length, gotdnsnak, ipaddr_req; + int type, length, gotdnsnak; u_int32_t compproto; struct compreq *pcomp; struct in_addr ipaddr, dstipaddr, have_ip; char tbuff[100], tbuff2[100]; gotdnsnak = 0; - ipaddr_req = 0; while (plen >= sizeof(struct fsmconfig)) { type = *cp; @@ -1166,7 +1166,7 @@ switch (mode_type) { case MODE_REQ: - ipaddr_req = 1; + ipcp->peer_req = 1; ipcp_ValidateReq(ipcp, ipaddr, dec); break; @@ -1414,8 +1414,17 @@ } if (mode_type != MODE_NOP) { - if (mode_type == MODE_REQ && !ipaddr_req) { - /* We *REQUIRE* that the peer requests an IP address */ + if (mode_type == MODE_REQ && !ipcp->peer_req) { + if (dec->rejend == dec->rej && dec->nakend == dec->nak) { + /* + * Pretend the peer has requested an IP. + * We do this to ensure that we only send one NAK if the only + * reason for the NAK is because the peer isn't sending a + * TY_IPADDR REQ. This stops us from repeatedly trying to tell + * the peer that we have to have an IP address on their end. + */ + ipcp->peer_req = 1; + } ipaddr.s_addr = INADDR_ANY; ipcp_ValidateReq(ipcp, ipaddr, dec); } Index: ipcp.h =================================================================== RCS file: /home/ncvs/src/usr.sbin/ppp/ipcp.h,v retrieving revision 1.33 diff -u -r1.33 ipcp.h --- ipcp.h 2001/06/13 21:52:17 1.33 +++ ipcp.h 2001/07/27 11:37:35 @@ -108,6 +108,7 @@ unsigned heis1172 : 1; /* True if he is speaking rfc1172 */ + unsigned peer_req : 1; /* Any TY_IPADDR REQs from the peer ? */ struct in_addr peer_ip; /* IP address he's willing to use */ u_int32_t peer_compproto; /* VJ params he's willing to use */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107271152.f6RBqYc03803>