Roy Marples | 19 Mar 21:29 2015



FreeBSD added RTF_BROADCAST a very long time ago.
I'd like to add it to NetBSD to make it clear what the route is for and
to avoid a potentially expensive call to in_broadcast() in ip_output().
It also avoids a needless allocation for the storage of llinfo_arp and
thus vanishes from the output of arp(8) - it always showed as incomplete
so this is a nice side effect.

FreeBSD also uses RTF_BROADCAST as a check to drop packets in
ip_fastforward() .... the closest match I can find is our
ipflow_fastforward() where I made a similar change and ensuring the
route is not RTF_BLACKHOLE either.
Oddly FreeBSD does not have the same functionality for IPv6 as I can
find, but we do so I added a check there as well.
If you are wondering why there is not a check for RTF_BROADCAST in
ip6_fastforward() it's because broadcast addresses are a IPv4 only concept.

I've been running this patch on a few machines, including my router, for
a few days now without any adverse effects.
Commentary welcome.

Index: sys/net/route.h
RCS file: /cvsroot/src/sys/net/route.h,v
retrieving revision 1.87
diff -u -r1.87 route.h
(Continue reading)

Tyler Retzlaff | 14 Mar 15:57 2015

patch: sockaddr instead of mbuf to carry addresses


attached is the first of a set of patches intended to remove the use of 
mbuf as a bucket to carry sockaddr structures for per-user requests. 
this patch introduces the structure required and changes bind.

i've been running it myself, the atf tests work with it and there has 
been some private review prior to posting.

comments welcome

