Willing to test any driver for AX210
Is anyone working on the driver for the AX210 Wi-Fi chip from intel? I am ready to test anything for that chip. Have to get rid of the wire for openbsd to become my main os)) Have a T14s gen 2 intel... dmesg (running the snapshot): *** OpenBSD 6.9-current (GENERIC.MP) #139: Wed Jul 21 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16873091072 (16091MB) avail mem = 16345780224 (15588MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x910b1000 (63 entries) bios0: vendor LENOVO version "(1.07 )" date 02/22/2021 bios0: LENOVO 20WM0052US acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT TPM2 SSDT ECDT HPET APIC MCFG SSDT SSDT SSDT NHLT SSDT SSDT SSDT LPIT WSMT SSDT DBGP DBG2 MSDM SSDT BATB SSDT BGRT PTDT UEFI FPDT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) GLAN(S4) XHCI(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 27448.30 MHz, 06-8c-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 256KB 64b/line disabled L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 38MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 2294.72 MHz, 06-8c-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 256KB 64b/line disabled L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 2294.71 MHz, 06-8c-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 256KB 64b/line disabled L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 2294.71 MHz, 06-8c-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 256KB 64b/line disabled L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 2294.71 MHz, 06-8c-01 cpu4:
Re: rpki-client support more http status codes
On 2021/08/04 19:58, Sebastian Benoit wrote: > just as i had looked them up :P My usual quick http status code reference doesn't even have 103 (and the graphical representation of https://http.cat/308 is a bit confusing :)
Re: Add versioned lib to system perl's @INC for non-packaged modules
On 2021/08/04 19:45, Ingo Schwarze wrote:
> Hi Andrew,
>
> Andrew Fresh wrote on Fri, Jul 30, 2021 at 05:34:40PM -0700:
> > On Sun, May 16, 2021 at 03:30:39PM -0700, Andrew Hewus Fresh wrote:
>
> >> There do appear to be some annoyances with still shared directories for
> >> man pages, in that if you install a CPAN module and then attempt to
> >> pkg_add it, it complains because "files already exist" in the man
> >> directory. We could separate the cpan man pages, or I think un-setting
> >> the site_lib man*dir will mean cpan won't instal them. I haven't yet
> >> tested that, but I'm not sure what would be best there.
>
> If i understand correctly, this is all about making installation of
> un-ported Perl modules work better and reducing clashes between doing
> that on the one hand and between package installation with pkg_add(1)
> on the other hand.
Correct. The specific problem that prompted this was people who had
installed something locally outside of ports - I think it was an updated
version of a core perl module - and made worse by pkg_add at the time
searching /usr/local/libdata/perl5/site_perl for modules and refusing
to run until the locally built module was removed.
pkg_add now uses "no lib ('/usr/local/libdata/perl5/site_perl')" so
it won't run into the same problem any longer, but most other perl
software is likely to still have the problem.
> Who will profit most from that? I guess very experienced Perl users
> and porters who play around a lot with many different Perl modules
> and with very large Perl programs, in particular when evaluating
> whether those large programs are worth porting. Not having manual
> pages installed for dependencies while trying to get a complicated
> program to work and while trying to understand it seems like a
> disservice to me. So "un-setting the site_lib man*dir" doesn't
> strike me as particularly convincing on first sight.
>
> I guess ordinary users are less likely to use this route, they are more
> likely to just use pkg_add(1). But if they do, for whatever reason,
> not getting manual pages is not good for them, either.
I think it's likely to be the other way round, at least people with more
experience of OpenBSD are more likely to start by making a port, partly
because they realise that installing modules from CPAN can cause
problems, partly to make it easier to clean up if needed.
I think ordinary users who need something that isn't ported are probably
more likely to pick it up from CPAN instead. (then, if they're more
experienced with Perl, they'll realise the cause of the "key mismatch"
error quickly and know what to do with it).
> So i think in the long term, installing those manual pages into their
> own manpath outside /ust/local/man/ would seem desirable to me.
> I'm not saying it needs to be done in the same commit; sorting that
> out can certainly be a later step.
I agree with all this.
> You suggest to make the sitelib directory versioned. Consequently,
> i guess that you want the following process to work:
>
> 1. install base and arbitrary numbers of packages
> 2. install lots of modules and programs from CPAN for evaluation
> 3. install the next Perl version outside base to figure out what
> needs to be done to ultimately move base to it
> 4. install various modules for the new Perl from step 3
> for testing purposes
>
> If i got that right, then the new man directory needs to be versioned
> just like the new sitelib directory, or the manual pages from steps 2
> and 4 will clash just like the libraries from steps 2 and 4 would.
> The price to pay, of course, is that you need to edit man.conf(5)
> for each new Perl you install. And not just you, the base system
> Perl maintainer, but all users installing stuff from CPAN.
I think perldoc would pick them up anyway - if so, users still have
an easy way to read the docs without editing man.conf.
> On the other hand, if working with two different Perl versions in
> parallel is not a requirement (for example because people do testing
> like in steps 3 and 4 on separate machines?), then i don't see why
> either the sitelib or the new man dir needs to be versioned at all,
> making everything simpler.
I think it's mostly to mitigate some user problems (at least, make it so
they are more obvious and less likely to need somebody more experienced
to point out what the problem is). On the one hand, that is already
reduced by the pkg_add change. But on the other, if it's simple enough
to reduce problems further then, as long as it doesn't get in the
way too much, why not..
OpenBSD Errata: August 4, 2021 (kernel, sparc64)
An errata patch for the kernel on the sparc64 architecture has been released for OpenBSD 6.8 and OpenBSD 6.9. On sparc64, a missaligned address could trigger a kernel assert and panic the kernel. Source code patches can be found on the respective errata pages: https://www.openbsd.org/errata68.html https://www.openbsd.org/errata69.html
Re: Willing to test any driver for AX210
The iwlwifi driver has this commit for adding the "device family AX210" https://patchwork.kernel.org/project/linux-wireless/patch/20190207223622.9642-14-l...@coelho.fi/ There are other commits too. It requires driver adaptation, firmware, the iwx driver will have to be extended.
Re: rpki-client support more http status codes
Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.08.04 17:45:14 +0200:
> On Wed, Aug 04, 2021 at 10:53:39AM +0200, Claudio Jeker wrote:
> > This adds a few more HTTP Status codes to the mix of the accepted ones.
> > Mainly 100, 103 and 203 are now also accepted. All other codes in the 1xx
> > and 2xx are still considered an error since they are not expected from the
> > GET request made by the http client. This is a minimal HTTP client and it
> > should remain minimal. If a server is sending back something unexpected
> > just fail and fall back to rsync.
>
>
> Update with additional comments for the various status codes.
just as i had looked them up :P
ok benno@
> --
> :wq Claudio
>
> Index: http.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/http.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 http.c
> --- http.c23 Jul 2021 16:03:47 - 1.34
> +++ http.c4 Aug 2021 15:22:22 -
> @@ -865,7 +865,9 @@ http_request(struct http_connection *con
>
> /*
> * Parse the HTTP status line.
> - * Return 0 for status codes 200, 301-304, 307-308.
> + * Return 0 for status codes 100, 103, 200, 203, 301-304, 307-308.
> + * The other 1xx and 2xx status codes are explicitly not handled and are
> + * considered an error.
> * Failure codes and other errors return -1.
> * The redirect loop limit is enforced here.
> */
> @@ -885,7 +887,7 @@ http_parse_status(struct http_connection
> cp++;
>
> strlcpy(ststr, cp, sizeof(ststr));
> - status = strtonum(ststr, 200, 599, );
> + status = strtonum(ststr, 100, 599, );
> if (errstr != NULL) {
> strnvis(gerror, cp, sizeof gerror, VIS_SAFE);
> warnx("Error retrieving %s: %s", http_info(conn->host),
> @@ -894,19 +896,23 @@ http_parse_status(struct http_connection
> }
>
> switch (status) {
> - case 301:
> - case 302:
> - case 303:
> - case 307:
> - case 308:
> + case 301: /* Redirect: moved permanently */
> + case 302: /* Redirect: found / moved temporarily */
> + case 303: /* Redirect: see other */
> + case 307: /* Redirect: temporary redirect */
> + case 308: /* Redirect: permanent redirect */
> if (conn->req->redirect_loop++ > 10) {
> warnx("%s: Too many redirections requested",
> http_info(conn->host));
> return -1;
> }
> /* FALLTHROUGH */
> - case 200:
> - case 304:
> + case 100: /* Informational: continue (ignored) */
> + case 103: /* Informational: early hints (ignored) */
> + /* FALLTHROUGH */
> + case 200: /* Success: OK */
> + case 203: /* Success: non-authoritative information (proxy) */
> + case 304: /* Redirect: not modified */
> conn->status = status;
> break;
> default:
> @@ -931,6 +937,14 @@ http_isredirect(struct http_connection *
> return 0;
> }
>
> +static inline int
> +http_isok(struct http_connection *conn)
> +{
> + if (conn->status >= 200 && conn->status < 300)
> + return 1;
> + return 0;
> +}
> +
> static void
> http_redirect(struct http_connection *conn)
> {
> @@ -1165,7 +1179,7 @@ again:
> }
>
> /* Check status header and decide what to do next */
> - if (conn->status == 200 || http_isredirect(conn)) {
> + if (http_isok(conn) || http_isredirect(conn)) {
> if (http_isredirect(conn))
> http_redirect(conn);
>
> @@ -1174,6 +1188,8 @@ again:
> else
> conn->state = STATE_RESPONSE_DATA;
> goto again;
> + } else if (conn->status == 100 || conn->status == 103) {
> + conn->state = STATE_RESPONSE_STATUS;
> } else if (conn->status == 304) {
> return http_done(conn, HTTP_NOT_MOD);
> }
>
Re: Add versioned lib to system perl's @INC for non-packaged modules
Hi Andrew, Andrew Fresh wrote on Fri, Jul 30, 2021 at 05:34:40PM -0700: > On Sun, May 16, 2021 at 03:30:39PM -0700, Andrew Hewus Fresh wrote: >> There do appear to be some annoyances with still shared directories for >> man pages, in that if you install a CPAN module and then attempt to >> pkg_add it, it complains because "files already exist" in the man >> directory. We could separate the cpan man pages, or I think un-setting >> the site_lib man*dir will mean cpan won't instal them. I haven't yet >> tested that, but I'm not sure what would be best there. If i understand correctly, this is all about making installation of un-ported Perl modules work better and reducing clashes between doing that on the one hand and between package installation with pkg_add(1) on the other hand. Who will profit most from that? I guess very experienced Perl users and porters who play around a lot with many different Perl modules and with very large Perl programs, in particular when evaluating whether those large programs are worth porting. Not having manual pages installed for dependencies while trying to get a complicated program to work and while trying to understand it seems like a disservice to me. So "un-setting the site_lib man*dir" doesn't strike me as particularly convincing on first sight. I guess ordinary users are less likely to use this route, they are more likely to just use pkg_add(1). But if they do, for whatever reason, not getting manual pages is not good for them, either. So i think in the long term, installing those manual pages into their own manpath outside /ust/local/man/ would seem desirable to me. I'm not saying it needs to be done in the same commit; sorting that out can certainly be a later step. You suggest to make the sitelib directory versioned. Consequently, i guess that you want the following process to work: 1. install base and arbitrary numbers of packages 2. install lots of modules and programs from CPAN for evaluation 3. install the next Perl version outside base to figure out what needs to be done to ultimately move base to it 4. install various modules for the new Perl from step 3 for testing purposes If i got that right, then the new man directory needs to be versioned just like the new sitelib directory, or the manual pages from steps 2 and 4 will clash just like the libraries from steps 2 and 4 would. The price to pay, of course, is that you need to edit man.conf(5) for each new Perl you install. And not just you, the base system Perl maintainer, but all users installing stuff from CPAN. On the other hand, if working with two different Perl versions in parallel is not a requirement (for example because people do testing like in steps 3 and 4 on separate machines?), then i don't see why either the sitelib or the new man dir needs to be versioned at all, making everything simpler. Yours, Ingo
Re: bgpd add add-path receive support
On Fri, Jul 30, 2021 at 12:02:12PM +0200, Claudio Jeker wrote:
> This diff implements the bit to support the receive side of
> RFC7911 - Advertisement of Multiple Paths in BGP.
>
> I did some basic tests and it works for me. People running route
> collectors should give this a try. The interaction of Add-Path and bgpctl
> probably needs some work. Also the MRT dumper needs to be updated to
> support RFC8050. I have a partial diff for that ready as well.
>
> Sending out multiple paths will follow in a later step since that is a
> bit more complex. I still need to decide how stable I want to make the
> assigned path_ids for the multiple paths and then changes to the decision
> process and adjrib-out are required to allow multipe paths there.
Updated diff that includes some minimal support for bgpctl.
This add 'bgpctl show rib nei foo path-id 42' as a way to limit which
paths to show. Now the RFC itself is very flexible in how path-ids are
assigned (it is possible that different prefixes have different path-ids)
but the assumtion is that most systems assign path-id in a stable way and
so it makes sense to allow to filter on path-id.
Apart from that not much changed.
--
:wq Claudio
Index: bgpctl/bgpctl.8
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.8,v
retrieving revision 1.99
diff -u -p -r1.99 bgpctl.8
--- bgpctl/bgpctl.8 16 Jun 2021 16:24:12 - 1.99
+++ bgpctl/bgpctl.8 4 Aug 2021 13:15:53 -
@@ -348,6 +348,13 @@ Show RIB memory statistics.
Show only entries from the specified peer.
.It Cm neighbor group Ar description
Show only entries from the specified peer group.
+.It Cm path-id Ar pathid
+Show only entries which match the specified
+.Ar pathid .
+Must be used together with either
+.Cm neighbor
+or
+.Cm out .
.It Cm peer-as Ar as
Show all entries with
.Ar as
Index: bgpctl/bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.272
diff -u -p -r1.272 bgpctl.c
--- bgpctl/bgpctl.c 2 Aug 2021 16:51:39 - 1.272
+++ bgpctl/bgpctl.c 4 Aug 2021 15:54:25 -
@@ -249,6 +249,7 @@ main(int argc, char *argv[])
ribreq.neighbor = neighbor;
strlcpy(ribreq.rib, res->rib, sizeof(ribreq.rib));
ribreq.aid = res->aid;
+ ribreq.path_id = res->pathid;
ribreq.flags = res->flags;
imsg_compose(ibuf, type, 0, 0, -1, , sizeof(ribreq));
break;
Index: bgpctl/parser.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/parser.c,v
retrieving revision 1.106
diff -u -p -r1.106 parser.c
--- bgpctl/parser.c 16 Feb 2021 08:30:21 - 1.106
+++ bgpctl/parser.c 4 Aug 2021 13:08:31 -
@@ -61,7 +61,8 @@ enum token_type {
RD,
FAMILY,
RTABLE,
- FILENAME
+ FILENAME,
+ PATHID,
};
struct token {
@@ -114,6 +115,7 @@ static const struct token t_log[];
static const struct token t_fib_table[];
static const struct token t_show_fib_table[];
static const struct token t_communication[];
+static const struct token t_show_rib_path[];
static const struct token t_main[] = {
{ KEYWORD, "reload", RELOAD, t_communication},
@@ -178,10 +180,11 @@ static const struct token t_show_rib[] =
{ FLAG, "in", F_CTL_ADJ_IN, t_show_rib},
{ FLAG, "out", F_CTL_ADJ_OUT, t_show_rib},
{ KEYWORD, "neighbor", NONE, t_show_rib_neigh},
+ { KEYWORD, "ovs", NONE, t_show_ovs},
+ { KEYWORD, "path-id", NONE, t_show_rib_path},
{ KEYWORD, "table",NONE, t_show_rib_rib},
{ KEYWORD, "summary", SHOW_SUMMARY, t_show_summary},
{ KEYWORD, "memory", SHOW_RIB_MEM, NULL},
- { KEYWORD, "ovs", NONE, t_show_ovs},
{ FAMILY, "", NONE, t_show_rib},
{ PREFIX, "", NONE, t_show_prefix},
{ ENDTOKEN, "", NONE, NULL}
@@ -479,6 +482,11 @@ static const struct token t_show_fib_tab
{ ENDTOKEN, "", NONE, NULL}
};
+static const struct token t_show_rib_path[] = {
+ { PATHID, "", NONE, t_show_rib},
+ { ENDTOKEN, "", NONE, NULL}
+};
+
static struct parse_result res;
const struct token *match_token(int *argc, char **argv[],
@@ -748,6 +756,7 @@ match_token(int *argc, char **argv[], co
case PREPSELF:
case WEIGHT:
case RTABLE:
+ case PATHID:
if (word != NULL && wordlen > 0 &&
parse_number(word, , table[i].type)) {
Re: rpki-client support more http status codes
On Wed, Aug 04, 2021 at 10:53:39AM +0200, Claudio Jeker wrote:
> This adds a few more HTTP Status codes to the mix of the accepted ones.
> Mainly 100, 103 and 203 are now also accepted. All other codes in the 1xx
> and 2xx are still considered an error since they are not expected from the
> GET request made by the http client. This is a minimal HTTP client and it
> should remain minimal. If a server is sending back something unexpected
> just fail and fall back to rsync.
Update with additional comments for the various status codes.
--
:wq Claudio
Index: http.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/http.c,v
retrieving revision 1.34
diff -u -p -r1.34 http.c
--- http.c 23 Jul 2021 16:03:47 - 1.34
+++ http.c 4 Aug 2021 15:22:22 -
@@ -865,7 +865,9 @@ http_request(struct http_connection *con
/*
* Parse the HTTP status line.
- * Return 0 for status codes 200, 301-304, 307-308.
+ * Return 0 for status codes 100, 103, 200, 203, 301-304, 307-308.
+ * The other 1xx and 2xx status codes are explicitly not handled and are
+ * considered an error.
* Failure codes and other errors return -1.
* The redirect loop limit is enforced here.
*/
@@ -885,7 +887,7 @@ http_parse_status(struct http_connection
cp++;
strlcpy(ststr, cp, sizeof(ststr));
- status = strtonum(ststr, 200, 599, );
+ status = strtonum(ststr, 100, 599, );
if (errstr != NULL) {
strnvis(gerror, cp, sizeof gerror, VIS_SAFE);
warnx("Error retrieving %s: %s", http_info(conn->host),
@@ -894,19 +896,23 @@ http_parse_status(struct http_connection
}
switch (status) {
- case 301:
- case 302:
- case 303:
- case 307:
- case 308:
+ case 301: /* Redirect: moved permanently */
+ case 302: /* Redirect: found / moved temporarily */
+ case 303: /* Redirect: see other */
+ case 307: /* Redirect: temporary redirect */
+ case 308: /* Redirect: permanent redirect */
if (conn->req->redirect_loop++ > 10) {
warnx("%s: Too many redirections requested",
http_info(conn->host));
return -1;
}
/* FALLTHROUGH */
- case 200:
- case 304:
+ case 100: /* Informational: continue (ignored) */
+ case 103: /* Informational: early hints (ignored) */
+ /* FALLTHROUGH */
+ case 200: /* Success: OK */
+ case 203: /* Success: non-authoritative information (proxy) */
+ case 304: /* Redirect: not modified */
conn->status = status;
break;
default:
@@ -931,6 +937,14 @@ http_isredirect(struct http_connection *
return 0;
}
+static inline int
+http_isok(struct http_connection *conn)
+{
+ if (conn->status >= 200 && conn->status < 300)
+ return 1;
+ return 0;
+}
+
static void
http_redirect(struct http_connection *conn)
{
@@ -1165,7 +1179,7 @@ again:
}
/* Check status header and decide what to do next */
- if (conn->status == 200 || http_isredirect(conn)) {
+ if (http_isok(conn) || http_isredirect(conn)) {
if (http_isredirect(conn))
http_redirect(conn);
@@ -1174,6 +1188,8 @@ again:
else
conn->state = STATE_RESPONSE_DATA;
goto again;
+ } else if (conn->status == 100 || conn->status == 103) {
+ conn->state = STATE_RESPONSE_STATUS;
} else if (conn->status == 304) {
return http_done(conn, HTTP_NOT_MOD);
}
rpki-client support more http status codes
This adds a few more HTTP Status codes to the mix of the accepted ones.
Mainly 100, 103 and 203 are now also accepted. All other codes in the 1xx
and 2xx are still considered an error since they are not expected from the
GET request made by the http client. This is a minimal HTTP client and it
should remain minimal. If a server is sending back something unexpected
just fail and fall back to rsync.
OK?
--
:wq Claudio
Index: http.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/http.c,v
retrieving revision 1.34
diff -u -p -r1.34 http.c
--- http.c 23 Jul 2021 16:03:47 - 1.34
+++ http.c 4 Aug 2021 08:48:01 -
@@ -865,7 +865,9 @@ http_request(struct http_connection *con
/*
* Parse the HTTP status line.
- * Return 0 for status codes 200, 301-304, 307-308.
+ * Return 0 for status codes 100, 103, 200, 203, 301-304, 307-308.
+ * The other 1xx and 2xx status codes are explicitly not handled and are
+ * considered an error.
* Failure codes and other errors return -1.
* The redirect loop limit is enforced here.
*/
@@ -885,7 +887,7 @@ http_parse_status(struct http_connection
cp++;
strlcpy(ststr, cp, sizeof(ststr));
- status = strtonum(ststr, 200, 599, );
+ status = strtonum(ststr, 100, 599, );
if (errstr != NULL) {
strnvis(gerror, cp, sizeof gerror, VIS_SAFE);
warnx("Error retrieving %s: %s", http_info(conn->host),
@@ -905,7 +907,11 @@ http_parse_status(struct http_connection
return -1;
}
/* FALLTHROUGH */
+ case 100:
+ case 103:
+ /* FALLTHROUGH */
case 200:
+ case 203:
case 304:
conn->status = status;
break;
@@ -931,6 +937,14 @@ http_isredirect(struct http_connection *
return 0;
}
+static inline int
+http_isok(struct http_connection *conn)
+{
+ if (conn->status >= 200 && conn->status < 300)
+ return 1;
+ return 0;
+}
+
static void
http_redirect(struct http_connection *conn)
{
@@ -1165,7 +1179,7 @@ again:
}
/* Check status header and decide what to do next */
- if (conn->status == 200 || http_isredirect(conn)) {
+ if (http_isok(conn) || http_isredirect(conn)) {
if (http_isredirect(conn))
http_redirect(conn);
@@ -1174,6 +1188,8 @@ again:
else
conn->state = STATE_RESPONSE_DATA;
goto again;
+ } else if (conn->status == 100 || conn->status == 103) {
+ conn->state = STATE_RESPONSE_STATUS;
} else if (conn->status == 304) {
return http_done(conn, HTTP_NOT_MOD);
}
