Re: Patches for RFC6937 and draft-ietf-tcpm-newcwv-00
On Thu, Jun 19, 2014 at 02:35:13PM -0700, George Neville-Neil wrote: On 4 Feb 2014, at 1:38, Eggert, Lars wrote: Hi, below are two patches that implement RFC6937 (Proportional Rate Reduction for TCP) and draft-ietf-tcpm-newcwv-00 (Updating TCP to support Rate-Limited Traffic). They were done by Aris Angelogiannopoulos for his MS thesis, which is at https://eggert.org/students/angelogiannopoulos-thesis.pdf. The patches should apply to -CURRENT as of Sep 17, 2013. (Sorry for the delay in sending them, we'd been trying to get some feedback from committers first, without luck.) Please note that newcwv is still a work in progress in the IETF, and the patch has some limitations with regards to the pipeACK Sampling Period mentioned in the Internet-Draft. Aris says this in his thesis about what exactly he implemented: The second implementation choice, is in regards with the measurement of pipeACK. This variable is the most important introduced by the method and is used to compute the phase that the sender currently lies in. In order to compute pipeACK the approach suggested by the Internet Draft (ID) is followed [ncwv]. During initialization, pipeACK is set to the maximum possible value. A helper variable prevHighACK is introduced that is initialized to the initial sequence number (iss). prevHighACK holds the value of the highest acknowledged byte so far. pipeACK is measured once per RTT meaning that when an ACK covering prevHighACK is received, pipeACK becomes the difference between the current ACK and prevHighACK. This is called a pipeACK sample. A newer version of the draft suggests that multiple pipeACK samples can be used during the pipeACK sampling period. Lars [prr.patch] [newcwv.patch] Apologies for not looking at this as yet. It is now closer to the top of my list. Best, George Hi George, I have a set of patches for draft-ietf-tcpm-newcwv-06 that I was going to bring to the list in the next few days. My implementation is a port of the Linux implementation by a colleague of mine at the University of Aberdeen. Feeback on how Aris hooked in his newcwv calls would be helpful. -- Tom @adventureloop adventurist.me #pragma summon cthulhu :wq ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: IPv6: xxx::x already configured in logs... why?
On 2014-06-19 23:08, Hiroki Sato wrote: Larry Rosenman l...@lerctr.org wrote in 20140619140801.ga65...@thebighonker.lerctr.org: le le Ideas? (I may be an idiot, so any criticism welcomed). le le le le if you need the 1841's config, I can supply that as well. It's using a Hurricane le le electric Tunnel. le le How frequent were the log message added into /var/log/messages? And le when did it start to happen after boot. Just after lagg0 is le configured? le le -- Hiroki le Looks like: le le Jun 12 07:00:01 thebighonker kernel: in6_ifadd: 2001:470:1f0f:3ad:223:7dff:fe9e:6e8a is already configured Thank you. Three more questions: 1. output of ifconfig lagg0, ifconfig bce0, and ifconfig bce1. 2. output of netstat -s -i. 3. output of ndp -p. The cause of the message is that the automatically-configured address is not recognized as configured one and FreeBSD IPv6 stack is trying to add it every time a Router Advertisement message is received. I am still not sure why it happened, but the above three would help for further investigation. -- Hiroki I updated the system from r267121M to r267653M and rebooted. The issue does NOT occur at this level. thebighonker.lerctr.org /etc/rc.d $ ifconfig lagg0 lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether 00:23:7d:9e:6e:8a inet 192.147.25.65 netmask 0xff00 broadcast 192.147.25.255 inet6 fe80::223:7dff:fe9e:6e8a%lagg0 prefixlen 64 scopeid 0x4 inet 192.147.25.45 netmask 0xff00 broadcast 192.147.25.255 inet 192.147.25.11 netmask 0xff00 broadcast 192.147.25.255 inet 192.147.25.66 netmask 0xff00 broadcast 192.147.25.255 inet6 2001:470:1f0f:3ad:223:7dff:fe9e:6e8a prefixlen 64 autoconf nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL media: Ethernet autoselect status: active laggproto loadbalance lagghash l2,l3,l4 laggport: bce1 flags=4ACTIVE laggport: bce0 flags=4ACTIVE thebighonker.lerctr.org /etc/rc.d $ ifconfig bce0 bce0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether 00:23:7d:9e:6e:8a inet6 fe80::223:7dff:fe9e:6e8a%bce0 prefixlen 64 tentative scopeid 0x1 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active thebighonker.lerctr.org /etc/rc.d $ ifconfig bce1 bce1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether 00:23:7d:9e:6e:8a inet6 fe80::223:7dff:fe9e:6e8a%bce1 prefixlen 64 tentative scopeid 0x2 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active thebighonker.lerctr.org /etc/rc.d $ thebighonker.lerctr.org /etc/rc.d $ netstat -s -i ip6 on bce0: 0 total input datagrams 0 datagrams with invalid header received 0 datagrams exceeded MTU received 0 datagrams with no route received 0 datagrams with invalid dst received 0 datagrams with unknown proto received 0 truncated datagrams received 0 input datagrams discarded 0 datagrams delivered to an upper layer protocol 0 datagrams forwarded to this interface 4 datagrams sent from an upper layer protocol 0 total discarded output datagrams 0 output datagrams fragmented 0 output datagrams failed on fragment 0 output datagrams succeeded on fragment 0 incoming datagrams fragmented 0 datagrams reassembled 0 datagrams failed on reassembly 0 multicast datagrams received 4 multicast datagrams sent ip6 on bce1: 0 total input datagrams 0 datagrams with invalid header received 0 datagrams exceeded MTU received 0 datagrams with no route received 0 datagrams with invalid dst received 0 datagrams with unknown proto received 0 truncated datagrams received 0 input datagrams discarded 0 datagrams delivered to an upper layer protocol 0 datagrams forwarded to this interface 4 datagrams sent from an upper layer protocol 0 total discarded output datagrams 0 output datagrams fragmented 0 output datagrams failed on fragment 0 output datagrams succeeded on fragment 0 incoming datagrams fragmented 0 datagrams reassembled 0 datagrams failed on reassembly 0 multicast datagrams received 4 multicast datagrams sent ip6 on lo0: 45224 total input datagrams 0 datagrams
Ordering problem in if_detach_internal regarding if_bridge
Hello,
I've stumbled across the following panic when testing Xen netback with
if_bridge:
Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex if_bridge (if_bridge) r = 0 (0xf80006306c18) locked @
/usr/src/sys/m
KDB: stack backtrace:
X_db_symbol_values() at X_db_symbol_values+0x10b/frame 0xfe213490
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe213540
witness_warn() at witness_warn+0x4a8/frame 0xfe213600
trap() at trap+0xc9d/frame 0xfe2136a0
trap() at trap+0x669/frame 0xfe2138b0
calltrap() at calltrap+0x8/frame 0xfe2138b0
--- trap 0xc, rip = 0x8221a0ef, rsp = 0xfe213970, rbp =
0xfe2139e0 ---
bridge_input() at bridge_input+0x5ff/frame 0xfe2139e0
ether_vlanencap() at ether_vlanencap+0x4a3/frame 0xfe213a10
netisr_dispatch_src() at netisr_dispatch_src+0x90/frame 0xfe213a80
ether_ifattach() at ether_ifattach+0x19f/frame 0xfe213ab0
ath_dfs_get_thresholds() at ath_dfs_get_thresholds+0x81ce/frame
0xfe213b30
intr_event_execute_handlers() at intr_event_execute_handlers+0x93/frame
0xfe213b70
db_dump_intr_event() at db_dump_intr_event+0x796/frame 0xfe213bb0
fork_exit() at fork_exit+0x84/frame 0xfe213bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe213bf0
--- trap 0, rip = 0, rsp = 0xfe213cb0, rbp = 0 ---
I've tracked this down to if_detach_internal setting ifp-if_addr to
NULL before calling EVENTHANDLER_INVOKE(ifnet_departure_event..., which
causes a panic in GRAB_OUR_PACKETS in the if_bridge code when it tries
to perform IF_LLADDR on an interface that's in the process of being
destroyed (ifp-if_addr set to NULL, but the ifnet_departure_event event
has not fired yet).
I have the following naive patch that moves the firing of the event
before if_addr is set to NULL, but I'm not familiar with the ordering
in if_detach_internal, so I'm not sure if this might cause problems in
other parts of the code, could someone familiar with the net stuff
comment on the best way to deal with it?
Thanks, Roger.
From 35430bcf6458bb5218268fd28f59bd911ea1ce2b Mon Sep 17 00:00:00 2001
From: Roger Pau Monne roger@citrix.com
Date: Fri, 20 Jun 2014 15:16:58 +0200
Subject: [PATCH]
---
sys/net/if.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/sys/net/if.c b/sys/net/if.c
index 47b5b9d..1b3227e 100644
--- a/sys/net/if.c
+++ b/sys/net/if.c
@@ -875,6 +875,10 @@ if_detach_internal(struct ifnet *ifp, int vmove)
#endif
if_purgemaddrs(ifp);
+ /* Announce that the interface is gone. */
+ rt_ifannouncemsg(ifp, IFAN_DEPARTURE);
+ EVENTHANDLER_INVOKE(ifnet_departure_event, ifp);
+
if (!vmove) {
/*
* Prevent further calls into the device driver via ifnet.
@@ -912,9 +916,6 @@ if_detach_internal(struct ifnet *ifp, int vmove)
}
}
- /* Announce that the interface is gone. */
- rt_ifannouncemsg(ifp, IFAN_DEPARTURE);
- EVENTHANDLER_INVOKE(ifnet_departure_event, ifp);
if (IS_DEFAULT_VNET(curvnet))
devctl_notify(IFNET, ifp-if_xname, DETACH, NULL);
if_delgroups(ifp);
--
1.7.7.5 (Apple Git-26)
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: network.subr vlan handling broken
Hi Hiroki,
On Fri, Jun 20, 2014 at 12:48:03PM +0900, Hiroki Sato wrote:
John Hay j...@meraka.org.za wrote
in 20140619103513.ga92...@zibbi.meraka.csir.co.za:
jh Hi Guys,
jh
jh freebsd-rc did not react, so I'm just checking on -net too.
jh
jh I found after upgrading that vlan handling broke. I tried the following:
jh
jh vlans_bce1=6
jh ipv4_addrs_bce1_6=inet 10.239.100.2/24
jh ifconfig_bce1_6_aliases=inet 10.239.100.2/24
jh ifconfig_bce1_6_alias0=inet 10.239.100.2/24
jh
jh I traced it down to ifalias_af_common_handler being called with the
jh mangled interfcace name _if and it then calls ifconfig with it. Here
jh is my fix. Any reason not to commit it? My diff is against 10-stable,
jh but head looks the same.
Can you try the attached patch? It seemed broken after list_vars()
was introduced. Replacing $_if with $1 also fixes it, but $_if
should be used for ifname as the other parts do.
I have tested ipv4 and ipv6 cases and it seems ok:
##
vlans_re1=6 7
ipv4_addrs_re1_6=inet 10.254.254.253/24
ifconfig_re1_6_aliases=inet 10.254.254.254/24
ifconfig_re1_6_ipv6=inet6 accept_rtadv
ifconfig_re1_7_ipv6=inet6 fd99:6829:597c:2::1 prefixlen 64
root@angel:/etc # ifconfig re1.6
re1.6: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=3RXCSUM,TXCSUM
ether 90:2b:34:df:ae:c4
inet6 fe80::922b:34ff:fedf:aec4%re1.6 prefixlen 64 scopeid 0x4
inet 10.254.254.254 netmask 0xff00 broadcast 10.254.254.255
inet 10.254.254.253 netmask 0xff00 broadcast 10.254.254.255
nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL
media: Ethernet autoselect (none)
status: no carrier
vlan: 6 parent interface: re1
root@angel:/etc # ifconfig re1.7
re1.7: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=3RXCSUM,TXCSUM
ether 90:2b:34:df:ae:c4
inet6 fd99:6829:597c:2::1 prefixlen 64
inet6 fe80::922b:34ff:fedf:aec4%re1.7 prefixlen 64 scopeid 0x5
nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
media: Ethernet autoselect (none)
status: no carrier
vlan: 7 parent interface: re1
root@angel:/etc #
##
Thanks
John
jh While looking through the code I saw that ltr is called with different
jh styling. Is there a reason for it? Which is the prefered style?
jh
jh ltr ${_if} ${_punct} '_' _if
jh ltr $_if $_punct _ _if
I do not think there is a reason.
I think there is no consensus about the style but I am using {} only
when boundary between the variable name and the subsequent characters
can be ambiguous.
-- Hiroki
Index: network.subr
===
--- network.subr (revision 267636)
+++ network.subr (working copy)
@@ -1077,7 +1077,7 @@
ifalias_af_common()
{
local _ret _if _af _action alias ifconfig_args _aliasn _c _tmpargs _iaf
- local _punct=.-/+
+ local _vif _punct=.-/+
_ret=1
_aliasn=
@@ -1086,11 +1086,11 @@
_action=$3
# Normalize $_if before using it in a pattern to list_vars()
- ltr $_if $_punct _ _if
+ ltr $_if $_punct _ _vif
# ifconfig_IF_aliasN which starts with $_af
- for alias in `list_vars ifconfig_${_if}_alias[0-9]\* |
- sort_lite -nk1.$((9+${#_if}+7))`
+ for alias in `list_vars ifconfig_${_vif}_alias[0-9]\* |
+ sort_lite -nk1.$((9+${#_vif}+7))`
do
eval ifconfig_args=\\$$alias\
_iaf=
@@ -1118,8 +1118,8 @@
# backward compatibility: ipv6_ifconfig_IF_aliasN.
case $_af in
inet6)
- for alias in `list_vars ipv6_ifconfig_${_if}_alias[0-9]\* |
- sort_lite -nk1.$((14+${#_if}+7))`
+ for alias in `list_vars ipv6_ifconfig_${_vif}_alias[0-9]\* |
+ sort_lite -nk1.$((14+${#_vif}+7))`
do
eval ifconfig_args=\\$$alias\
case ${_action}:${ifconfig_args} in
@@ -1129,7 +1129,7 @@
alias:*)
_aliasn=${_aliasn} inet6 ${ifconfig_args}
warn \$${alias} is obsolete. \
- Use ifconfig_$1_aliasN instead.
+ Use ifconfig_${_vif}_aliasN instead.
;;
esac
done
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
[Bug 185967] [lagg] [patch] Link Aggregation LAGG: LACP not working in 10.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967 kved...@kvedulv.de changed: What|Removed |Added CC||kved...@kvedulv.de --- Comment #9 from kved...@kvedulv.de --- This patch did solve my occasional problems with FreeBSD 10-STABLE and a Netgear GS110TP, so somebody should at least have a look at it (or scottl could just commit it). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
[Bug 185967] [lagg] [patch] Link Aggregation LAGG: LACP not working in 10.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967 --- Comment #10 from kved...@kvedulv.de --- Hi Oliver, (In reply to olivier from comment #8) The patch didn't solve Lagg regression between 9.2 and 10-stable (r267244). My configuration only use one lagg member (the second will be added later): _Maybe_ #179926 is your Bug and you could try the patch over there... (Although that problem seems to have existed at least in 9.1) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ifaddr refcount problem
On Fri, Jun 20, 2014 at 1:15 PM, Navdeep Parhar navd...@chelsio.com wrote:
Revision 264905 and 266860 that followed it seem to leak ifaddr
references. ifa_ifwithdstaddr and ifa_ifwithnet both install a
reference on the ifaddr returned to the caller but ip_output does not
release it, eventually leading to a panic when the refcount wraps over
to 0 and the ifaddr is freed while it is still on various lists.
Are you referring to the ifa_ref() calls at lines 1674, 1745, 1756,
and 1795 of sys/net/if.c? Those long predate 264905.Why do you
think that 264905 introduced the bug? If anything, I guess that it
was introduced by change 262747, which removed ifa_free() from the
done: block of ip_output().
I'm using this patch for now. Thoughts?
Regards,
Navdeep
diff -r 6dfcecd314af sys/netinet/ip_output.c
--- a/sys/netinet/ip_output.c Fri Jun 20 10:33:22 2014 -0700
+++ b/sys/netinet/ip_output.c Fri Jun 20 12:07:12 2014 -0700
@@ -243,6 +243,7 @@ again:
ifp = ia-ia_ifp;
ip-ip_ttl = 1;
isbroadcast = 1;
+ ifa_free((void *)ia);
} else if (flags IP_ROUTETOIF) {
if ((ia = ifatoia(ifa_ifwithdstaddr(sintosa(dst == NULL
(ia = ifatoia(ifa_ifwithnet(sintosa(dst), 0))) == NULL) {
@@ -253,6 +254,7 @@ again:
ifp = ia-ia_ifp;
ip-ip_ttl = 1;
isbroadcast = in_broadcast(dst-sin_addr, ifp);
+ ifa_free((void *)ia);
} else if (IN_MULTICAST(ntohl(ip-ip_dst.s_addr))
imo != NULL imo-imo_multicast_ifp != NULL) {
/*
I don't think this is quite right. ip_output() references ia at lines
366, 433, 630-637, 674, and 675. All of those references have NULL
checks, so your patch won't cause a use-after-free bug, but I think
that the patch might cause statistics collection to fail, and it might
cause the IP source address to not be set.
Do you have a test case that can reproduce the panic?
-Alan
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ifaddr refcount problem
On 06/20/14 15:20, Alan Somers wrote:
...
Do you have a test case that can reproduce the panic?
-Alan
Just run some UDP traffic on head or stable/10 and watch the refcount
leak on the transmitter.
# netperf -H ... -t UDP_STREAM
I see these two do ifa_ref (once per packet).
kernel`ip_output+0x527
kernel`udp_send+0xa88
kernel`sosend_dgram+0x583
kernel`kern_sendit+0x244
kernel`sendit+0x129
kernel`sys_sendto+0x4d
kernel`amd64_syscall+0x3fb
kernel`in_pcbladdr+0x160
kernel`in_pcbconnect_setup+0x18b
kernel`udp_send+0x3d7
kernel`sosend_dgram+0x583
kernel`kern_sendit+0x244
kernel`sendit+0x129
kernel`sys_sendto+0x4d
kernel`amd64_syscall+0x3fb
(kgdb) l *(ip_output + 0x527)
0x80ac37f7 is in ip_output (/usr/src/sys/netinet/ip_output.c:249).
244 ip-ip_ttl = 1;
245 isbroadcast = 1;
246 ifa_free((void *)ia);
247 } else if (flags IP_ROUTETOIF) {
248 if ((ia = ifatoia(ifa_ifwithdstaddr(sintosa(dst ==
NULL
249 (ia = ifatoia(ifa_ifwithnet(sintosa(dst), 0))) ==
NULL) {
250 IPSTAT_INC(ips_noroute);
251 error = ENETUNREACH;
252 goto bad;
253 }
And only this one does ifa_free (once per packet)
kernel`in_pcbladdr+0x1fb
kernel`in_pcbconnect_setup+0x18b
kernel`udp_send+0x3d7
kernel`sosend_dgram+0x583
kernel`kern_sendit+0x244
kernel`sendit+0x129
kernel`sys_sendto+0x4d
kernel`amd64_syscall+0x3fb
So there is a net leak of 1 refcount per packet.
Regards,
Navdeep
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
getpeername returning ENOTCONN for a connected socket
Reviving an old thread where Steve found this problem: A call to
getpeername on a connected tcp socket returns ENOTCONN with no prior
errors being reported by previous socket calls.
Please look at
http://lists.freebsd.org/pipermail/freebsd-net/2011-January/027647.html
for more details.
Here is a proposed patch derived from
$src/sys/netsmb/smb_trantcp.c:nbssn_recv()'s way of handling a similar
situation:
Index: sys/kern/uipc_syscalls.c
===
--- sys/kern/uipc_syscalls.c(revision 267693)
+++ sys/kern/uipc_syscalls.c(working copy)
@@ -1755,6 +1755,12 @@
if (error != 0)
return (error);
so = fp-f_data;
+ if ((so-so_state (SS_ISDISCONNECTED|SS_ISDISCONNECTING)) ||
+ (so-so_rcv.sb_state SBS_CANTRCVMORE)) {
+ error = ECONNRESET;
+ goto done;
+ }
if ((so-so_state (SS_ISCONNECTED|SS_ISCONFIRMING)) == 0) {
error = ENOTCONN;
goto done;
Does this look correct?
cheers,
Hiren
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: 6rd and DNS (bind/nsd) on FreeBSD
On 6/19/2014 4:57 AM, Massimiliano Stucchi wrote: On 19/06/14 05:11, Darren Pilgrim wrote: FreeBSD doesn't support 6rd. Ironically, pfSense does. This is not entirely true. 6RD is about establishing a 6to4 tunnel to a well-defined tunnel server in your provider's infrastructure, so as long as you have the details about the tunnel server's IP and the prefix you're assigned, you can easily do it manually (or, better, write a tiny script to do it for you). Do you have a working example? FreeBSD's stf interface doesn't support prefixes other than 2002::/16 or IPv4 mask lengths other than 0. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
