Charlet, Ricky | 24 Apr 23:44 2015

patch for duplicate tcp acks


        I was suffering duplicate tpc acks.  It seems trivial to duplicate.... Any time I receive a non-zero len tcp
packet, I ack it twice.  Note that I'm using a window scale of 3 and that may or may come into play.

        Anyway, did some debugging and some comparing. I found a patch for this problem in freebsd.

Here is how I applied it to netbsd (diff included below). It works for me. But I'm on an embedded system with a
funky compiler and modified source.  I'm giving this patch to the list in hopes that someone will feel like
compiling / testing it in a truer netbsd kernel.

Index: src/sys/netinet/tcp_output.c
RCS file: /cvsroot/src/sys/netinet/tcp_output.c,v
retrieving revision 1.173
diff -r1.173 tcp_output.c
<               long adv = min(win, (long)TCP_MAXWIN << tp->rcv_scale) -
<                       (tp->rcv_adv - tp->rcv_nxt);
>               long adv;
>               int oldwin;
>               adv = fp_min(win, (long)FP_TCP_MAXWIN << tp->rcv_scale);
>               if (SEQ_GT(tp->rcv_adv, tp->rcv_nxt)) {
>                               oldwin = (tp->rcv_adv - tp->rcv_nxt);
>                               adv -= oldwin;
>               } else
>                               oldwin = 0;
(Continue reading)

Mouse | 24 Apr 01:48 2015

ping6 -o?

On the machines I have ready access to, ping6 lacks ping's -o flag.

Is there any particular reason for this?  I find myself wanting it.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at>
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Roy Marples | 21 Apr 10:46 2015

IPv4 Address Flags

Hi List

As discussed here [1], a few people voiced their opinion that they
didn't like address removal when the carrier drops and would rather
re-negotiate at carrier up. The first step of doing this is to add IPv6
address flag semantics to IPv4 addresses.

This patch adds the following flags to IPv4 and mimics the IPv6
behaviour of the same flags:

ioctl SIOCGIFAFLAG_IN has been added to retrieve the flags using a ifreq
struct (ifaliasreq is probably better but then we run into compatibility
issues, also why IN_IFF_NODAD is not implemented).

ifconfig(8) has been modified to report the new flags and wait for
tentative to vanish via -w alongside the IPv6 addresses.

sysctl(8) now has these new values:

DAD is implemented according to RFC 5227.
A future patch could be made to implement address defence from the RFC,
but this is optional (although required for IPv4LL, but dhcpcd will
handle that).

(Continue reading)

Tyler Retzlaff | 19 Apr 22:52 2015

mbuf -> sockaddr patch for get{sock,peer}name and accept


attached is the next patch for converting protocol
user-request methods to use sockaddr * instead of mbuf *.
This patch covers getsockname, getpeername and accept.

The only part of the patch I think needs help is what to do
with the ktrkuser(mbuftypes[MT_SONAME], addr, len) call from
copyout_sockname_sb().  Obviously mbuftypes[] makes no real
sense and addr is not in alias of an mbuf.  What should be
done with the ktrace hook?

comments welcome


Index: compat/svr4/svr4_stream.c
RCS file: /cvsroot/src/sys/compat/svr4/svr4_stream.c,v
retrieving revision 1.83
diff -p -u -r1.83 svr4_stream.c
--- compat/svr4/svr4_stream.c	19 Apr 2015 19:17:37 -0000	1.83
+++ compat/svr4/svr4_stream.c	19 Apr 2015 20:50:25 -0000
 <at>  <at>  -872,11 +872,12  <at>  <at>  svr4_stream_ti_ioctl(file_t *fp, struct 
 	struct svr4_strm *st = svr4_stream_get(fp);
 	int error;
 	struct svr4_strmcmd sc;
-	struct mbuf *name;
(Continue reading)

John Klos | 6 Apr 06:07 2015

Networking strangeness in NetBSD 7


I've been using NetBSD machines for NAT and firewalling for many years. As 
of NetBSD 7, though, I'm seeing several strange things.

First, dhcpd and rtadvd packets are somehow bleeding in to the wrong 
interfaces. An example is running rtadvd on wm0 and seeing advertisements 
being given to machines on re0. Here's what a client saw:

01:11:49.852530 IP6 :: > ff02::1:fff5:81b1: ICMP6, neighbor solicitation, 
who has 2001:470:a068:2b:8649:d273:62f5:81b1, length 24

I checked, double checked and triple checked the settings and even double 
checked the physical wiring - the machine running rtadvd was told to use 
wm0 and the interface which it had in common with the client that received 
that router solicitation was on a separate segment via re0.

When I ran tcpdump on wm0 on the machine running rtadvd, the problem 
didn't occur. When I stopped tcpdump, the client got the same reply to 

I've also been seeing something similar with dhcpd on a different machine 
which is a different architecture and has different interfaces. In this 
case, I'm seeing things like this:

Mar 20 16:16:59 cheese /netbsd: b4:f2:e8:ea:4c:a8 on aue0 tried to overwrite arp info for on mvgbe0
Mar 20 16:16:59 cheese dhcpd: DHCPREQUEST for ( from b4:f2:e8:ea:4c:a8
(DIRECTV-HR34-E8EA4CA8) via mvgbe0
Mar 20 16:16:59 cheese dhcpd: DHCPACK on to b4:f2:e8:ea:4c:a8 (DIRECTV-HR34-E8EA4CA8)
via mvgbe0
(Continue reading)

Roy Marples | 2 Apr 21:58 2015

Dealing with ICMPv6 network unreachable.

Hi List!

I'm currently holidaying in Spain, and my apartments router is giving me
no end of grief. It claims it's a IPv6 router with the address fe80::1
but with no prefix information. Interestingly enough it is serving DNS
and DHCP on v6 as well.

Anyway, the problem is that because it's added a default route, various
programs will try IPv6 first. For each address tried, the router issues
an ICMPv6 unreachable message of code 0. This is displayed with ping -v
as well, so it is hitting userland. However, applications are ignoring
it. My simple test case is wget (available in pkgsrc).

On NetBSD, using wget on a IPv6 host, such as, will try
IPv6 first. It then stalls, ignoring the ICMP unreachable message.
On Linux (running in QEMU on the same NetBSD host) the same wget command
tries the IPv6 host first but reports that it's unreachable and moves
onto the IPv4 address which works fine. This is quite a fast operation.
Other applications, such as ssh and firefox also have long stalls before
falling back to IPv4 and again the fallback is quite prompt in Linux.

I've looked over the icmp and routing code but am at a total loss how or
even if this is supposed to work. Any help would be appreciated so I can
resolve this before I head home!


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)