Richard Hansen | 23 Jul 08:53 2014

bind() to IPv6 link-local multicast group gives EADDRNOTAVAIL

Hi all,

I'm trying to troubleshoot an IPv6 multicast problem I'm experiencing on
NetBSD 6.1_STABLE.  When I run the following Python (2.6 or 2.7) script:

    import socket
    ip = 'ff02::101%re1' # replace re1 with the name of your interface
    port = 8123
    a = socket.getaddrinfo(ip, port, 0, socket.SOCK_DGRAM)[0]
    s = socket.socket(*a[0:3])
    addr = a[4]
    #addr = ('::',) + a[4][1:]

I get the following error:

    Traceback (most recent call last):
      File "./", line 8, in <module>
      File "<string>", line 1, in bind
    socket.error: [Errno 49] Can't assign requested address

Note that errno 49 is EADDRNOTAVAIL.  I'm guessing (but haven't
verified) that the EADDRNOTAVAIL comes from in6_pcbbind_addr() at
src/sys/netinet6/in6_pcb.c line 246, due to ifa_ifwithaddr() returning
NULL (of course that would return NULL -- no interface has the multicast
IPv6 address assigned to it).

The same script works on Linux as expected.  A similar program written
in C behaves like the Python script.
(Continue reading)

Tyler Retzlaff | 6 Jul 20:16 2014

pru & stat(2) failure / return cleanups


recently effort is being undertaken to separate out functions being
dispatched through the generic pr_usrreq() switches. as a result some
inconsistencies have been identified in failure / return of PRU_SENSE
requests (i.e. stat(2)).

issue #1 so_pcb is NULL

    across the range of protocols there is inconsistency in whether or not
    the so_pcb being NULL is an error.

    for protocols that allocate a pcb in attach should it ever be valid
    for socket->so_pcb to be NULL (except upon entry to attach)?

    currently only tcp & rip6 deviate from this expectation. tcp because of
    pr/46077 (which made PRU_SENSE not fail) and rip6 is probably just wrong.

issue #2 PRU_SENSE / stat(2) returning success, a lot

    most implementations of pr_stat don't fill any values / change the
    passed in struct stat *ub in any way but some of them return 0
    (success) and some of them return EOPNOTSUPP.

    i'd like to suggest that for all the cases where struct stat *ub is
    not being filled in they be changed to EOPNOTSUPP because it seems
    a bit wrong to do nothing at all and then claim success.

comments, clarification, education invited

(Continue reading)

Zafer Aydoğan | 6 Jul 15:20 2014

iscsi (initiator) unstable

Hello List,

I am new to the iscsi world and I am experiencing some difficulties getting
iscsi to work reliably with NetBSD without knowing the core reason.
I hope to figure it out and to fix the issues with this discussion.

Status Quo:
I have a server running 6.99.45 amd64 very smoothly and I have an
iscsi target in
the same network that I can connect to as described in iscsictl(8).

After the logging in the sd0 disk device is present (or dk0 when
formatted with gpt)
and I can successfully newfs and mount the disk.

Everything looks fine to this point.

But the trouble starts as soon as I am writing data to the new storage.

Copying files or creating a big sparse file (50 GB) with dd will stop
the connection
to the storage quite fast. Disk activity with small files will delay
the interruption. The smaller the later.
There is no obvious network problem. I can see packets flying around
until they suddenly stop.
When the connection stops, then the process is in state tstile (ps D).

Everything else works fine. No crash or hang.
I can cd to /storage but writes to the disk will not complete and
wedge in tstile as well.
(Continue reading)

Roy Marples | 5 Jul 23:48 2014

Shifting 128 bits

Hi List!

I'm struggling with bit shifting, trying to implement an RFC.

Basically there is code that deals with uint128_t - an IPv6 address.
As I cannot realistically use that in dhcpcd I need something else. 
However, this is very much out of my comfort zone and I'm not good at 
handling bits!

Here is the code

uint8_t   l = 69;
uint128_t p = a_ipv6address;
uint128_t i = p << l;

