NetBSD Problem Report #52313
From dmb@yenn.ulegend.net Sun Jun 18 19:12:59 2017
Return-Path: <dmb@yenn.ulegend.net>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id F36267A28A
for <gnats-bugs@gnats.NetBSD.org>; Sun, 18 Jun 2017 19:12:58 +0000 (UTC)
Message-Id: <20170618191208.1F3395DE8@yenn.ulegend.net>
Date: Sun, 18 Jun 2017 19:12:08 +0000 (UTC)
From: dmb@yenn.ulegend.net
Reply-To: dmb@yenn.ulegend.net
To: gnats-bugs@NetBSD.org
Subject: NetBSD 8.0_BETA issues with ircd, ipfilter, and v6only=0 set
X-Send-Pr-Version: 3.95
>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: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Jun 18 19:15:00 +0000 2017
>Closed-Date: Tue Sep 26 09:08:12 +0000 2017
>Last-Modified: Tue Sep 26 09:08:12 +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
>Fix:
Dunno yet.
>Release-Note:
>Audit-Trail:
From: Ryota Ozaki <ozaki-r@netbsd.org>
To: "gnats-bugs@NetBSD.org" <gnats-bugs@netbsd.org>
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
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> 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?
What exactly happens on "all connections on IPv4 are being reset"?
- (I assume ircd is a server)
- Anyone cannot connect to the ircd? Or can connect but disconnect
for some reason?
- Where packets reach? ircd? ipfilter? the NIC?
Thanks,
ozaki-r
From: Dominik Bialy <dmb@yenn.ulegend.net>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, dmb@yenn.ulegend.net
Subject: Re: kern/52313: NetBSD 8.0_BETA issues with ircd, ipfilter, and
v6only=0 set
Date: Tue, 20 Jun 2017 13:19:57 +0200
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>
> To: "gnats-bugs@NetBSD.org" <gnats-bugs@netbsd.org>
> Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
> 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> 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
From: Dominik Bialy <dmb@yenn.ulegend.net>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, dmb@yenn.ulegend.net
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>
> > To: "gnats-bugs@NetBSD.org" <gnats-bugs@netbsd.org>
> > Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
> > 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> 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'
Hope we are closer... :)
Dominik
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, dmb@yenn.ulegend.net
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 (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>
| To: gnats-bugs@NetBSD.org
| Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
| netbsd-bugs@netbsd.org, dmb@yenn.ulegend.net
| 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>
| > > To: "gnats-bugs@NetBSD.org" <gnats-bugs@netbsd.org>
| > > Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
| > > 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> 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
So the issue is the following, demonstrated by the program enclosed.
Non-blocking sockets that connect to loopback return EINPROGRESS, but
between the connect call and the getsockname call the connection gets
dropped because the client gets RST+ACK tcp_input.c:1.357,2230 so the
getsockname call returns EINVAL because it can't find a pcb for the
socket. This is not how the socket code behaves on a remote host that
does not respond, or on linux. I believe this is a BSD stack behavior.
The root of the problem is that connecting to localhost:6667 returns
connection refused; one can try this with telnet...
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <netinet/in.h>
#include <stdlib.h>
#include <fcntl.h>
#include <string.h>
#include <errno.h>
#include <err.h>
int
main(void)
{
struct sockaddr_in sa;
int fd;
socklen_t salen;
struct sockaddr_storage ss;
fd = socket(PF_INET, SOCK_STREAM, 6);
if (fd == -1)
err(EXIT_FAILURE, "socket");
if (fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) | O_NONBLOCK) == -1)
err(EXIT_FAILURE, "fcntl");
memset(&sa, 0, sizeof(sa));
sa.sin_port = htons(6667);
sa.sin_addr.s_addr = inet_addr("127.0.0.1");
sa.sin_family = AF_INET;
sa.sin_len = sizeof(sa);
if (connect(fd, (struct sockaddr *)&sa, sizeof(sa)) == -1 &&
errno != EINPROGRESS)
err(EXIT_FAILURE, "connect");
salen = sizeof(ss);
if (getsockname(fd, (struct sockaddr *)&ss, &salen) == -1)
err(EXIT_FAILURE, "getsockname");
return 0;
}
From: Dominik Bialy <dmb@yenn.ulegend.net>
To: gnats-bugs@NetBSD.org
Cc: dmb@yenn.ulegend.net
Subject: Re: kern/52313: NetBSD 8.0_BETA issues with ircd, ipfilter, and
v6only=0 set
Date: Tue, 26 Sep 2017 11:03:19 +0200
On Sun, Jun 18, 2017 at 07:15:00PM +0000, gnats-admin@netbsd.org wrote:
> Thank you very much for your problem report.
> It has the internal identification `kern/52313'.
> The individual assigned to look at your
> report is: kern-bug-people.
>
> >Category: kern
> >Responsible: kern-bug-people
> >Synopsis: NetBSD 8.0_BETA has issues with ircd (IRCnet one) + ipfilter + v6only=0 set
> >Arrival-Date: Sun Jun 18 19:15:00 +0000 2017
>
Please close this one.
I did upgrade, last known to me not working
NetBSD 8.0_BETA was from mid-Jul. Now the
sources from 15 Sep are working fine. ircd
again is working on IPv4 as expected.
Thank you!
Dominik Biały
State-Changed-From-To: open->closed
State-Changed-By: martin@NetBSD.org
State-Changed-When: Tue, 26 Sep 2017 09:08:12 +0000
State-Changed-Why:
Closed on submitters request (fixed!)
Thanks for the PR!
>Unformatted:
Sources from Jun 13 2017, kernel compiled with altq, but it shouldn't matter.
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home