Re: IPv6 NDP not completing
Interesting links, thanks. Looking into the second one, I noticed this commit: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/netinet6/nd6_nbr.c.diff?r1=1.117=1.118=h It seems like OpenBSD should respond to NS addressed to both global or link-local addresses on the upstream interface. I also set net.inet6.icmp6.nd6_debug=1, but haven't seen anything related in the logs. On 7/31/19 8:23 PM, john slee wrote: Hi, I'm having very similar problems to this, I think. Syspatch'ed OpenBSD 6.5 on an apu4c4, with my ISP-supplied termination device (cable modem, effectively) directly attached to an ethernet interface. No switch. IPv4 works fine. DHCPv6 NA+PD seems to work OK — I get v6 NA & PD assignments — but I can't ping anything beyond my gateway. If I use the ISP-supplied router I have fully functional dualstack networking. I saw sthen@'s recent post on this topic with his configs included. I adjusted my configs (which were already pretty close) to reflect what he'd done, but no joy :-(. FWIW my ISP is Telstra in Australia. Looking around a bit I found a pfSense discussion wherein the suggestion was to make a config change to what I assume underneath the pfSense UI is FreeBSD's "net.inet6.icmp6.nd6_onlink_ns_rfc4861" sysctl: https://whirlpool.net.au/wiki/pfsense_ipv6_telstra But I also found this old discussion that suggested that OpenBSD's behaviour here — and lack of this particular knob — was a result of a nasty old CVE: https://misc.openbsd.narkive.com/3KdNDcEM/openbsd-ignoring-rfc-compliant-ipv6-neighbor-solicitation#post1 My next discovery step is to boot Debian on my spare apu4c4 and see if it works there, capture some traffic, etc. I don't want to use that as a gateway, though. John On Tue, 30 Jul 2019 at 16:22, Kyle wrote: Hi all, I'm trying to get IPv6 set up on a firewall box running 6.4. I'm using dhcpcd to get an NA and several PDs, which appears to be working fine, but no normal v6 traffic can be sent or received. tcpdump on the egress interface (em3) shows lots of icmp6 neighbor solicits going back and forth, but no responses from either side: $ ifconfig em3 em3: flags=8843 mtu 1500 lladdr 0c:c4:7a:ad:2a:e7 index 4 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::8dfc:5795:8ab7:e2b%em3 prefixlen 64 scopeid 0x4 inet netmask 0xe000 broadcast inet6 2605:a601:fe07:c900::1 prefixlen 128 pltime 64553 vltime 86153 $ tcpdump -nlp -i em3 ip6 ... neighbor sol repeating many times ... 22:46:53.876457 fe80::8dfc:5795:8ab7:e2b > ff02::1:ffea:4ff0: icmp6: neighbor sol: who has fe80::2d0:f6ff:feea:4ff0 22:47:01.876688 fe80::2d0:f6ff:feea:4ff0 > 2605:a601:fe07:c900::1: icmp6: neighbor sol: who has 2605:a601:fe07:c900::1 [class 0xc0] 22:47:01.876778 fe80::8dfc:5795:8ab7:e2b > ff02::1:ffea:4ff0: icmp6: neighbor sol: who has fe80::2d0:f6ff:feea:4ff0 22:47:01.877542 fe80::2d0:f6ff:feea:4ff0 > fe80::8dfc:5795:8ab7:e2b: icmp6: neighbor sol: who has fe80::8dfc:5795:8ab7:e2b [class 0xc0] 22:47:02.876594 fe80::8dfc:5795:8ab7:e2b > ff02::1:ffea:4ff0: icmp6: neighbor sol: who has fe80::2d0:f6ff:feea:4ff0 22:47:03.876603 fe80::8dfc:5795:8ab7:e2b > ff02::1:ffea:4ff0: icmp6: neighbor sol: who has fe80::2d0:f6ff:feea:4ff0 22:47:32.337233 fe80::8dfc:5795:8ab7:e2b.546 > ff02::1:2.547: dhcp6 release [hlim 1] 22:47:32.515413 fe80::2d0:f6ff:feea:4ff0.547 > fe80::8dfc:5795:8ab7:e2b.546: dhcp6 [class 0xc0] I added "pass quick on em3 inet6" to the top of pf.conf to make sure the responses aren't being filtered. The peer LL address is always marked incomplete: $ ndp -na | grep em3 2605:a601:fe07:c900::1 0c:c4:7a:ad:2a:e7 em3 permanent R l fe80::2d0:f6ff:feea:4ff0%em3 00:d0:f6:ea:51:96 em3 expired I R fe80::8dfc:5795:8ab7:e2b%em3 0c:c4:7a:ad:2a:e7 em3 permanent R l Pinging any v6 address outside my network only results in one fe80::8dfc:5795:8ab7:e2b > ff02::1:ffea:4ff0: icmp6: neighbor sol: who has fe80::2d0:f6ff:feea:4ff0 per ping sent. Routes: $ route -n show -inet6 | grep em3 default fe80::2d0:f6ff:feea:4ff0%em3 UGS053699 - 8 em3 2605:a601:fe07:c900::1 0c:c4:7a:ad:2a:e7 UHLl 0 1752 - 1 em3 fe80::%em3/64 fe80::8dfc:5795:8ab7:e2b%em3 UCn11 - 4 em3 fe80::2d0:f6ff:feea:4ff0%em3 00:d0:f6:ea:51:96 UHLch 1 720183 - 3 em3 fe80::8dfc:5795:8ab7:e2b%em3 0c:c4:7a:ad:2a:e7 UHLl 0 110606 - 1 em3 ff01::%em3/32 fe80::8dfc:5795:8ab7:e2b%em3 Um 03 - 4 em3 ff02::%em3/32 fe80::8dfc:5795:8ab7:e2b%em3 Um 0 161322 - 4 em3 There is a managed switch between the firewall's egress and the ISP, but it's not doing any packet filtering. I'm currently out of ideas; any suggestions would be much appreciated.
Re: hardware assisted ethernet filtering
On Wed, Jul 31, 2019 at 11:48:24PM +0100, Tom Smyth wrote: > Hi all, > I was just wondering is there an ethtool equivalent in OpenBSD > in particular Im interested in trying to harness some of the features > in the xl710 and more advanced intel Ethernet chipsets where they > allow a (limited) number of filter rules to be applied to a given network > interface, > example to drop high packet rate udp floods / amplification attacks > #drop NTP responses (good and bad) inbound on interface enp134s0f0 > ethtool --config-ntuple enp134s0f0 flow-type udp4 src-port 123 action -1 > #drop DNS responses (good and bad) inbound on interface enp134s0f0 > ethtool --config-ntuple enp134s0f0 flow-type udp4 src-port 53 action -1 > Not hardware filter features, no. But you may be interested in the bpf(4) "filter drop" feature extended recently by dlg@, and added to tcpdump(8), it can be useful in cases where pf(4) cannot. https://marc.info/?l=openbsd-cvs=155286777331151=2 https://man.openbsd.org/tcpdump#B > the benefit of using the NICs ability to filter would be to reduce the > effects > of a high packet rate attack against the OpenBSD router > what way would the openBSD devs think this should be done. > extending ifconfig ? > or a separate tool ? > > It would be nice that the tools commands would be more like pf and less > like eth tools (cause the syntax of ethtools sucks a little here) > some downside risks of the hardware filtering offload is that is not > immediately obvious to someone analysing the firewall rules that there is > a hardware filter in place... perhaps this could be mitigated by some sort > of > > so it might be an idea to prepend a line comment to /etc.pf.conf to give > the sysadmin a hint that there is a hardware filter in play before the > firewall gets > to see the packets... > > any interest ? ideas? alternative view points on it ... > Thanks for your time > > Tom Smyth. >
Re: IPv6 NDP not completing
Hi, I'm having very similar problems to this, I think. Syspatch'ed OpenBSD 6.5 on an apu4c4, with my ISP-supplied termination device (cable modem, effectively) directly attached to an ethernet interface. No switch. IPv4 works fine. DHCPv6 NA+PD seems to work OK — I get v6 NA & PD assignments — but I can't ping anything beyond my gateway. If I use the ISP-supplied router I have fully functional dualstack networking. I saw sthen@'s recent post on this topic with his configs included. I adjusted my configs (which were already pretty close) to reflect what he'd done, but no joy :-(. FWIW my ISP is Telstra in Australia. Looking around a bit I found a pfSense discussion wherein the suggestion was to make a config change to what I assume underneath the pfSense UI is FreeBSD's "net.inet6.icmp6.nd6_onlink_ns_rfc4861" sysctl: https://whirlpool.net.au/wiki/pfsense_ipv6_telstra But I also found this old discussion that suggested that OpenBSD's behaviour here — and lack of this particular knob — was a result of a nasty old CVE: https://misc.openbsd.narkive.com/3KdNDcEM/openbsd-ignoring-rfc-compliant-ipv6-neighbor-solicitation#post1 My next discovery step is to boot Debian on my spare apu4c4 and see if it works there, capture some traffic, etc. I don't want to use that as a gateway, though. John On Tue, 30 Jul 2019 at 16:22, Kyle wrote: > Hi all, > > I'm trying to get IPv6 set up on a firewall box running 6.4. I'm using > dhcpcd to get an NA and several PDs, which appears to be working fine, but > no normal v6 traffic can be sent or received. tcpdump on the egress > interface (em3) shows lots of icmp6 neighbor solicits going back and forth, > but no responses from either side: > > > $ ifconfig em3 > em3: flags=8843 mtu 1500 > lladdr 0c:c4:7a:ad:2a:e7 > index 4 priority 0 llprio 3 > groups: egress > media: Ethernet autoselect (1000baseT full-duplex) > status: active > inet6 fe80::8dfc:5795:8ab7:e2b%em3 prefixlen 64 scopeid 0x4 > inet netmask 0xe000 broadcast > inet6 2605:a601:fe07:c900::1 prefixlen 128 pltime 64553 vltime > 86153 > > > $ tcpdump -nlp -i em3 ip6 > ... neighbor sol repeating many times ... > 22:46:53.876457 fe80::8dfc:5795:8ab7:e2b > ff02::1:ffea:4ff0: icmp6: > neighbor sol: who has fe80::2d0:f6ff:feea:4ff0 > 22:47:01.876688 fe80::2d0:f6ff:feea:4ff0 > 2605:a601:fe07:c900::1: icmp6: > neighbor sol: who has 2605:a601:fe07:c900::1 [class 0xc0] > 22:47:01.876778 fe80::8dfc:5795:8ab7:e2b > ff02::1:ffea:4ff0: icmp6: > neighbor sol: who has fe80::2d0:f6ff:feea:4ff0 > 22:47:01.877542 fe80::2d0:f6ff:feea:4ff0 > fe80::8dfc:5795:8ab7:e2b: > icmp6: neighbor sol: who has fe80::8dfc:5795:8ab7:e2b [class 0xc0] > 22:47:02.876594 fe80::8dfc:5795:8ab7:e2b > ff02::1:ffea:4ff0: icmp6: > neighbor sol: who has fe80::2d0:f6ff:feea:4ff0 > 22:47:03.876603 fe80::8dfc:5795:8ab7:e2b > ff02::1:ffea:4ff0: icmp6: > neighbor sol: who has fe80::2d0:f6ff:feea:4ff0 > 22:47:32.337233 fe80::8dfc:5795:8ab7:e2b.546 > ff02::1:2.547: dhcp6 > release [hlim 1] > 22:47:32.515413 fe80::2d0:f6ff:feea:4ff0.547 > > fe80::8dfc:5795:8ab7:e2b.546: dhcp6 [class 0xc0] > > > I added "pass quick on em3 inet6" to the top of pf.conf to make sure the > responses aren't being filtered. > > The peer LL address is always marked incomplete: > > $ ndp -na | grep em3 > 2605:a601:fe07:c900::1 0c:c4:7a:ad:2a:e7 em3 permanent R > l > fe80::2d0:f6ff:feea:4ff0%em3 00:d0:f6:ea:51:96 em3 expired I > R > fe80::8dfc:5795:8ab7:e2b%em3 0c:c4:7a:ad:2a:e7 em3 permanent R > l > > > Pinging any v6 address outside my network only results in one > fe80::8dfc:5795:8ab7:e2b > ff02::1:ffea:4ff0: icmp6: neighbor sol: who has > fe80::2d0:f6ff:feea:4ff0 > > per ping sent. > > Routes: > > $ route -n show -inet6 | grep em3 > default fe80::2d0:f6ff:feea:4ff0%em3 UGS053699 - 8 em3 > 2605:a601:fe07:c900::1 0c:c4:7a:ad:2a:e7 UHLl 0 > 1752 - 1 em3 > fe80::%em3/64 fe80::8dfc:5795:8ab7:e2b%em3 UCn11 - 4 > em3 > fe80::2d0:f6ff:feea:4ff0%em3 00:d0:f6:ea:51:96 UHLch 1 > 720183 - 3 em3 > fe80::8dfc:5795:8ab7:e2b%em3 0c:c4:7a:ad:2a:e7 UHLl 0 > 110606 - 1 em3 > ff01::%em3/32 fe80::8dfc:5795:8ab7:e2b%em3 Um 03 - 4 > em3 > ff02::%em3/32 fe80::8dfc:5795:8ab7:e2b%em3 Um 0 161322 - 4 > em3 > > > There is a managed switch between the firewall's egress and the ISP, but > it's not doing any packet filtering. I'm currently out of ideas; any > suggestions would be much appreciated. > > >
hardware assisted ethernet filtering
Hi all, I was just wondering is there an ethtool equivalent in OpenBSD in particular Im interested in trying to harness some of the features in the xl710 and more advanced intel Ethernet chipsets where they allow a (limited) number of filter rules to be applied to a given network interface, example to drop high packet rate udp floods / amplification attacks #drop NTP responses (good and bad) inbound on interface enp134s0f0 ethtool --config-ntuple enp134s0f0 flow-type udp4 src-port 123 action -1 #drop DNS responses (good and bad) inbound on interface enp134s0f0 ethtool --config-ntuple enp134s0f0 flow-type udp4 src-port 53 action -1 the benefit of using the NICs ability to filter would be to reduce the effects of a high packet rate attack against the OpenBSD router what way would the openBSD devs think this should be done. extending ifconfig ? or a separate tool ? It would be nice that the tools commands would be more like pf and less like eth tools (cause the syntax of ethtools sucks a little here) some downside risks of the hardware filtering offload is that is not immediately obvious to someone analysing the firewall rules that there is a hardware filter in place... perhaps this could be mitigated by some sort of so it might be an idea to prepend a line comment to /etc.pf.conf to give the sysadmin a hint that there is a hardware filter in play before the firewall gets to see the packets... any interest ? ideas? alternative view points on it ... Thanks for your time Tom Smyth.
[www] mail.html - adding few links
Hi, here is a small cosmetics update for the mail.html. Cheers, Alex Index: mail.html === RCS file: /cvs/www/mail.html,v retrieving revision 1.165 diff -u -p -r1.165 mail.html --- mail.html 1 Jun 2019 23:12:48 - 1.165 +++ mail.html 31 Jul 2019 20:05:16 - @@ -240,7 +240,7 @@ These private addresses are for reportin These lists are focused on user issues and development on individual -platforms. +platforms. al...@openbsd.org @@ -294,14 +294,15 @@ comments. source-chan...@openbsd.org -Automated mail of CVS source tree changes in the src, xenocara and www -repositories. +Automated mail of CVS source tree changes in the src, +xenocara and www repositories. (https://marc.info/?l=openbsd-cvs;>Archive) ports-chan...@openbsd.org -Automated mail of CVS source tree changes in the ports repository. +Automated mail of CVS source tree changes in the ports +repository. (https://marc.info/?l=openbsd-ports-cvs;>Archive) @@ -409,7 +410,7 @@ This is handy for those who don't like t The insomniac at https://www.benzedrine.ch/mailinglist.html;> benzedrine.ch maintains the pf list for people using the -OpenBSD packet filter. +OpenBSD packet filter. To subscribe, send an email with the message body of "subscribe" to pf-requ...@benzedrine.ch.
Re: How to debug hanging machines / proc: table is full
On Wed, Jul 31, 2019 at 05:46:08PM +0200, Raimo Niskanen wrote: > I have enabled Witness, it went so-so. We'll see what it catches. > > I downloaded 6.5 amd64 src.tar.gz and sys.tar.gz, unpacked them, > applied all patches for stable 001-006 and built a kernel with: > include "arch/amd64/conf/GENERIC" > option MULTIPROCESSOR > option MP_LOCKDEBUG > option WITNESS > > Then I activated in /etc/sysctl.conf: > ddb.console=1 > kern.witness.locktrace=1 > kern.witness.watch=3 > > For fun, I pressed Ctrl+Alt+Esc at the console, got a ddb> prompt and typed > "show witness". It printed lots of info, I scrolled down to the end, but > during the printout there was an UVM fault: > > Spin locks: > /usr/src/sys/ > : > bla bla bla > : > uvm_fault(0x81e03b50, 0x800022368360, 0, 1) -> e > kernel: page fault trap, code=0 > Faulted in DDB: continuing... The output of "show witness" is unlikely to be useful in your case. It is more of a tool for debugging witness. You can ignore it. However, "show all locks" might display interesting information after a witness-related panic.
Re: How to debug hanging machines / proc: table is full
On Mon, Jul 29, 2019 at 01:20:58PM +, Stuart Henderson wrote: > On 2019-07-29, Raimo Niskanen wrote: > > A new hang, I tried to invstigate: > > > > At July 19 the last log entry from my 'ps' log was from 14:55, which is > > also the time on the 'systat vmstat' screen when it froze. Then the machine > > hums along but just after midnight at 00:42:01 the first "/bsd: process: > > table is full" entry appears. That message repeats until I rebooted it > > today at July 29 10:48. > > > > I had a terminal with top running. It was still updating. It showed about > > 98% sys and 2% spin on one of 4 CPUs, the others 100% idle. Then (after > > the process table had gotten full) it had 1282 idle processes and 1 on > > processor, which was 'top' itself. > > Memory: Real: 456M/1819M act/tot Free: 14G Cache: 676M Swap: 0K/16G. > > > > I had 8 shells under tmux ready for debugging. 'ls worked. > > 'systat' on one hung. 'top' on another failed with "cannot fork". > > 'exec ps ajxww" printed two lines with /sbin/init and /sbin/slaac > > and then hung. 'exec reboot' did not succeed. Neither did a short power > > button, that at least caused a printout "stopping daemon nginx(failed)", > > but got no further. I had to do a hard power off. > > > > My theory now is that our daily tests right before 14:55 started a process > > (this process is the top 'top' process with 10:14 execution time) that > > triggers a lock or other contention problem in the kernel which causes > > one CPU to spin in the system, and blocks processes from dying. > > About 10 hours later the process table gets full. > > > > Any, ANY ideas of how to proceed would be appreciated! > > > > Best Regards > > Did you notice any odd waitchan's (WAIT in top output)? > > Maybe set ddb.console=1 in sysctl.conf and reboot (if not already > set), then try to break into DDB during a hang and see how things look > in ps there. (Test breaking into DDB before a hang first so you know > that you can do it .. you can just "c" to continue). > > There might also be clues in things like "sh malloc" or "sh all pools". > > Perhaps you could also get clues from running a kernel built with > 'option WITNESS', you may get some messages in dmesg, or it adds commands > to ddb like "show locks", "show all locks", "show witness" (see ddb(4) for > details). I have enabled Witness, it went so-so. We'll see what it catches. I downloaded 6.5 amd64 src.tar.gz and sys.tar.gz, unpacked them, applied all patches for stable 001-006 and built a kernel with: include "arch/amd64/conf/GENERIC" optionMULTIPROCESSOR optionMP_LOCKDEBUG optionWITNESS Then I activated in /etc/sysctl.conf: ddb.console=1 kern.witness.locktrace=1 kern.witness.watch=3 For fun, I pressed Ctrl+Alt+Esc at the console, got a ddb> prompt and typed "show witness". It printed lots of info, I scrolled down to the end, but during the printout there was an UVM fault: Spin locks: /usr/src/sys/ : bla bla bla : uvm_fault(0x81e03b50, 0x800022368360, 0, 1) -> e kernel: page fault trap, code=0 Faulted in DDB: continuing... Then I typed "cont" and it panicked. If anybody want details I took a picture. Have I combined too many debugging options, or is this sh*t that happens? Nevertheless, now the machine is running again, with Witness... I'll be back. > > Can you provoke a hang by running this process manually? -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: lrint(INT_MAX) != INT_MAX
Op Tue, 30 Jul 2019 17:12:56 +0200 schreef :
This is what happens on my relatively current
OpenBSD bbb.stare.cz 6.5 GENERIC#0 armv7(BeagleBone Black)
OpenBSD ppc.stare.cz 6.5 GENERIC#0 macppc (an old MacMini)
#include
#include
#include
int
main()
{
long l;
double d = INT_MAX;
l = lrint(d);
printf("%f is %ld\n", d, l);
l = lround(d);
printf("%f is %ld\n", d, l);
return 0;
}
2147483647.00 is -1
2147483647.00 is -1
That doesn't seem right: isn't INT_MAX representable as a long,
even on these machines where sizeof(int) == sizeof(long)?
If it is less than LONG_MAX, then yes.
If so, shouldn't lrint(INT_MAX) == INT_MAX = lround(INT_MAX)?
If the double type provides enough mantisse (which I think it does on all
platforms), and if I read a few C standards correctly, then yes.
On i386 (an ALIX), I see
2147483647.00 is 2147483647
2147483647.00 is -1
so lrint() returns the expected value but lround() does not.
On the amd64s I have, I see the expected:
2147483647.00 is 2147483647
2147483647.00 is 2147483647
Is this a bug or am I missing something obvious?
I'd say it's a bug. Also with a float variable and with lrintf/lroundf the
outcome should ideally be 2147483647.
--
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Re: su - root => segmentation fault
On 31.07.19 17:00, Solene Rapenne wrote: On Wed, Jul 31, 2019 at 04:49:54PM +0500, dmitry.sensei wrote: Hi! why did it happen? OpenBSD 6.5 current $su - root root's password: Segmentation fault $ doas su - root # -- Dmitry Orlov what current? What arch? works for me© OpenBSD 6.5-current (GENERIC.MP) #153: Sun Jul 28 20:33:09 MDT 2019 usually it means that your kernel does not match the userspace
Re: su - root => segmentation fault
On Wed, Jul 31, 2019 at 04:49:54PM +0500, dmitry.sensei wrote: > Hi! > why did it happen? > > OpenBSD 6.5 current > $su - root > root's password: > Segmentation fault > $ doas su - root > # > > -- > Dmitry Orlov what current? What arch? works for me© OpenBSD 6.5-current (GENERIC.MP) #153: Sun Jul 28 20:33:09 MDT 2019
su - root => segmentation fault
Hi! why did it happen? OpenBSD 6.5 current $su - root root's password: Segmentation fault $ doas su - root # -- Dmitry Orlov
problem to copy a (possibly large) file over a network device
Dear list, I am able to copy a subtree 'www' with the command ; tar -cf - www | pv| (cd ~ruda/tmp/test && tar -xpf -) but I can't do the same with In one terminal: ;tar -cf - www | pv | nc localhost 7000 In another terminal: ;nc -l 7000 | pv | tar -xpf - [ I actually wanted to do a backup of the subtree with rsync over the network, but that didn't work, spitting sth. like rsync error: unexplained error (code 255) at io.c(820) [sender=3.1.3] [sender] _exit_cleanup(code=10, file=io.c, line=820): about to call exit(255) I then tried to do the copying with nc, which again did not succeed; but without any message this time, it just got stuck. So I tried to copy just locally, within one machine, using localhost. ] What one sees with the nc command is that the connection keeps existing, but the copying itself stops. Ie., I can ctrl-c at the source end, and the receiving command exits. As I have no idea what can cause this behaviour, I am asking for any help. Thank you! Best regards Rudolf Sykora
