Re: DNS using Name Service Switch module and Casper

[Mark Johnston]

On Sun, Jan 10, 2021 at 04:32:13PM +0300, Vasily Postnicov wrote:
> This is as minimal as I can get. If I knew where to find, what to fix, I
> would never waste my time seeking for help on mailing lists.
> 
> Just put FreeBSD in that damn bhyve and play with it, get your hands dirty,
> you are the developer after all, not me! Your knowledge of FreeBSD is
> supposedly much greater that mine.
> 
> For me acceptable solutions are:
> 1) Remove unsandboxed call to getaddrinfo() from ping.
> 2) Do not compile with that casper crap which gives false sense of security
> or whatsoever.
> 
> I just wanted to help you find a bug where fork() hangs for no reason. So I
> provided you with all I can get from this situation. Just 20 lines of code
> to reproduce the bug. And you tell me this is not what you want. So what do
> you want? A patch that fixes your problem?
> 
> Sorry for harsh words in your address. But in such situations I question
> myself should I really report anything and ask anything in FreeBSD
> community.
> 
> Btw, if you are still interested, I think I can provide you with the whole
> bhyve image in which you can reproduce the bug. It contains modified
> /etc/nsswitch.conf if you cannot change it yourself.

Just to follow up, we got a simpler repro based on the one you provided.
A few bugs were found and fixed as a result:

https://cgit.freebsd.org/src/commit/?id=21f749da82e755aafab127618affeffb86cff9a5
https://cgit.freebsd.org/src/commit/?id=513320c0f1122f096468c0b01623ba7c7e77cbe2
https://cgit.freebsd.org/src/commit/?id=85d028223bc2768651f4d44881644ceb5dc2a664
https://cgit.freebsd.org/src/commit/?id=57f22c828ec01e0d92bc8858f61df06b4d81ea5c

> сб, 9 янв. 2021 г., 21:47 Konstantin Belousov :
> 
> > On Sat, Jan 09, 2021 at 08:25:46PM +0300, Vasily Postnicov wrote:
> > > Brilliant! It took me almost a day to dive into ZeroMQ to reassure
> > > myself that there is nothing wrong with it. When I tried to write
> > > minimal test programs which call fork after pthread_create() in all
> > > combinations. When I realized that NSS stub module is what I need.
> > >
> > > Instructions:
> > >
> > > 1) Compile NSS stub module: cc -shared -fPIC -pthread -o
> > > nss_zerodns.so.1 test.c (Note '.1' at the end).
> > > 2) Copy nss_zerodns.so.1 to /usr/local/lib
> > > 3) Apply the patch src_sbin_ping_main.c to ping source code. With this
> > > patch ping will not quit too early when the initial call to
> > > getaddrinfo() fails.
> > > 4) Add stub module to /etc/nsswitch.conf: edit 'hosts' line to be
> > > 'hosts: files dns zerodns'
> > > 5) Ping non-existent host, like 'ping foo.bar'
> > > 6) Ping will hang. The child process which it creates cannot be killed
> > > even with killall -9 ping
> >
> > This is exactly what I do not want.  Provide a standalone binary (or
> > binaries) that can be just run and demonstrate the issue.  Without
> > editing nsswitch.conf or patching ping.
> >
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FreeBSD does not reply to IPv6 Neighbor Solicitations

[John-Mark Gurney]

