Re: How does bsd.upgrade work?
On Thu, Oct 21, 2021 at 03:46:20PM +0200, Janne Johansson wrote: https://marc.info/?l=openbsd-tech&m=138829898720574&w=2 and https://marc.info/?l=openbsd-tech&m=139013674405106&w=2 might help. Thanks. This is the critical section: https://github.com/openbsd/src/blob/9c70cf5498e471044289f4c9857b84b309c5964e/sys/dev/rnd.c#L44-L45 So if the volume with the bootloader on it is not booted, the RNG is intialised with a less-random value (in particular if a hardware RNG is not present). On Linux it's possible to check for an Intel hardware RNG[1] by looking for `rdrand` in /proc/cpuinfo[2]. *BSD seems to split this across `sysctl hw`, dmesg, and `dmidecode` [3]. Does this sound right -- will OpenBSD use the `rdrand` instruction if present, early in the boot process? [1] https://stackoverflow.com/questions/26771329/is-there-any-legitimate-use-for-intels-rdrand [2] https://0f5f.blogs.minster.io/2015/10/leveraging-intel-ivy-bridges-hardware-rng/ [3] https://stackoverflow.com/questions/4083848/what-is-the-equivalent-of-proc-cpuinfo-on-freebsd-v8-1
Re: How does bsd.upgrade work?
If you don't use all the interlocked openbsd pieces together, and replace some of them with your own, then you take on responsibility for the problems we didn't need to solve because they don't exist in our complete solution. I think that is pretty simple. I hope you understand. As such, I have no comments on the rest of your questions, because in our complete model, those questions don't matter. I'm not kidding. tetrahe...@danwin1210.me wrote: > On Thu, Oct 21, 2021 at 03:46:20PM +0200, Janne Johansson wrote: > >https://marc.info/?l=openbsd-tech&m=138829898720574&w=2 > >and > >https://marc.info/?l=openbsd-tech&m=139013674405106&w=2 > >might help. > > Thanks. This is the critical section: > https://github.com/openbsd/src/blob/9c70cf5498e471044289f4c9857b84b309c5964e/sys/dev/rnd.c#L44-L45 > > So if the volume with the bootloader on it is not booted, the RNG is > intialised with a less-random value (in particular if a hardware RNG is > not present). > > On Linux it's possible to check for an Intel hardware RNG[1] by looking > for `rdrand` in /proc/cpuinfo[2]. *BSD seems to split this across > `sysctl hw`, dmesg, and `dmidecode` [3]. > > Does this sound right -- will OpenBSD use the `rdrand` instruction if > present, early in the boot process? > > [1] > https://stackoverflow.com/questions/26771329/is-there-any-legitimate-use-for-intels-rdrand > > [2] > https://0f5f.blogs.minster.io/2015/10/leveraging-intel-ivy-bridges-hardware-rng/ > > [3] > https://stackoverflow.com/questions/4083848/what-is-the-equivalent-of-proc-cpuinfo-on-freebsd-v8-1 >
Re: USB athn0 issue in AP mode (AR9280+AR7010) no DHCP leases to modern portable devices
Hi Stefan, Just to check the issue is present, I've done live debug of pf rules to confirm that DHCP traffic not blocked. It seems something wrong in obtaining IPv4 addresses from dhcpd. And problem lies outside pf I suppose. Martin ‐‐‐ Original Message ‐‐‐ On Saturday, October 23, 2021 8:55 AM, Stefan Sperling wrote: > On Fri, Oct 22, 2021 at 06:53:17PM +, Martin wrote: > > > Hi there! > > I have an issue with athn USB stick with modern wifi devices like Android > > phones etc. > > I've set up athn0 as previous athn miniPCI-e cards (/etc/hostname.athn0, > > /etc/dhcpd.conf, /etc/pf.conf). No IP address given by OpenBSD7.0amd64 > > host's DHCP for certain device once client has been connected to AP based > > on athn USB stick. > > Tested only with portable devices, not PCs currently. > > Looking forward to resolve this! > > Martin > > No idea, sorry.
Re: Sony UWA-BR100 patch to recognize AR9280+AR7010 Atheros based USB card
Patch has been updated to use correct files and tested on a live system. Please
add it to tree.
Thanks.
--- if_athn_usb.c.orig Thu Apr 15 21:25:44 2021
+++ if_athn_usb.c Thu Oct 21 18:58:08 2021
@@ -91,6 +91,8 @@
ATHN_USB_FLAG_AR7010 },
{{ USB_VENDOR_PANASONIC, USB_PRODUCT_PANASONIC_N5HBZ055 },
ATHN_USB_FLAG_AR7010 },
+ {{ USB_VENDOR_MELCO, USB_PRODUCT_MELCO_UWABR100 },
+ ATHN_USB_FLAG_AR7010 },
{{ USB_VENDOR_VIA, USB_PRODUCT_VIA_AR9271 }}
};
#define athn_usb_lookup(v, p) \
--- usbdevs.origWed Sep 1 01:55:56 2021
+++ usbdevs Sun Oct 24 17:03:13 2021
@@ -3079,6 +3079,7 @@
product MELCO WLIUCGNHP0x0158 WLI-UC-GNHP
product MELCO WLIUCGN 0x015d WLI-UC-GN
product MELCO WLIUCG301N 0x016f WLI-UC-G301N
+product MELCO UWABR100 0x017f SONY UWA-BR100
product MELCO WLIUCGNM 0x01a2 WLI-UC-GNM
product MELCO WLIUCGNM20x01ee WLI-UC-GNM2
‐‐‐ Original Message ‐‐‐
On Saturday, October 23, 2021 8:55 AM, Stefan Sperling wrote:
> On Fri, Oct 22, 2021 at 07:02:20PM +, Martin wrote:
>
> > Hi Stefan,
> > Dev. patches to implement into source tree to recognize automatically Sony
> > UWA-BR100 devices based on AR9280+AR7010.
>
> This patch is changing the wrong files.
> It should change the files 'usbdevs' and if_athn_usb.c only.
>
> usbdevs.h is a generated file, it should not be patched.
> It can be re-generated by running 'make' in the sys/dev/usb directory.
>
> > --- if_athn_usb.c.orig Tue Jun 8 15:29:31 2021
> > +++ if_athn_usb.c Tue Jun 8 15:34:11 2021
> > @@ -91,6 +91,8 @@
> > ATHN_USB_FLAG_AR7010 },
> > {{ USB_VENDOR_PANASONIC, USB_PRODUCT_PANASONIC_N5HBZ055 },
> > ATHN_USB_FLAG_AR7010 },
> >
> > - {{ USB_VENDOR_MELCO, USB_PRODUCT_MELCO_UWABR100 },
> > - ATHN_USB_FLAG_AR7010 },
> > {{ USB_VENDOR_VIA, USB_PRODUCT_VIA_AR9271 }}
> > };
> > #define athn_usb_lookup(v, p) \
> > --- usbdevs.h.orig Tue Jun 1 09:40:48 2021
> > +++ usbdevs.h Tue Jun 8 15:30:51 2021
> > @@ -3077,6 +3077,7 @@
> > #define USB_PRODUCT_MELCO_WLIUCGNHP 0x0158 /* WLI-UC-GNHP /
> > #define USB_PRODUCT_MELCO_WLIUCGN 0x015d / WLI-UC-GN /
> > #define USB_PRODUCT_MELCO_WLIUCG301N 0x016f / WLI-UC-G301N /
> > +#define USB_PRODUCT_MELCO_UWABR100 0x017f / SONY UWA-BR100 /
> > #define USB_PRODUCT_MELCO_WLIUCGNM 0x01a2 / WLI-UC-GNM /
> > #define USB_PRODUCT_MELCO_WLIUCGNM2 0x01ee / WLI-UC-GNM2 */Thanks for
> > your attention.
> > Martin
> >