Index: sys/compat/linux/common/linux_socket.c
RCS file: /cvsroot/src/sys/compat/linux/common/linux_socket.c,v
retrieving revision 1.122
diff -u -p -r1.122 linux_socket.c
--- sys/compat/linux/common/linux_socket.c	26 Nov 2014 09:53:53 -0000	1.122
+++ sys/compat/linux/common/linux_socket.c	14 Mar 2015 14:47:37 -0000
 <at>  <at>  -121,6 +121,8  <at>  <at>  int linux_getifconf(struct lwp *, regist
 int linux_getifhwaddr(struct lwp *, register_t *, u_int, void *);
 static int linux_get_sa(struct lwp *, int, struct mbuf **,
 		const struct osockaddr *, unsigned int);
+static int linux_get_sa_sb(struct lwp *, int, struct sockaddr_big *,
+		const struct osockaddr *, socklen_t);
 static int linux_sa_put(struct osockaddr *osa);
 static int linux_to_bsd_msg_flags(int);
 static int bsd_to_linux_msg_flags(int);
 <at>  <at>  -1445,14 +1447,14  <at>  <at>  linux_sys_bind(struct lwp *l, const stru
(Continue reading)

Ryota Ozaki | 2 Mar 10:05 2015

if_vlan extra padding


We found extra frame padding in vlan(4).

Here vlan pads a frame with zeros up to 68 bytes
that if the frame is untagged, it keeps 64 bytes
at least. However, it lacks concern about CRC
(4 bytes). So a sending frame will be 68 + 4 = 72 bytes.

Our fix pads up to 64 bytes like the below patch.
How about the fix? Any comments?

FYI FreeBSD also pads up to 64 bytes:
(it pads before tagging though.)


diff --git a/sys/net/if_vlan.c b/sys/net/if_vlan.c
index 2d5b861..02b6686 100644
--- a/sys/net/if_vlan.c
+++ b/sys/net/if_vlan.c
 <at>  <at>  -806,9 +806,10  <at>  <at>  vlan_start(struct ifnet *ifp)
                                 * after deleting a tag.
                                if (m->m_pkthdr.len <
-                                   (ETHER_MIN_LEN + ETHER_VLAN_ENCAP_LEN)) {
(Continue reading)

Robert Swindells | 1 Mar 01:16 2015

mbuf flags

I'm going to add an extra mbuf flag for SCTP, is there a preferred style
to use for it ?

Right now we have M_LINK[0-7] with the final one having a value of
0x80000, should I add the new flag before them and move them all up by
one bit or add it after ?

Also, keeping everything aligned would require adding an extra hex digit
to every one which would make it less clear what had really changed.

Nothing seems to be using M_LINK7 right now.

Robert Swindells

Ritesh Agrawal | 27 Feb 14:00 2015

DIAGNOSTIC panic in unp_gc function

Hi All,

I have been seeing random panics on my NetBSD-6.0 based system and this 
panic was in AF_LOCAL protocol code (uipc_usrreq.c). One of the panic was:

uvm_fault(0xffffffff81a195e0, 0x0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip ffffffff803042ff cs 8 rflags 10283 cr2  8 cpl 0 rsp
panic: trap
cpu1: Begin traceback...
printf_nolog() at netbsd:printf_nolog
startlwp() at netbsd:startlwp
alltraps() at netbsd:alltraps+0x96
unp_detach() at netbsd:unp_detach+0x2e
uipc_usrreq() at netbsd:uipc_usrreq+0x79
soclose() at netbsd:soclose+0x79
soo_close() at netbsd:soo_close+0x1a
closef() at netbsd:closef+0x4a
unp_thread() at netbsd:unp_thread+0x3cb
cpu1: End traceback...

I than installed the NetBSD kernel with "DIAGNOSTIC option" and the 
DIAGNOSTIC kernel paniced on following line no:

sys/kern/uipc_usrreq.c:1713 with current TOT for MAIN branch.

It seems that we can get into this code with file pointer reference 
count as 0.
I got into this situation by following steps:
(Continue reading)

Roy Marples | 27 Feb 13:34 2015

host route out of subnet

Hi List

I am working on an issue with managing a host route to a host outside of
the defined subnet.
We have a wiki on it here:

 # ifconfig fxp0 inet
 # route add -host -link fxp0 -iface
 # route add default -ifa

On -current at least, this fails.
netstat and route report the gateway as being an ethernet address made
from the letters fxp0 which also looks odd but seems to be a failing of
link_addr(3) or the way route and netstat display it.

On the other hand this works instead:

 # ifconfig fxp0 inet
 # route add -net -link fxp0 -iface -cloning
 # route add default -ifa

I have had a very unsatisfactory ad-hoc chat with a few people, so I'm
bring this here.

1) Is the route add -host command above expected to work as described in
the wiki? If so a simple fix is not to use link_addr(3) and instead set
sdl->sdl_index to the interface index. This makes it then work.
However, the kernel then displays an advisory of arpresolve: unresolved
and rt_expire == 0 so it might just be working by accident rather than
(Continue reading)

Roy Marples | 26 Feb 15:06 2015

carp(4) code reduction

Hi List

With todays changes in -current I think it's possible to reduce the code
in carp_setroute. I don't use carp(4) and have little idea how it works,
but the patch looks right and mirrors an improvement made in other BSD.

What I don't know if it's correct, or the improvement relies on other
pieces as well.
The patch can be found here:

I won't apply it until I get some testing feedback or can try it myself.



Roy Marples | 24 Feb 16:46 2015

RTF_LOCAL support

Hi List

FreeBSD and OpenBSD have added the routing flag RTF_LOCAL to indicate
the route represents a local address. They also create a local route for
each IPv4 address in a similar way to IPv6. dhcpcd and dhclient-script
do this for NetBSD as well, but it makes sense to move this into the
kernel for statically added addresses as well.

I have created a patch to do this for NetBSD which also moves the bulk
of the in6_if{add,rem}loop() functions into more generic
rt_ifa_{add,rem}local() functions and also renamed to
in6_if{add,rem}local(). in_if{add,rem}local() functions have also been
added to achieve the same functionality for IPv4.

One question though - sys/netinet/ip_carp.c has a large block of code
which looks like it handles this for IPv4. the IPv6 segment just calls
in6_{add,rem}loop(). Can this large block of code be changed to call
in_if{add,rem}local() for IPv4 or have I missed something? I don't know
anything about carp(4), hence asking.

Attachment (rtf_local.diff): text/x-diff, 22 KiB
Hauke Fath | 20 Feb 13:14 2015

ixg(4) and Intel X540?


I have a batch of servers here with an Intel X540-T1 10GbE card that I 
had hoped would be recognized as ixg(4) by NetBSD, but no...

pci1 at ppb0 bus 1
vendor 0x8086 product 0x1528 (ethernet network, revision 0x01) at pci1 
dev 0 function 0 not configured

OpenBSD 5.6 probes it as

ix0 at pci1 dev 0 function 0 "Intel X540T" rev. 0x01: msi, address 

but then fails to detect a carrier.

FreeBSD 10.1 probes it as

ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.15> 
mem 0xf6000000-0xf61fffff,0xf6200000-0xf6203fff irq 16 at device 0.0 on 
ix0: Using MSIX interrupts with 5 vectors
ix0: Ethernet address: a0:36:9f:23:21:fc
ix0: PCI Express Bus: Speed 5.0GT/s Width x8

and then fails to recognize the cd drive it just booted from, so I 
couldn't run ifconfig.

I understand that the NetBSD ixg(4) was ported from FreeBSD 
<>. What 
(Continue reading)

Robert Swindells | 18 Feb 21:10 2015

Adding const to in6_sin_2_v4mapsin6

Would anyone object to the following change ?

It makes it easier to use an address from the route cache as the
input to the address mapping.

Index: in6.c
RCS file: /cvsroot/src/sys/netinet6/in6.c,v
retrieving revision 1.180
diff -u -r1.180 in6.c
--- in6.c       2 Dec 2014 19:36:58 -0000       1.180
+++ in6.c       18 Feb 2015 19:39:39 -0000
 <at>  <at>  -2341,7 +2341,7  <at>  <at> 

 /* Convert sockaddr_in to sockaddr_in6 in v4 mapped addr format. */
-in6_sin_2_v4mapsin6(struct sockaddr_in *sin, struct sockaddr_in6 *sin6)
+in6_sin_2_v4mapsin6(const struct sockaddr_in *sin, struct sockaddr_in6 *sin6)
        memset(sin6, 0, sizeof(*sin6));
        sin6->sin6_len = sizeof(struct sockaddr_in6);
Index: in6.h
RCS file: /cvsroot/src/sys/netinet6/in6.h,v
retrieving revision 1.82
diff -u -r1.82 in6.h
--- in6.h       20 Jan 2015 21:27:36 -0000      1.82
+++ in6.h       18 Feb 2015 19:39:39 -0000
 <at>  <at>  -770,7 +770,7  <at>  <at> 
(Continue reading)

Manuel Bouyer | 13 Feb 17:37 2015

connect to vs ::

while trying to understand what apache is doing with pipes and why it
could end up hanging:

I though that maybe it could be related to these messages in the
[Sat Feb 15 14:18:42 2014] [warn] (51)Network is unreachable: connect to listener on [::]:80
[Sat Feb 15 14:18:43 2014] [warn] (51)Network is unreachable: connect to listener on [::]:80
[Sat Feb 15 14:18:44 2014] [warn] (51)Network is unreachable: connect to listener on [::]:80
[Sat Feb 15 14:18:45 2014] [warn] (51)Network is unreachable: connect to listener on [::]:80
[Sat Feb 15 14:18:46 2014] [warn] (51)Network is unreachable: connect to listener on [::]:80

After more analisis of the apache code, it turns out the master
connects to its own listeing socket as a way to wake up one of its
childs (this is dummy_connection() in mpm_common.c, called from
ap_mpm_pod_signal() and ap_mpm_pod_killpg()). 

We have a different behavior for ipv4 and ipv6:
antioche:/tmp#telnet :: 80
Trying ::...
telnet: Unable to connect to remote host: Network is unreachable
antioche:/tmp#telnet 80
Connected to
Escape character is '^]'.

and this cause apache to fail to wake its childs (and eventually fill up the
pipe, causing the problem I'm seeing now). Is it expected behavior ?
On a linux system, both and :: connects to localhost if
(Continue reading)