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(, 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=1.72=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
