Re: kern/52313: NetBSD 8.0_BETA issues with ircd, ipfilter, and v6only=0 set

[christos%zoulas.com@localhost (Christos Zoulas)]

The following reply was made to PR kern/52313; it has been noted by GNATS.

From: christos%zoulas.com@localhost (Christos Zoulas)
To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, 
	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, dmb%yenn.ulegend.net@localhost
Cc: 
Subject: Re: kern/52313: NetBSD 8.0_BETA issues with ircd, ipfilter, and v6only=0 set
Date: Tue, 20 Jun 2017 12:07:21 -0400

 On Jun 20, 11:55am, dmb%yenn.ulegend.net@localhost (Dominik Bialy) wrote:
 -- Subject: Re: kern/52313: NetBSD 8.0_BETA issues with ircd, ipfilter, and v
 
 | The following reply was made to PR kern/52313; it has been noted by GNATS.
 | 
 | From: Dominik Bialy <dmb%yenn.ulegend.net@localhost>
 | To: gnats-bugs%NetBSD.org@localhost
 | Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 | 	netbsd-bugs%netbsd.org@localhost, dmb%yenn.ulegend.net@localhost
 | Subject: Re: kern/52313: NetBSD 8.0_BETA issues with ircd, ipfilter, and
 |  v6only=0 set
 | Date: Tue, 20 Jun 2017 13:54:11 +0200
 | 
 |  On Tue, Jun 20, 2017 at 01:19:57PM +0200, Dominik Bialy wrote:
 |  > On Tue, Jun 20, 2017 at 09:20:01AM +0000, Ryota Ozaki wrote:
 |  > > The following reply was made to PR kern/52313; it has been noted by GNATS.
 |  > > 
 |  > > From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
 |  > > To: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%netbsd.org@localhost>
 |  > > Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
 |  > > Subject: Re: kern/52313: NetBSD 8.0_BETA issues with ircd, ipfilter, and
 |  > >  v6only=0 set
 |  > > Date: Tue, 20 Jun 2017 18:14:57 +0900
 |  > > 
 |  > >  On Mon, Jun 19, 2017 at 4:15 AM,  <dmb%yenn.ulegend.net@localhost> wrote:
 |  > >  >>Number:         52313
 |  > >  >>Category:       kern
 |  > >  >>Synopsis:       NetBSD 8.0_BETA has issues with ircd (IRCnet one) + ipfilter + v6only=0 set
 |  > >  >>Confidential:   no
 |  > >  >>Severity:       serious
 |  > >  >>Priority:       medium
 |  > >  >>Responsible:    kern-bug-people
 |  > >  >>State:          open
 |  > >  >>Class:          sw-bug
 |  > >  >>Submitter-Id:   net
 |  > >  >>Arrival-Date:   Sun Jun 18 19:15:00 +0000 2017
 |  > >  >>Originator:     Dominik Bialy
 |  > >  >>Release:        NetBSD 8.0_BETA
 |  > >  >>Organization:
 |  > >  > Underlegend Networks
 |  > >  >>Environment:
 |  > >  > System: NetBSD yenn 8.0_BETA NetBSD 8.0_BETA (YENN) #2: Thu Jun 15 05:53:36 UTC 2017 builds@yenn:/var/obj/sys/arch/amd64/compile/YENN amd64
 |  > >  > Architecture: x86_64
 |  > >  > Machine: amd64
 |  > >  >>Description:
 |  > >  > When using an application which needs v6only=0 -- ircd (IRCnet one) --
 |  > >  > all connections on IPv4 are being reset.  There is ipfilter set.
 |  > >  > I was trying to pass all on it, but effect is the same.  I didn't try
 |  > >  > to disable ipfilter.  I'm not sure wether it's the ircd bug, or some
 |  > >  > bug/misfeature of NetBSD or ipfilter in it.
 |  > >  >
 |  > >  > I didn't test any other v6only=0 apps.
 |  > >  >
 |  > >  > PS: I can't restart the machine for now, so I can't test any fixes...
 |  > >  >>How-To-Repeat:
 |  > >  > Try to run IRCnet ircd with v6only=0 + ipfilter, and connecting using IPv4
 |  > >  
 |  > >  Is this a regression? Did the same setup work on NetBSD 7 or earlier?
 |  > 
 |  > Yes.  This setup worked well with NetBSD 6.
 |  > 
 |  > >  
 |  > >  What exactly happens on "all connections on IPv4 are being reset"?
 |  > >  - (I assume ircd is a server)
 |  > 
 |  > The server is ircd 2.11.2p3 -- latest IRCnet ircd you can get
 |  > from the maintainer's site: http://42.pl/ircd/
 |  > 
 |  > It relays on IPv6-mapped IPv4 addresses when configured with --ip6
 |  > 
 |  > It is compiled with -m32 since the code isn't 64-bit clean.
 |  > 
 |  > >  - Anyone cannot connect to the ircd? Or can connect but disconnect
 |  > >    for some reason?
 |  > 
 |  > The effect is "Connection reset by peer" when trying to connect to ircd (on IPv4)
 |  > either from outside or localhost (lo0). Connection doesn't even get established.
 |  > Connections initiated by ircd on IPv4 (server links) work well. IPv6 works well, too.
 |  > 
 |  > There are following rules on top of ipf.conf:
 |  > 
 |  > ### block policy
 |  > block in all
 |  > block out all
 |  > 
 |  > ### DEBUG
 |  > #pass in quick all
 |  > #pass out quick all
 |  > 
 |  > ### antispoofing
 |  > block in from fc00::/7
 |  > block in on gif0 from fe80::/10
 |  > block in on gif0 from ::1/128
 |  > block in on ex0 from 10.0.0.0/8
 |  > block in on ex0 from 172.16.0.0/12
 |  > block in on ex0 from 192.168.0.0/16
 |  > block in on ex0 from 127.0.0.0/8
 |  > block in on ex1 from 127.0.0.0/8
 |  > 
 |  > ### localhost
 |  > pass in quick on lo0 all
 |  > pass out quick on lo0 all
 |  > 
 |  > Later in the ipf.conf there is:
 |  > 
 |  > block return-rst in proto tcp from any to <external IP>
 |  > 
 |  > and then more specific rules that "pass" the traffic
 |  > on external IP.  We're passing all tcp traffic above port 1023,
 |  > and the ircd is on 6667.
 |  > 
 |  > And it smells like this is being trggered... but the "pass" rule
 |  > on lo0 above should just pass it.
 |  > 
 |  > I also used the "DEBUG" section for passing all,
 |  > and effect was the same.  I didn't try to disable ipfilter yet.
 |  > 
 |  > In fstat -nu irc:
 |  > 
 |  > irc      ircd        1581    7* internet6 stream tcp [::ffff:127.0.0.1]:6667
 |  > 
 |  > so it does listen, as well as on external IP.
 |  > 
 |  > >  - Where packets reach? ircd? ipfilter? the NIC?
 |  > >  
 |  > There are no symptoms of clients reaching the ircd (no traffic on
 |  > the &CLIENTS server channel).  I guess the NIC doesn't matter
 |  > since it happens on lo0, too.
 |  > 
 |  > I suspect ipfilter.  I had to do couple of changes to ipf.conf
 |  > since now there's one file for both IPv4 and IPv6, and the file
 |  > is pretty long.  Maybe one need to explicitly pass the ::ffff(...)
 |  > rules?  But how? Ipfilter parser returns errors with such notation,
 |  > and there is nothing about such addresses.
 |  > 
 |  > It might also be that something in the sockets API changed, and
 |  > this old ircd stopped working even though it was rebuilt for
 |  > NetBSD 8 (compat32).
 |  > 
 |  > PS:  I just did ipf -l block, and ipf -l nomatch, and nothing shows up
 |  > in ipmon...  But frankly speaking I'm green in ipf logging :P
 |  > 
 |  > >  Thanks,
 |  > >    ozaki-r
 |  > >  
 |  > 
 |  > What else checks I can do?
 |  > 
 |  > Thank you
 |  > 	Dominik BiaÅ?y
 |  
 |  More info -- I just run irc nick 127.0.0.1 (ircII client), and it showed
 |  
 |  error in getsockname()
 |  
 |  I can't reproduce it since another try gave "Connection reset by peer"
 |  
 |  Also it seems that ircd-hybrid, which I was giving a try, can't bind
 |  to AF_INET et all... (it has listen{} on all ports 6661-6669.) No
 |  internet sockets are showing up in fstat.
 |  
 |  Also irssi is giving that warning:
 |  
 |  ** (irssi:5441): WARNING **: settings_get_time(server_connect_timeout) : Invalid time '-1'
 
 Can you ktrace it and see what it passes to getsockname()?
 
 christos