Bug 139559 - [tun] several tun(4) interfaces can be created with same dst addr
Summary: [tun] several tun(4) interfaces can be created with same dst addr
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 9.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: qingli
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-13 06:40 UTC by Roman Bogorodskiy
Modified: 2019-01-19 19:49 UTC (History)
1 user (show)

See Also:
bugmeister: mfc-stable10?
bugmeister: mfc-stable9?
bugmeister: mfc-stable8?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Bogorodskiy freebsd_committer 2009-10-13 06:40:01 UTC
	I'm using -CURRENT for some time and I use tun(4) in pair with ppp(8).
	I have several connections and sometimes it happens that remote pair
	sends dst address that is already used on other tun(4) interface. Previously,
	ppp complained about "File exists" error when assigning a new address
	and redialed. Few days (maybe weeks) ago I've noted a regression: ppp
	complains about "File exists", but nevertheless address gets assigned
	to the interface. I've experimented a bit with it and I have an
	impression that there's some bug in SIOCAIFADDR implementation and it's
	not related to ppp directly. See the 'How-To-Repeat' section.

How-To-Repeat: 	(09:09) novel@underworld:~ %> sudo ifconfig tun4 create
	(09:10) novel@underworld:~ %> sudo ifconfig tun5 create
	(09:10) novel@underworld:~ %> sudo ifconfig tun4 10.0.0.2 10.0.0.1
	(09:10) novel@underworld:~ %> ifconfig tun4
	tun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        	inet 10.0.0.2 --> 10.0.0.1 netmask 0xff000000
	(09:10) novel@underworld:~ %> ifconfig tun5
	tun5: flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1500
	(09:10) novel@underworld:~ %> sudo ifconfig tun5 10.0.0.3 10.0.0.1
	ifconfig: ioctl (SIOCAIFADDR): File exists
	(09:18) novel@underworld:~ %> ifconfig tun5
	tun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        	inet 10.0.0.3 --> 10.0.0.1 netmask 0xff000000
	(09:18) novel@underworld:~ %>

	As you can see, ifconfig throwed the "File exists", but for some reason
	address got assigned, which seems to be wrong to me. Though, data for
	tun5 wasn't added to the routing table.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2009-10-13 14:34:59 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s).
Comment 2 qingli freebsd_committer 2009-12-04 19:44:12 UTC
Responsible Changed
From-To: freebsd-net->qingli

Take ownership of this bug.
Comment 3 qingli freebsd_committer 2010-01-05 22:03:52 UTC
State Changed
From-To: open->closed

Patch committed in svn r201282 fixes this bug.
Comment 4 Roman Bogorodskiy freebsd_committer 2010-01-06 21:50:39 UTC
State Changed
From-To: closed->open

Still reproducable in exactly the same way as described in 
'how to repeat section'.
Comment 5 dfilter service freebsd_committer 2010-01-08 17:49:36 UTC
Author: qingli
Date: Fri Jan  8 17:49:24 2010
New Revision: 201811
URL: http://svn.freebsd.org/changeset/base/201811

Log:
  Ensure an address is removed from the interface address
  list when the installation of that address fails.
  
  PR:		139559

Modified:
  head/sys/netinet/in.c

Modified: head/sys/netinet/in.c
==============================================================================
--- head/sys/netinet/in.c	Fri Jan  8 17:47:37 2010	(r201810)
+++ head/sys/netinet/in.c	Fri Jan  8 17:49:24 2010	(r201811)
@@ -562,7 +562,7 @@ in_control(struct socket *so, u_long cmd
 		    (hostIsNew || maskIsNew))
 			error = in_ifinit(ifp, ia, &ifra->ifra_addr, 0);
 		if (error != 0 && iaIsNew)
-			goto out;
+			break;
 
 		if ((ifp->if_flags & IFF_BROADCAST) &&
 		    (ifra->ifra_broadaddr.sin_family == AF_INET))
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2011-03-01 15:16:13 UTC
State Changed
From-To: open->patched

committed in head (201811)
Comment 7 Roman Bogorodskiy freebsd_committer 2015-06-14 06:26:47 UTC
I've been browsing through the bugs I submitted and spotted this one and decided to check if it's still relevant on -CURRENT. So, currently, it allows to create tuns with the matching dst addresses:

tun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet 10.0.0.3 --> 10.0.0.1 netmask 0xff000000 
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        groups: tun 
tun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet 10.0.0.2 --> 10.0.0.1 netmask 0xff000000 
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        groups: tun 
tun6: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet 10.0.0.6 --> 10.0.0.1 netmask 0xff000000 
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        groups: tun 

The route table contains an entry for the first device:

Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            <snip>
10.0.0.1           link#6             UH         tun4
10.0.0.2           link#6             UHS         lo0
10.0.0.3           link#5             UHS         lo0
10.0.0.6           link#7             UHS         lo0

I'm not sure if that's a bug or not though. Anyway, I haven't been using ppp+tun for a long time now, so this problem doesn't trouble me, so it could be closed if it doesn't feel like a bug.
Comment 8 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2019-01-19 19:49:44 UTC
Qing, is it OK to close this PR?

Thanks