Rhialto | 4 Feb 21:20 2016
Picon

dhcpcd: re1: DHCPv6 REPLY: iana not found

Since yesterday I have a new arrangemet wrt my IPv6 connection, and I'm
trying to use dhcpcd to manage the addresses tat are assigned to me from
my provider (xs4all.nl). They do native IPv6 via Fritz!Box modems and
(V)VDSL.

Little schematic:

    .--------.      .-----------.        .------.    
    | xs4all +------+ Fritz!Box +-----re1+ Main +re0---- local network
    `--------'      `-----------'        `------'    

So I thought I'd use the example give in the manual page,
dhcpcd.conf(5):

             noipv6rs            # disable routing solicitation
             denyinterfaces eth2 # Don't touch eth2 at all
             interface eth0
                 ipv6rs          # enable routing solicitation get the
                                 # default IPv6 route
                 ia_na 1         # request an IPv6 address
                 ia_pd 2 eth1/0  # get a /64 and assign it to eth1

This didn't work at all! And when it did things, it did them wrong.
(Of course I adjusted for my interfaces).

It took me a while to realise that this is a devilishly deceptive
example. dhcpcd does not allow end-of-line comments!

That surely should be made clearer in the manual, closer to the example,
and not just the line near the start "Blank lines and lines starting
(Continue reading)

Patrick Welche | 27 Jan 12:47 2016
Picon
Picon

identd

Code inspection suggests that identd forwarding with ipfilter is broken.

     -m filter     Enables forwarding of ident queries.  The filter argument
                   specifies which packet filter should be used to lookup the
                   connections, currently `pf' and `ipfilter' are supported
                   packet filters.  Note that identd changes the ident queries
                   to use the local port on the NAT host instead of the local
                   port on the forwarding host.  This is needed because other-
                   wise we can't do a lookup on the proxy host.  On the proxy
                   host, ``proxy mode'' should be enabled with the -P flag or
                   ``lying mode'' with the -L flag.

Any hints on how to set up an identd proxying testbed? (i.e., an experiment
to test the theory?)

Relates to http://gnats.netbsd.org/50198

Cheers,

Patrick

Christos Zoulas | 22 Jan 23:18 2016

blacklistd and IPv6 mapped IPv4 addresses


Hi,

I noticed that some servers (proftpd) report their IPv4 connections
as IPv6 mapped addresses:  ::ffff:x.y.z.w. Adding these addresses to npf,
works just fine (after I fixed the parser), but the packet filter does not
block connections from them because the rule does not match. Presumably
because the connections are processed by the IPv4 part of the stack and
there is no rule to match that.

What should blacklistd do? Recognize the mapped v4 addresses and convert
them to real v4 addresses and send those to the packet filter? Is that
guaranteed to work across different OS's? Or send both the v4 and mapped
v6 variants to the packet filter?

Or is it the responsibility of the packet filter to know that this is
a mapped v4 address and DTRT?

Thanks,

christos

Taylor R Campbell | 17 Jan 00:57 2016
Picon

eliminate struct protosw::pr_output

The ip_output function must be called as

	ip_output(m, opt, ro, flags, mopt, so)

where the arguments have the types

	struct mbuf *m;
	struct mbuf *opt;
	struct route *ro;
	int flags;
	struct ip_moptions *mopt;
	struct socket *so;

However, the prototype for ip_output is variadic:

	int ip_output(struct mbuf *, ...);

This is silly.  The only reason it is like this is that it is put in
the pr_output member of a struct protosw somewhere -- and then never
used via that path.  There's no way you could use it if you didn't
know the protocol you were using, so this pr_output member can't be
used anyway unless you know a priori that you're in netinet.  The same
is true of every other pr_output routine.

The only pr_output members that are ever actually used are (net/route)
rtsock's and (netipsec) keysock's, via raw_send.

The attached patch eliminates the pr_output member of struct protosw
(and struct ip6protosw), and adds an explicit (fully typed) callback
to raw_send for use by rtsock and keysock.
(Continue reading)

Wolfgang Solfrank | 18 Dec 15:11 2015
Picon

IPV6_USE_MIN_MTU

Hi,

finally I got around to analyzing a problem I had with dnssec and
named.  Actually, I didn't find the final cause of the problem yet
(something is eating ipv6 fragments), however, the analysis
led me to some sub-optimal implementation detail of our IPv6 stack.

