[Bug 243096] netgraph ng_nat example causes panic on CURRENT

Sat Jan 4 20:54:50 UTC 2020

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243096

            Bug ID: 243096
           Summary: netgraph ng_nat example causes panic on CURRENT
           Product: Base System
           Version: CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: rob at sarcasticadmin.com

Created attachment 210453
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210453&action=edit
core.txt from panic

Overview:

Im seeing a consistent panic on CURRENT r356261 when following an example taken
from `man ng_nat`:

 The ng_nat node can also be attached directly to the physical interface
 via ng_ether(4) node in the graph.  In the following example, we perform
 masquerading on a Ethernet interface connected to a public network.

           ifconfig igb0 inet x.y.8.35 netmask 0xfffff000
           route add default x.y.0.1
           /usr/sbin/ngctl -f- <<-SEQ
                   mkpeer igb0: nat lower in
                   name igb0:lower igb0_NAT
                   connect igb0: igb0_NAT: upper out
                   msg igb0_NAT: setdlt 1
                   msg igb0_NAT: setaliasaddr x.y.8.35
           SEQ

Im not very familar with netgraph so its been a little difficult for me to
investigate and understand what might be wrong with the above example.
/usr/share/examples/netgraph didnt seem to have a ng_nat example either.
Essentially Im looking to create a NAT with the "wan" side being a physical
interface and the "lan" being a bridge.

Steps to Reproduce:

Im testing on a x230 with em0 instead of igb0 and using DHCP:
$ ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

options=481249b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,NOMAP>
        ether 3c:97:0e:21:cf:52
        inet 192.168.88.85 netmask 0xffffff00 broadcast 192.168.88.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

$ netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.88.1       UGS         em0
127.0.0.1          link#2             UH          lo0
192.168.88.0/24    link#1             U           em0
192.168.88.85      link#1             UHS         lo0

Internet6:
Destination                       Gateway                       Flags     Netif
Expire
::/96                             ::1                           UGRS        lo0
::1                               link#2                        UH          lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
fe80::/10                         ::1                           UGRS        lo0
fe80::%lo0/64                     link#2                        U           lo0
fe80::1%lo0                       link#2                        UHS         lo0
ff02::/16                         ::1                           UGRS        lo0

With the physical interface up the following snippet causes the system to panic
(again borrowed from the ng_nat manpage above):

$ /usr/sbin/ngctl -f- <<-SEQ
        mkpeer em0: nat lower in
        name em0:lower em0_NAT
        connect em0: em0_NAT: upper out
        msg em0_NAT: setdlt 1
        msg em0_NAT: setaliasaddr 192.168.88.85
SEQ

Actual Results:

After a few seconds the system then panics:

Unread portion of the kernel message buffer:
panic: ng_nat: ip_len != m_pkthdr.len
cpuid = 3
time = 1578139602
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe004b4bd690
vpanic() at vpanic+0x17e/frame 0xfffffe004b4bd6f0
panic() at panic+0x43/frame 0xfffffe004b4bd750
ng_nat_rcvdata() at ng_nat_rcvdata+0x3d5/frame 0xfffffe004b4bd7a0
ng_apply_item() at ng_apply_item+0xa3/frame 0xfffffe004b4bd820
ng_snd_item() at ng_snd_item+0x2b0/frame 0xfffffe004b4bd860
ng_ether_input() at ng_ether_input+0x4c/frame 0xfffffe004b4bd890
ether_nh_input() at ether_nh_input+0x24a/frame 0xfffffe004b4bd8f0
netisr_dispatch_src() at netisr_dispatch_src+0xb1/frame 0xfffffe004b4bd970
ether_input() at ether_input+0x9d/frame 0xfffffe004b4bd9d0
iflib_rxeof() at iflib_rxeof+0xbcd/frame 0xfffffe004b4bdae0
_task_fn_rx() at _task_fn_rx+0x7d/frame 0xfffffe004b4bdb20
gtaskqueue_run_locked() at gtaskqueue_run_locked+0x155/frame 0xfffffe004b4bdb80
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xc2/frame
0xfffffe004b4bdbb0
fork_exit() at fork_exit+0x80/frame 0xfffffe004b4bdbf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe004b4bdbf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

See core.txt attached from panic for more info

In my testing it seems to be the last command thats the problematic one: msg
em0_NAT: setaliasaddr 192.168.88.85

Expected Results:

em0_NAT interface to be available

If theres anything else that would be helpful for me to include just let me
know.

System Info:
$ uname -a
FreeBSD test 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r356261: Thu Jan  2 04:59:38
UTC 2020    
root at releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

-- 
You are receiving this mail because:
You are the assignee for the bug.