Robert Swindells | 20 Oct 23:06 2014
Picon

rtsol


What is the recommended way to replace rtsol(8) ?

I have read the man page.

My /etc/rc.conf contains the following:

dhcpcd=YES
dhcpcd_flags="-B6 --nodhcp6 rtk0"

At boot, dhcpcd prints that it has received the RA but then blocks,
prints an error that it has timed out and overwrites the
/etc/resolv.conf file with an empty one.

It doesn't set the IPv6 address of the interface.

Robert Swindells

Mouse | 20 Oct 20:15 2014

127.0.0.1 deprecated??

I just now had occasion to look at lo(4), for the first time in I don't
know how long.

All three versions I have on hand - 1.4T, 4.0.1, and 5.2 - have a BUGS
section saying

BUGS
     Previous versions of the system enabled the loopback interface automati-
     cally, using a nonstandard Internet address (127.1).  Use of that address
     is now discouraged; a reserved host address for the local network should
     be used instead.

This is the first I've heard of 127.1, a very old syntax for 127.0.0.1,
being nonstandard for loopback use or of its being deprecated, and,
indeed, the startup scripts for each of those three versions are
hardwired to bring lo0 up as 127.0.0.1.

Anyone have any idea what's behind that paragraph?

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

Roy Marples | 12 Oct 22:30 2014

Remove ability for userland to toggle IPv6 tentative address flag

Hi List

Can anyone think of a use case for allowing userland to toggle the 
IN6_IFF_TENTATIVE flag for IPv6 addresses?

I can't.

The way it's presently implemented can cause a problem as well when the same 
address is added twice, because the logic is thus:

Add IPv6 address without tentative flag
Kernel checks if it's a new address, if so sets tentative flag and starts DAD 
after a random delay.
Add the same IPv6 address without tentative flag again while DAD is still 
running.
Kernel sees it's the same address, so blindly updates the flags which clears 
IN6_IFF_TENTATIVE. This then confuses the DAD process. I've seen it not notify 
userland of the flag being cleared whilst others have reported invalid 
duplicate addresses being reported.

So, can you think of a valid use case for allowing userland to toggle the 
tentative flag? Note that setting it doesn't actually start DAD, just makes 
the address unuseable.

Attached is the patch to remove the ability for userland to toggle 
IN6_IFF_TENTATIVE.

Comments as always are welcome

Roy
(Continue reading)

Dennis Ferguson | 11 Oct 01:57 2014
Picon

Route lookup library

I have a library implementing a longest match prefix
lookup (i.e. a route lookup) which might be useful
and which I'd like people to look at if anyone is
interested.  The library is intended to be useful both
in the kernel and as a user space library with the code
as-is by virtue of the fact that it does memory allocations
using functions provided by the user.  The library has
only a few other dependencies on the external environment,
it is mostly self-contained data structure builder and
parser code.  It should be available here:

    http://www.netbsd.org/~dennis/rttree.tar.gz

The library implements a fairly modern route lookup data
structure.  Its memory usage is O(N), that is a reasonably
constant number of bytes per route installed in the
structure.  As for the value of that constant, there is
a memory-versus-performance tradeoff made by letting the
user tell it how aggressive it should be.  The default
schedule used makes the internal memory usage more or less
the same as the current kernel radix trie, though I like the
effect of the alternative schedule which grows internal
memory to maybe 30% larger than that.

The structure is a tree but the average complexity of a lookup
scales at better than O(log(N)).  I can't tell you how much better.
I once convinced myself that if the algorithm were solely constrained
by the O(N) memory consumption it would scale as something
like O(log(log(N))) on average, but additional constraints
placed on it to make incremental updates efficient have likely
(Continue reading)

Roy Marples | 8 Sep 12:24 2014

removal of rtsol{d}

Hi

rtsol and rtsold have historically been used to send ICMPv6 Router 
Solicitation
messages on specified interfaces and expected the kernel to fully parse 
the
resultant Router Advertisement message. Of course, this turned out to be 
a bad
idea because some userland options crept into the Router Advertisement, 
such
as DNS options and wanting more configuration via DHCPv6.

dhcpcd has supported the sending of ICMPv6 RS and processing the 
resultant RA
packets for some time now, thus making rtsol and rtsold redundant. I 
would like
to propose that we remove rtsold from NetBSD as dhcpcd supplies the 
equivalent
functionality. For example, you can launch dhcpcd in IPv6 only mode, 
disable
DHCPv6 like so:
     dhcpcd -6 --nodhcp6 bge0

I also propose we change ip6mode `autohost` to start dhcpcd if not 
started in
rc.conf. Also, the static DAD sleep timings should be removed as dhcpcd 
will
ensure DAD has completed before forking if a carrier is present (if no 
carrier
then the static sleep is pointless anyway and dhcpcd will fork).
(Continue reading)

Takahiro HAYASHI | 26 Jul 03:29 2014
Picon

axen: axen_reset resets nothing

Hello,

My axen(4) won't link-up but I find that axen_reset()
in sys/dev/usb/if_axen.c does not do anything.
It should call chip init routine, I think.

This patch works, though axen_ax88179_init() does full chip reset.
Not tested on UPS_SUPER_SPEED.

Any suggestions?

--- if_axen.c.orig	2014-07-25 18:26:44.000000000 +0900
+++ src/sys/dev/usb/if_axen.c	2014-07-26 08:53:13.000000000 +0900
 <at>  <at>  -392,6 +392,7  <at>  <at>  axen_reset(struct axen_softc *sc)
  	if (sc->axen_dying)
  		return;
  	/* XXX What to reset? */
+	axen_ax88179_init(sc);

  	/* Wait a little while for the chip to get its brains in order. */
  	DELAY(1000);

Thanks,
--

-- 
t-hash

Richard Hansen | 23 Jul 08:53 2014
Picon

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:]
    s.bind(addr)

I get the following error:

    Traceback (most recent call last):
      File "./minimal.py", line 8, in <module>
        s.bind(addr)
      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
Picon

pru & stat(2) failure / return cleanups

hello,

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
Picon

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?

Thanks

Roy

Thomas Bieg | 5 Jul 18:00 2014

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

Hello,

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 192.168.1.1, where the httpd is listening.
- re0 is connected to a LAN with 192.168.1.2 as internet gateway (does DHCP and
   DNS).

- 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 192.168.1.2 over the bridge and can access LAN and
   internet just fine if I allow it).

- ipnat.conf has:
   rdr re1 1.2.3.4/32 port 80 -> 192.168.1.1 port 80

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

I was expecting/hoping ipnat would silently redirect connections coming in on
re1 and intended for 1.2.3.4 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)


Gmane