John-Mark Gurney wrote this message on Wed, Jan 13, 2021 at 17:59 -0800:
> Andrey V. Elsukov wrote this message on Wed, Jan 13, 2021 at 11:42 +0300:
> > On 13.01.2021 00:37, John-Mark Gurney wrote:
> > >> when this will happen again, it would be nice to make sure that NS
> > >> packets hit the IP stack. E.g. with attached dtrace script.
> > > 
> > > Ok, I ran the dtrace script when I reproduced the problem, and it did
> > > not produce any output.
> > > 
> > > These are effectively what the script does:
> > > 9) configure inet6 addresses on ure and bge (duplicating the addresses
> > >already configured)
> > 
> > Does it mean that you just reconfigure address without removing it? It
> > looks like the problem, that was discussed here
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233535
> 
> Yeah, I guess it is the same...
> 
> > > bge0:
> > > inet6 fe80::12e7:c6ff:fexx:%bge0 scopeid 0x2
> > > mldv2 flags=2 rv 2 qi 125 qri 10 uri 3
> > > group ff01::1%bge0 scopeid 0x2 mode exclude
> > > mcast-macaddr 33:33:00:00:00:01
> > > group ff02::1%bge0 scopeid 0x2 mode exclude
> > > mcast-macaddr 33:33:00:00:00:01
> > > group ff02::1:ffxx:%bge0 scopeid 0x2 mode exclude
> > > mcast-macaddr 33:33:ff:xx:xx:xx
> > > 
> > > so, I made things works, and ran ifmcstat again, and this time it has
> > > an additional group in the output:
> > > [...]
> > > bge0:
> > > inet6 fe80::12e7:c6ff:fexx:%bge0 scopeid 0x2
> > > mldv2 flags=2 rv 2 qi 125 qri 10 uri 3
> > > group ff02::1:ff00:c43c%bge0 scopeid 0x2 mode exclude
> > > mcast-macaddr 33:33:ff:00:c4:3c
> > > group ff01::1%bge0 scopeid 0x2 mode exclude
> > > mcast-macaddr 33:33:00:00:00:01
> > > group ff02::1%bge0 scopeid 0x2 mode exclude
> > > mcast-macaddr 33:33:00:00:00:01
> > > group ff02::1:ffxx:%bge0 scopeid 0x2 mode exclude
> > > mcast-macaddr 33:33:ff:xx:xx:xx
> > > 
> > > and the tcpdump output:
> > > 21:10:53.938655 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, 
> > > neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32
> > > 21:10:55.001428 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, 
> > > neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32
> > 
> > Since ff02::1:ff00:c43c%bge0 is not configured in first case, IP stack
> > just ignores NS messages and they don't hit ND6 code.
> > 
> > In the PR 233535 the problem was reproducible with MLDv1, so if you
> > disable MLDv2 will it work (to reduce possible scope of problematic code)?
> > 
> > net.inet6.mld.v2enable=0
> 
> I just tested this, and it does not fix the problem for me.
> 
> Do I need to reboot or something?  If I set it to 0, the bug
> still appears, and also the ifmcstat has the line:
> mldv2 flags=2 rv 2 qi 125 qri 10 uri 3
> 
> is there something else that needs to be done to disable mldv2?

I was able to reproduce using epair on a single system.  It did
take a few runs of the test before it failed, but it was able to
fail.

So, to reproduce, on a -current system (mine is
main-c255640-gc38e59ce1b0), do:

ifconfig epair0 create
sh ipv6.failure.sh init epair0a epair0b
sh ipv6.failure.sh run epair0a epair0b
sh ipv6.failure.sh run epair0a epair0b
sh ipv6.failure.sh run epair0a epair0b
sh ipv6.failure.sh run epair0a epair0b

In my case, it failed on the fourth try, but it does appear to be
inconsistent, as a fifth run worked, but then the sixth run failed
again, and additional runs worked...

If you want to see the live tcpdump, you can run the following
commands in a coupld different windows:
jexec testjail tcpdump -n -p -i epair0a

and:
jexec checkjail tcpdump -n -p -i epair0b

uname -a:
FreeBSD test 13.0-CURRENT FreeBSD 13.0-CURRENT #7 main-c255640-gc38e59ce1b0: 
Sat Jan  9 01:55:25 UTC 2021 
root@test:/usr/obj/usr/src.git/amd64.amd64/sys/GENERIC  amd64

and the cpu:
CPU: AMD PRO A10-8770E R7, 10 COMPUTE CORES 4C+6G(2794.80-MHz K8-class CPU)

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"