Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > introduced with commit 47a6959fa331fe892a4fc3b48ca08e92045c6bda > > (5.13-rc1). Before that point, it seems CONFIG_COMPAT was the relevant > > flag. > > Sorry, I got confused by this recent commit, it's indeed CONFIG_COMPAT > the right toggle in old kernels. > > > The checks on CONFIG_COMPAT were already introduced with commit > > 81e675c227ec60a0bdcbb547dc530ebee23ff931 in 2.6.34.x. > > > > I have seen this problem on Linux 4.1 and 4.9, on an Aarch64 CPU with > > 64-bit kernel and userspace compiled as 32-bit ARM. In both kernels, > > CONFIG_COMPAT was set. > > Hm, then ebtables compat is buggy. It was only ever tested with i686 binary on amd64 arch. Thomas, does unmodified 32bit iptables work on those arch/kernel combinations? > > So I am a bit surprised that I bump into this issue after upgrading > > ebtables from 2.0.10-4 to 2.0.11 where the padding was removed. > > According to your mail and the commits mentioned, it is supposed to > > work without ebtables making specific provisions for the 32/64 bit > > type difference. ebtables-userspace compat fixups predate the ebtables kernel side support, it was autoenabled on sparc64 in the old makefile: ifeq ($(shell uname -m),sparc64) CFLAGS+=-DEBT_MIN_ALIGN=8 -DKERNEL_64_USERSPACE_32 endif I don't even know if the ebtables compat support is compiled in on non-amd64.
