sysupgrade(8) and FAQ 4 - File Sets
Hi all! First, I'd like to say to say thank you to the developers for sysupgrade(8). As a hobbyist with limited time and energy, anything that reduces the pain of keeping software up-to-date is always going to be a boon for security (in the sense that I'm more likely to find the time to do an upgrade that is relatively quick and straightforward). Between syspatch and sysupgrade, running OpenBSD has gotten a lot easier over the last few years, and I really appreciate it! I have a suggestion, though: for the sake of us dabblers (who do read the FAQs and the manual, but aren't necessarily mailing list subscribers), I'd like to propose the following update to FAQ 4, under the heading "File Sets". Instead of: New users are recommended to install all of them. I propose the following: Installing all file sets is standard practice, even on headless systems. Only skip a file set if you have a very good reason to do so. This will bring the FAQ more in-line with the tone of what I've been reading on the mailing lists recently, and makes the target audience clearer (I've been using OpenBSD on and off for nearly fifteen years, so my status as a "new" user is somewhat ambiguous, at least in my own head). It will also help to clarify sysupdate's behaviour (which otherwise can come as a surprise during an operation when all surprises in particular are unwelcome). Thanks! Sincerely, Russell Ault
Re: sysupgrade failure due to boot.conf
Theo wrote: > Interesting. Wonder how common this is. It could possibly come back in some future bios update bug/change as well but very very rarely I would expect. This problem showed up for me in a different way as well; My clock would always drift and ntpd would report that it was always trying to adjust the clock but would never get closer to the target time. Now I can explain why since my bios clock was stuck. > Should our code eventually advance if it has done millions of inspection loops? I saw code in there in /usr/src/sys/stand/boot/cmd.c that counted 1000 before calling getsecs() so I would weary about adding more counts: /* check for timeout expiration less often (for some very constrained archs) */ while (!cnischar()) if (!(i++ % 1000) && (getsecs() >= tt)) break; I don't know the amd64 architecture too well but I would think there would be a more reliable timer that can be used instead of the system clock. Only relative time is needed for the timeout to operate correctly. Or possibly use some known tick. http://books.gigatux.nl/mirror/kerneldevelopment/0672327201/ch10lev1sec2.html > If you can re-create the condition, can you propose a diff which does that? I would if I can get someone to point me to a good timer or tick to use. -alfred On Wed, Jul 15, 2020 at 9:43 PM Theo de Raadt wrote: > Alfred Morgan wrote: > > > Theo wrote: > > > Figure out how to build and install. It is not hard to test. > > > > Thank you, I did as you suggested and I was able to narrow down the issue > > to this line of code in /usr/src/sys/arch/amd64/stand/efiboot/efiboot.c: > > > > EFI_CALL(ST->RuntimeServices->GetTime, , NULL); > > > > > > The GetTime call would always return the same time. It turned out that my > > BIOS clock was frozen and was not ticking so the boot prompt was waiting > > for a time that never arrived. > > > > I learned a lot about OpenBSD efiboot and a good BIOS lesson. Always use > > the clear CMOS hardware jumper after a BIOS update. I have been using the > > "Load defaults" in the BIOS after a BIOS update but that is not good > enough. > > > > Thanks again Theo for your direction and encouragement. > > Interesting. Wonder how common this is. > > Should our code eventually advance if it has done millions of inspection > loops? If you can re-create the condition, can you propose a diff which > does that? >
Re: sysupgrade failure due to boot.conf
> On Jul 13, 2020, at 6:58 AM, Alfred Morgan wrote: > > > Brian wrote: > > (echo boot /bsd.upgrade; echo boot) > /etc/boot.conf > > Brian, that doesn't work. I tried that already before. It seems to stop at > the error not finding bsd.upgrade and won't continue. > > -alfred Thanks for checking this, it was untested advice. I’m glad it didn’t work, your follow-up emails regarding the root cause were enlightening for me.
Re: Shell account service providers
ibs...@ripsbusker.no.eu.org writes: > Aaron Mason writes: > > What are you looking for in such a service? > > Minimally, SSH login, 100GB disk space, and build tools arpnetworks.com
Re: iXorg / xenodm logs fill with errors: "_XSERVTransSocketUNIXAccept: accept() failed"
On Sat, Jul 11, 2020 at 07:38:58PM +0200, Caspar Schutijser wrote: > > > [501037.408] _XSERVTransSocketUNIXAccept: accept() failed > > > ... > > This message may be of interest: > https://marc.info/?l=openbsd-misc=155787066627780=2 Hi, I must have missed that message - thanks for pointing it out! I've made the changes for daemon in login.conf and restarted. Time will tell ... Thanks again! Cheers, Robb.
Re: HD OpenBSD Artwork
that's aweseome! Thanks! On 16.07.20 15:43, Ben Jahmine wrote: >> Is there somewhere to get higher resolution OpenBSD artwork? >> >> I see the stuff on the website, and it's great, but on my 8k screen it's >> kind of like a postage stamp in the middle. >> >> Do higher Res copies exist somewhere? Can they be made available? > Scale to your needs. > > Cheers > > Ben
Re: fw_update issue with colon in URL
‐‐‐ Original Message ‐‐‐ On Wednesday, July 15, 2020 12:49 PM, Theo Buehler wrote: > One server had an incorrect config. This should be fixed now. Thanks for your notification, so I didn't go mad ;) I can confirm, it works like a charm. Thanks again for fixing!
Re: HD OpenBSD Artwork
> Is there somewhere to get higher resolution OpenBSD artwork? > > I see the stuff on the website, and it's great, but on my 8k screen it's > kind of like a postage stamp in the middle. > > Do higher Res copies exist somewhere? Can they be made available? Scale to your needs. Cheers Ben
Re: Shell account service providers
On Thu, 16 Jul 2020 at 02:56, Wesley wrote: > > > > Ibsen S Ripsbusker wrote: > > Are there services that sell managed OpenBSD shell accounts? > > I mean a service similar to sdf.org. > > Try google with keywords "online unix terminal for shell scripting", you > will find a lot results. I struggle to see how this is relevant to the OP's question. -- Ottavio Caruso
Re: Shell account service providers
If you connect to IRC on irc.ircnow.org and join #ircnow, we offer free openbsd shell accounts. Our web page is at https://ircnow.org. jrmu IRCNow On Thu, Jul 16, 2020 at 01:51:44AM +, Ibsen S Ripsbusker wrote: > Are there services that sell managed OpenBSD shell accounts? > I mean a service similar to sdf.org. >
Re: Installation in a Xen guest (pvgrub)
Am 10.07.2020 23:30, schrieb Demi M. Obenour: [...] For me, OpenBSD boots fine in HVM mode (with an I/O emulator). I have not tried PVH mode and would not expect it to work. PV mode definitely won’t work, and should be avoided anyway for both security and performance reasons. Is HVM mode okay, or do you need PVH? I'd like to install and boot it in a remote service provider environment. There I have only Linux systems available to install and a Linux rescue system to switch over. The installation is not the problem. I could also use a disk image. For boot I can only rely on a bunch of provided Linux kernels or the pvgrub stuff to boot from the disks. So the only chance to get it running would be the way with the "Xen-grub" I think, if there is no possibility that Linux has learned to boot (not virtual) BSD ;-) Would there be a chance to hack on the Linux-bootcode to boot the BSD-kernel? Makes it sense to look into how this boot works or doesn't it make sense at all?!
athn(4): hidenwid?
I'm testing an athn(4) wireless adapter (Qualcomm Atheros AR9280) in "Host AP" mode on OpenBSD 6.7 (amd64). While trying the hidenwid flag, I discovered that the ESSID is sent in responses to unspecified probe requests. This can be seen by capturing packets on another machine with wireless adapter in monitor mode. The ifconfig(8) manpage says this: "The ‘hidenwid’ flag will hide the network ID (ESSID) in beacon frames when operating in Host AP mode. It will also prevent responses to probe requests with an unspecified network ID." I can confirm that no ESSID is sent in beacon frames, but the adapter will both respond to probe requests and also add the ESSID to those responses. In athn(4) manpage under "CAVEATS" there is no information about problems with the hidenwid flag. # cat /etc/hostname.athn0 mediaopt hostap mode 11g chan 6 nwid TEST-AP wpakey 123456789 nwflag hidenwid inet 192.168.10.1 255.255.255.0 192.168.10.255 # ifconfig athn0 athn0: flags=8843 mtu 1500 lladdr XX:XX:XX:XX:XX:XX index 4 priority 4 llprio 3 groups: wlan media: IEEE802.11 autoselect mode 11g hostap status: active ieee80211: nwid TEST-AP chan 6 bssid XX:XX:XX:XX:XX:XX -95dBm \ wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp \ hidenwid inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255 Does anyone have an idea what could be the problem? I'm not trying to start a discussion on whether hiding the ESSID is ridiculous or not, I'm just testing different things, so I know which features work and which don't. Regards, Mogens Jensen
Re: athn(4): hidenwid?
On Thu, Jul 16, 2020 at 11:10:58AM +0200, Stefan Sperling wrote:
> Line 1927 of
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net80211/ieee80211_input.c?annotate=1.218
>
> This code runs before a response is generated for a probe request and it
> should ensure that a probe request is only generated if the SSID matches.
>
> The next step would be to find out how this check is being bypassed in
> your case.
Nevermind, I have found the problem.
I moved the HIDENWID flag to a different variable some time ago:
[[[
CVSROOT:/cvs
Module name:src
Changes by: s...@cvs.openbsd.org2019/05/12 12:12:38
Modified files:
sbin/ifconfig : ifconfig.8
sys/dev/ic : if_wi.c
sys/net80211 : ieee80211_input.c ieee80211_ioctl.c
ieee80211_ioctl.h ieee80211_output.c
ieee80211_var.h
Log message:
Fix 'ifconfig nwflags; These flags ended up overlapping with other flags
in ieee80211com's ic_flags because we haven't been paying attention to
them (they're not in the same place in the code and hence easy to miss).
Move them to a dedicated variable to avoid this problem in the future.
Add a new 'stayauth' nwflag which can be set to let net80211 ignore
deauth frames. This can be useful when deauth frames are being
persistently spoofed by an attacker. Idea from beck@
ok beck@ phessler@
]]]
There is some use of the HIDENWID flag which I missed in this conversion.
This patch should fix it.
diff b38ea36846c22ecbc2e7394f8dcf015e2b6a523f /usr/src
blob - 8942bc3b47923fe0d78a4435b181777069b2a119
file + sys/dev/ic/bwfm.c
--- sys/dev/ic/bwfm.c
+++ sys/dev/ic/bwfm.c
@@ -1959,7 +1959,7 @@ bwfm_hostap(struct bwfm_softc *sc)
memset(join.assoc.bssid, 0xff, sizeof(join.assoc.bssid));
bwfm_fwvar_cmd_set_data(sc, BWFM_C_SET_SSID, , sizeof(join));
bwfm_fwvar_var_set_int(sc, "closednet",
- (ic->ic_flags & IEEE80211_F_HIDENWID) != 0);
+ (ic->ic_userflags & IEEE80211_F_HIDENWID) != 0);
}
#endif
blob - 0cea2f80840c2b7bdbbf2dd7de3d83e3beabc7fa
file + sys/dev/ic/rt2560.c
--- sys/dev/ic/rt2560.c
+++ sys/dev/ic/rt2560.c
@@ -1588,7 +1588,7 @@ rt2560_tx_bcn(struct rt2560_softc *sc, struct mbuf *m0
mtod(m0, uint8_t *) +
sizeof (struct ieee80211_frame) +
8 + 2 + 2 +
- ((ic->ic_flags & IEEE80211_F_HIDENWID) ?
+ ((ic->ic_userflags & IEEE80211_F_HIDENWID) ?
1 : 2 + ni->ni_esslen) +
2 + min(ni->ni_rates.rs_nrates, IEEE80211_RATE_SIZE) +
2 + 1 +
blob - 7170cb0085cbb2f47ff2d02d204f5706f4eb22a2
file + sys/dev/ic/rt2661.c
--- sys/dev/ic/rt2661.c
+++ sys/dev/ic/rt2661.c
@@ -2935,7 +2935,7 @@ rt2661_prepare_beacon(struct rt2661_softc *sc)
RT2661_HW_BEACON_BASE0 + 24 +
sizeof (struct ieee80211_frame) +
8 + 2 + 2 +
- ((ic->ic_flags & IEEE80211_F_HIDENWID) ?
+ ((ic->ic_userflags & IEEE80211_F_HIDENWID) ?
1 : 2 + ni->ni_esslen) +
2 + min(ni->ni_rates.rs_nrates, IEEE80211_RATE_SIZE) +
2 + 1 +
blob - 098aa9bce19481ce09676ce3c4fc0040f14c9b93
file + sys/net80211/ieee80211_input.c
--- sys/net80211/ieee80211_input.c
+++ sys/net80211/ieee80211_input.c
@@ -1937,7 +1937,7 @@ ieee80211_recv_probe_req(struct ieee80211com *ic, stru
return;
}
/* refuse wildcard SSID if we're hiding our SSID in beacons */
- if (ssid[1] == 0 && (ic->ic_flags & IEEE80211_F_HIDENWID)) {
+ if (ssid[1] == 0 && (ic->ic_userflags & IEEE80211_F_HIDENWID)) {
DPRINTF(("wildcard SSID rejected"));
ic->ic_stats.is_rx_ssidmismatch++;
return;
HD OpenBSD Artwork
Is there somewhere to get higher resolution OpenBSD artwork? I see the stuff on the website, and it's great, but on my 8k screen it's kind of like a postage stamp in the middle. Do higher Res copies exist somewhere? Can they be made available? Cheers!
Re: athn(4): hidenwid?
On Thu, Jul 16, 2020 at 06:19:40AM +, Mogens Jensen wrote:
> I'm not trying to start a discussion on whether hiding the ESSID is
> ridiculous or not, I'm just testing different things, so I know which
> features work and which don't.
Thanks for digging into this. Since there are no automated tests for
the wifi stack it is difficult to determine whether the code is fully
correct. And regressions do sometimes occur. So getting test reports
such as this is very valuable.
There is this chunk of code which is supposed to catch a wrong SSID and
it does take "hidenwid" mode into account:
/* SSID element is mandatory */
if (ssid == NULL || ssid[1] > IEEE80211_NWID_LEN) {
DPRINTF(("invalid SSID element\n"));
return;
}
/* check that the specified SSID (if not wildcard) matches ours */
if (ssid[1] != 0 && (ssid[1] != ic->ic_bss->ni_esslen ||
memcmp([2], ic->ic_bss->ni_essid, ic->ic_bss->ni_esslen))) {
DPRINTF(("SSID mismatch\n"));
ic->ic_stats.is_rx_ssidmismatch++;
return;
}
/* refuse wildcard SSID if we're hiding our SSID in beacons */
if (ssid[1] == 0 && (ic->ic_flags & IEEE80211_F_HIDENWID)) {
DPRINTF(("wildcard SSID rejected"));
ic->ic_stats.is_rx_ssidmismatch++;
return;
}
Line 1927 of
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net80211/ieee80211_input.c?annotate=1.218
This code runs before a response is generated for a probe request and it
should ensure that a probe request is only generated if the SSID matches.
The next step would be to find out how this check is being bypassed in
your case. Are you really sure that probe responses are sent to the MAC
address of clients which do not already know the correct SSID? The patch
below will make the kernel print the MAC addresses of rejected clients
to 'dmesg':
diff b38ea36846c22ecbc2e7394f8dcf015e2b6a523f /usr/src
blob - 098aa9bce19481ce09676ce3c4fc0040f14c9b93
file + sys/net80211/ieee80211_input.c
--- sys/net80211/ieee80211_input.c
+++ sys/net80211/ieee80211_input.c
@@ -1932,13 +1932,15 @@ ieee80211_recv_probe_req(struct ieee80211com *ic, stru
/* check that the specified SSID (if not wildcard) matches ours */
if (ssid[1] != 0 && (ssid[1] != ic->ic_bss->ni_esslen ||
memcmp([2], ic->ic_bss->ni_essid, ic->ic_bss->ni_esslen))) {
- DPRINTF(("SSID mismatch\n"));
+ printf("SSID mismatch from %s\n",
+ ether_sprintf((u_int8_t *)wh->i_addr2));
ic->ic_stats.is_rx_ssidmismatch++;
return;
}
/* refuse wildcard SSID if we're hiding our SSID in beacons */
if (ssid[1] == 0 && (ic->ic_flags & IEEE80211_F_HIDENWID)) {
- DPRINTF(("wildcard SSID rejected"));
+ printf("wildcard SSID rejected from %s\n",
+ ether_sprintf((u_int8_t *)wh->i_addr2));
ic->ic_stats.is_rx_ssidmismatch++;
return;
}
