[patch] dhcpleased(8): No new lease when trunk(4) failover
Hi tech@
I've setup my machine to use trunk(4) with re(4) and iwm(4) as failover,
to make life easier when switching between wired and wireless
networking. The wired network at home is on a different subnet from
the wireless network, so when I unplug the cable, a DHCP request is
required to get my connection to work again. Before, dhcpleased(8),
dhclient(8) handled this as expected.
I skimmed through the code to try to understand how dhclient(8) handles
this, but I'm not sure I fully understand this. My first take was to
change the rtfilter, as I noticed dhclient(8) was listening for way more
things. But after some testing I learned that RTM_IFINFO was enough,
even if trunk(4) remains "active" and UP when the cable is unplugged.
This solution might not be optimal, as I've basically just removed some
of the checks in engine_update_iface() that return early if nothing has
changed on the interface. At least it solves my issue with trunk(4) and
so far I haven't managed to spawn any dragons from this. Though, this
might cause engine_update_iface() to fully more often?
Thoughts?
Index: engine.c
===
RCS file: /cvs/src/sbin/dhcpleased/engine.c,v
retrieving revision 1.22
diff -u -p -r1.22 engine.c
--- engine.c26 Jul 2021 09:26:36 - 1.22
+++ engine.c28 Jul 2021 20:39:45 -
@@ -586,7 +586,6 @@ void
engine_update_iface(struct imsg_ifinfo *imsg_ifinfo)
{
struct dhcpleased_iface *iface;
- int need_refresh = 0;
iface = get_dhcpleased_iface_by_id(imsg_ifinfo->if_index);
@@ -604,32 +603,14 @@ engine_update_iface(struct imsg_ifinfo *
memcpy(&iface->hw_address, &imsg_ifinfo->hw_address,
sizeof(struct ether_addr));
LIST_INSERT_HEAD(&dhcpleased_interfaces, iface, entries);
- need_refresh = 1;
} else {
- if (memcmp(&iface->hw_address, &imsg_ifinfo->hw_address,
- sizeof(struct ether_addr)) != 0) {
- memcpy(&iface->hw_address, &imsg_ifinfo->hw_address,
- sizeof(struct ether_addr));
- need_refresh = 1;
- }
- if (imsg_ifinfo->rdomain != iface->rdomain) {
- iface->rdomain = imsg_ifinfo->rdomain;
- need_refresh = 1;
- }
- if (imsg_ifinfo->running != iface->running) {
- iface->running = imsg_ifinfo->running;
- need_refresh = 1;
- }
-
- if (imsg_ifinfo->link_state != iface->link_state) {
- iface->link_state = imsg_ifinfo->link_state;
- need_refresh = 1;
- }
+ memcpy(&iface->hw_address, &imsg_ifinfo->hw_address,
+ sizeof(struct ether_addr));
+ iface->rdomain = imsg_ifinfo->rdomain;
+ iface->running = imsg_ifinfo->running;
+ iface->link_state = imsg_ifinfo->link_state;
}
- if (!need_refresh)
- return;
-
if (iface->running && LINK_STATE_IS_UP(iface->link_state)) {
if (iface->requested_ip.s_addr == INADDR_ANY)
parse_lease(iface, imsg_ifinfo);
@@ -641,6 +622,7 @@ engine_update_iface(struct imsg_ifinfo *
} else
state_transition(iface, IF_DOWN);
}
+
struct dhcpleased_iface*
get_dhcpleased_iface_by_id(uint32_t if_index)
{
Index: frontend.c
===
RCS file: /cvs/src/sbin/dhcpleased/frontend.c,v
retrieving revision 1.15
diff -u -p -r1.15 frontend.c
--- frontend.c 27 Jul 2021 18:17:37 - 1.15
+++ frontend.c 28 Jul 2021 20:39:45 -
@@ -605,11 +605,9 @@ update_iface(struct if_msghdr *ifm, stru
}
}
- if (memcmp(&iface->ifinfo, &ifinfo, sizeof(iface->ifinfo)) != 0) {
- memcpy(&iface->ifinfo, &ifinfo, sizeof(iface->ifinfo));
- frontend_imsg_compose_main(IMSG_UPDATE_IF, 0, &iface->ifinfo,
- sizeof(iface->ifinfo));
- }
+ memcpy(&iface->ifinfo, &ifinfo, sizeof(iface->ifinfo));
+ frontend_imsg_compose_main(IMSG_UPDATE_IF, 0, &iface->ifinfo,
+ sizeof(iface->ifinfo));
}
void
rc: Broken autoconf default route sleeping
Revision 1.552 of etc/rc broke the pause for autoconf interfaces that
use "rdomain" or "metric" by matching only for "mtu" after the flags.
An interface may look like this:
lo1: flags=8008 rdomain 1 metric 1 mtu 32768
Source: sbin/ifconfig/ifconfig.c:status():
printf("%s: ", ifname);
printb("flags", flags | (xflags << 16), IFFBITS);
#ifndef SMALL
if (rdomainid)
printf(" rdomain %d", rdomainid);
#endif
if (metric)
printf(" metric %lu", metric);
if (mtu)
printf(" mtu %lu", mtu);
putchar('\n');
Index: etc/rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.552
diff -u -p -r1.552 rc
--- etc/rc 22 Jul 2021 18:29:47 - 1.552
+++ etc/rc 28 Jul 2021 20:09:26 -
@@ -461,7 +461,7 @@ random_seed
reorder_libs
# If interface autoconf exists, pause a little for at least one default route
-if ifconfig | grep -q ': flags=.*<.*AUTOCONF.*> mtu'; then
+if ifconfig | grep -q ': flags=.*<.*AUTOCONF.*>'; then
count=0
while ((count++ < 20)); do
route -n show | grep -q ^default && break
rpki-client 7.2 released
rpki-client 7.2 has just been released and will be available in the rpki-client directory of any OpenBSD mirror soon. rpki-client is a FREE, easy-to-use implementation of the Resource Public Key Infrastructure (RPKI) for Relying Parties (RP) to facilitate validation of the Route Origin of a BGP announcement. The program queries the RPKI repository system and outputs Validated ROA Payloads in the configuration format of OpenBGPD, BIRD, and also as CSV or JSON objects for consumption by other routing stacks. See RFC 6811 for a description of how BGP Prefix Origin Validation secures the Internet's global routing system. rpki-client was primarily developed by Kristaps Dzonsons, Claudio Jeker, Job Snijders, Theo Buehler, Theo de Raadt and Sebastian Benoit as part of the OpenBSD Project. This release includes the following changes to the previous release: * Use RRDP as default protocol for syncronizing the RPKI repository data, with rsync used as secondary. * At startup, warn if the filesystem containing the cache directory is probably too small. 500 MB is the suggested minimum size. * Handle running out of disk space more gracefully, including cleanup of temporary and old files before exiting. * Improve the HTTP/1.1 request headers being sent. * Improved validation checks for ROA and MFT objects. rpki-client is known to compile and run on at least the following operating systems: Alpine 3.12, CentOS/RHEL/Rocky 7, 8, Debian 9 and 10, Fedora 32, 33 and 34, Ubuntu 20.04 LTS, FreeBSD 12 and 13, macOS, and of course OpenBSD. It is our hope that packagers take interest and help adapt rpki-client-portable to more distributions. The mirrors where rpki-client can be found are on https://www.rpki-client.org/portable.html Reporting Bugs: === General bugs may be reported to tech@openbsd.org Portable bugs may be filed at https://github.com/rpki-client/rpki-client-portable We welcome feedback and improvements from the broader community. Thanks to all of the contributors who helped make this release possible.
systat(1) iostat cumulative mode scaling issue
Hi,
While running systat(1)'s iostat view in cumulative mode (activated by pressing
'b') I noticed that it divides the results by the refresh interval. This is
because the cumulative mode is implemented by setting last = 0, and then it does
(current - last) / etime, thereby giving wrong cumulative results. This can be
verified by comparing with `iostat -dI`. The attached diff fixes this.
ok?
Index: usr.bin/systat/iostat.c
===
RCS file: /cvs/src/usr.bin/systat/iostat.c,v
retrieving revision 1.49
diff -u -p -r1.49 iostat.c
--- usr.bin/systat/iostat.c 28 Jun 2019 13:35:04 - 1.49
+++ usr.bin/systat/iostat.c 28 Jul 2021 19:04:41 -
@@ -167,9 +167,12 @@ void
print_io(void)
{
int n, count = 0;
-
int curr;
- etime = naptime;
+
+ if (state == BOOT)
+ etime = 1.0;
+ else
+ etime = naptime;
/* XXX engine internals: save and restore curr_line for bcache */
curr = curr_line;
Re: ftp.1: -o and multiple files
On Wed, Jul 28, 2021 at 10:33:05AM -0600, Theo de Raadt wrote:
> Klemens Nanni wrote:
>
> > With the current wording, I'd either expect usage error when passing
> > `-o output' or more wording explaining the behaviour when fetching
> > multiple files.
> >
> > Usage error seems wrong since our synopsis explicitly allows it, but
> > writing the contents behind multiple URLs into the same file, while
> > truncating the file for each URL does not make much sense, either.
> >
> >
> > I came across this as I wanted to fetch multiple URLs at once without
> > scripting, looked at ftp(1) and didn't found anything to do that.
> > Tried `-o' with multiple URLs to see how it behaves as that case isn't
> > documented.
> >
> > So should we at least go with this correction?
> >
> > Index: ftp.1
> > ===
> > RCS file: /cvs/src/usr.bin/ftp/ftp.1,v
> > retrieving revision 1.122
> > diff -u -p -r1.122 ftp.1
> > --- ftp.1 2 Feb 2021 12:58:42 - 1.122
> > +++ ftp.1 28 Jul 2021 15:46:19 -
> > @@ -212,7 +212,7 @@ will prompt for the remote machine login
> > identity on the local machine) and, if necessary, prompt for a password
> > and an account with which to log in.
> > .It Fl o Ar output
> > -When fetching a single file or URL, save the contents in
> > +When fetching files or URLs, save the contents in
> > .Ar output .
> > To make the contents go to stdout,
> > use
> >
>
> So it concatenates the output to the one file? Fine. But we should
> also block users from more than one -o option.
Why? ftp(1) does not say multiple `-o's are allowed and nothing would
imply that, either.
I'd let later options overwrite earlier ones as is common.
Specificically, ftp's other options behave the same way:
$ ftp -N foo -o /no-write-perm /nope http://localhost/
Trying ::1...
Requesting http://localhost/
foo: Can't open /no-write-perm: Permission denied
$ ftp -N foo -N bar -o /no-write-perm /nope http://localhost/
Trying ::1...
Requesting http://localhost/
bar: Can't open /no-write-perm: Permission denied
>
> Index: main.c
> ===
> RCS file: /cvs/src/usr.bin/ftp/main.c,v
> retrieving revision 1.138
> diff -u -p -u -r1.138 main.c
> --- main.c14 Jul 2021 13:33:57 - 1.138
> +++ main.c28 Jul 2021 16:31:31 -
> @@ -501,6 +501,8 @@ main(volatile int argc, char *argv[])
> break;
>
> case 'o':
> + if (outfile)
> + usage();
> outfile = optarg;
> if (*outfile == '\0') {
> pipeout = 0;
>
Re: ftp.1: -o and multiple files
Klemens Nanni wrote:
> With the current wording, I'd either expect usage error when passing
> `-o output' or more wording explaining the behaviour when fetching
> multiple files.
>
> Usage error seems wrong since our synopsis explicitly allows it, but
> writing the contents behind multiple URLs into the same file, while
> truncating the file for each URL does not make much sense, either.
>
>
> I came across this as I wanted to fetch multiple URLs at once without
> scripting, looked at ftp(1) and didn't found anything to do that.
> Tried `-o' with multiple URLs to see how it behaves as that case isn't
> documented.
>
> So should we at least go with this correction?
>
> Index: ftp.1
> ===
> RCS file: /cvs/src/usr.bin/ftp/ftp.1,v
> retrieving revision 1.122
> diff -u -p -r1.122 ftp.1
> --- ftp.1 2 Feb 2021 12:58:42 - 1.122
> +++ ftp.1 28 Jul 2021 15:46:19 -
> @@ -212,7 +212,7 @@ will prompt for the remote machine login
> identity on the local machine) and, if necessary, prompt for a password
> and an account with which to log in.
> .It Fl o Ar output
> -When fetching a single file or URL, save the contents in
> +When fetching files or URLs, save the contents in
> .Ar output .
> To make the contents go to stdout,
> use
>
So it concatenates the output to the one file? Fine. But we should
also block users from more than one -o option.
Index: main.c
===
RCS file: /cvs/src/usr.bin/ftp/main.c,v
retrieving revision 1.138
diff -u -p -u -r1.138 main.c
--- main.c 14 Jul 2021 13:33:57 - 1.138
+++ main.c 28 Jul 2021 16:31:31 -
@@ -501,6 +501,8 @@ main(volatile int argc, char *argv[])
break;
case 'o':
+ if (outfile)
+ usage();
outfile = optarg;
if (*outfile == '\0') {
pipeout = 0;
ftp.1: -o and multiple files
With the current wording, I'd either expect usage error when passing `-o output' or more wording explaining the behaviour when fetching multiple files. Usage error seems wrong since our synopsis explicitly allows it, but writing the contents behind multiple URLs into the same file, while truncating the file for each URL does not make much sense, either. I came across this as I wanted to fetch multiple URLs at once without scripting, looked at ftp(1) and didn't found anything to do that. Tried `-o' with multiple URLs to see how it behaves as that case isn't documented. So should we at least go with this correction? Index: ftp.1 === RCS file: /cvs/src/usr.bin/ftp/ftp.1,v retrieving revision 1.122 diff -u -p -r1.122 ftp.1 --- ftp.1 2 Feb 2021 12:58:42 - 1.122 +++ ftp.1 28 Jul 2021 15:46:19 - @@ -212,7 +212,7 @@ will prompt for the remote machine login identity on the local machine) and, if necessary, prompt for a password and an account with which to log in. .It Fl o Ar output -When fetching a single file or URL, save the contents in +When fetching files or URLs, save the contents in .Ar output . To make the contents go to stdout, use
Re: iwx(4) firmware update to -63
On Mon, Jul 26, 2021 at 06:21:46PM +0200, Stefan Sperling wrote:
> This patch implements support for new iwx(4) -63 firmware images
> available in the iwx-firmware-20210512 package (via fw_update).
>
> Please test this patch and report back. If testing works out well
> then I will commit these changes to CVS incrementally. Thanks!
>
> For those testing my iwx Tx agg patch: Please remove that patch first.
> Tx agg will come back later. Getting new firmware images to work is more
> important right now because these images contain fixes for fragattacks.
Several people have reported messages such as:
iwx0: unhandled firmware response 0xc2/0xc rx ring 63[255]
The 0xc2 response is a new notification from firmware (BAR_FRAME_RELEASE).
This updated version of the patch adds support for this feature.
diff 54a415eecf0903b6663209706a0fc6e2e9d40044 refs/heads/iwxfw
blob - 48bf14d7a8a421c6f1bf2b4bfc6c1792396b5400
blob + 0b97503422759e3898791e31ff096d6ce9cb
--- sys/dev/pci/if_iwx.c
+++ sys/dev/pci/if_iwx.c
@@ -232,6 +232,7 @@ const int iwx_mcs2ridx[] = {
};
uint8_tiwx_lookup_cmd_ver(struct iwx_softc *, uint8_t, uint8_t);
+uint8_tiwx_lookup_notif_ver(struct iwx_softc *, uint8_t, uint8_t);
intiwx_is_mimo_ht_plcp(uint8_t);
intiwx_is_mimo_mcs(int);
intiwx_store_cscheme(struct iwx_softc *, uint8_t *, size_t);
@@ -297,6 +298,8 @@ int iwx_nic_rx_init(struct iwx_softc *);
intiwx_nic_init(struct iwx_softc *);
intiwx_enable_txq(struct iwx_softc *, int, int, int, int);
void iwx_post_alive(struct iwx_softc *);
+intiwx_schedule_session_protection(struct iwx_softc *, struct iwx_node *,
+ uint32_t);
void iwx_protect_session(struct iwx_softc *, struct iwx_node *, uint32_t,
uint32_t);
void iwx_unprotect_session(struct iwx_softc *, struct iwx_node *);
@@ -315,6 +318,8 @@ int iwx_ampdu_rx_start(struct ieee80211com *, struct i
void iwx_ampdu_rx_stop(struct ieee80211com *, struct ieee80211_node *,
uint8_t);
void iwx_rx_ba_session_expired(void *);
+void iwx_rx_bar_frame_release(struct iwx_softc *, struct iwx_rx_packet *,
+ struct iwx_rx_data *, struct mbuf_list *);
void iwx_reorder_timer_expired(void *);
void iwx_sta_rx_agg(struct iwx_softc *, struct ieee80211_node *, uint8_t,
uint16_t, uint16_t, int, int);
@@ -356,6 +361,10 @@ void iwx_rx_tx_cmd(struct iwx_softc *, struct
iwx_rx_p
void iwx_rx_bmiss(struct iwx_softc *, struct iwx_rx_packet *,
struct iwx_rx_data *);
intiwx_binding_cmd(struct iwx_softc *, struct iwx_node *, uint32_t);
+intiwx_phy_ctxt_cmd_uhb_v3(struct iwx_softc *, struct iwx_phy_ctxt *,
uint8_t,
+ uint8_t, uint32_t);
+intiwx_phy_ctxt_cmd_v3(struct iwx_softc *, struct iwx_phy_ctxt *, uint8_t,
+ uint8_t, uint32_t);
intiwx_phy_ctxt_cmd_uhb(struct iwx_softc *, struct iwx_phy_ctxt *, uint8_t,
uint8_t, uint32_t, uint32_t);
intiwx_phy_ctxt_cmd(struct iwx_softc *, struct iwx_phy_ctxt *, uint8_t,
@@ -387,7 +396,16 @@ intiwx_add_sta_cmd(struct iwx_softc *, struct
iwx_nod
intiwx_add_aux_sta(struct iwx_softc *);
intiwx_rm_sta_cmd(struct iwx_softc *, struct iwx_node *);
intiwx_fill_probe_req(struct iwx_softc *, struct iwx_scan_probe_req *);
+intiwx_config_umac_scan_reduced(struct iwx_softc *);
intiwx_config_umac_scan(struct iwx_softc *);
+uint16_t iwx_scan_umac_flags_v2(struct iwx_softc *, int);
+void iwx_scan_umac_dwell_v10(struct iwx_softc *,
+ struct iwx_scan_general_params_v10 *, int);
+void iwx_scan_umac_fill_general_p_v10(struct iwx_softc *,
+ struct iwx_scan_general_params_v10 *, uint16_t, int);
+void iwx_scan_umac_fill_ch_p_v6(struct iwx_softc *,
+ struct iwx_scan_channel_params_v6 *, uint32_t, int, int);
+intiwx_umac_scan_v14(struct iwx_softc *, int);
intiwx_umac_scan(struct iwx_softc *, int);
void iwx_mcc_update(struct iwx_softc *, struct iwx_mcc_chub_notif *);
uint8_tiwx_ridx2rate(struct ieee80211_rateset *, int);
@@ -490,6 +508,21 @@ iwx_lookup_cmd_ver(struct iwx_softc *sc, uint8_t grp,
return IWX_FW_CMD_VER_UNKNOWN;
}
+uint8_t
+iwx_lookup_notif_ver(struct iwx_softc *sc, uint8_t grp, uint8_t cmd)
+{
+ const struct iwx_fw_cmd_version *entry;
+ int i;
+
+ for (i = 0; i < sc->n_cmd_versions; i++) {
+ entry = &sc->cmd_versions[i];
+ if (entry->group == grp && entry->cmd == cmd)
+ return entry->notif_ver;
+ }
+
+ return IWX_FW_CMD_VER_UNKNOWN;
+}
+
int
iwx_is_mimo_ht_plcp(uint8_t ht_plcp)
{
@@ -924,7 +957,7 @@ iwx_firmware_store_section(struct iwx_softc *sc, enum
#define IWX_DEFAULT_SCAN_CHANNELS 40
/* Newer firmware might support more channels. Raise this value if needed. */
-#define IWX_MAX_SCAN_CHANNELS 52 /* as of 8265-34 firmware image */
+#define IWX_MAX_SCAN_CHANNELS 67 /* as of iwx-cc-a0-62 firmware */
