Re: Possible off-by-one bug in usr.sbin/rad/engine.c

On 2022-12-31 23:54 +01, Ingo Schwarze wrote: > Hi Alejandro, > > Alejandro Colomar wrote on Sat, Dec 31, 2022 at 05:56:27PM +0100: > >> I've started auditing the OpenBSD source code after the discussion on >> arc4random_uniform(3) and my suggestion of arc4random_range() on the glibc >> mailing

Re: Possible off-by-one bug in usr.sbin/rad/engine.c

Hi Alejandro, Alejandro Colomar wrote on Sat, Dec 31, 2022 at 05:56:27PM +0100: > I've started auditing the OpenBSD source code after the discussion on > arc4random_uniform(3) and my suggestion of arc4random_range() on the glibc > mailing list. > > I found some cases where it seems like

Re: [RFC v1 1/2] Add arc4random_range(min, max)

Hi Alexandro, i fail to see the point. We do not usually add extra functions if the same effect can be be attained with one-liners. There is significant value in keeping the API as small as possible, it makes the API easier to learn and it makes programming mistakes less likely. On top of

Re: Some NFS clients won't mount

I did some tests and I'm now pretty sure the problem revolves around the point naddy made: Kodi and VLC try to mount my NFS share through a non-privileged port. As both Kodi and VLC use the same NFS client library (libnfs), I tried to find out a bit more about how it works. According to its

[RFC v1 2/2] Use arc4random_range() instead of arc4random_uniform() when appropriate

This makes the code much more readable and self-documented. While doing this, I noticed a few bugs, and other cases which may be bugs or not. Switching to this specialized API makes it easier to spot such bugs, but since I'm not familiar with the code, I kept some bugs unfixed. The most obvious

[RFC v1 1/2] Add arc4random_range(min, max)

Signed-off-by: Alejandro Colomar --- Hi, The patch to the manual page is still a draft; I know it has formatting issues; I don't know mdoc(7) enough to write in it. I CCd Ingo so that he may help me improve it. Theo, and any others, please consider the addition of this function, since it

Possible off-by-one bug in usr.sbin/rad/engine.c

Hi Theo and Florian, I've started auditing the OpenBSD source code after the discussion on arc4random_uniform(3) and my suggestion of arc4random_range() on the glibc mailing list. I found some cases where it seems like there's an off-by-one bug, which would be solved by providing

Re: "/bsd: cannot forward" ip6 traffic messages

Hi Gábor, Yes, these are ULA addresses I’ve assigned, each interface has a /64 (fd58:6af3:2ff6:aa::1/64 and fd58:6af3:2ff6:c8::1/64). Those two host addresses, however, have not changed. They are still active as I write this. I believe Apple only assigns temporary addresses for globally

Re: equivalent to linux/serial.h?

On 2022-12-31, cho...@jtan.com wrote: > Justin Muir writes: >> Hello, >> >> Just attempting to compile SDRAngel from source and I'm getting some errors >> in the process. >> >> The latest is: "linux/serial.h" missing. Is there an equivalent I can >> point to on OpenBSD? >> >> I'm also having

Re: "/bsd: cannot forward" ip6 traffic messages

Hi Brian, I am not familiar with Apple devices, but I am familiar with IPv6. The IPv6 addresses in your log file have the fc00::/7 prefix, that is, they are from the RFC4193 "unique local unicast" range: https://datatracker.ietf.org/doc/html/rfc4193#section-3.1 The L bit is 1, the next

Re: equivalent to linux/serial.h?

Justin Muir writes: > Hello, > > Just attempting to compile SDRAngel from source and I'm getting some errors > in the process. > > The latest is: "linux/serial.h" missing. Is there an equivalent I can > point to on OpenBSD? > > I'm also having difficulties with the dab-cmdline library. The