Since path mtu discovery doesn't work too well with the short lived
tcp connections that are occasionally used with dns, BIND software
tries to set the mtu to the minimum when using IPv6.  For this it
sets the IPV6_USE_MIN_MTU option to IP6PO_MINMTU_ALL. The intention
is to use the minimum mtu (1280 bytes) for TCP connections over IPv6.

However, the code in tcp_output, which constructs the TCP packet
for a connection, doesn't know about this option. It uses the path
mtu (in the problematic case I investigated 1500 bytes). Only after
constructing the TCP packet and handing it over to ip6_output, that
routine recognizes the IP6PO_MINMTU_ALL option and fragments the
1500 byte packet in one with 1280 bytes and one with the rest.

The net result is that the use of the IPV6_USE_MIN_MTU option,
meant to avoid fragmentation, actually ensures that the packets
are fragmented (at least most of the time).

To fix this we need to make tcp_output aware of the option so it
can use the same value for mtu as is later used by ip6_output.

Comments?

Ciao,
(Continue reading)

Paul Goyette | 12 Dec 09:06 2015

Re: PCI MSI for re(4)

> Attached is a patch that should enable PCI MSI for pci(4)-attached
> re(4) NICs.  I would like both review of the code, and additional
> testing.
>
> I've tested it successfully on amd64 -current with a
> 8100E/8101E/8102E/8102EL chip.

I've been running with this for a couple weeks now, and everything just
works.  No issues seen.

...
re0 at pci3 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet (rev. 0x06)
re0: interrupting at msi0 vec 0
re0: Ethernet address 30:b5:c2:05:0e:66
re0: using 256 tx descriptors
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 4
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
...

Are you planning to commit the changes soon?

+------------------+--------------------------+------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+

Jaap Boender | 8 Dec 16:10 2015

smbfs gives Input/output errors

Hello all,

Trying to get my AD share mounted at work through smbfs, but I'm running into 
some problems that I'm hoping someone might be able to elucidate.

I'm able to mount_smbfs the share (//Jaap1 <at> HOST/Staff), and if I look at the 
directory contents, I can see them. However, if I try to access my home 
directory, Home/J/Jaap1, I get an Input/output error.

I can access the share through smbclient (I know that's a different mechanism, 
but at least it shows that the share is accessible from the outside)

smbutil view //Jaap1 <at> HOST results in this:
smbutil: unable to list resources: syserr = RPC struct is bad

Now, all this might of course just be a server configuration problem, but 
before I start the long process of talking to our IT department, I thought I 
might just see if there is something I can do on my side.

One of the directions I was thinking in is that for some reason the server 
thinks I don't have permission to access my home directory (maybe it thinks 
I'm a guest user or something?) and I've noticed that there are a lot of 
connection options to mount_smbfs (-M and -O for example), but I haven't 
really been able to figure out from the manpage or Googling what those 
actually do (and if they might help). Can anyone enlighten me?

In general, any advice would be appreciated!

thanks,

(Continue reading)

Nick Hudson | 6 Dec 10:22 2015
Picon

On softints, softnet_lock and sleeping (aka ipv6 vs USB network interfaces)

Hi,

PR/50491 raises some questions that I need some guidance on.
Take this stack trace...

  Setting date via ntp.
  panic: assert_sleepable: softint caller=0x802e2014
  cpu2: Begin traceback...
  0xbada3c3c: netbsd:db_panic+0xc
  0xbada3c6c: netbsd:vpanic+0x1b0
  0xbada3c84: netbsd:snprintf
  0xbada3cbc: netbsd:assert_sleepable+0xb4
  0xbada3d0c: netbsd:usbd_do_request_flags_pipe+0x28
  0xbada3d34: netbsd:usbd_do_request+0x38
  0xbada3d64: netbsd:smsc_write_reg+0x60
  0xbada3d8c: netbsd:smsc_setmulti+0x100
  0xbada3dbc: netbsd:smsc_ioctl+0x124
  0xbada3e64: netbsd:if_mcast_op+0x50
  0xbada3eb4: netbsd:in6_delmulti+0x154
  0xbada3ecc: netbsd:in6_leavegroup+0x20
  0xbada3ef4: netbsd:in6_purgeaddr+0x6c
  0xbada3f2c: netbsd:nd6_timer+0x108
  0xbada3f64: netbsd:callout_softclock+0x194
  0xbada3fac: netbsd:softint_dispatch+0xd4

