svn commit: r204402 - head/sys/netinet6
Author: qingli
Date: Sat Feb 27 07:12:25 2010
New Revision: 204402
URL: http://svn.freebsd.org/changeset/base/204402
Log:
Use reference counting instead of locking to secure an address while
that address is being used to generate temporary IPv6 address. This
approach is sufficient and avoids recursive locking.
MFC after:3 days
Modified:
head/sys/netinet6/nd6.c
Modified: head/sys/netinet6/nd6.c
==
--- head/sys/netinet6/nd6.c Sat Feb 27 06:28:22 2010(r204401)
+++ head/sys/netinet6/nd6.c Sat Feb 27 07:12:25 2010(r204402)
@@ -764,22 +764,25 @@ regen_tmpaddr(struct in6_ifaddr *ia6)
*/
if (!IFA6_IS_DEPRECATED(it6))
public_ifa6 = it6;
+
+ if (public_ifa6 != NULL)
+ ifa_ref(&public_ifa6->ia_ifa);
}
+ IF_ADDR_UNLOCK(ifp);
if (public_ifa6 != NULL) {
int e;
if ((e = in6_tmpifadd(public_ifa6, 0, 0)) != 0) {
- IF_ADDR_UNLOCK(ifp);
+ ifa_free(&public_ifa6->ia_ifa);
log(LOG_NOTICE, "regen_tmpaddr: failed to create a new"
" tmp addr,errno=%d\n", e);
return (-1);
}
- IF_ADDR_UNLOCK(ifp);
+ ifa_free(&public_ifa6->ia_ifa);
return (0);
}
- IF_ADDR_UNLOCK(ifp);
return (-1);
}
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r204902 - in head/sys: net netinet
Author: qingli
Date: Tue Mar 9 01:11:45 2010
New Revision: 204902
URL: http://svn.freebsd.org/changeset/base/204902
Log:
One of the advantages of enabling ECMP (a.k.a RADIX_MPATH) is to
allow for connection load balancing across interfaces. Currently
the address alias handling method is colliding with the ECMP code.
For example, when two interfaces are configured on the same prefix,
only one prefix route is installed. So connection load balancing
among the available interfaces is not possible.
The other advantage of ECMP is for failover. The issue with the
current code, is that the interface link-state is not reflected
in the route entry. For example, if there are two interfaces on
the same prefix, the cable on one interface is unplugged, new and
existing connections should switch over to the other interface.
This is not done today and packets go into a black hole.
Also, there is a small bug in the kernel where deleting ECMP routes
in the userland will always return an error even though the command
is successfully executed.
MFC after:5 days
Modified:
head/sys/net/flowtable.c
head/sys/net/radix.c
head/sys/net/radix_mpath.c
head/sys/net/route.c
head/sys/net/route.h
head/sys/netinet/in.c
head/sys/netinet/ip_output.c
Modified: head/sys/net/flowtable.c
==
--- head/sys/net/flowtable.cTue Mar 9 00:52:16 2010(r204901)
+++ head/sys/net/flowtable.cTue Mar 9 01:11:45 2010(r204902)
@@ -472,7 +472,8 @@ flow_stale(struct flowtable *ft, struct
|| ((fle->f_rt->rt_flags & RTF_HOST) &&
((fle->f_rt->rt_flags & (RTF_UP))
!= (RTF_UP)))
- || (fle->f_rt->rt_ifp == NULL))
+ || (fle->f_rt->rt_ifp == NULL)
+ || !RT_LINK_IS_UP(fle->f_rt->rt_ifp))
return (1);
idle_time = time_uptime - fle->f_uptime;
Modified: head/sys/net/radix.c
==
--- head/sys/net/radix.cTue Mar 9 00:52:16 2010(r204901)
+++ head/sys/net/radix.cTue Mar 9 01:11:45 2010(r204902)
@@ -761,8 +761,10 @@ on2:
if (m->rm_flags & RNF_NORMAL) {
mmask = m->rm_leaf->rn_mask;
if (tt->rn_flags & RNF_NORMAL) {
+#if !defined(RADIX_MPATH)
log(LOG_ERR,
"Non-unique normal route, mask not entered\n");
+#endif
return tt;
}
} else
Modified: head/sys/net/radix_mpath.c
==
--- head/sys/net/radix_mpath.c Tue Mar 9 00:52:16 2010(r204901)
+++ head/sys/net/radix_mpath.c Tue Mar 9 01:11:45 2010(r204902)
@@ -270,7 +270,8 @@ rtalloc_mpath_fib(struct route *ro, uint
* XXX we don't attempt to lookup cached route again; what should
* be done for sendto(3) case?
*/
- if (ro->ro_rt && ro->ro_rt->rt_ifp && (ro->ro_rt->rt_flags & RTF_UP))
+ if (ro->ro_rt && ro->ro_rt->rt_ifp && (ro->ro_rt->rt_flags & RTF_UP)
+ && RT_LINK_IS_UP(ro->ro_rt->rt_ifp))
return;
ro->ro_rt = rtalloc1_fib(&ro->ro_dst, 1, 0, fibnum);
Modified: head/sys/net/route.c
==
--- head/sys/net/route.cTue Mar 9 00:52:16 2010(r204901)
+++ head/sys/net/route.cTue Mar 9 01:11:45 2010(r204902)
@@ -830,7 +830,13 @@ rt_getifa_fib(struct rt_addrinfo *info,
int
rtexpunge(struct rtentry *rt)
{
+#if !defined(RADIX_MPATH)
struct radix_node *rn;
+#else
+ struct rt_addrinfo info;
+ int fib;
+ struct rtentry *rt0;
+#endif
struct radix_node_head *rnh;
struct ifaddr *ifa;
int error = 0;
@@ -843,14 +849,26 @@ rtexpunge(struct rtentry *rt)
if (rnh == NULL)
return (EAFNOSUPPORT);
RADIX_NODE_HEAD_LOCK_ASSERT(rnh);
-#if 0
- /*
-* We cannot assume anything about the reference count
-* because protocols call us in many situations; often
-* before unwinding references to the table entry.
-*/
- KASSERT(rt->rt_refcnt <= 1, ("bogus refcnt %ld", rt->rt_refcnt));
-#endif
+
+#ifdef RADIX_MPATH
+ fib = rt->rt_fibnum;
+ bzero(&info, sizeof(info));
+ info.rti_ifp = rt->rt_ifp;
+ info.rti_flags = RTF_RNH_LOCKED;
+ info.rti_info[RTAX_DST] = rt_key(rt);
+ info.rti_info[RTAX_GATEWAY] = rt->rt_ifa->ifa_addr;
+
+ RT_UNLOCK(rt);
+ error = rtrequest1_fib(RTM_DELETE, &info, &rt0, fib);
+
+ if (error == 0 && rt0 != NULL) {
+ rt = rt0;
+ RT_LOCK(rt);
+ } else if (error != 0) {
+ RT_LOCK(rt)
Re: svn commit: r204902 - in head/sys: net netinet
> > I looked at it, and at the diff of his original commit. The changes were > large enough that I don't want to assume his patch takes care of all the > issues given that patch hasn't been committed verbatim. > The change itself is not a huge change but if you disagree, then please be specific. The current mechanism and code is broken according to the original design intention. I have a habit of not committing things or quick finger until everyone had a chance to test the patch, although I have done unit testings myself. When you say "... made the kernel toxic" and "...I don't want to assume ...", well, again, be specific instead about what you mean and give me details. The other reason I decided to postpone is because I wanted to spend more time with the PPP driver. Every other PPP interface types (if_tun, if_ng etc.) updates the if_link_state variable except PPP. > > We also have reports of the patch not working in freebsd-curr...@. > I have seen that report but it lacks detail. I have asked for more information and will investigate further as soon as it becomes available. -- Qing ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r205024 - head/sys/net
Author: qingli
Date: Thu Mar 11 17:56:46 2010
New Revision: 205024
URL: http://svn.freebsd.org/changeset/base/205024
Log:
The if_tap interface is of IFT_ETHERNET type, but it
does not set or update the if_link_state variable.
As such RT_LINK_IS_UP() fails for the if_tap interface.
Also, the RT_LINK_IS_UP() needs to bypass all loopback
interfaces because loopback interfaces are considered
up logically as long as the system is running.
This patch fixes the above issues by setting and updating
the if_link_state variable when the tap interface is
opened or closed respectively. Similary approach is
already done in the if_tun device.
MFC after:3 days
Modified:
head/sys/net/if_tap.c
head/sys/net/route.h
Modified: head/sys/net/if_tap.c
==
--- head/sys/net/if_tap.c Thu Mar 11 17:15:40 2010(r205023)
+++ head/sys/net/if_tap.c Thu Mar 11 17:56:46 2010(r205024)
@@ -502,6 +502,7 @@ tapopen(struct cdev *dev, int flag, int
ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
if (tapuponopen)
ifp->if_flags |= IFF_UP;
+ if_link_state_change(ifp, LINK_STATE_UP);
splx(s);
TAPDEBUG("%s is open. minor = %#x\n", ifp->if_xname, dev2unit(dev));
@@ -547,6 +548,7 @@ tapclose(struct cdev *dev, int foo, int
} else
mtx_unlock(&tp->tap_mtx);
+ if_link_state_change(ifp, LINK_STATE_DOWN);
funsetown(&tp->tap_sigio);
selwakeuppri(&tp->tap_rsel, PZERO+1);
KNOTE_UNLOCKED(&tp->tap_rsel.si_note, 0);
Modified: head/sys/net/route.h
==
--- head/sys/net/route.hThu Mar 11 17:15:40 2010(r205023)
+++ head/sys/net/route.hThu Mar 11 17:56:46 2010(r205024)
@@ -319,7 +319,9 @@ struct rt_addrinfo {
#ifdef _KERNEL
-#define RT_LINK_IS_UP(ifp) ((ifp)->if_link_state == LINK_STATE_UP)
+#define RT_LINK_IS_UP(ifp) (((ifp)->if_flags & \
+ (IFF_LOOPBACK | IFF_POINTOPOINT)) \
+|| (ifp)->if_link_state == LINK_STATE_UP)
#defineRT_LOCK_INIT(_rt) \
mtx_init(&(_rt)->rt_mtx, "rtentry", NULL, MTX_DEF | MTX_DUPOK)
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r205024 - head/sys/net
> > A couple of questions: > > (1) It used to be the case that quite a few interface drivers and types > didn't have a notion of "link up" -- especially older ethernet devices. Do > those all have the same problem? It was probably a design oversight that > devices don't declare an explicit capability for "can report link state". > What you raised is definitely a possibility and these fixes take the similar approach. I am going to try and go through each of these drivers in /sys/dev/ and converting them, very soon. > > (2) While loopback interfaces don't really have a link state, they can be > administratively down -- should/do you check that as well as link state? > And more generally, even if link is up, administratively down should be > obeyed? > For loopback interfaces, althgouth administrative these can be taken down, I personally cannot think one practical usage case where ECMP across loopback interfaces would be interesting or usefaul. So I can think of very little reason to be concerned in the loopback case. > > Finally, it would be neat if there were a way to have information beyond > link state influence the choice to balance to a particular route/interface. > For example, imagine if I have a router with ECMP, and on the other side on > a single ethernet segment, I have two DSL modems. The ethernet link will > remain up, but I may (via out-of-band mechanisms, such as SNMP or an active > probe) be able to tell that one of the DSL lines is down. Is there a way to > push that information into the kernel currently without deleting the routes, > and instead say "yeah, but for ECMP purposes this is 'down'"? > The above really falls into policy based routing. And policy based routing infrastrucutre is something I have already been working on but cannot yet push back into -current. In fact Julian and I had a conversation about this topic during the FIBs implementation time in late 2008. This infrastructure enhancement is definitely coming but I cannot yet prvoide a timeline for merge back. It's mostly a time issue. Let me know if I have answered these questions to your satisfaction. -- Qing ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r205024 - head/sys/net
I guess it's a good time to clean things up. The if_link_state code has been around for quite some time, either it be fully utilized or not be there at all. The inconsistency is the root cause. I will try going through these tonight and hopefully the fix all take a common approach. -- Qing On Thu, Mar 11, 2010 at 3:35 PM, Juli Mallett wrote: > On Thu, Mar 11, 2010 at 15:30, Qing Li wrote: >>> >>> A couple of questions: >>> >>> (1) It used to be the case that quite a few interface drivers and types >>> didn't have a notion of "link up" -- especially older ethernet devices. Do >>> those all have the same problem? It was probably a design oversight that >>> devices don't declare an explicit capability for "can report link state". >>> >> >> What you raised is definitely a possibility and these fixes take the >> similar approach. I am going to try and go through each of these >> drivers in /sys/dev/ and converting them, very soon. > > Go through drivers in the embedded port directories, too. The Octeon > port's Ethernet driver was broken by this, and it looks like the > Atheros if_arge is probably broken, too. I would even suggest going > back to the old behavior briefly while the port maintainers are given > an opportunity to update their drivers. Actually, it looks like only > MIPS has Ethernet drivers outside of dev/ at a quick glance, but I'd > be surprised if there weren't other broken examples. > > Juli. > ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r205024 - head/sys/net
> > If you can think of a way to add some invariants (warn the first time > a driver receives a packet without having ever set the link state, > make sure the media status callback sets the valid flag in the > request, etc) that would probably be very helpful for people who are > writing network drivers. If I hadn't been following the threads about > your changes, I would have had to spend much longer fixing the Octeon > port's Ethernet driver, wondering why suddenly it broke and > instrumenting the routing code. A printf would go a long way. > You definitely have a very good point here. I was a bit surprised during debugging that the link state is not consistently initialized and by far not enforced across all of the drivers. Admittedly I checked the most commonly deployed devices and they are in good state. I certainly appreciate your patience on this one and will try to get it resolved quickly. -- Qing ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r205024 - head/sys/net
That's a good idea. I will take your approach. -- Qing On Thu, Mar 11, 2010 at 11:15 PM, Julian Elischer wrote: > Juli Mallett wrote: >> >> On Thu, Mar 11, 2010 at 15:39, Qing Li wrote: >>> >>> I guess it's a good time to clean things up. The if_link_state code has >>> been >>> around for quite some time, either it be fully utilized or not be there >>> at all. >>> The inconsistency is the root cause. >> >> Sure. There is an increasing amount of stuff that network drivers are >> expected to do, but they work without doing them. It's easy to think >> you have a functioning network driver and that you can get by without >> adding support for media changes and link status reporting, etc. >> >>> I will try going through these tonight and hopefully the fix all take a >>> common approach. > > probably should add a flag that means "we have media state" > and if it is not set, assume it is always on. > >> >> If you can think of a way to add some invariants (warn the first time >> a driver receives a packet without having ever set the link state, >> make sure the media status callback sets the valid flag in the >> request, etc) that would probably be very helpful for people who are >> writing network drivers. If I hadn't been following the threads about >> your changes, I would have had to spend much longer fixing the Octeon >> port's Ethernet driver, wondering why suddenly it broke and >> instrumenting the routing code. A printf would go a long way. >> >> Juli. > > ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r205024 - head/sys/net
> > Is there any way we can pick up via an assertion that an interface driver has > failed to implement this functionality? This has never been a historic > requirement, so I suspect there are a lot of drivers floating around that > fail to meet the requirement. Also, is this for IFT_ETHER only, or also other > link types? > Not sure if I get the assertion suggestion. How would an assertion help here ? -- Qing ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r205024 - head/sys/net
I like Julian's suggestion because it is simple and very low risk. And there isn't a need to check for interface type any more. Here is why: 1. The interfaces that are popular and modern are already supporting link_state. So for these drivers, and there are just a few, I will go set its if_flags to include "can change link_state". 2. For the existing dated drivers, because that flag bit is never set, no check is done. 3. In the mean time, we try to convert the drivers progressively. 4. If one wants to do ECMP and not having packets go into a black hole when the physical link is down, that person can ping the ML and ask for driver compatibility list. If we haven't converted that particular driver by then, we will update the driver if it's capable at that time. -- Qing On Fri, Mar 12, 2010 at 12:00 AM, Robert N. M. Watson wrote: > > On Mar 12, 2010, at 7:52 AM, Qing Li wrote: > >>> Is there any way we can pick up via an assertion that an interface driver >>> has failed to implement this functionality? This has never been a historic >>> requirement, so I suspect there are a lot of drivers floating around that >>> fail to meet the requirement. Also, is this for IFT_ETHER only, or also >>> other link types? >> >> Not sure if I get the assertion suggestion. How would an assertion help here >> ? > > I think my proposal is similar to what Juli is suggesting: > > - Define a new interface capability for link state detection. > - If a packet is sent or received on the interface, the capability is set, > but the link state hasn't been set, panic. > - If a packet is sent received on the interface, the capability isn't set, > and the link state has been set, panic. > > That way the system blows up nicely and immediately, rather than dhclient > simply never working, etc. Also, that way, testing for link state support is > done at a point when we know the interface is live (a packet is sent or > received). > > Finally, it means that code interested in link state isn't testing for one of > (n) IFT_ types it thinks should have link state, but instead testing > specifically whether the driver declares link state support. Of course, then > you have to decide how to behave if a configured interface ECMP is running on > doesn't support link state: the answer there is probably to assume it is > always up, which would make this work for all those drivers that current fail > to implement it. And if the hardware can't support link state, which some > historic (and perhaps future) link types can't, things still work. > > Robert ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r205024 - head/sys/net
I believe what Julian means is the following: 1. in the driver, I do this ifp->if_flags |= IFF_KNOWS_LINK_STATE; 2. In route.h, I do this if (ifp->flags & IFF_KNOWS_LINK_STATE) && (ifp->if_link_state == LINK_STATE_UP) return 1; -- Qing On Fri, Mar 12, 2010 at 12:26 AM, Robert N. M. Watson wrote: > > On Mar 12, 2010, at 8:11 AM, Qing Li wrote: > >> I like Julian's suggestion because it is simple and very low risk. >> And there isn't a need to check for interface type any more. >> Here is why: >> >> 1. The interfaces that are popular and modern are already supporting >> link_state. So for these drivers, and there are just a few, I will go set >> its if_flags to include "can change link_state". >> >> 2. For the existing dated drivers, because that flag bit is never set, >> no check is done. >> >> 3. In the mean time, we try to convert the drivers progressively. >> >> 4. If one wants to do ECMP and not having packets go into a black >> hole when the physical link is down, that person can ping the ML >> and ask for driver compatibility list. If we haven't converted that >> particular driver by then, we will update the driver if it's capable >> at that time. > > > Today, we support three link state values: > > 170 /* > 171 * Values for if_link_state. > 172 */ > 173 #define LINK_STATE_UNKNOWN 0 /* link invalid/unknown */ > 174 #define LINK_STATE_DOWN 1 /* link is down */ > 175 #define LINK_STATE_UP 2 /* link is up */ > > I'm confused about Julian's proposal because it seems to me that we already > know when a driver hasn't set or is unable to determine the link state: it > will (should) be set to LINK_STATE_UNKNOWN by default. > > So the only question we don't know the answer to, at run-time, is whether a > driver may *ever* set the link state (i.e., it thinks it knows how to), and > hence whether or not tools like dhclient should try to wait for that to > happen. That is the problem that an interface capability would solve. > > For the purposes of ECMP, you just need to decide on your policy: map UNKNOWN > to either UP or DOWN for your purposes. > > Robert ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r205024 - head/sys/net
Nope, I meant Julian, and what he proposed, and if I understood correctly, is the simplest approach and easily done. -- Qing On Fri, Mar 12, 2010 at 12:29 AM, Robert N. M. Watson wrote: > > On Mar 12, 2010, at 8:11 AM, Qing Li wrote: > >> I like Julian's suggestion because it is simple and very low risk. >> And there isn't a need to check for interface type any more. >> Here is why: > > Re-reading this e-mail: perhaps you mean Juli, not Julian? > ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r205077 - head/sys/net
Author: qingli Date: Fri Mar 12 10:24:58 2010 New Revision: 205077 URL: http://svn.freebsd.org/changeset/base/205077 Log: The flow-table module retrieves the destination and source address as well as the transport protocol port information from the outbound packets. The routing code is generic and compares every byte in the given sockaddr object. Therefore the temporary sockaddr objects must be cleared due to padding bytes. In addition, the port information must be stripped or the route search will either fail or return the incorrect route entry. Unit testing is done using OpenVPN over the if_tun interface. MFC after:7 days Modified: head/sys/net/flowtable.c Modified: head/sys/net/flowtable.c == --- head/sys/net/flowtable.cFri Mar 12 10:01:06 2010(r205076) +++ head/sys/net/flowtable.cFri Mar 12 10:24:58 2010(r205077) @@ -593,6 +593,8 @@ flowtable_lookup_mbuf4(struct flowtable dsin = (struct sockaddr_in *)&dsa; ssin = (struct sockaddr_in *)&ssa; + bzero(dsin, sizeof(*dsin)); + bzero(ssin, sizeof(*ssin)); flags = ft->ft_flags; if (ipv4_mbuf_demarshal(ft, m, ssin, dsin, &flags) != 0) return (NULL); @@ -796,6 +798,8 @@ flowtable_lookup_mbuf6(struct flowtable dsin6 = (struct sockaddr_in6 *)&dsa; ssin6 = (struct sockaddr_in6 *)&ssa; + bzero(dsin6, sizeof(*dsin6)); + bzero(ssin6, sizeof(*ssin6)); flags = ft->ft_flags; if (ipv6_mbuf_demarshal(ft, m, ssin6, dsin6, &flags) != 0) @@ -1088,6 +1092,14 @@ flowtable_lookup(struct flowtable *ft, s ro = &sro; memcpy(&ro->ro_dst, dsa, sizeof(struct sockaddr_in)); + /* +* The harvested source and destination addresses +* may contain port information if the packet is +* from a transport protocol (e.g. TCP/UDP). The +* port field must be cleared before performing +* a route lookup. +*/ + ((struct sockaddr_in *)&ro->ro_dst)->sin_port = 0; dsin = (struct sockaddr_in *)dsa; ssin = (struct sockaddr_in *)ssa; if ((dsin->sin_addr.s_addr == ssin->sin_addr.s_addr) || @@ -1105,6 +1117,7 @@ flowtable_lookup(struct flowtable *ft, s ro = (struct route *)&sro6; memcpy(&sro6.ro_dst, dsa, sizeof(struct sockaddr_in6)); + ((struct sockaddr_in6 *)&ro->ro_dst)->sin6_port = 0; dsin6 = (struct sockaddr_in6 *)dsa; ssin6 = (struct sockaddr_in6 *)ssa; ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r205024 - head/sys/net
> > We've got LINK_STATE_UNKNOWN, we can just initialize if_link_state to > this value in ether_ifattach(). And Qing should treat this value as > LINK_STATE_UP in routing decision until better times. > Thanks everyone for your input. I generally try to avoid overloading a variable to have more than 1 meaning. For example, the if_tun interface is in LINK_STATE_UNKNOWN until it's opened, then the link can be one of the other two states. Also, some of the pseudo drivers such as if_tun do not call ether_ifattach(). Right now I like to implement Robert's suggestion of using if_capabilities field. I'd like to create a new flag, IFCAP_LINKSTATE_NOTIFY flag. The routing decision will check against the if_link_state if this bit is set. Only a handful of drivers have this capability. So updating those drivers is a small task. Do we agree on this approach? -- Qing ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r205222 - in head: sbin/ifconfig sys/net
Author: qingli
Date: Tue Mar 16 17:59:12 2010
New Revision: 205222
URL: http://svn.freebsd.org/changeset/base/205222
Log:
Verify interface up status using its link state only
if the interface has such capability. The interface
capability flag indicates whether such capability
exists. This approach is much more backward compatible.
Physical device driver changes will be part of another
commit.
Also updated the ifconfig utility to show the LINKSTATE
capability if present.
Reviewed by: rwatson, imp, juli
MFC after:3 days
Modified:
head/sbin/ifconfig/ifconfig.c
head/sys/net/if.h
head/sys/net/if_tap.c
head/sys/net/if_tun.c
head/sys/net/route.h
Modified: head/sbin/ifconfig/ifconfig.c
==
--- head/sbin/ifconfig/ifconfig.c Tue Mar 16 17:45:16 2010
(r205221)
+++ head/sbin/ifconfig/ifconfig.c Tue Mar 16 17:59:12 2010
(r205222)
@@ -881,7 +881,7 @@ unsetifdescr(const char *val, int value,
#defineIFCAPBITS \
"\020\1RXCSUM\2TXCSUM\3NETCONS\4VLAN_MTU\5VLAN_HWTAGGING\6JUMBO_MTU\7POLLING" \
"\10VLAN_HWCSUM\11TSO4\12TSO6\13LRO\14WOL_UCAST\15WOL_MCAST\16WOL_MAGIC" \
-"\21VLAN_HWFILTER\23VLAN_HWTSO"
+"\21VLAN_HWFILTER\23VLAN_HWTSO\24LINKSTATE"
/*
* Print the status of the interface. If an address family was
Modified: head/sys/net/if.h
==
--- head/sys/net/if.h Tue Mar 16 17:45:16 2010(r205221)
+++ head/sys/net/if.h Tue Mar 16 17:59:12 2010(r205222)
@@ -219,6 +219,7 @@ struct if_data {
#defineIFCAP_VLAN_HWFILTER 0x1 /* interface hw can filter vlan
tag */
#defineIFCAP_POLLING_NOCOUNT 0x2 /* polling ticks cannot be
fragmented */
#defineIFCAP_VLAN_HWTSO0x4 /* can do IFCAP_TSO on VLANs */
+#defineIFCAP_LINKSTATE 0x8 /* the runtime link state is
dynamic */
#define IFCAP_HWCSUM (IFCAP_RXCSUM | IFCAP_TXCSUM)
#defineIFCAP_TSO (IFCAP_TSO4 | IFCAP_TSO6)
Modified: head/sys/net/if_tap.c
==
--- head/sys/net/if_tap.c Tue Mar 16 17:45:16 2010(r205221)
+++ head/sys/net/if_tap.c Tue Mar 16 17:59:12 2010(r205222)
@@ -443,6 +443,8 @@ tapcreate(struct cdev *dev)
ifp->if_mtu = ETHERMTU;
ifp->if_flags = (IFF_BROADCAST|IFF_SIMPLEX|IFF_MULTICAST);
ifp->if_snd.ifq_maxlen = ifqmaxlen;
+ ifp->if_capabilities |= IFCAP_LINKSTATE;
+ ifp->if_capenable |= IFCAP_LINKSTATE;
dev->si_drv1 = tp;
tp->tap_dev = dev;
Modified: head/sys/net/if_tun.c
==
--- head/sys/net/if_tun.c Tue Mar 16 17:45:16 2010(r205221)
+++ head/sys/net/if_tun.c Tue Mar 16 17:59:12 2010(r205222)
@@ -386,6 +386,8 @@ tuncreate(const char *name, struct cdev
ifp->if_snd.ifq_drv_maxlen = 0;
IFQ_SET_READY(&ifp->if_snd);
knlist_init_mtx(&sc->tun_rsel.si_note, NULL);
+ ifp->if_capabilities |= IFCAP_LINKSTATE;
+ ifp->if_capenable |= IFCAP_LINKSTATE;
if_attach(ifp);
bpfattach(ifp, DLT_NULL, sizeof(u_int32_t));
Modified: head/sys/net/route.h
==
--- head/sys/net/route.hTue Mar 16 17:45:16 2010(r205221)
+++ head/sys/net/route.hTue Mar 16 17:59:12 2010(r205222)
@@ -319,8 +319,7 @@ struct rt_addrinfo {
#ifdef _KERNEL
-#define RT_LINK_IS_UP(ifp) (((ifp)->if_flags & \
- (IFF_LOOPBACK | IFF_POINTOPOINT)) \
+#define RT_LINK_IS_UP(ifp) (!((ifp)->if_capabilities & IFCAP_LINKSTATE) \
|| (ifp)->if_link_state == LINK_STATE_UP)
#defineRT_LOCK_INIT(_rt) \
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r205268 - head/sys/dev/mii
Author: qingli Date: Wed Mar 17 22:12:12 2010 New Revision: 205268 URL: http://svn.freebsd.org/changeset/base/205268 Log: Set the device capabilities to include dynamic link-state for those modern drivers. Reviewed by: imp (and suggested by imp) MFC after:3 days Modified: head/sys/dev/mii/mii.c Modified: head/sys/dev/mii/mii.c == --- head/sys/dev/mii/mii.c Wed Mar 17 21:19:30 2010(r205267) +++ head/sys/dev/mii/mii.c Wed Mar 17 22:12:12 2010(r205268) @@ -173,6 +173,8 @@ miibus_attach(device_t dev) * XXX: EVIL HACK! */ mii->mii_ifp = *(struct ifnet**)device_get_softc(device_get_parent(dev)); + mii->mii_ifp->if_capabilities |= IFCAP_LINKSTATE; + mii->mii_ifp->if_capenable |= IFCAP_LINKSTATE; ivars = device_get_ivars(dev); ifmedia_init(&mii->mii_media, IFM_IMASK, ivars->ifmedia_upd, ivars->ifmedia_sts); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r205272 - head/usr.sbin/ppp
Author: qingli Date: Thu Mar 18 00:23:39 2010 New Revision: 205272 URL: http://svn.freebsd.org/changeset/base/205272 Log: Need to set the proper flag bit when inserting ARP entries into the kernel. MFC after:3 days Modified: head/usr.sbin/ppp/arp.c Modified: head/usr.sbin/ppp/arp.c == --- head/usr.sbin/ppp/arp.c Wed Mar 17 22:57:58 2010(r205271) +++ head/usr.sbin/ppp/arp.c Thu Mar 18 00:23:39 2010(r205272) @@ -119,7 +119,7 @@ arp_ProxySub(struct bundle *bundle, stru return 0; } arpmsg.hdr.rtm_type = add ? RTM_ADD : RTM_DELETE; - arpmsg.hdr.rtm_flags = RTF_ANNOUNCE | RTF_HOST | RTF_STATIC; + arpmsg.hdr.rtm_flags = RTF_ANNOUNCE | RTF_HOST | RTF_STATIC | RTF_LLDATA; arpmsg.hdr.rtm_version = RTM_VERSION; arpmsg.hdr.rtm_seq = ++bundle->routing_seq; arpmsg.hdr.rtm_addrs = RTA_DST | RTA_GATEWAY; ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
