Date: Sat, 30 Jan 2021 17:43:35 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 253096] TCP MD5 regression on STABLE/13 Message-ID: <bug-253096-7501-cQfKd9Zfk3@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-253096-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-253096-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253096 --- Comment #1 from Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> --- It looks to be more quirky than it looked at a glance. In this setup igb(4) lagg(4), vlan(4) and if_bridge(4) are involved. Since the machine was upgraded from the recent 12.2-STABLE and I still have old BE, I rebooted to check if 12.2-STABLE was affected. The machine is not running Bird in production, I test here peering setups only occasionally and haven't done so since a long while. So after booting into 12.2-STABLE it came out that MD5 signed session cannot be established either. The interface used for peering is a vlan(4) created on top of lagg(4) which is aggregating two igb(4)s, moreover, this if_lagg(4) was a member of a bridge(4). To simplify it a bit in the first step I destroyed the bridge, reloaded ipsec rules and everything went back to normal - MD5 signed BGP session was established (12.2-STABLE). The diagnose is not so obvious, since the same steps taken under 13.0-STABLE (removing lagg from the bridge and destroying brdige) don't change anything (still MD5 signatures of segments originating from this host are invalid). I will test it in simplified scenario later, where neither lagg(4) nor vlan(4) be involved and I suspect TCP MD5 to work fine in such a setup. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253096-7501-cQfKd9Zfk3>