From nobody@FreeBSD.org Fri May 7 15:50:19 2010 Return-Path: Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DDF41065672 for ; Fri, 7 May 2010 15:50:19 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [69.147.83.33]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB528FC0C for ; Fri, 7 May 2010 15:50:19 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o47FoJkh076893 for ; Fri, 7 May 2010 15:50:19 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id o47FoJRs076892; Fri, 7 May 2010 15:50:19 GMT (envelope-from nobody) Message-Id: <201005071550.o47FoJRs076892@www.freebsd.org> Date: Fri, 7 May 2010 15:50:19 GMT From: John Bayly To: freebsd-gnats-submit@FreeBSD.org Subject: Interface doesn't clear addresses when PPPoE connection closes X-Send-Pr-Version: www-3.1 X-GNATS-Notify: >Number: 146377 >Category: bin >Synopsis: [ppp] [tun] Interface doesn't clear addresses when PPPoE connection closes >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-net >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri May 07 16:00:10 UTC 2010 >Closed-Date: >Last-Modified: Mon May 10 14:10:03 UTC 2010 >Originator: John Bayly >Release: 7.2-RELEASE >Organization: TipsTrade >Environment: FreeBSD router.tipstrade.net 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Tue Oct 6 11:49:42 BST 2009 xxx@router.tipstrade.net:/usr/obj/usr/src/sys/CUSTOM20091006 i386 >Description: When using ppp to create an ADSL connection, the addresses for the tun interface aren't removed when either the connection drops (due to LCP/LQM echoes being lost), or when the connection is closed. This means that even though a connection has been dropped, using ifconfig to check the state makes it appear as if a connection is still up. When settings "set log +all", I've seen that the ioctl calls to remove the address (SIOCDIFADDR) is never called. Calling "iface clear" in ppp.linkdown doesn't work either, as it's executed before the connection has closed so the address cannot be removed. I've confirmed this from looking at the ppp source: iface_Clear is only called from the following places: 1). ipcp_SetIPaddress & ipcp_SetIPv6address 2). IfaceClearCommand ie. the interactive command "iface clear" 3). bundle_destroy, which is in turn called solely from AbortProgram Would it make sense to add a call to iface_Clear somewhere in bundle_close? Apologies for the vagueness, but I'm still getting my head around the code here. >How-To-Repeat: 1). Open ppp in interactive mode 2). ppp> dial 3). PPP> iface show 4). PPP> close 5). ppp> iface show 6). ppp> iface clear 7). ppp> iface show >Fix: >Release-Note: >Audit-Trail: Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 7 21:39:05 UTC 2010 Responsible-Changed-Why: Assign to wrong mailing list. erk. http://www.freebsd.org/cgi/query-pr.cgi?pr=146377 Responsible-Changed-From-To: freebsd-fs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 7 21:40:04 UTC 2010 Responsible-Changed-Why: Assign to right mailing list. http://www.freebsd.org/cgi/query-pr.cgi?pr=146377 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-- >Unformatted: