From owner-freebsd-net@FreeBSD.ORG Mon May 10 14:10:05 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1A281065672 for ; Mon, 10 May 2010 14:10:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8755C8FC13 for ; Mon, 10 May 2010 14:10:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4AEA5mq042788 for ; Mon, 10 May 2010 14:10:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4AEA5JX042787; Mon, 10 May 2010 14:10:05 GMT (envelope-from gnats) Date: Mon, 10 May 2010 14:10:05 GMT Message-Id: <201005101410.o4AEA5JX042787@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: John Bayly Cc: Subject: Re: bin/146377: [ppp] [tun] Interface doesn't clear addresses when PPPoE connection closes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Bayly List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 14:10:05 -0000 The following reply was made to PR bin/146377; it has been noted by GNATS. From: John Bayly To: bug-followup@FreeBSD.org, john.bayly@tipstrade.net Cc: Subject: Re: bin/146377: [ppp] [tun] Interface doesn't clear addresses when PPPoE connection closes Date: Mon, 10 May 2010 14:49:04 +0100 This is a multi-part message in MIME format. --------------090209090702000507070503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Having had a good look at the source over the weekend (Spanish Grand Prix was dull as ever), I've seen that my suggestion of putting a call to iface_Clear somewhere in bundle_close was a tad off the mark. Noticing that the calls to iface_Add & iface_Clear appear to come from ipcp & ipv6cp (makes sense really) it's clear that the call to clear the interface's addresses should come from there too. Also, the call to clear should be made at the last possible moment, to make sure that connection is definitely closed, so I add the call in the LayerFinish method for both ipcp & ipv6cp. I've attached diffs for both files. I've tested the patched version, and by calling close in interactive mode, and by disconnecting the phone cable (so that the connection will drop after 5 LCP echoes are lost) I now have the desired effect of the addresses being cleared from the interface. I'm going to run with this patched version as I can't see how this could cause any catastrophic issues. Would this be an acceptable solution for future releases? John --------------090209090702000507070503 Content-Type: text/plain; name="ipcp.c.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipcp.c.diff" LS0tIGlwY3AuYy5vcmlnIDIwMTAtMDUtMTAgMTM6Mjc6MjIuMDAwMDAwMDAwICswMTAwDQor KysgaXBjcC5jICAgICAgMjAxMC0wNS0xMCAxMzo0MjoyMy4wMDAwMDAwMDAgKzAxMDANCkBA IC0yNSw3ICsyNSw3IEBADQogICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwg RVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRg0KICAqIFNVQ0ggREFNQUdF Lg0KICAqDQotICogJEZyZWVCU0Q6IHNyYy91c3Iuc2Jpbi9wcHAvaXBjcC5jLHYgMS4xMjMu MjAuMSAyMDA5LzA0LzE1IDAzOjE0OjI2IGtlbnNtaXRoIEV4cCAkDQorICogJEZyZWVCU0Q6 IHNyYy91c3Iuc2Jpbi9wcHAvaXBjcC5jLHYgMS4xMjMuMjAuMS4xIDIwMTAvMDUvMTAgMTM6 NDM6MDAgam9obmJheWx5IEV4cCAkDQogICovDQoNCiAjaW5jbHVkZSA8c3lzL3BhcmFtLmg+ DQpAQCAtODI5LDYgKzgyOSwxMCBAQA0KICAgLyogV2UncmUgbm93IGRvd24gKi8NCiAgIHN0 cnVjdCBpcGNwICppcGNwID0gZnNtMmlwY3AoZnApOw0KDQorICAvKiBDbGVhciBhbGwgYWRk cmVzc2VzIGZyb20gdGhlIGludGVyZmFjZSAqLw0KKyAgaWZhY2VfQ2xlYXIoZnAtPmJ1bmRs ZS0+aWZhY2UsICZmcC0+YnVuZGxlLT5uY3AsIEFGX0lORVQsDQorICAgICAgICAgICAgICAg ICAgIElGQUNFX0NMRUFSX0FMTCk7DQorDQogICBsb2dfUHJpbnRmKExvZ0lQQ1AsICIlczog TGF5ZXJGaW5pc2guXG4iLCBmcC0+bGluay0+bmFtZSk7DQogICB0aHJvdWdocHV0X3N0b3Ao JmlwY3AtPnRocm91Z2hwdXQpOw0KICAgdGhyb3VnaHB1dF9sb2coJmlwY3AtPnRocm91Z2hw dXQsIExvZ0lQQ1AsIE5VTEwpOw== --------------090209090702000507070503 Content-Type: text/plain; name="ipv6cp.c.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipv6cp.c.diff" LS0tIGlwdjZjcC5jLm9yaWcgICAgICAgMjAxMC0wNS0xMCAxMzoyOTo0OC4wMDAwMDAwMDAg KzAxMDANCisrKyBpcHY2Y3AuYyAgICAyMDEwLTA1LTEwIDEzOjQzOjA5LjAwMDAwMDAwMCAr MDEwMA0KQEAgLTIzLDcgKzIzLDcgQEANCiAgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNP RlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GDQogICogU1VD SCBEQU1BR0UuDQogICoNCi0gKiAkRnJlZUJTRDogc3JjL3Vzci5zYmluL3BwcC9pcHY2Y3Au Yyx2IDEuMTcuMjAuMSAyMDA5LzA0LzE1IDAzOjE0OjI2IGtlbnNtaXRoIEV4cCAkDQorICog JEZyZWVCU0Q6IHNyYy91c3Iuc2Jpbi9wcHAvaXB2NmNwLmMsdiAxLjE3LjIwLjEuMSAyMDEw LzA1LzEwIDEzOjQzOjAwIGpvaG5iYXlseSBFeHAgJA0KICAqLw0KDQogI2luY2x1ZGUgPHN5 cy9wYXJhbS5oPg0KQEAgLTU4Niw2ICs1ODYsMTAgQEANCiAgIC8qIFdlJ3JlIG5vdyBkb3du ICovDQogICBzdHJ1Y3QgaXB2NmNwICppcHY2Y3AgPSBmc20yaXB2NmNwKGZwKTsNCg0KKyAg LyogQ2xlYXIgYWxsIGFkZHJlc3NlcyBmcm9tIHRoZSBpbnRlcmZhY2UgKi8NCisgIGlmYWNl X0NsZWFyKGZwLT5idW5kbGUtPmlmYWNlLCAmZnAtPmJ1bmRsZS0+bmNwLCBBRl9JTkVUNiwN CisgICAgICAgICAgICAgICAgICAgSUZBQ0VfQ0xFQVJfQUxMKTsNCisNCiAgIGxvZ19Qcmlu dGYoTG9nSVBWNkNQLCAiJXM6IExheWVyRmluaXNoLlxuIiwgZnAtPmxpbmstPm5hbWUpOw0K ICAgdGhyb3VnaHB1dF9zdG9wKCZpcHY2Y3AtPnRocm91Z2hwdXQpOw0KICAgdGhyb3VnaHB1 dF9sb2coJmlwdjZjcC0+dGhyb3VnaHB1dCwgTG9nSVBWNkNQLCBOVUxMKTs= --------------090209090702000507070503--