altroot weekly.local
Is there any problem with putting ROOTBACKUP=1 in my weekly.local instead of daily.local? I'm backing up to an SD card and it's maybe not fast enough to back up in 24 hours, plus weekly backup would be fine. Many thanks.
Re: EACCES of UDP packet
On Tue, Jun 22, 2021 at 04:48:26PM +0800, Siegfried Levin wrote: > > Why have you chosen to hide information that may be useful in debugging > > your problem? > > I’m truly sorry for the inconvenience but I do have some concerns of security > and privacy. I confirm it is not a broadcast address because it is the public > IP of the server and this issue has a probability of 1% to happen. The > address cannot just be a broadcast address at 1% of the time while not at the > rest of 99%. I also double checked it by SSHing to the address I copied from > the kdump, if it makes sense. > > > So, since the manpage mentions blocking pf, I suggest the hypothesis "it > > returns EACCES because pf is blocking your packets". I can think of > > several ways to test that; what testing have you performed to confirm or > > rule out that possibility? "doas pfctl -d; run test; doas pfctl -e”? > > This issue is really hard to reproduce because the application works at most > of the time, but I think you are right. I’ll be watching the pf log in next > weeks. > Also check the various counters of netstat -s and especially pfctl -si (or systat pf). In the pfctl output especially check memory, congestion or state errors. -- :wq Claudio
Re: Localization of date(1) and XFCE
On Jun 20 18:58:31, ffuen...@texto-plano.xyz wrote: > I speak Spanish and thus I use a locale called es_CL.UTF-8. XFCE is fine > with it. However, my date is expressed directly as it comes from date(1). > This is confirmed by their docs > https://docs.xfce.org/xfce/xfce4-panel/4.16/clock so how do I make date to > work with my language. > > This is my locale: > > LANG=es_CL.UTF-8 > LC_COLLATE="es_CL.UTF-8" > LC_CTYPE="es_CL.UTF-8" > LC_MONETARY="es_CL.UTF-8" > LC_NUMERIC="es_CL.UTF-8" > LC_TIME="es_CL.UTF-8" > LC_MESSAGES="es_CL.UTF-8" > LC_ALL=es_CL.UTF-8 man locale Programs in the OpenBSD base system ignore the locale except for the character encoding, and it is not recommended to use any of these variables except that the following non-default setting is supported as an option: export LC_CTYPE=en_US.UTF-8 OpenBSD's date(1) ignores your locale setting. XFCE as a third-party application might choose to support it, but that has nothing to do with the base date(1).
Re: EACCES of UDP packet
> Why have you chosen to hide information that may be useful in debugging your
> problem?
I’m truly sorry for the inconvenience but I do have some concerns of security
and privacy. I confirm it is not a broadcast address because it is the public
IP of the server and this issue has a probability of 1% to happen. The address
cannot just be a broadcast address at 1% of the time while not at the rest of
99%. I also double checked it by SSHing to the address I copied from the kdump,
if it makes sense.
> So, since the manpage mentions blocking pf, I suggest the hypothesis "it
> returns EACCES because pf is blocking your packets". I can think of several
> ways to test that; what testing have you performed to confirm or rule out
> that possibility? "doas pfctl -d; run test; doas pfctl -e”?
This issue is really hard to reproduce because the application works at most of
the time, but I think you are right. I’ll be watching the pf log in next weeks.
> Alternatively: what's different about *that* call? Does every sento() call
> on that socket fail? What is special about that socket? If other sendto()
> calls succeed, what is different about that call? Earlier setsockopt() calls?
The call failed once after a few days of running. I have no idea of how to
present this but it seems the second and third arguments of sendto call are
always changing?
3058 myapp CALL
sendto(5,0x1689f5f6100,0x5d,0x400,0x7f7f1144,0x10)
3058 myapp STRU struct sockaddr { AF_INET, xxx.xx.xxx.xx:y }
3058 myapp GIO fd 5 wrote 93 bytes
"\M^Ai9\M^N\M^U\M-@9
\M-7\M-B\M-m\M^C.\M-ut\M^E~)\M^H'w\M-A\M-p|\M-+DK\M-V\M-8v\M-~c\240\M-=y\M-E\M-*\M-+.\M-I\M-m\M^[\M-s\M-&\\\M^GwP\M-I\r\M^[\M-C\^]B\M-%\M-<\M-q\
\M-rk\M-_\M-g\M-9Y\^B\M-+Y\M-:K\M^X\^E/*\M-4_\M-x\at\M-{\M-$\M-[\^NU\\\M^HPk\M-i\\\M-M\M-H8t
"
3058 myapp RET sendto 93/0x5d
3058 myapp CALL kevent(3,0,0,0x168a7f0c000,128,0)
3058 myapp STRU struct kevent { ident=4, filter=EVFILT_READ,
flags=0x61, fflags=0<>, data=73, udata=0x2 }
3058 myapp RET kevent 1
3058 myapp CALL read(4,0x7f7f0af0,0x7d0)
3058 myapp GIO fd 4 read 73 bytes
"\0\0\0\^BE\0\0E\M^_?\0\0@\^Q\M-9\M-:\M-@\M-(_\^D\^A\^A\^A\^A\M-x\M-U\0005\0001\M^U\M-Q\M-B\M-U\^A\0\0\^A\0\0\0\0\0\^A\^Bbt\^Ehenbt\^Ccom\0\0\^A\0\^A\0\0)\^D\M-P\0\
\0\M^@\0\0\0"
3058 myapp RET read 73/0x49
3058 myapp CALL read(4,0x7f7f0af0,0x7d0)
3058 myapp GIO fd 4 read 79 bytes
"\0\0\0\^BE\0\0K\M-i\M^E\0\0@\^Qpo\M-@\M-(_\^D\^A\0\0\^A\M-Sy\0005\0007\M-8
\M-dB\^A\0\0\^A\0\0\0\0\0\^A\atracker\^Fcity9x\^Ccom\0\0\^A\0\^A\0\0)\^D\M-P\0\0\M^@\0\0\
\0"
3058 myapp RET read 79/0x4f
3058 myapp CALL read(4,0x7f7f0af0,0x7d0)
3058 myapp RET read -1 errno 35 Resource temporarily unavailable
3058 myapp CALL read(7,0x7f7f07e0,0xc)
3058 myapp GIO fd 7 read 12 bytes
"4z.\M-"\M-)-\M-o\^E\M-v\^Q\M-5u"
3058 myapp RET read 12/0xc
3058 myapp CALL
sendto(5,0x1690776aa00,0x61,0x400,0x7f7f1144,0x10)
3058 myapp STRU struct sockaddr { AF_INET, xxx.xx.xxx.xx:y }
3058 myapp GIO fd 5 wrote 97 bytes
"\M-)\M-,\M-r\M-b\^R\M-Jb\M-@\M-b\M-{\M^G"\M-Z\v\M-v\M-L\^^\M-BI\M-X\M-S\M-L]\M-&\^R%\M-?\M-\\M-kN\M^G:\M-NVI\M-@s\0#\M-V\M-}\M-h\M-T\M^C\^R\M-W\M-"\^?\M^Q[:u\M-=\
\M-Q%\M-c\M-+\M-xZ\^B\M-$\M-N\M-1\^Zy\M^D 9#\^Q\M--\M^Jb\M^T(
\M^@\M^L;~\M-<\M-}0\M-G\M-`4z.\M-"\M-)-\M-o\^E\M-v\^Q\M-5u"
3058 myapp RET sendto 97/0x61
3058 myapp CALL read(7,0x7f7f07e0,0xc)
3058 myapp GIO fd 7 read 12 bytes
"\M-j\M->\M-9\^V\^U\^^\M-c/h',\M^D"
3058 myapp RET read 12/0xc
3058 myapp CALL
sendto(5,0x1690776a600,0x67,0x400,0x7f7f1144,0x10)
3058 myapp STRU struct sockaddr { AF_INET, xxx.xx.xxx.xx:y }
3058 myapp GIO fd 5 wrote 103 bytes
"\^W\^\\M-B\M^E\M-~\M-c\M-3\M-f\M-X\M^Y\M-Z\^V\M-G\M-p\M^L\M^G\M-b\M-T\M^I\M-SWu\M-]\M^Jq\M^Q\M-Z\^Z\M^[\bW>`/fW\b\M^K\M-*\^]:E\M-T\M-[\M^X\M-5M\M^J\M-j\M-v\^^Z@:\
\M-QfQ\a-\M-\)\M-O$[\M-x]\b\M-Wh5\M^F\M^B|I>
\M^CY\M-%\M-6'\M^?g9F?y\^T\M-}\^E\M-g\M-j\M->\M-9\^V\^U\^^\M-c/h',\M^D"
3058 myapp RET sendto 103/0x67
3058 myapp CALL kevent(3,0,0,0x168a7f0c000,128,0)
3058 myapp STRU struct kevent { ident=4, filter=EVFILT_READ,
flags=0x61, fflags=0<>, data=75, udata=0x2 }
3058 myapp RET kevent 1
3058 myapp CALL read(4,0x7f7f0af0,0x7d0)
3058 myapp GIO fd 4 read 75 bytes
"\0\0\0\^BE\0\0GS\M^L\0\0@\^Q\^Fm\M-@\M-(_\^D\^A\0\0\^A\M-n\M-)\0005\0003m\M-_N\M-#\^A\0\0\^A\0\0\0\0\0\^A\^Cbtx\aanifilm\^Btv\0\0\^A\0\^A\0\0)\^D\M-P\0\0\M^@\0\0\0"
3058 myapp RET read 75/0x4b
3058 myapp CALL read(4,0x7f7f0af0,0x7d0)
3058 myapp RET read -1 errno 35 Resource temporarily unavailable
3058 myapp CALL read(7,0x7f7f07e0,0xc)
3058 myapp GIO fd 7 read 12 bytes
"\M^T\M-|\M-e\M-Fk-\M^P\M-u}\M-j\M^U="
3058 myapp RET read 12/0xc
3058 myapp CALL
Re: EACCES of UDP packet
On Mon, Jun 21, 2021 at 9:07 PM Siegfried Levin
wrote:
> Thanks a lot for the hint. Unfortunately I’m still not able to see why
> sendto failed with 13 Permission denied. The AF_INET address masked is the
> correct one of my server, not a broadcast address. A sendto before this one
> to the same address just worked.
>
> 3058 myapp CALL
> sendto(5,0x1689f5f6500,0x5d,0x400,0x7f7f1144,0x10)
> 3058 myapp STRU struct sockaddr { AF_INET, xxx.xxx.xxx.xxx: }
>
Why have you chosen to hide information that may be useful in debugging
your problem?
"Hi, I'm asking for help but I have to hide addresses because...this
application is insecure if anyone else has its IP+port? Because I've never
heard of shodan and don't believe that people are constantly scanning the
Internet? And while I don't know why it's failing I'm 1000% sure that
there's no information to be gained from seeing the IP, so if it later
turns out my understanding of 'broadcast address' is incorrect, the time
I've wasted for myself and others will be...a total loss?"
3058 myapp RET sendto -1 errno 13 Permission denied
> 3058 myapp CALL close(5)
> 3058 myapp RET close 0
>
The dump file is like 600MB. I can provide more trace log if it is
> necessary for locating the root cause.
>
Use the scientific method:
* make a testable hypothesis
* devise a test for that
* perform the test
* determine whether the hypothesis has been ruled out or confirmed
So, since the manpage mentions blocking pf, I suggest the hypothesis "it
returns EACCES because pf is blocking your packets". I can think of
several ways to test that; what testing have you performed to confirm or
rule out that possibility? "doas pfctl -d; run test; doas pfctl -e"?
Alternatively: what's different about *that* call? Does every sento() call
on that socket fail? What is special about that socket? If other sendto()
calls succeed, what is different about that call? Earlier setsockopt()
calls?
You say "I can confirm the packet was not sent to a broadcast address":
*how* have you confirmed that your understanding of 'broadcast address'
matches the kernel's understanding? It ain't just 255.255.255.255
Philip Guenther
>
>
> Siegfried
> siegfried.le...@gmail.com
>
>
>
>
> > On Jun 15, 2021, at 8:50 PM, Theo de Raadt wrote:
> >
> > use ktrace
> >
> > Siegfried Levin wrote:
> >
> >> Hi,
> >>
> >> I have a application run by a normal user communicating with the server
> with UDP. It crashes very occasionally, like once per week, due to EACCES
> when sending a UDP packet. According to the manpage (
> https://man.openbsd.org/OpenBSD-6.9/sendmsg.2#EACCES), the reason might
> be either being blocked by PF or sending to a broadcast address. I can
> confirm the packet was not sent to a broadcast address. However, I cannot
> figure out what rule could block the connection occasionally either. The
> application can be brought back online without changing any configuration.
> Does anyone know what might fix this? I can also rewrite the code to make
> it ignore the error and keep trying but that might not be a proper
> solution. Running it as root might not be a good idea, too.
> >>
> >> It happens since OpenBSD 6.8. Now I’m running it on 6.9. The
> application is written in Rust.
> >>
> >> Siegfried
> >> siegfried.le...@gmail.com
> >>
> >>
> >>
> >>
>
>
Re: 6.9 regression: opensmtpd complains "smtp cert-check result=\"no certificate presented\""
On 6/21/21 5:42 PM, naib+li...@xn--bimann-cta.de wrote: You wrote: since the upgrade to 6.9 at the weekend opensmtpd complains smtp cert-check result="no certificate presented" for incoming EMails. Again, this is just a notification from the server, that no client certificates were sent in case of client tls authentication. Wouldn't you agree that this message is misleading? The current message doesn't tell whose certificate is missing. Instead, I would suggest to write something like peer did not authenticate via client certificate into the log file. This has nothing to do with your second issue: Diagnostic-Code: X-Postfix; TLS is required, but was not offered by host mail.example.de I'd say that you can safely ignore the previous message. Instead, I'd suggest trying to debug OpenSMTPD with -dT all (or -dT transfer) and look at the output. If there is something wrong with your certs or config, it'll be shown there. OK, I will check. Thanx very much for your help Regards Harri