uint8_t *id = a_buffer;
uint8_t d = a_length;
while (d-- > 0) {
        *id++ = i >> 120;
        i <<= NBBY;

Can anyone help me please?



Thomas Bieg | 5 Jul 18:00 2014

Bridged ethernet with ipnat redirect to local port - getting ICMP redirects instead


I am stuck trying to redirect HTTP requests targeted outside to a local httpd
via a bridged and ipf'ed ethernet port.

The bridge machine is running NetBSD 6.1_STABLE as of two weeks ago with a
custom kernel that's basically GENERIC + BRIDGE_IPF enabled.

- re0 is, where the httpd is listening.
- re0 is connected to a LAN with as internet gateway (does DHCP and

- re1 has no ip.
- re1 is bridged to re0 with ipf enabled.
- re1 is directly connected to the machine (a "smart" TV actually) where the
   requests to be redirected are originating from (which succesfully gets its
   192.168.1.x IP from over the bridge and can access LAN and
   internet just fine if I allow it).

- ipnat.conf has:
   rdr re1 port 80 -> port 80

(IP forwarding is also enabled, but as I understand it, that shouldn't even be

I was expecting/hoping ipnat would silently redirect connections coming in on
re1 and intended for to the local httpd on re0, but instead it's sending
out ICMP redirects on re1.

Shouldn't that work? Or is there something I missed?
(Continue reading)

Petar Bogdanovic | 23 Jun 12:24 2014

something is randomly closing ssh-tunnels (was: ipfilter randomly dropping..)

During the past few weeks the ssh-tunnels to a remote machine started
failing randomly.  In a previous mail to tech-net I prematurely blamed
ipfilter because disabling it yielded some immediate success.

Unfortunately, subsequent testing showed that having npf enabled instead
eventually lead to the same issues.

What I know:

	* the server suddenly FINs the connection
	* the server ignores everything after that and sends about 20-30
	  RSTs for lots of late ACKs sent by the client
	* ipmon is able to track the connection but misses the FIN
	* yet ipfilter manages to update its state table and reduces the
	  TTL of the connection from 24h to 30s
	* a server-tcpdump captures the FIN
	* a client-tcpdump captures the same FIN
	* according to wireshark, the FINs in both pcaps have sequence
	  numbers that indicate lost segments (which at least in one
	  case makes little sense since it was captured directly at the
	* ssh and sshd both never try to tear down the connection
	* ssh reports that the remote end has closed the connection
	* sshd bails on a failed write() with ENETUNREACH
	* the success rate of the tunnel changes a lot, first it was 50%
	  then it was 100% and during the past few days it was almost 0%
	* server and client are managed very carefully by me and there
	  were no significant changes during the past 6+ months.

Now I'm thinking about compiling sshd with SO_DEBUG and a new kernel
(Continue reading)

Darren Reed | 12 Jun 00:53 2014

Patches for IPFilter

This patch fixes "ipfstat" not displaying group rules and fixes problems
being able to remove individual rules using ipf/ipnat.

#547 rule parsing puts junk at the end of ipf rules
#546 ipfstat -io does not list rules in groups aside from 0

Due to unforeseen circumstances I'm not able to commit this myself.


diff -r -u ipf/dist/lib/gethost.c.orig ipf/dist/lib/gethost.c
--- usr/external/bsd/ipf/dist/lib/gethost.c.orig	2012-07-23 00:27:36.000000000 +1000
+++ usr/external/bsd/ipf/dist/lib/gethost.c	2014-06-09 01:53:41.000000000 +1000
 <at>  <at>  -19,6 +19,7  <at>  <at> 
 	struct netent *n;
 	u_32_t addr;

+	bzero(hostp, sizeof(*hostp));
 	if (!strcmp(name, "")) {
 		if (family == AF_INET) {
 			hostp->in4.s_addr = htonl(0xfedcba98);
diff -r -u ipf/dist/tools/ipf_y.y.orig.orig ipf/dist/tools/ipf_y.y
--- usr/external/bsd/ipf/dist/tools/ipf_y.y.orig	2012-07-22 23:44:52.000000000 +1000
+++ usr/external/bsd/ipf/dist/tools/ipf_y.y	2014-06-09 00:25:29.000000000 +1000
 <at>  <at>  -2601,7 +2601,13  <at>  <at> 
 	int pos;

(Continue reading)

Petar Bogdanovic | 11 Jun 17:57 2014

ipfilter randomly dropping (ssh-)connections


about a week ago, the automated daily ssh-tunnels to a netbsd-6 box
started to close shortly after they were established (client said
"Connection closed by remote host"; server said: "fatal: Write failed:
Network is unreachable").  A quick tcpdump revealed that the server side
at one point just FINs the connection and then spams the client with a
bunch of TCP resets.

After a while of tcpdump and ktrace, disabling ipfilter (v4.1.34) solved
the problem.  Which was very confusing, because its ipf.conf hasn't
changed for years.

The following [1]issue seems similar.  I'm also attaching the [2]full
and [3]truncated pcaps of the failed ssh-session, and my [4]ipf.conf.

Maybe someone has some ideas about this.


		Petar Bogdanovic



[3]	tcpdump client (77.X.X.X):
23:12:30.295355 IP 85.X.X.X.22 > 77.X.X.X.65352: Flags [.], seq 5578992:5580440, ack 6391120, win
10341, options [nop,nop,TS val 31 ecr 31], length 1448
(Continue reading)

Edgar Fuß | 4 Jun 12:14 2014

multi-threaded nfsd, RPC SVCXPRT re-usage

During a discussion un the am-utils list, it emerged that the RPC library
apparantly doesn't allow one SVCXPRT to service two request in parallel 
(e.g. accept a second before the first has been replied to) because the 
structure contains (private) fields specific to a request.

How does the (threaded) NetBSD in-kernel NFS server deal with that?

Roy Marples | 4 Jun 11:36 2014

IPv6 Stable Private Addresses RFC 7217

Hi List

The next dhcpcd release will have support for IPv6 Stable Private 
Addresses, RFC 7217.

In summary, this is designed as a replacement interface identifier for 
the normal hardware derived one when using SLAAC.
By storing a persistent secret key and combing this with stable network 
information such as prefix, ssid (if available), hardware address and a 
dad_counter we can then take an interface identifier from a hash of the 
above information combined.

The most basic goal is that the host is no longer track-able across 
different networks based on their global address, but the address 
remains stable on each network.

My question is this: should this be enabled by default as privacy is a 
good thing, or should the normal hardware based address be kept?



Joerg Sonnenberger | 2 Jun 19:34 2014

Remove kvm(3) dependency of ifmcstat(8)

Hi all,
please test the attached patch on systems with IPv6 multicast,
especially, if you can trigger the creation of "kludge" entries.
There is one small functional difference -- the new code doesn't show
IPv6 addresses *without* associated multicast group.

For now, the backing sysctls do not require privileges. That can be seen
if someone makes a good point for it.

Attachment (ifmcstat.diff): text/x-diff, 18 KiB