Loganaden Velvindron | 21 Jan 21:52 2015

NetBSD and atomic fragments

Hi folks,

Going through fgont's draft:

   The following text from Section 5 of [RFC2460]:

      "In response to an IPv6 packet that is sent to an IPv4 destination
      (i.e., a packet that undergoes translation from IPv6 to IPv4), the
      originating IPv6 node may receive an ICMP Packet Too Big message
      reporting a Next-Hop MTU less than 1280.  In that case, the IPv6
      node is not required to reduce the size of subsequent packets to
      less than 1280, but must include a Fragment header in those
      packets so that the IPv6-to-IPv4 translating router can obtain a
      suitable Identification value to use in resulting IPv4 fragments.
      Note that this means the payload may have to be reduced to 1232
      octets (1280 minus 40 for the IPv6 header and 8 for the Fragment
      header), and smaller still if additional extension headers are

   is formally replaced with:

      "An IPv6 node that receives an ICMPv6 Packet Too Big error message
      that reports a Next-Hop MTU smaller than 1280 bytes (the minimum
      IPv6 MTU) MUST NOT include a Fragment header in subsequent packets
      sent to the corresponding destination.  That is, IPv6 nodes MUST
      NOT generate IPv6 atomic fragments."

Tentative diff:
(Continue reading)

Leonardo Taccari | 14 Jan 11:10 2015

alc(4): add support for 816x devices (and request for review)

Hello tech-net <at> , current-users <at>  and Jared[0],
my new laptop has an Atheros AR8171 PCIe Gigabit Ethernet card that ATM
is not supported in NetBSD.
Some months ago alc(4) driver in FreeBSD was modified in order to
support the 816x devices too.
I have tried to port the changes from FreeBSD to NetBSD and at least
with the AR8171 ethernet card the alc(4) driver *works*. However, I
do not have the needed knowledge and the patches that I will attach in
this email should be considered a cargo-cult.
Another problem that I have introduced is that it wrongly recognise
multiple atphy(4):

 alc0 at pci2 dev 0 function 0: Atheros AR8171 PCIe Gigabit Ethernet
 alc0: interrupting at ioapic0 pin 18
 alc0: Ethernet address XX:XX:XX:XX:XX:XX
 atphy0 at alc0 phy 0: Atheros AR8035 10/100/1000 PHY, rev. 9
 atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
 atphy1 at alc0 phy 1: Atheros AR8035 10/100/1000 PHY, rev. 9
 atphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
 atphy2 at alc0 phy 2: Atheros AR8035 10/100/1000 PHY, rev. 9
 atphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
 atphy31 at alc0 phy 31: Atheros AR8035 10/100/1000 PHY, rev. 9
 atphy31: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
 ifmedia_match: multiple match for 0x20/0xffbff8ff, selected instance 0

If a developer has got some time please review the patches (especially
the various REVIEWME). I am completely available in order to test the
further changes. When I will have got the ok I will take care to fill
a PR containing the patches and man pages updates.
(Continue reading)

chris@chriswareham.net | 9 Jan 11:00 2015

Kernel panic on assertion in if_wpi.c


I upgraded my Dell Latitude D420 to -current, and have run into an issue with
wpi(4) wireless. It appears to be connected to Manuel Bouyer's recent work
around power management, as the kernel panics at the following assertion:

kernel diagnostic assertion "mutex_owned(&sc->sc_rsw_mtx)" failed: file
"/home/source/ab/HEAD/src/sys/dev/if_wpi.c", line 3309

A backtrace on the kernel dump shows this to be in wpi_getrfkill after it's
called from wpi_init.



Martin Husemann | 2 Jan 17:02 2015

Strange TCP problem with awge0

A strange network problem, reproducable on netbsd-current when using an
ARM device with awge network interface (basically all Allwinner boards)
has been reported to me:

Simply trying to get anything from one of the KDE mirror sites fails
like this:

> ftp ftp://ftp.solnet.ch/mirror/KDE/stable/
Connected to ftp.solnet.ch.
220-  __ _                    _            _         _     
331 Please specify the password.
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.

421 Service not available, remote server timed out. Connection closed.

When running Raspbian on affected hardware and using tnftp, the transfer

331 Please specify the password.
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
200 Switching to Binary mode.
250 Directory successfully changed.
550 Failed to change directory.
221 Goodbye.
(Continue reading)

Manuel Bouyer | 19 Dec 17:03 2014

powerd(8) radio_button event; wpi(4) implementation

