Re: Profiling ifconfig
Profiling ifconfig was my first guess, I am not an experienced programmer in any sense of the word. I did the ktrace/kdump run, and the result is just 65 lines, most of which seem normal (attached). The suspicious lines below: ``` 78429 ifconfig 1639744429.761912 CALL socket(AF_INET,0x2,0) 78429 ifconfig 1639744429.761920 RET socket 3 78429 ifconfig 1639744429.761922 CALL ioctl(3,SIOCGIFFLAGS,0xcc175b5b2a8) 78429 ifconfig 1639744429.761925 RET ioctl 0 78429 ifconfig 1639744429.761926 CALL ioctl(3,SIOCGIFXFLAGS,0xcc175b5b2a8) 78429 ifconfig 1639744429.761927 RET ioctl 0 78429 ifconfig 1639744429.761928 CALL ioctl(3,SIOCGIFMETRIC,0xcc175b5b2a8) 78429 ifconfig 1639744429.761929 RET ioctl 0 78429 ifconfig 1639744429.761934 CALL ioctl(3,SIOCBRDGRTS,0x7f7bda50) 78429 ifconfig 1639744429.761936 RET ioctl -1 errno 25 Inappropriate ioctl for device 78429 ifconfig 1639744429.761937 CALL ioctl(3,SIOCGIFMTU,0xcc175b5b2a8) 78429 ifconfig 1639744429.761939 RET ioctl 0 78429 ifconfig 1639744429.761939 CALL ioctl(3,SIOCGIFRDOMAIN,0xcc175b5b2a8) 78429 ifconfig 1639744429.761942 RET ioctl 0 78429 ifconfig 1639744429.761943 CALL ioctl(3,SIOCGIFLLPRIO,0xcc175b5b2a8) 78429 ifconfig 1639744429.761944 RET ioctl 0 78429 ifconfig 1639744429.761945 CALL ioctl(3,SIOCGIFFLAGS,0x7f7bda80) 78429 ifconfig 1639744429.761946 RET ioctl 0 78429 ifconfig 1639744429.761947 CALL ioctl(3,SIOCSIFFLAGS,0x7f7bda80) 78429 ifconfig 1639744660.684179 RET ioctl 0 78429 ifconfig 1639744660.701556 CALL mprotect(0xcc385a48000,0x1000,0x3) ``` I have no idea what this means, to be honest. ioctl(3,SIOCSIFFLAGS,0x7f7bda80) seems to be the one running for 231 second. I looked at the code of if_vio.c, and it seems to be taking time at calling vio_init (as there is not much more in this ioctl), however, I do not know much about debugging kernel drivers, so suggestions welcome :). Is there a way to recompile it with profiling/tracing information, or maybe just putting printfs manually around the most interesting lines would be more productive? ifconfig-kdump.result.2021-12-17_12-34 Description: Binary data "Theo de Raadt" writes: > Claudio Jeker wrote: > >> On Thu, Dec 16, 2021 at 03:55:43PM +0800, Vladimir Nikishkin wrote: >> > Hello, everyone >> > >> > Recently I had a problem: my system is losing network connectivity, >> > although the interface (vio0 on KVM) seemed up. Restarting the >> > connection with `ifconfig vio0 down` and `ifconfig vio0 up` restores the >> > connection. >> > >> > However, when I timed the execution, I found that the second `up` can >> > take up to 15 minutes. (Hugely unexpected!) To find out where the >> > program is waiting, I decided to recompile ifconfig from source with >> > debugging and profiling support. >> > >> > Slightly adjusting the commands provided by the Makefile, I came up with >> > the following commands: >> > >> > ``` >> > egcc -O0 -g -pg -fPIC -Werror-implicit-function-declaration -c ifconfig.c >> > egcc -O0 -g -pg -fPIC -Werror-implicit-function-declaration -c brconfig.c >> > egcc -O0 -g -pg -fPIC -Werror-implicit-function-declaration -c sff.c >> > egcc -g -pg -shared -pie -o ifconfig ifconfig.o brconfig.o sff.o -lc -pg >> > ``` >> > >> > However, when I run ./ifconfig compiled like this, I am getting (besides >> > the output of ifconfig itself) the following error message: >> > >> > ``` >> > gmon.out: No such file or directory >> > ``` >> > >> > I find this unexpected. Compiling and linking a simple helloworld with >> > -pg -g seems to be working fine, and gmon.out is produced as expected. >> > >> > What am I doing wrong? Is there something specific that needs to be >> > permitted to profile ifconfig? >> >> I doubt the problem is in ifconfig(8) itself but more an ioctl that takes >> long to finish. Anyway for prfiling to work you need to neuter unveil() in >> ifconfig. e.g. by changing the code. With unveil on the gmon.out file >> written in the atexit handler can't be created. > > Wrong tool being used to debug a userland program. It is better to attach > a debugger to a -g executable. Or use ktrace -di with kdump, to figure out > what system calls it is stuck in. > > And I suspect you will quickly decide there is no problem in ifconfig.. -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop)
Profiling ifconfig
Hello, everyone Recently I had a problem: my system is losing network connectivity, although the interface (vio0 on KVM) seemed up. Restarting the connection with `ifconfig vio0 down` and `ifconfig vio0 up` restores the connection. However, when I timed the execution, I found that the second `up` can take up to 15 minutes. (Hugely unexpected!) To find out where the program is waiting, I decided to recompile ifconfig from source with debugging and profiling support. Slightly adjusting the commands provided by the Makefile, I came up with the following commands: ``` egcc -O0 -g -pg -fPIC -Werror-implicit-function-declaration -c ifconfig.c egcc -O0 -g -pg -fPIC -Werror-implicit-function-declaration -c brconfig.c egcc -O0 -g -pg -fPIC -Werror-implicit-function-declaration -c sff.c egcc -g -pg -shared -pie -o ifconfig ifconfig.o brconfig.o sff.o -lc -pg ``` However, when I run ./ifconfig compiled like this, I am getting (besides the output of ifconfig itself) the following error message: ``` gmon.out: No such file or directory ``` I find this unexpected. Compiling and linking a simple helloworld with -pg -g seems to be working fine, and gmon.out is produced as expected. What am I doing wrong? Is there something specific that needs to be permitted to profile ifconfig? -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop)
(Feedback needed) openbsd and ulimits.
Hello, everyone. I found this problem when trying to write some go on OpenBSD: https://github.com/google/starlark-go/issues/382 OpenBSD enforces ulimits on virtual space, whereas many operating systems do not. `starlark`, as, in fact, many other pieces of software, casually allocate "all virtual space in 32 bits", because presumably that does not hurt on other operating systems. Hence, software using starlark compiles, but does not run. What would be the best approach to make it work on OpenBSD? I am not an expert on POSIX memory management in any sense of the word, so please, those who are, comment on that issue. -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop)
portgen does not handle go ports with capital letter in name
Dear all, I tried to use portgen to semi-automatically generate a port for a go project with a capital letter in the name. It failed with a cryptic error. I commented out the code in Port.pm the place which retries to generate a name for everything other than Perl (p5), and it worked. I thing Go.pm does not expect to be called the second time with a name. Hope this helps. -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop)
Re: (bug?) relayd forward to directives interfering
This has actually been reported before: https://www.mail-archive.com/bugs@openbsd.org/msg14189.html Jean-Pierre de Villiers writes: > On 21/08/11 04:34pm, Vladimir Nikishkin wrote: >> I do not think my setup is related to "TLS Inspection". > > Apologies, my misunderstanding. I always forget I divert traffic to to > localhost in my setup. Anyway, > >> There is no problem connecting to the TLS-enabled backend. The problem >> appears when connecting to the HTTP backend, when, _at the same time_, >> in the same relay there is another redirect to the TLS backend. > > Did you make sure to use the https scheme in your curl request? > Something like: > > $ curl https://domain.example/http > > The listener is still a TLS listener even if the backend uses only plain > http. > > Sorry for the confusion. > > Regards, > JP -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop)
Re: (bug?) relayd forward to directives interfering
I do not think my setup is related to "TLS Inspection". There is no problem connecting to the TLS-enabled backend. The problem appears when connecting to the HTTP backend, when, _at the same time_, in the same relay there is another redirect to the TLS backend. On Wed, 11 Aug 2021 at 16:15, Jean-Pierre de Villiers wrote: > > On 21/08/11 02:40pm, Vladimir Nikishkin wrote: > > However, if I keep "with tls", the requests to port 81 are going > > encrypted, and are failing with the following message in relayd logs: > > `SSL routines:ST_CONNECT:tlsv1 alert protocol version`, > > `TLS handshake error: handshake failed:`. > > What you're currently attemting is referred to as TLS inspection in > relayd.conf(5). This is when one combines client and server modes. > > In order for TLS inspection to function properly the protocol options > "ca cert" and "ca key" both need to be set. Further details found in > the "TLS Relays" and "Protocols" sections of relayd.conf(5). > > Regards, > JP -- Yours sincerely, Vladimir Nikishkin (Sent from GMail web interface.)
(bug?) relayd forward to directives interfering
Hello, everyon
I have a super simple (sanitised) relayd.conf
```
$ext_ip = 192.168.1.1
table { 127.0.0.1 }
table { 127.0.0.1 }
http protocol "p-https" {
tls session tickets
tls keypair domain.example
tls ca file "/etc/ssl/cert.pem"
http websockets
tcp { nodelay, sack, socket buffer 65536, backlog 100 }
return error
block
pass request path log "/http*" forward to
pass request path log "/https*" forward to
pass response
}
relay "tlsforward" {
listen on $ext_ip port 443 tls
protocol "p-https"
forward to port 81
forward with tls to port 82
}
```
The the problem is with the second-to-last line.
If I remove "with tls",
then requests to 82 are forwarded unencrypted, and curl test reports
`curl: (52) Empty reply from server`.
However, if I keep "with tls", the requests to port 81 are going
encrypted, and are failing with the following message in relayd logs:
`SSL routines:ST_CONNECT:tlsv1 alert protocol version`,
`TLS handshake error: handshake failed:`.
There should not be any TLS handshakes at port 81, because the backend
at port 81 is http-only.
Could someone verify that this is the case?
Is there anything I am missing here?
--
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)
iked choosing the wrong policy?
Hello, everyone. This is my iked.conf: ``` ikev2 "for-phone" passive esp \ from any to 10.0.3.2/32 \ local egress peer any \ ikesa enc aes-256 prf hmac-sha2-256 auth hmac-sha2-256 group ecp256 \ childsa enc aes-256 auth hmac-sha2-256 prf hmac-sha2-256 group ecp256 \ srcid server.mine \ dstid phone.mine \ eap "mschap-v2" \ config address 10.0.3.2 \ config name-server 10.0.0.1 \ config netmask 255.255.255.255 \ config protected-subnet 10.0.0.0/24 \ config protected-subnet 10.0.1.0/24 \ config protected-subnet 10.0.2.0/24 \ tag "ROADW" ikev2 "for-laptop" passive esp \ from any to 10.0.3.3/32 \ local egress peer any \ ikesa enc aes-256 auth hmac-sha2-512 prf hmac-sha2-512 group ecp521 \ childsa enc aes-256 auth hmac-sha2-512 group ecp521 \ srcid server.mine \ dstid laptop.mine \ rsa \ config address 10.0.3.3 \ config name-server 10.0.0.1 \ config netmask 255.255.255.255 \ config protected-subnet 10.0.0.0/24 \ config protected-subnet 10.0.1.0/24 \ config protected-subnet 10.0.2.0/24 \ tag "ROADW" ``` I expected the peer presenting itself as "phone.mine" get the first policy (as long as it manages to authenticate by mschapv2), and the peer presenting itself as "laptop.mine" to get the second policy. However, what happens in reality is that both of them are being given the second policy, and the phone fails to authenticate. If I comment out the second policy, the phone successfully gets the first policy and authenticates itself, but, obviously, the laptop does not work then. How to correct the setup? -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop)
Potential bug in /usr/sbin/ndp lines 316-364 with RTF_LLINFO
Hello, everyone. I believe, ndp.c has a bug. 1. Line 319 defines a fresh m_rtmsg, and does not initialise it. 2. Therefore m_rtmsg.m_rtm should be empty or zero. (Or constant, I am not very sure) 3. Line 329 defines rtm and makes it a pointer to a fresh (empty or constant) m_rtmsg.m_rtm. 4. Nothing uses either m_rtmsg or rtm until lines 363+364. 5. On line 363, `if` checks that rtm->rtm_flags & RTF_LLINFO is true. Effectively, it is checking that m_rtmsg.r_rtm.rtm_flags has some bit set. This check is either checking an uninitialised, or a constant value. (I am not very sure how fresh structures are initialised in OpenBSD) In either case, it is not useful. In effect, `ndp -s ` always fails, because this check is always false. -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop)
ndp for ND (ipv6) proxying on /64 prefix is failing cryptically.
Hello, everyone I am running an OpenBSD 6.9 Vultr node. Vultr is issuing /64 prefixes with SLAAC. I have a few machines behind this node, connected via wireguard. For simplicity, let us say that vio0 is the default interface, configured the way Vultr suggests: hostname.vio0 dhcp inet6 autoconf -temporary -soii wireguard is configured like this: hostname.wg0 inet6 128 !/usr/local/bin/wg setconf wg0 /etc/wireguard/server.conf from the outside I cannot pint , the response being 2401:c080:1c00:a4::33 icmp_seq=3 Destination unreachable: Address unreachable If my understanding is correct, that is because wg0 cannot respond to ND requests from the router. Trying to set up proxy NDP, I am running ndp like thi: ndp -s temp proxy If I understand correctly, this should make "vio0" announce the static ip to the router. (the words "temp" and "proxy" seem to have no effect) However, ndp errs: ndp: set: cannot configure a new entry There seems to have been a similar error in 2008: http://openbsd-archive.7691.n7.nabble.com/error-with-ndp-only-on-sparc64-td200752.html and https://marc.info/?l=openbsd-ipv6&m=120731349004033&w=2 sysctl: net.inet6.ip6.forwarding=1 but net.inet6.ip6.accept_rtadv=0 seems to have disappeared. What is it that I am doing wrong? The nabble message mentions some bug in ndp, but it should have disappeared long ago. Perhaps, an FAQ entry related to ndp would be nice to have? Ipv6 is supposed to have the adoption rate of 33%, not such an uncommon thing any more. -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop)
