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

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

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