From owner-freebsd-net@FreeBSD.ORG Tue Jul 15 18:21:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B787BB for ; Tue, 15 Jul 2014 18:21:26 +0000 (UTC) Received: from forward-corp1f.mail.yandex.net (forward-corp1f.mail.yandex.net [IPv6:2a02:6b8:0:801::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C387E24AE for ; Tue, 15 Jul 2014 18:21:25 +0000 (UTC) Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1f.mail.yandex.net (Yandex) with ESMTP id 7E6E22420068; Tue, 15 Jul 2014 22:21:13 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id 434812C0A54; Tue, 15 Jul 2014 22:21:13 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:401:222:4dff:fe50:cd2f]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id vOFLs0ra0Q-LD28OLLP; Tue, 15 Jul 2014 22:21:13 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: f2218227-b348-45c9-b2c3-2c842100aa91 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1405448473; bh=dA5LMpjdRmO9frlmmQSbyPon+utQx/groGxTsUewRzQ=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pBPxV9iQk19a82dG7vYR1BaM82itRu7PF79MTJY73Juo4UV7ThVepxFz9hhQ1IphM X14+V9Xbj7WZtO9hNF2NVzbFJWZxLs4fTn/lu1nFGHkkL5R1D0IMLpxoo4BGE0yd27 kfEpNajIhNDScDBJguVY5bBu/2/N67SzHYnuzLk0= Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <53C5710F.3010701@yandex-team.ru> Date: Tue, 15 Jul 2014 22:21:03 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: chenkun Subject: Re: tincd and mpd5 make kernel panic References: <53C521B1.5050605@yandex-team.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 18:21:26 -0000 On 15.07.2014 21:40, chenkun wrote: > On Tue, Jul 15, 2014 at 8:42 PM, Alexander V. Chernikov > wrote: >> On 15.07.2014 14:36, chk wrote: >>> Hi, everyone, >>> Help.... >>> I have a tincd vpn running in freebsd box FreeBSD 10.0-RELEASE-p2 #0 r265318M. >>> below is ifconfig outut: >>> [chk@NUC ~]$ ifconfig >>> em0: flags=8843 metric 0 mtu 1500 >>> options=4219b >>> ether ec:a8:6b:f3:76:6a >>> inet 192.168.2.202 netmask 0xffffff00 broadcast 255.255.255.255 >>> nd6 options=29 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> lo0: flags=8049 metric 0 mtu 16384 >>> options=600003 >>> inet6 ::1 prefixlen 128 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >>> inet 127.0.0.1 netmask 0xff000000 >>> nd6 options=21 >>> run0: flags=8843 metric 0 mtu 2290 >>> ether c8:3a:35:c0:b8:2f >>> nd6 options=29 >>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >>> status: associated >>> em0.3: flags=8843 metric 0 mtu 1500 >>> options=103 >>> ether ec:a8:6b:f3:76:6a >>> inet 192.168.3.1 netmask 0xffffff00 broadcast 255.255.255.0 >>> inet6 fe80::eea8:6bff:fef3:766a%em0.3 prefixlen 64 scopeid 0x4 >>> nd6 options=29 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> vlan: 3 parent interface: em0 >>> wlan0: flags=8843 metric 0 mtu 1500 >>> ether c8:3a:35:c0:b8:2f >>> inet 192.168.30.222 netmask 0xffffff00 broadcast 255.255.255.0 >>> inet6 fe80::ca3a:35ff:fec0:b82f%wlan0 prefixlen 64 scopeid 0x5 >>> nd6 options=29 >>> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >>> status: no carrier >>> ssid "" channel 10 (2457 MHz 11g) >>> country US authmode WPA1+WPA2/802.11i privacy MIXED deftxkey UNDEF >>> txpower 0 bmiss 7 scanvalid 60 protmode CTS wme roaming MANUAL >>> tun0: flags=8043 metric 0 mtu 1500 >>> options=80000 >>> inet 192.168.30.254 netmask 0xffffff00 broadcast 192.168.30.255 >>> inet6 fe80::eea8:6bff:fef3:766a%tun0 prefixlen 64 scopeid 0x6 >>> nd6 options=21 >>> Opened by PID 1015 >>> ========================= >>> Convenient for connect to vpn, I add a pppoe_server to mpd5, but when client dialing up, kernel panic. >> Is it reproducible? >> Can you issue "route -n monitor" and share its output before the panic? > Yes, after several times of re dail up, kernel panic > > route -n monitor print as below: > > [root@NUC /usr/home/chk]# route -n monitor > > got message of size 24 on Wed Jul 16 01:15:28 2014 > RTM_IEEE80211: IEEE 802.11 wireless event: len 24, pid: 0, seq > 6881280, errno 0, > flags: > locks: inits: > got message of size 24 on Wed Jul 16 01:15:34 2014 > RTM_IEEE80211: IEEE 802.11 wireless event: len 24, pid: 0, seq > 6881280, errno 0, > flags: > locks: inits: > got message of size 24 on Wed Jul 16 01:15:41 2014 > RTM_IEEE80211: IEEE 802.11 wireless event: len 24, pid: 0, seq > 6881280, errno 0, > flags: > locks: inits: > got message of size 24 on Wed Jul 16 01:15:46 2014 > RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 7, what: arrival > > got message of size 168 on Wed Jul 16 01:15:46 2014 > RTM_IFINFO: iface status change: len 168, if# 7, link: unknown, > flags: > > got message of size 184 on Wed Jul 16 01:15:46 2014 > RTM_DELETE: Delete Route: len 184, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > 0.0.0.0 (0) (0) > > got message of size 100 on Wed Jul 16 01:15:46 2014 > RTM_DELADDR: address being removed from iface: len 100, metric 0, flags: > sockaddrs: > 0.0.0.0 ng0 (0) (0) > > got message of size 184 on Wed Jul 16 01:15:46 2014 > RTM_DELETE: Delete Route: len 184, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > 0.0.0.0 (0) (0) > > got message of size 108 on Wed Jul 16 01:15:46 2014 > RTM_DELADDR: address being removed from iface: len 108, metric 0, flags: > sockaddrs: > 255.255.255.255 ng0 (0) (0) > > got message of size 116 on Wed Jul 16 01:15:46 2014 > RTM_NEWADDR: address being added to iface: len 116, metric 0, flags: > sockaddrs: > 255.255.255.255 ng0 192.168.40.1 192.168.41.50 > > got message of size 224 on Wed Jul 16 01:15:46 2014 > RTM_ADD: Add Route: len 224, pid: 0, seq 0, errno 0, flags: > locks: inits: > sockaddrs: > 192.168.41.50 link#7 > > got message of size 148 on Wed Jul 16 01:15:46 2014 > RTM_NEWADDR: address being added to iface: len 148, metric 0, flags: > sockaddrs: > ffff:ffff:ffff:ffff:: ng0 fe80::eea8:6bff:fef3:766a%ng0 (0) > > got message of size 272 on Wed Jul 16 01:15:46 2014 > RTM_ADD: Add Route: len 272, pid: 0, seq 0, errno 0, flags: > locks: inits: > sockaddrs: > fe80::eea8:6bff:fef3:766a%ng0 0.0.0.0.0.0 ffff:ffff:ffff:ffff:: > > got message of size 104 on Wed Jul 16 01:15:46 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff02::1:fff3:766a%ng0 > > got message of size 104 on Wed Jul 16 01:15:46 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff02::1%ng0 > > got message of size 104 on Wed Jul 16 01:15:46 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff02::2:ffd7:6760%ng0 > > got message of size 104 on Wed Jul 16 01:15:46 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff02::2:d767:6055%ng0 > > got message of size 104 on Wed Jul 16 01:15:46 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff01::1%ng0 > > got message of size 344 on Wed Jul 16 01:15:46 2014 > RTM_ADD: Add Route: len 344, pid: 0, seq 0, errno 0, flags: > locks: inits: > sockaddrs: > fe80::%ng0 link#7 (255) ffff ffff ffff ffff ffff ffff ffff ng0 > fe80::eea8:6bff:fef3:766a%ng0 > > got message of size 168 on Wed Jul 16 01:15:46 2014 > RTM_IFINFO: iface status change: len 168, if# 7, link: unknown, > flags: > > got message of size 168 on Wed Jul 16 01:15:46 2014 > RTM_IFINFO: iface status change: len 168, if# 7, link: unknown, > flags: > > got message of size 272 on Wed Jul 16 01:15:46 2014 > RTM_DELETE: Delete Route: len 272, pid: 0, seq 0, errno 0, flags: > locks: inits: > sockaddrs: > fe80::eea8:6bff:fef3:766a%7 link#0 ffff:ffff:ffff:ffff:: > > got message of size 148 on Wed Jul 16 01:15:46 2014 > RTM_DELADDR: address being removed from iface: len 148, metric 0, flags: > sockaddrs: > ffff:ffff:ffff:ffff:: ng0 fe80::eea8:6bff:fef3:766a%7 (0) > > got message of size 344 on Wed Jul 16 01:15:46 2014 > RTM_DELETE: Delete Route: len 344, pid: 0, seq 0, errno 0, flags: > locks: inits: > sockaddrs: > fe80::%7 link#7 (255) ffff ffff ffff ffff ffff ffff ffff ng0 > fe80::eea8:6bff:fef3:766a%7 > > got message of size 24 on Wed Jul 16 01:15:46 2014 > RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 7, what: departure > > got message of size 24 on Wed Jul 16 01:15:48 2014 > RTM_IEEE80211: IEEE 802.11 wireless event: len 24, pid: 0, seq > 6881280, errno 0, > flags: > locks: inits: > got message of size 24 on Wed Jul 16 01:15:54 2014 > RTM_IEEE80211: IEEE 802.11 wireless event: len 24, pid: 0, seq > 6881280, errno 0, > flags: > locks: inits: > got message of size 24 on Wed Jul 16 01:15:55 2014 > RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 7, what: arrival > > got message of size 168 on Wed Jul 16 01:15:55 2014 > RTM_IFINFO: iface status change: len 168, if# 7, link: unknown, > flags: > > got message of size 184 on Wed Jul 16 01:15:55 2014 > RTM_DELETE: Delete Route: len 184, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > 0.0.0.0 (0) (0) > > got message of size 100 on Wed Jul 16 01:15:55 2014 > RTM_DELADDR: address being removed from iface: len 100, metric 0, flags: > sockaddrs: > 0.0.0.0 ng0 (0) (0) > > got message of size 184 on Wed Jul 16 01:15:55 2014 > RTM_DELETE: Delete Route: len 184, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > 0.0.0.0 (0) (0) > > got message of size 108 on Wed Jul 16 01:15:55 2014 > RTM_DELADDR: address being removed from iface: len 108, metric 0, flags: > sockaddrs: > 255.255.255.255 ng0 (0) (0) > > got message of size 116 on Wed Jul 16 01:15:55 2014 > RTM_NEWADDR: address being added to iface: len 116, metric 0, flags: > sockaddrs: > 255.255.255.255 ng0 192.168.40.1 192.168.41.50 > > got message of size 224 on Wed Jul 16 01:15:55 2014 > RTM_ADD: Add Route: len 224, pid: 0, seq 0, errno 0, flags: > locks: inits: > sockaddrs: > 192.168.41.50 link#7 > > got message of size 148 on Wed Jul 16 01:15:55 2014 > RTM_NEWADDR: address being added to iface: len 148, metric 0, flags: > sockaddrs: > ffff:ffff:ffff:ffff:: ng0 fe80::eea8:6bff:fef3:766a%ng0 (0) > > got message of size 272 on Wed Jul 16 01:15:55 2014 > RTM_ADD: Add Route: len 272, pid: 0, seq 0, errno 0, flags: > locks: inits: > sockaddrs: > fe80::eea8:6bff:fef3:766a%ng0 0.0.0.0.0.0 ffff:ffff:ffff:ffff:: > > got message of size 104 on Wed Jul 16 01:15:55 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff02::1:fff3:766a%ng0 > > got message of size 104 on Wed Jul 16 01:15:55 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff02::1%ng0 > > got message of size 104 on Wed Jul 16 01:15:55 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff02::2:ffd7:6760%ng0 > > got message of size 104 on Wed Jul 16 01:15:55 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff02::2:d767:6055%ng0 > > got message of size 104 on Wed Jul 16 01:15:55 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff01::1%ng0 > > got message of size 344 on Wed Jul 16 01:15:55 2014 > RTM_ADD: Add Route: len 344, pid: 0, seq 0, errno 0, flags: > locks: inits: > sockaddrs: > fe80::%ng0 link#7 (255) ffff ffff ffff ffff ffff ffff ffff ng0 > fe80::eea8:6bff:fef3:766a%ng0 > > got message of size 168 on Wed Jul 16 01:15:55 2014 > RTM_IFINFO: iface status change: len 168, if# 7, link: unknown, > flags: > > got message of size 168 on Wed Jul 16 01:15:55 2014 > RTM_IFINFO: iface status change: len 168, if# 7, link: unknown, > flags: > > got message of size 272 on Wed Jul 16 01:15:55 2014 > RTM_DELETE: Delete Route: len 272, pid: 0, seq 0, errno 0, flags: > locks: inits: > sockaddrs: > fe80::eea8:6bff:fef3:766a%7 link#0 ffff:ffff:ffff:ffff:: > > got message of size 148 on Wed Jul 16 01:15:55 2014 > RTM_DELADDR: address being removed from iface: len 148, metric 0, flags: > sockaddrs: > ffff:ffff:ffff:ffff:: ng0 fe80::eea8:6bff:fef3:766a%7 (0) > > got message of size 344 on Wed Jul 16 01:15:55 2014 > RTM_DELETE: Delete Route: len 344, pid: 0, seq 0, errno 0, flags: > locks: inits: > sockaddrs: > fe80::%7 link#7 (255) ffff ffff ffff ffff ffff ffff ffff ng0 > fe80::eea8:6bff:fef3:766a%7 > > got message of size 24 on Wed Jul 16 01:15:55 2014 > RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 7, what: departure > > got message of size 24 on Wed Jul 16 01:15:59 2014 > RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 7, what: arrival > > got message of size 168 on Wed Jul 16 01:15:59 2014 > RTM_IFINFO: iface status change: len 168, if# 7, link: unknown, > flags: > > got message of size 184 on Wed Jul 16 01:15:59 2014 > RTM_DELETE: Delete Route: len 184, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > 0.0.0.0 (0) (0) > > got message of size 100 on Wed Jul 16 01:15:59 2014 > RTM_DELADDR: address being removed from iface: len 100, metric 0, flags: > sockaddrs: > 0.0.0.0 ng0 (0) (0) > > got message of size 184 on Wed Jul 16 01:15:59 2014 > RTM_DELETE: Delete Route: len 184, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > 0.0.0.0 (0) (0) > > got message of size 108 on Wed Jul 16 01:15:59 2014 > RTM_DELADDR: address being removed from iface: len 108, metric 0, flags: > sockaddrs: > 255.255.255.255 ng0 (0) (0) > > got message of size 116 on Wed Jul 16 01:15:59 2014 > RTM_NEWADDR: address being added to iface: len 116, metric 0, flags: > sockaddrs: > 255.255.255.255 ng0 192.168.40.1 192.168.41.50 > > got message of size 224 on Wed Jul 16 01:15:59 2014 > RTM_ADD: Add Route: len 224, pid: 0, seq 0, errno 0, flags: > locks: inits: > sockaddrs: > 192.168.41.50 link#7 > > got message of size 148 on Wed Jul 16 01:15:59 2014 > RTM_NEWADDR: address being added to iface: len 148, metric 0, flags: > sockaddrs: > ffff:ffff:ffff:ffff:: ng0 fe80::eea8:6bff:fef3:766a%ng0 (0) > > got message of size 272 on Wed Jul 16 01:15:59 2014 > RTM_ADD: Add Route: len 272, pid: 0, seq 0, errno 0, flags: > locks: inits: > sockaddrs: > fe80::eea8:6bff:fef3:766a%ng0 0.0.0.0.0.0 ffff:ffff:ffff:ffff:: > > got message of size 104 on Wed Jul 16 01:15:59 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff02::1:fff3:766a%ng0 > > got message of size 104 on Wed Jul 16 01:15:59 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff02::1%ng0 > > got message of size 104 on Wed Jul 16 01:15:59 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff02::2:ffd7:6760%ng0 > > got message of size 104 on Wed Jul 16 01:15:59 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff02::2:d767:6055%ng0 > > got message of size 104 on Wed Jul 16 01:15:59 2014 > RTM_NEWMADDR: new multicast group membership on iface: len 104, > sockaddrs: > ng0 ff01::1%ng0 > > got message of size 344 on Wed Jul 16 01:15:59 2014 > RTM_ADD: Add Route: len 344, pid: 0, seq 0, errno 0, flags: > locks: inits: > sockaddrs: > fe80::%ng0 link#7 (255) ffff ffff ffff ffff ffff ffff ffff ng0 > fe80::eea8:6bff:fef3:766a%ng0 > > got message of size 168 on Wed Jul 16 01:15:59 2014 > RTM_IFINFO: iface status change: len 168, if# 7, link: unknown, > flags: > > >> >> >>> here is information of core dump: >>> [root@NUC /var/log]# kgdb -c ../crash/vmcore.1 /boot/kernel/kernel >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and you are >>> welcome to change it and/or distribute copies of it under certain conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for details. >>> This GDB was configured as "amd64-marcel-freebsd"... >>> >>> Unread portion of the kernel message buffer: >>> >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 0; apic id = 00 >>> fault virtual address = 0x0 >>> fault code = supervisor read data, page not present >>> instruction pointer = 0x20:0xffffffff8098ae09 >>> stack pointer = 0x28:0xfffffe0234584660 >>> frame pointer = 0x28:0xfffffe02345846f0 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 780 (wpa_supplicant) >>> trap number = 12 >>> panic: page fault >>> cpuid = 0 >>> KDB: stack backtrace: >>> #0 0xffffffff808f5910 at kdb_backtrace+0x60 >>> #1 0xffffffff808bd3f5 at panic+0x155 >>> #2 0xffffffff80c9c1e2 at trap_fatal+0x3a2 >>> #3 0xffffffff80c9c4b9 at trap_pfault+0x2c9 >>> #4 0xffffffff80c9bc46 at trap+0x5e6 >>> #5 0xffffffff80c82ee2 at calltrap+0x8 >>> #6 0xffffffff809852f0 at rn_walktree+0x70 >>> #7 0xffffffff8098a470 at sysctl_rtsock+0x1a0 >>> #8 0xffffffff808c894f at sysctl_root+0x24f >>> #9 0xffffffff808c8f08 at userland_sysctl+0x1d8 >>> #10 0xffffffff808c8cf4 at sys___sysctl+0x74 >>> #11 0xffffffff80c9cad7 at amd64_syscall+0x357 >>> #12 0xffffffff80c831cb at Xfast_syscall+0xfb >>> Uptime: 10m24s >>> (ada0:ahcich0:0:0:0): STANDBY_IMMEDIATE. ACB: e0 00 00 00 00 40 00 00 00 00 00 00 >>> (ada0:ahcich0:0:0:0): CAM status: CCB request is in progress >>> (ada0:ahcich0:0:0:0): Error 5, Retries exhausted >>> (ada0:ahcich0:0:0:0): Spin-down disk failed >>> Dumping 439 out of 8067 MB:..4%..11%..22%..33%..41%..51%..62%..73%..81%..92% >>> (kgdb) f 7 >>> #7 0xffffffff8098ae09 in sysctl_dumpentry (rn=0xfffff800110eae10, vw=0xfffffe0234584748) >>> at /usr/src/sys/net/rtsock.c:1592 >>> 1592 info.rti_info[RTAX_IFP] = rt->rt_ifp->if_addr->ifa_addr; >>> Current language: auto; currently minimal >>> (kgdb) l >>> 1587 info.rti_info[RTAX_DST] = rt_key(rt); >>> 1588 info.rti_info[RTAX_GATEWAY] = rt->rt_gateway; >>> 1589 info.rti_info[RTAX_NETMASK] = rt_mask(rt); >>> 1590 info.rti_info[RTAX_GENMASK] = 0; >>> 1591 if (rt->rt_ifp) { >>> 1592 info.rti_info[RTAX_IFP] = rt->rt_ifp->if_addr->ifa_addr; >> This one looks strange. There is a check on added routes that rt_ifp is not NULL. >> >>> 1593 info.rti_info[RTAX_IFA] = rt->rt_ifa->ifa_addr; >>> 1594 if (rt->rt_ifp->if_flags & IFF_POINTOPOINT) >>> 1595 info.rti_info[RTAX_BRD] = rt->rt_ifa->ifa_dstaddr; >>> 1596 } >>> (kgdb) i loc >>> info = {rti_addrs = 0, rti_info = {0xfffff80005dace00, 0xfffff80005dace10, 0x0, 0x0, 0x0, 0x0, >>> 0x0, 0x0}, rti_flags = 0, rti_ifa = 0x0, rti_ifp = 0x0} >>> error = Cannot access memory at address 0x0 >>> (kgdb) p *rt >>> No symbol "rt" in current context. >>> (kgdb) p rt >>> No symbol "rt" in current context. >>> (kgdb) p info >>> $1 = {rti_addrs = 0, rti_info = {0xfffff80005dace00, 0xfffff80005dace10, 0x0, 0x0, 0x0, 0x0, 0x0, >>> 0x0}, rti_flags = 0, rti_ifa = 0x0, rti_ifp = 0x0} >> Can you decode which prefix it is? >> e.g. >> p (struct sockaddr_in *)info.rti_info[RTAX_DST] > (kgdb) p *(struct sockaddr_in *)info.rti_info[0] > $2 = {sin_len = 16 '\020', sin_family = 2 '\002', sin_port = 0, > sin_addr = {s_addr = 841590976}, > sin_zero = "\000\000\000\000\000\000\000"} So this looks like route to the other end of ng0 got message of size 116 on Wed Jul 16 01:15:46 2014 RTM_NEWADDR: address being added to iface: len 116, metric 0, flags: sockaddrs: 255.255.255.255 ng0 192.168.40.1 192.168.41.50 got message of size 224 on Wed Jul 16 01:15:46 2014 RTM_ADD: Add Route: len 224, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: ---------- ^^^^^^^^^^ 192.168.41.50 link#7 No ifp passed here. There are, however, some messy logic to determine ifp/ifa based on GW inside rtsock code.. > > >> p (struct sockaddr_in *)info.rti_info[RTAX_NETMASK] > info.rti_info[RTAX_NETMASK] is NULL. > >> and what is ifp (and others): >> >> p (struct rtentry *)0xfffff800110eae10 >> p *$1 >> p $1->rt_ip->if_addrs > (kgdb) p (struct rtentry *)0xfffff800110eae10 > $3 = (struct rtentry *) 0xfffff800110eae10 > (kgdb) p *$3 > Cannot access memory at address 0xfffff800110eae10 > ####0xfffff800110eae10 is address of rn? It's different in the last core dump. Yes. > (kgdb) p (struct rtentry *)0xfffff800122f0258 > $4 = (struct rtentry *) 0xfffff800122f0258 > (kgdb) p *$4 > $5 = {rt_nodes = {{rn_mklist = 0x0, rn_parent = 0xfffff800122f0288, > rn_bit = -1, rn_bmask = 0 '\0', > rn_flags = 4 '\004', rn_u = {rn_leaf = {rn_Key = > 0xfffff80005851c00 "\020\002", rn_Mask = 0x0, > rn_Dupedkey = 0x0}, rn_node = {rn_Off = 92609536, rn_L = > 0x0, rn_R = 0x0}}}, {rn_mklist = 0x0, > rn_parent = 0xfffff800122f08c8, rn_bit = 55, rn_bmask = 1 > '\001', rn_flags = 4 '\004', rn_u = { > rn_leaf = {rn_Key = 0x6
, rn_Mask = > 0xfffff8001208abe8 "À\234\003\022", > rn_Dupedkey = 0xfffff800122f0258}, rn_node = {rn_Off = 6, > rn_L = 0xfffff8001208abe8, > rn_R = 0xfffff800122f0258}}}}, rt_gateway = > 0xfffff80005851c10, rt_flags = 1048581, > rt_refcnt = 0, rt_ifp = 0xfffff800131fd000, rt_ifa = > 0xfffff80005ff7800, rt_rmx = {rmx_mtu = 1480, > rmx_expire = 0, rmx_pksent = 0, rmx_weight = 1}, rt_fibnum = 0, > rt_mtx = {lock_object = { > lo_name = 0xffffffff80eff57f "rtentry", lo_flags = 21168128, > lo_data = 0, lo_witness = 0x0}, > mtx_lock = 4}} > (kgdb) p $4->rt_ip->if_addrs > There is no member named rt_ip. > (kgdb) p $5->rt_ip->if_addrs > There is no member named rt_ip. Hm. ok. p (struct ifnet *)0xfffff800131fd000 p *$1 p *$1->if_addr p (struct ifaddr *)0xfffff80005ff7800 p *$2 > (kgdb) l > 1587 info.rti_info[RTAX_DST] = rt_key(rt); > 1588 info.rti_info[RTAX_GATEWAY] = rt->rt_gateway; > 1589 info.rti_info[RTAX_NETMASK] = rt_mask(rt); > 1590 info.rti_info[RTAX_GENMASK] = 0; > 1591 if (rt->rt_ifp) { > 1592 info.rti_info[RTAX_IFP] = rt->rt_ifp->if_addr->ifa_addr; > 1593 info.rti_info[RTAX_IFA] = rt->rt_ifa->ifa_addr; > 1594 if (rt->rt_ifp->if_flags & IFF_POINTOPOINT) > 1595 info.rti_info[RTAX_BRD] = > rt->rt_ifa->ifa_dstaddr; > 1596 } > (kgdb) p $5->rt_ifp->if_addrs > There is no member named if_addrs. > (kgdb) p $5->rt_ifp->if_addr > $6 = (struct ifaddr *) 0x0 > > Is that mean trap occur because of access a NULL point? Yes. > >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>>