Mac80211: 802.11s TCP/IP Connectivity on "master" Failing After 2018-09

Ah, OK, saw the name, so now I know the context -- the referenced commit e9d92bf1e1 is a good commit, from my testing! The "puzzling" tarball was committed after that commit as well.

I'll likely open a thread for it and/or query the dev mailing list, but the short of it is that 802.11s TCP/IP transport seems to have been "broken" in master, after commit e9d92bf1e1 was merged, by

commit db90c243a0b9bd72fc691cd09e58a96ac2a452cf
Author: Hauke Mehrtens <redacted>
Date:   Sun Sep 23 18:02:35 2018 +0200

    mac80211: update to version based on 4.19-rc4

confirmation of this through git bisect needed to use the just-prior commits, which were trying to use the the v4.18.5 tarball. Changing the hash allowed confirmation of the "update to version based on 4.19-rc4" commit as the "first bad" commit.

diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index fcb7181655..66401984b8 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -13,7 +13,8 @@ PKG_NAME:=mac80211
 PKG_VERSION:=v4.18.5
 PKG_RELEASE:=1
 PKG_SOURCE_URL:=http://mirror2.openwrt.org/sources
-PKG_HASH:=9c13660e98b9397260266f98c9db76bdad2b48462cb376b5862dfbd18369edf2
+# PKG_HASH:=9c13660e98b9397260266f98c9db76bdad2b48462cb376b5862dfbd18369edf2
+PKG_HASH := a0c272d29b415f34e3f841d8f6ab444ebd3046e49e2717934a7b11b28953ebfe
 
 PKG_SOURCE:=backports-$(PKG_VERSION).tar.xz
 PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/backports-$(PKG_VERSION)

The symptom under examination is that builds off master from early September, 2018, function properly with respect to establishment and use of 802.11s as either connectivity and routing, or as connectivity with batman-adv for routing. Builds off the "update to version based on 4.19-rc4" commit and later establish the 802.11s mesh, but there is no connectivity at the TCP/IP layer with either 802.11s routing, or batman-adv routing. The output of iw dev mesh0 station dump between a "good" and "bad" build doesn't provide any hints, as the mesh itself appears connected in both cases.

	mesh plink:	ESTAB
	mesh local PS mode:	ACTIVE
	mesh peer PS mode:	ACTIVE
	mesh non-peer PS mode:	ACTIVE
	authorized:	yes
	authenticated:	yes
	associated:	yes