On Mon, Jun 21, 2021 at 9:07 PM Siegfried Levin <siegfried.le...@gmail.com>
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<MSG_NOSIGNAL>,0x7f7fffff1144,0x10)
> 3058 myapp STRU struct sockaddr { AF_INET, xxx.xxx.xxx.xxx:yyyy }
>
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 <dera...@openbsd.org> wrote:
> >
> > use ktrace
> >
> > Siegfried Levin <siegfried.le...@gmail.com> 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
> >>
> >>
> >>
> >>
>
>