as described in a previous thread ("wpi0: radio is disabled by hardware
switch"), in order to get userland notifications when the wifi switch
is turned on or off (e.g. to start/stop wpa_supplicant), I implemented
a new sysmon_pswitch(9) switch type, PSWITCH_TYPE_RADIO. I also
changed wpi(4) so that it would report button "pressed" and "released"
events (which would be better described as "on" and "off" but
this is what sysmon_pswitch(9) knows for buttons).

With the attached patch (against netbsd-7, but -current should'nt be much
different), and an extra radio_button script in /etc/powerd/scripts/,
wpa_suplicant is automatically started when I turn the radio button
on, and stopped when I turn the radio button off (the driver takes care of
taking the interface down itself).

Does anyone object to this change ?


Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
Index: share/man/man9/sysmon_pswitch.9
RCS file: /cvsroot/src/share/man/man9/sysmon_pswitch.9,v
retrieving revision 1.5
diff -u -p -u -r1.5 sysmon_pswitch.9
--- share/man/man9/sysmon_pswitch.9	18 Mar 2014 18:20:40 -0000	1.5
+++ share/man/man9/sysmon_pswitch.9	19 Dec 2014 15:48:22 -0000
(Continue reading)

Patrick Welche | 13 Dec 16:59 2014

MKINET6=no fixes

I found the following patch to be necessary when trying to compile
-current/amd64 with MKINET6=no.

One issue is that it isn't obvious to me where the boundary between
MKINET6 and USE_INET6 is.  e.g., after compiling route with
MKINET6=no, would expect to see

Protocol Family 24:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
af 24: Q00.00.00.0 (24) Q00.00.00.00. UGR         -        -      -  lo0
af 24: Q00.00.00.0 (24) Q00.00.00.00. UGR         -        -      -  lo0

or just have that part omitted?

Makes enough sense to commit?


Index: external/apache2/mDNSResponder/dist/mDNSPosix/mDNSPosix.c
RCS file: /cvsroot/src/external/apache2/mDNSResponder/dist/mDNSPosix/mDNSPosix.c,v
retrieving revision 1.6
diff -u -r1.6 mDNSPosix.c
--- external/apache2/mDNSResponder/dist/mDNSPosix/mDNSPosix.c	31 Mar 2014 23:26:30 -0000	1.6
+++ external/apache2/mDNSResponder/dist/mDNSPosix/mDNSPosix.c	13 Dec 2014 14:47:24 -0000
 <at>  <at>  -718,7 +718,7  <at>  <at> 
 				err = setsockopt(*sktPtr, IPPROTO_IPV6, IPV6_RECVPKTINFO, &kOn, sizeof(kOn));
(Continue reading)

Roy Marples | 11 Dec 04:14 2014


dhcpcd polls SIOCGNBRINFO_IN6 every second for every IPv6 router it 
knows about to test neighbour reach-ability.
This isn't exactly optimal, hello battery drain.

Attached is a patch to add RTM_NEWNEIGH so that userland can react to 
Neighbour Discovery changes, similar to the Linux equivalent.
It's designed to be protocol agnostic, (ie could be used for ARP as 
Currently, it only raises RTM_NEWNEIGH on IPv6 neighbour state and flag 
(is it a router?) changes.
There is little point in generating RTM_DELNEIGH or RTM_GETNEIGH as 
Linux does because our current
implementation sends equivalent messages via RTM_DELETE or RTM_CHANGE.

I have a patch for dhcpcd to use this (attached as well, needs my latest 
fossil trunk, -current is too old).
The end result is that on NetBSD there are no longer any polls for state 
- the kernel notifies every event change.
The only elephants left in the room are drivers that don't set IFF_UP 
before LINK_STATE_UPi (hi sk(4)) and drivers which could set link state 
but don't bother to (hi ppp(4)).

Comments, as always, are welcome.

Attachment (rtm_newneigh.diff): text/x-diff, 8153 bytes
Attachment (dhcpcd-bsd-newneigh.diff): text/x-diff, 3096 bytes
D'Arcy J.M. Cain | 10 Dec 06:15 2014

npf vs. pf

I have been having issues with pf.  See "pf add not working" in
netbsd-users for details.  Basically I have created a persistent table
and dynamically add and delete to/from it based on my intrusion
system.  Everything seems to work but even with IPs in the table as
shown by pfctl it seems that people still get through.  Something weird
is going on.  I wonder if it is pf itself.

I asked if npf would have a good shot at fixing this issue but no one
has replied to that question.  Anyone here have any thoughts on that?
Is npf stable enough to consider replacing pf on a production server?



D'Arcy J.M. Cain <darcy <at> NetBSD.org>
http://www.NetBSD.org/ IM:darcy <at> Vex.Net

Manuel Bouyer | 2 Dec 12:19 2014

wpi0: radio is disabled by hardware switch

on a laptop with a  wpi interface, dcpcd brings automatically the interface
up, which leads to an endless stream of "wpi0: radio is disabled by hardware
switch" on console when the radio is turned off.

Is there a way to get status and notifications (other than watching dmesg) 
of the radio hardware switch, in order to e.g. enable or disable
wpa_supplicant and dhcpcd on the interface when the switch is used to turn
the radio on or off ?


Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference

Christos Zoulas | 1 Dec 17:04 2014

sockaddr printing functions


We have a hodgepodge set of functions that print sockaddr_* and I wanted
to try to clean that up:

	1. consistent api
	2. don't use static storage
	3. testable from userland (with unit tests added)

For each socket type we have:

	int xx_print(char *buf, size_t len, const struct xxaddr *);

	int sxx_snprintf(char *buf, size_t len, void *sa, const char *fmt, ...);
	for xx  [ "in" "in6" "at" "un" "dl" ]
	[the dl portion is slightly different, and the un portion I have
	 not included in the patch]

There are also constants that describe the max string length that xx_print
	UNIX_ADDRSTRLEN (should we add this?)

The code is in:

(Continue reading)

Martin Husemann | 28 Nov 15:04 2014

mpls broken again

Some recent changes (no idea which) broke the MPLS regression tests:

PING ( 64 data bytes
72 bytes from icmp_seq=2 ttl=255 time=12.450469 ms

---- PING Statistics----
3 packets transmitted, 1 packets received, 66.7% packet loss
round-trip min/avg/max/stddev = 12.450469/12.450469/12.450469/0.000000 ms

Haven't we seen this before? Crash when trying to answer the first packet
or something?