tcpdump: print some more info about md5 auth in ospf
seeing the key-id in particular helped me debug a problem here. ok? Index: ospf.h === RCS file: /cvs/src/usr.sbin/tcpdump/ospf.h,v retrieving revision 1.10 diff -u -p -r1.10 ospf.h --- ospf.h 4 Aug 2010 16:47:01 - 1.10 +++ ospf.h 10 Apr 2019 22:27:29 - @@ -220,6 +220,13 @@ struct ospfhdr { } ospf_un ; } ; +struct ospf_md5_authdata { + uint16_tauth_md5_offset; + uint8_t auth_keyid; + uint8_t auth_len; + uint32_tauth_seq; +}; + #defineospf_hello ospf_un.un_hello #defineospf_db ospf_un.un_db #defineospf_lsrospf_un.un_lsr Index: print-ospf.c === RCS file: /cvs/src/usr.sbin/tcpdump/print-ospf.c,v retrieving revision 1.20 diff -u -p -r1.20 print-ospf.c --- print-ospf.c16 Nov 2015 00:16:39 - 1.20 +++ print-ospf.c10 Apr 2019 22:27:29 - @@ -32,6 +32,7 @@ #include #include +#include #include "interface.h" #include "addrtoname.h" @@ -554,9 +555,20 @@ ospf_print(const u_char *bp, u_int lengt printf("\""); break; - case OSPF_AUTH_MD5: - printf(" auth MD5"); + case OSPF_AUTH_MD5: { + struct ospf_md5_authdata auth; + memcpy(&auth, op->ospf_authdata, sizeof(auth)); + + printf(" auth MD5 key-id %u", auth.auth_keyid); + if (vflag) + printf(" seq %u", ntohl(auth.auth_seq)); + if (vflag > 1) { + printf(" off %u len %u", + ntohs(auth.auth_md5_offset), + auth.auth_len); + } break; + } default: printf(" ??authtype-%d??", ntohs(op->ospf_authtype));
Re: Unexpected boot(8) behaviour
On Wed, Apr 10, 2019 at 08:12:19PM +0100, Raf Czlonka wrote: > On Mon, Apr 08, 2019 at 02:55:46PM BST, Florian Obser wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: flor...@cvs.openbsd.org 2019/04/08 07:55:46 > > > > Modified files: > > sys/stand/boot : boot.c cmd.c cmd.h > > > > Log message: > > Detect /bsd.upgrade kernel and boot it if present instead of default > > /bsd. To be used for unattended upgrades in the future. > > Idea & OK deraadt > > > > Hi all, > > This breaks the expected boot(8) behaviour, i.e.: > > $ cat /etc/boot.conf > set timeout 1 > boot bsd.up > > bsd.up is *not* being ran at boot. > > It was working fine a couple of days ago. fixed, thanks! > > Regards, > > Raf -- I'm not entirely sure you are real.
Unexpected boot(8) behaviour
On Mon, Apr 08, 2019 at 02:55:46PM BST, Florian Obser wrote: > CVSROOT: /cvs > Module name: src > Changes by: flor...@cvs.openbsd.org 2019/04/08 07:55:46 > > Modified files: > sys/stand/boot : boot.c cmd.c cmd.h > > Log message: > Detect /bsd.upgrade kernel and boot it if present instead of default > /bsd. To be used for unattended upgrades in the future. > Idea & OK deraadt > Hi all, This breaks the expected boot(8) behaviour, i.e.: $ cat /etc/boot.conf set timeout 1 boot bsd.up bsd.up is *not* being ran at boot. It was working fine a couple of days ago. Regards, Raf
relayd(8) websockets proxy broken after adding websockets support
Dear all, After websockets support was added in relayd(8), https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/relayd/relay_http.c.diff?r1=1.71&r2=1.72&f=h the connections to services usging websockets are broken. I checked what caused this breakage, and found that the check for the "Connection" HTTP request header strictly checks for "Upgrade" value (line 402): if (cre->dir == RELAY_DIR_REQUEST) { if (strcasecmp("Connection", key) == 0 && strcasecmp("Upgrade", value) == 0) priv->http_upgrade_req |= HTTP_CONNECTION_UPGRADE; while the browser can also send (and sends) Connection: keep-alive, Upgrade Websockets work fine if I add keep-alive to the list of values, but I'm sure this must be fixed in some other way, --- usr.sbin/relayd/relay_http.c.orig Wed Apr 3 17:41:00 2019 +++ usr.sbin/relayd/relay_http.cWed Apr 3 21:31:37 2019 @@ -400,7 +400,8 @@ if (cre->line != 1) { if (cre->dir == RELAY_DIR_REQUEST) { if (strcasecmp("Connection", key) == 0 && - strcasecmp("Upgrade", value) == 0) + (strcasecmp("Upgrade", value) == 0 || + strcasecmp("keep-alive, Upgrade", value) == 0)) priv->http_upgrade_req |= HTTP_CONNECTION_UPGRADE; if (strcasecmp("Upgrade", key) == 0 && -- With best regards, Pavel Korovin