Discussion:
[Bug 233341] 12.0-RC1 i386 vnet does not behave like the amd64 vnet version.
(too old to reply)
b***@freebsd.org
2018-11-28 05:17:11 UTC
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233341

Mark Linimon <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Assignee|***@FreeBSD.org |***@FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freebsd.org
2018-12-01 13:22:09 UTC
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233341

--- Comment #10 from Kristof Provost <***@freebsd.org> ---
A simple kldload pflog / kldunload pflog is sufficient to provoke this on i386,
but not on amd64.

The panic happens trying to access V_pflogifs in pflog_clone_destroy():
#15 0x224022c0 in pflog_clone_destroy (ifp=0x22fc7800) at
/usr/src/sys/netpfil/pf/if_pflog.c:149
149 if (V_pflogifs[i] == ifp)

(kgdb) info registers
eax 0xffffffc0 -64
ecx 0x7597b08 123304712
edx 0x2 2
ebx 0x9aa7680 162166400
esp 0x0 0x0
ebp 0x1db26acc 0x1db26acc
esi 0x22fc7800 586971136
edi 0x22fc7800 586971136
eip 0x224022c0 0x224022c0
eflags 0x210246 2163270
cs 0x20 32
ss 0x0 0
ds 0x28 40
es 0x28 40
fs 0x8 8
gs 0x0 0
(kgdb) disassemble
Dump of assembler code for function pflog_clone_destroy:
0x224022a0 <pflog_clone_destroy+0>: push %ebp
0x224022a1 <pflog_clone_destroy+1>: mov %esp,%ebp
0x224022a3 <pflog_clone_destroy+3>: push %esi
0x224022a4 <pflog_clone_destroy+4>: push %eax
0x224022a5 <pflog_clone_destroy+5>: mov $0xffffffc0,%eax
0x224022aa <pflog_clone_destroy+10>: mov 0x8(%ebp),%esi
0x224022ad <pflog_clone_destroy+13>: nop
0x224022ae <pflog_clone_destroy+14>: nop
0x224022af <pflog_clone_destroy+15>: nop
0x224022b0 <pflog_clone_destroy+16>: mov %fs:0x0,%ecx
0x224022b7 <pflog_clone_destroy+23>: mov 0x31c(%ecx),%ecx
0x224022bd <pflog_clone_destroy+29>: mov 0x1c(%ecx),%ecx
0x224022c0 <pflog_clone_destroy+32>: cmp %esi,0x22403140(%ecx,%eax,1)
<-------------
0x224022c7 <pflog_clone_destroy+39>: je 0x224022d0
<pflog_clone_destroy+48>
0x224022c9 <pflog_clone_destroy+41>: add $0x4,%eax

Strangely, adding a printf("KP: %d\n", i); just before that prevents it from
panicking. With that printf() the module unloads just fine. Disassembling that
version shows:

for (i = 0; i < PFLOGIFS_MAX; i++) {
printf("KP %d\n", i);
12b0: 89 7c 24 04 mov %edi,0x4(%esp)
12b4: c7 04 24 71 01 00 00 movl $0x171,(%esp)
12bb: e8 fc ff ff ff call 12bc <pflog_clone_destroy+0x1c>
12c0: 64 a1 00 00 00 00 mov %fs:0x0,%eax
if (V_pflogifs[i] == ifp)
12c6: 8b 80 1c 03 00 00 mov 0x31c(%eax),%eax
12cc: 8b 40 1c mov 0x1c(%eax),%eax
12cf: 39 b4 b8 00 21 00 00 cmp %esi,0x2100(%eax,%edi,4)
12d6: 75 0b jne 12e3 <pflog_clone_destroy+0x43>
V_pflogifs[i] = NULL;
12d8: c7 84 b8 00 21 00 00 movl $0x0,0x2100(%eax,%edi,4)
<-------------------
12df: 00 00 00 00
static void
pflog_clone_destroy(struct ifnet *ifp)
{
int i;

for (i = 0; i < PFLOGIFS_MAX; i++) {
12e3: 47 inc %edi
12e4: 83 ff 10 cmp $0x10,%edi
12e7: 75 c7 jne 12b0 <pflog_clone_destroy+0x10>
printf("KP %d\n", i);
if (V_pflogifs[i] == ifp)
V_pflogifs[i] = NULL;

As opposed to the panicking version:
for (i = 0; i < PFLOGIFS_MAX; i++)
if (V_pflogifs[i] == ifp)
12b7: 8b 89 1c 03 00 00 mov 0x31c(%ecx),%ecx
12bd: 8b 49 1c mov 0x1c(%ecx),%ecx
12c0: 39 b4 01 40 21 00 00 cmp %esi,0x2140(%ecx,%eax,1)
<--------------
12c7: 74 07 je 12d0 <pflog_clone_destroy+0x30>

It's almost as if there's a compiler issue here. My x86 asm foo is a bit too
weak to work out what's supposed to be happening here, and what might be wrong.
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freebsd.org
2018-12-02 15:23:14 UTC
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233341

--- Comment #11 from Kristof Provost <***@freebsd.org> ---
Building with gcc doesn't seem to make the problem go away. It seems unlikely
that this is really a compiler issue then, but right now I have no idea.
--
You are receiving this mail because:
You are the assignee for the bug.
b***@freebsd.org
2018-12-02 20:55:43 UTC
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233341

--- Comment #12 from Joe Barbish <***@a1poweruser.com> ---
On the subject of the flooding packets. After many different tcpdumps and
device re-cabling have figured out where these packets are coming from. They
are originating from android phones and tablets. Unable to determine if this
action is normal by design or if those devices have been infected by malware.
Those android devices connect by WiFi router that had been bridged to a switch
that also has the LAN cable on it. At the switch the unwanted WiFi traffic
short cuts to the LAN cable never showing up on the gateway host.

Changed the WiFi router cabling layout and enabled the routers firewall adding
rules to drop the unwanted traffic so it doesn't exit the WiFi router any more.

What a learning experience!
--
You are receiving this mail because:
You are the assignee for the bug.
Loading...