It seems to me that nd6_timer is either expecting too much of
the USB stack by expecting a synchronous interface to changing
multicast filters that doesn't sleep; or the USB stack should
provide an asynchronous update method and any failure should be
handled elsewhere.
(Continue reading)

Anthony Mallet | 27 Nov 01:29 2015
Picon

ifconfig not waiting for DAD completion

When my wm(4) interface goes from down to up, it first enters a 'detached'
state for 1s or so, then the carrier is detected and the interface goes to the
ipv6 'tentative' state.

The detached state is long enough for ifconfig -w in /etc/rc.d/network to not
wait at all for DAD (the interface is still 'detached' when ifconfig -w runs).

This then leads to unexpected delays (~30s) in e.g. /etc/rc.d/mountall with an
NFS filesystem. (The machine is in ip6mode=host).

I tried the following quick patch to ifconfig(8) so that ifconfig -w waits for
DAD completion only once DAD has started. Does this look like the proper fix?

Index: sbin/ifconfig/af_inet6.c
===================================================================
RCS file: /cvsroot/src/sbin/ifconfig/af_inet6.c,v
retrieving revision 1.33
diff -u -r1.33 af_inet6.c
--- sbin/ifconfig/af_inet6.c  12 May 2015 14:05:29 -0000      1.33
+++ sbin/ifconfig/af_inet6.c  27 Nov 2015 00:05:46 -0000
 <at>  <at>  -489,7 +489,7  <at>  <at> 
        ifr.ifr_addr = *(struct sockaddr_in6 *)ifa->ifa_addr;
        if (prog_ioctl(s, SIOCGIFAFLAG_IN6, &ifr) == -1)
                err(EXIT_FAILURE, "SIOCGIFAFLAG_IN6");
-       return ifr.ifr_ifru.ifru_flags6 & IN6_IFF_TENTATIVE ? true : false;
+       return ifr.ifr_ifru.ifru_flags6 & (IN6_IFF_TENTATIVE|IN6_IFF_DETACHED) ? true : false;
 }

 static void

(Continue reading)

Edgar Fuß | 18 Nov 15:45 2015
Picon

page fault in fr_makefrip

On our gateway running 4.0.1/amd64, we yesterday hit (manual OCR):

kernel: page fault trap, code=0
Stopped at	netbsd:fr_makefrip+0x13d:	cmpl	0x20(%rax),%edx
db> bt
fr_makefrip() at netbsd:fr_makefrip+0x13d
fr_checkicmp6matchingstate() at fr_checkicmp6matchingstatd+0xe3
fr_stlookup() at netbsd:fr_stlookup+0x684
fr_checkstate() at netbsd:fr_checkstate+0x44c
fr_check() at netbsd:fr_check+0x73e
pfil_run_hooks() at netbsd:pfil_run_hooks+0xa0
ip6_input() at netbsd:ip6_input+0x3d0
ip6intr() at netbsd:ip6intr+0x42
DDB lost frame for netbsd:Xsoftnet+0x58, trying 0xffffffff806aed10
Xsoftnet() at netbsd:Xsoftnet+0x58
--- interrupt ---
0x246:
db> show reg
ds	0x7400
es	0x8402
fs	0x4
gs	0xbef7
rdi	0
rsi	0xffff80004cb6707a
rbp	0xffffffff806ae7b0	_prop_dictionary_keysym32_pool+0x8fc50
rbx	0x6a00
rdx	0x9228
rcx	0
rax	0
r8	0x38060120
(Continue reading)

Robert Swindells | 28 Oct 17:14 2015
Picon

wm(4)


Anyone else having problems with wm(4) in current ?

Works fine in a kernel from Oct 5, doesn't do anything in latest version.

The dmesg lines are:

wm0 at pci3 dev 0 function 0: Intel i82574L (rev. 0x00)
wm0: interrupting at ioapic0 pin 17
wm0: PCI-Express bus
wm0: 2048 words FLASH, version 1.8.0, Image Unique ID 0000ffff
wm0: Ethernet address 68:05:ca:28:b1:c7
makphy0 at wm0 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1

Robert Swindells


Gmane