From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 02:47:16 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 198F3106568D; Sun, 9 Nov 2008 02:47:16 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E61F28FC0C; Sun, 9 Nov 2008 02:47:15 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mA92lFgI076013; Sun, 9 Nov 2008 02:47:15 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mA92lFbE076009; Sun, 9 Nov 2008 02:47:15 GMT (envelope-from linimon) Date: Sun, 9 Nov 2008 02:47:15 GMT Message-Id: <200811090247.mA92lFbE076009@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/128247: [ip6] [panic] Fatal Trap 12 in ip6_forward = X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2008 02:47:16 -0000 Old Synopsis: [panic] Fatal Trap 12 in ip6_forward = New Synopsis: [ip6] [panic] Fatal Trap 12 in ip6_forward = Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 9 02:45:04 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128247 From owner-freebsd-net@FreeBSD.ORG Sun Nov 9 15:05:21 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 545A4106564A for ; Sun, 9 Nov 2008 15:05:20 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id F35968FC12 for ; Sun, 9 Nov 2008 15:05:19 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id mA9F5GmN062090 for ; Sun, 9 Nov 2008 22:05:16 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id mA9F5FrB062086 for net@freebsd.org; Sun, 9 Nov 2008 22:05:15 +0700 (KRAT) (envelope-from eugen) Date: Sun, 9 Nov 2008 22:05:15 +0700 From: Eugene Grosbein To: net@freebsd.org Message-ID: <20081109150515.GA61144@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: new little feature for sendmail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2008 15:05:21 -0000 Hi! Please give me advice on how to contribute new small feature to sendmail vendor code? I've discussed it in comp.mail.sendmail, it adds new flag -F to socketmap definition so ruleset may tell socketmap's permanent lookup failure (PERM) from 'not found' (NOTFOUND) error, for example: LOCAL_CONFIG Kcyrus socket -a -F -T local:/var/imap/socket/smmapd I've sent the patch and its description to sendmail-2008@ mailing list at support.sendmail.org but have not received a response. I do not even know if it has passed to the list or not, I have not found a web archive of the list. Usenet discussion of a problem and patch may be seen here: http://groups.google.com/group/comp.mail.sendmail/browse_thread/thread/d9a82dcb398019af Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 11:06:54 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E130210656A5 for ; Mon, 10 Nov 2008 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C7E808FC1E for ; Mon, 10 Nov 2008 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAAB6sYt049795 for ; Mon, 10 Nov 2008 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAAB6stU049791 for freebsd-net@FreeBSD.org; Mon, 10 Nov 2008 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Nov 2008 11:06:54 GMT Message-Id: <200811101106.mAAB6stU049791@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2008 11:06:55 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o kern/128181 net [fxp] panic in fxp_add_rfabuf o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126984 net [carp][patch] add carp userland notifications via devc o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 190 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 10 15:17:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 414461065670; Mon, 10 Nov 2008 15:17:26 +0000 (UTC) (envelope-from scaron@umich.edu) Received: from sonnet.diablonet.net (sonnet.diablonet.net [75.144.70.42]) by mx1.freebsd.org (Postfix) with ESMTP id E1E608FC24; Mon, 10 Nov 2008 15:17:25 +0000 (UTC) (envelope-from scaron@umich.edu) Received: from [141.211.10.207] (host10-207.sph.umich.edu [141.211.10.207]) by sonnet.diablonet.net (Postfix) with ESMTP id 8CE343DD066; Mon, 10 Nov 2008 09:46:32 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4098EE5C-1B7E-42B5-8F6C-F35DB8D4C917@umich.edu> Content-Transfer-Encoding: 7bit From: Sean Caron Date: Mon, 10 Nov 2008 09:46:46 -0500 To: freebsd-atm@freebsd.org, freebsd-net@freebsd.org X-Mailer: Apple Mail (2.753.1) Cc: Sean Caron Subject: Occasional kernel panic + reboot on 7.0-RELEASE, sparc64, fatm card. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2008 15:17:26 -0000 Hi folks, I posted this originally to the Freebsd/sparc64 general mailing list and someone there suggested that I send it this way, with the following note. "This apparently is a NULL-pointer dereference (probably "m" in sbsndptr()), with the cause being in one of the stacks involved. I'd suggest to report this backtrace to the atm@ and net@ lists." Quick background - I'm using fatm on FreeBSD/sparc64 7.0-RELEASE with a FORE PCA-200E PCI ATM card (fatm). I am using the Cranor (natm) driver. It generally works well but every couple of weeks the system will kernel panic and reboot. I switched on kernel dumps on panic and here's what I got (this time): sonnet.diablonet.net> kgdb kernel.debug /var/crash/vmcore.0 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): 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 "sparc64-marcel-freebsd". Unread portion of the kernel message buffer: panic: trap: fast data access mmu miss Uptime: 16d13h9m7s Dumping 1024 MB (2 chunks) chunk at 0: 536870912 bytes | #0 0x00000000c0280cd8 in doadump () at /usr/src/sys/kern/ kern_shutdown.c:240 240 savectx(&dumppcb); (kgdb) backtrace #0 0x00000000c0280cd8 in doadump () at /usr/src/sys/kern/ kern_shutdown.c:240 #1 0x00000000c0281608 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0x00000000c0281860 in panic (fmt=0xc066c6e0 "trap: %s") at /usr/src/sys/kern/kern_shutdown.c:563 #3 0x00000000c0541de4 in trap (tf=0xe5390e50) at /usr/src/sys/sparc64/sparc64/trap.c:378 #4 0x00000000c0070fe0 in tl1_trap () #5 0x00000000c02dd1d0 in sbsndptr (sb=0xfffff800014be6f0, off=0, len=1390, moff=0xe5391064) at /usr/src/sys/kern/uipc_sockbuf.c:939 #6 0x00000000c03edac4 in tcp_output (tp=0xfffff800014be6f0) at /usr/src/sys/netinet/tcp_output.c:802 #7 0x00000000c03edac4 in tcp_output (tp=0xfffff800014fce38) at /usr/src/sys/netinet/tcp_output.c:802 #8 0x00000000c03eaf98 in tcp_do_segment (m=0xfffff8005b354000, th=0xfffff8000133283c, so=0xfffff800014be570, tp=0xfffff800014fce38, drop_hdrlen=52, tlen=0) at /usr/src/sys/netinet/tcp_input.c:2347 #9 0x00000000c03ec214 in tcp_input (m=0xfffff8005b354000, off0=Variable "off0" is not available. ) at /usr/src/sys/netinet/tcp_input.c:845 #10 0x00000000c0381128 in ip_input (m=0xfffff8005b354000) at /usr/src/sys/netinet/ip_input.c:665 #11 0x00000000c0339cd0 in netisr_dispatch (num=2, m=0xfffff8005b354000) at /usr/src/sys/net/netisr.c:185 #12 0x00000000c032a930 in atm_input (ifp=0xfffff8000103c000, ah=0xe539162c, m=0xfffff8005b354000, rxhand=0x0) at /usr/src/sys/net/ if_atmsubr.c:347 #13 0x00000000c013d410 in fatm_intr (p=0xfffff80001173c00) at /usr/src/sys/dev/fatm/if_fatm.c:1573 #14 0x00000000c02615ec in ithread_loop (arg=0xfffff800011ce760) at /usr/src/sys/kern/kern_intr.c:1036 #15 0x00000000c025dd54 in fork_exit (callout=0xc0261420 , arg=0xfffff800011ce760, frame=0xe5391880) at /usr/src/sys/kern/kern_fork.c:781 #16 0x00000000c00711d0 in fork_trampoline () #17 0x00000000c00711d0 in fork_trampoline () Previous frame identical to this frame (corrupt stack?) (kgdb) up 15 #15 0x00000000c025dd54 in fork_exit (callout=0xc0261420 , arg=0xfffff800011ce760, frame=0xe5391880) at /usr/src/sys/kern/kern_fork.c:781 781 callout(arg, frame); (kgdb) list 776 * cpu_set_fork_handler intercepts this function call to 777 * have this call a non-return function to stay in kernel mode. 778 * initproc has its own fork handler, but it does return. 779 */ 780 KASSERT(callout != NULL, ("NULL callout in fork_exit")); 781 callout(arg, frame); 782 783 /* 784 * Check if a kernel thread misbehaved and returned from its main 785 * function. (kgdb) down #14 0x00000000c02615ec in ithread_loop (arg=0xfffff800011ce760) at /usr/src/sys/kern/kern_intr.c:1036 1036 ih->ih_handler(ih->ih_argument); (kgdb) list 1031 __func__, p->p_pid, (void *)ih->ih_handler, 1032 ih->ih_argument, ih->ih_name, ih->ih_flags); 1033 1034 if (!(ih->ih_flags & IH_MPSAFE)) 1035 mtx_lock(&Giant); 1036 ih->ih_handler(ih->ih_argument); 1037 if (!(ih->ih_flags & IH_MPSAFE)) 1038 mtx_unlock(&Giant); 1039 } 1040 if (!(ie->ie_flags & IE_SOFT)) (kgdb) down #13 0x00000000c013d410 in fatm_intr (p=0xfffff80001173c00) at /usr/src/sys/dev/fatm/if_fatm.c:1573 1573 atm_input(ifp, &aph, m0, vc->rxhand); (kgdb) list 1568 ifp->if_ipackets++; 1569 1570 vc->ipackets++; 1571 vc->ibytes += m0->m_pkthdr.len; 1572 1573 atm_input(ifp, &aph, m0, vc->rxhand); 1574 } 1575 1576 H_SETSTAT(q->q.statp, FATM_STAT_FREE); 1577 H_SYNCSTAT_PREWRITE(sc, q->q.statp); (kgdb) down #12 0x00000000c032a930 in atm_input (ifp=0xfffff8000103c000, ah=0xe539162c, m=0xfffff8005b354000, rxhand=0x0) at /usr/src/sys/net/ if_atmsubr.c:347 347 netisr_dispatch(isr, m); (kgdb) list 342 else 343 m_freem(m); 344 return; 345 } 346 } 347 netisr_dispatch(isr, m); 348 } 349 350 /* 351 * Perform common duties while attaching to interface list. (kgdb) down #11 0x00000000c0339cd0 in netisr_dispatch (num=2, m=0xfffff8005b354000) at /usr/src/sys/net/netisr.c:185 185 ni->ni_handler(m); (kgdb) list 180 * the packet but now do not. Doing so here will 181 * not preserve ordering so instead we fallback to 182 * guaranteeing order only from dispatch points 183 * in the system (see above). 184 */ 185 ni->ni_handler(m); 186 } else { 187 isrstat.isrs_deferred++; 188 if (IF_HANDOFF(ni->ni_queue, m, NULL)) 189 schednetisr(num); (kgdb) down #10 0x00000000c0381128 in ip_input (m=0xfffff8005b354000) at /usr/src/sys/netinet/ip_input.c:665 665 (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen); (kgdb) list 660 /* 661 * Switch out to protocol's input routine. 662 */ 663 ipstat.ips_delivered++; 664 665 (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen); 666 return; 667 bad: 668 m_freem(m); 669 } (kgdb) down #9 0x00000000c03ec214 in tcp_input (m=0xfffff8005b354000, off0=Variable "off0" is not available. ) at /usr/src/sys/netinet/tcp_input.c:845 845 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen); (kgdb) list 840 /* 841 * Segment belongs to a connection in SYN_SENT, ESTABLISHED or later 842 * state. tcp_do_segment() always consumes the mbuf chain, unlocks 843 * the inpcb, and unlocks pcbinfo. 844 */ 845 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen); 846 INP_INFO_UNLOCK_ASSERT(&tcbinfo); 847 return; 848 849 dropwithreset: (kgdb) down #8 0x00000000c03eaf98 in tcp_do_segment (m=0xfffff8005b354000, th=0xfffff8000133283c, so=0xfffff800014be570, tp=0xfffff800014fce38, drop_hdrlen=52, tlen=0) at /usr/src/sys/netinet/tcp_input.c:2347 2347 (void) tcp_output(tp); (kgdb) list 2342 2343 /* 2344 * Return any desired output. 2345 */ 2346 if (needoutput || (tp->t_flags & TF_ACKNOW)) 2347 (void) tcp_output(tp); 2348 2349 check_delack: 2350 KASSERT(headlocked == 0, ("%s: check_delack: head locked", 2351 __func__)); (kgdb) down #7 0x00000000c03edac4 in tcp_output (tp=0xfffff800014fce38) at /usr/src/sys/netinet/tcp_output.c:802 802 mb = sbsndptr(&so->so_snd, off, len, &moff); (kgdb) list 797 798 /* 799 * Start the m_copy functions from the closest mbuf 800 * to the offset in the socket buffer chain. 801 */ 802 mb = sbsndptr(&so->so_snd, off, len, &moff); 803 804 if (len <= MHLEN - hdrlen - max_linkhdr) { 805 m_copydata(mb, moff, (int)len, 806 mtod(m, caddr_t) + hdrlen); (kgdb) down #6 0x00000000c03edac4 in tcp_output (tp=0xfffff800014be6f0) at /usr/src/sys/netinet/tcp_output.c:802 802 mb = sbsndptr(&so->so_snd, off, len, &moff); (kgdb) list 797 798 /* 799 * Start the m_copy functions from the closest mbuf 800 * to the offset in the socket buffer chain. 801 */ 802 mb = sbsndptr(&so->so_snd, off, len, &moff); 803 804 if (len <= MHLEN - hdrlen - max_linkhdr) { 805 m_copydata(mb, moff, (int)len, 806 mtod(m, caddr_t) + hdrlen); (kgdb) down #5 0x00000000c02dd1d0 in sbsndptr (sb=0xfffff800014be6f0, off=0, len=1390, moff=0xe5391064) at /usr/src/sys/kern/uipc_sockbuf.c:939 939 off > 0 && off >= m->m_len; (kgdb) list 934 *moff = off - sb->sb_sndptroff; 935 m = ret = sb->sb_sndptr ? sb->sb_sndptr : sb->sb_mb; 936 937 /* Advance by len to be as close as possible for the next transmit. */ 938 for (off = off - sb->sb_sndptroff + len - 1; 939 off > 0 && off >= m->m_len; 940 m = m->m_next) { 941 sb->sb_sndptroff += m->m_len; 942 off -= m->m_len; 943 } (kgdb) down #4 0x00000000c0070fe0 in tl1_trap () (kgdb) list 944 sb->sb_sndptr = m; 945 946 return (ret); 947 } 948 949 /* 950 * Drop a record off the front of a sockbuf and move the next record to the 951 * front. 952 */ 953 void (kgdb) quit sonnet.diablonet.net> Please let me know if further information is required and I will furnish, no problem. Thanks, -Sean From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 08:44:12 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F247106564A; Wed, 12 Nov 2008 08:44:12 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2608FC18; Wed, 12 Nov 2008 08:44:12 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAC8iCLg077304; Wed, 12 Nov 2008 08:44:12 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAC8iCcV077300; Wed, 12 Nov 2008 08:44:12 GMT (envelope-from linimon) Date: Wed, 12 Nov 2008 08:44:12 GMT Message-Id: <200811120844.mAC8iCcV077300@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/128750: [ndis] BSS mode broken with ndis X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2008 08:44:12 -0000 Old Synopsis: BSS mode broken with ndis New Synopsis: [ndis] BSS mode broken with ndis Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Nov 12 08:44:00 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128750 From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 15:36:06 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F4C2106564A; Wed, 12 Nov 2008 15:36:06 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1FB158FC1A; Wed, 12 Nov 2008 15:36:06 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from freefall.freebsd.org (thompsa@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mACFa6v5086477; Wed, 12 Nov 2008 15:36:06 GMT (envelope-from thompsa@freefall.freebsd.org) Received: (from thompsa@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mACFa5Hd086473; Wed, 12 Nov 2008 15:36:05 GMT (envelope-from thompsa) Date: Wed, 12 Nov 2008 15:36:05 GMT Message-Id: <200811121536.mACFa5Hd086473@freefall.freebsd.org> To: onemda@gmail.com, thompsa@FreeBSD.org, freebsd-net@FreeBSD.org From: thompsa@FreeBSD.org Cc: Subject: Re: kern/128750: [ndis] BSS mode broken with ndis X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2008 15:36:06 -0000 Synopsis: [ndis] BSS mode broken with ndis State-Changed-From-To: open->closed State-Changed-By: thompsa State-Changed-When: Wed Nov 12 15:35:27 UTC 2008 State-Changed-Why: Fixed in r184833, does not affect older branches. Thanks Paul! http://www.freebsd.org/cgi/query-pr.cgi?pr=128750 From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 19:07:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F35641065678 for ; Wed, 12 Nov 2008 19:07:30 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by mx1.freebsd.org (Postfix) with ESMTP id C7AB88FC1D for ; Wed, 12 Nov 2008 19:07:30 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=FnB3QNx629wzC3SXQ+FcSs/lo6mUz8OGxBgVm892eg7ZjdJG57GFNb3p8hUMZd37; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L0Kto-00089Q-BC for freebsd-net@freebsd.org; Wed, 12 Nov 2008 13:57:08 -0500 Message-ID: <491B2703.4080707@earthlink.net> Date: Wed, 12 Nov 2008 13:57:07 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec795299462d2ca007e0be94b8088d65123f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Subject: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2008 19:07:31 -0000 Hi, When I run traceroute thru a gre it doesn't seem to decrement the ttl, so I get * * * for that hop. Can this be fixed? Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 19:23:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CB8C106568A; Wed, 12 Nov 2008 19:23:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 34C3F8FC19; Wed, 12 Nov 2008 19:23:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mACJN31P058759; Wed, 12 Nov 2008 19:23:03 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mACJN3ta058755; Wed, 12 Nov 2008 19:23:03 GMT (envelope-from linimon) Date: Wed, 12 Nov 2008 19:23:03 GMT Message-Id: <200811121923.mACJN3ta058755@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/128790: [netinet] [patch] bug in IP_MINTTL setsockopt() implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2008 19:23:03 -0000 Old Synopsis: [patch] bug in IP_MINTTL setsockopt() implementation New Synopsis: [netinet] [patch] bug in IP_MINTTL setsockopt() implementation Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Nov 12 19:22:37 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128790 From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 19:55:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BB4C106564A for ; Wed, 12 Nov 2008 19:55:11 +0000 (UTC) (envelope-from prvs=julian=195c31f52@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 867CA8FC1A for ; Wed, 12 Nov 2008 19:55:11 +0000 (UTC) (envelope-from prvs=julian=195c31f52@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 12 Nov 2008 11:43:53 -0800 Message-ID: <491B31F7.30200@elischer.org> Date: Wed, 12 Nov 2008 11:43:51 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: sclark46@earthlink.net References: <491B2703.4080707@earthlink.net> In-Reply-To: <491B2703.4080707@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2008 19:55:11 -0000 Stephen Clark wrote: > Hi, > > When I run traceroute thru a gre it doesn't seem to decrement the > ttl, so I get * * * for that hop. Can this be fixed? > > Thanks, > Steve you will need to define the setup and question better. TTL is controlled by the IP stack which is unaware of which interface it came in on and doesn't care which interface it goes out on. That includes GRE interfaces.. Is it freebsd at both ends? BTW * * * would come from an EXTRA decrement From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 20:57:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A0F01065672 for ; Wed, 12 Nov 2008 20:57:46 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6978FC12 for ; Wed, 12 Nov 2008 20:57:45 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=g99XYPf35+mvkOgA7soFmsryy80fc5TLrdFe8bN8Uc02ERynJRA//UP5pcDUZcm3; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L0MmU-0008Ex-TU; Wed, 12 Nov 2008 15:57:42 -0500 Message-ID: <491B4345.80106@earthlink.net> Date: Wed, 12 Nov 2008 15:57:41 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Julian Elischer References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> In-Reply-To: <491B31F7.30200@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec7992430d40651525e94b78ffce2a5c7506350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2008 20:57:46 -0000 Julian Elischer wrote: > Stephen Clark wrote: >> Hi, >> >> When I run traceroute thru a gre it doesn't seem to decrement the >> ttl, so I get * * * for that hop. Can this be fixed? >> >> Thanks, >> Steve > > you will need to define the setup and question better. > > TTL is controlled by the IP stack which is unaware of which interface > it came in on and doesn't care which interface it goes out on. That > includes GRE interfaces.. Is it freebsd at both ends? > > > BTW * * * would come from an EXTRA decrement > _______________________________________________ > 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" > FreeBSD workstation 10.0.129.1<-->10.0.128.1 Freebsd FW "A" with gre over ipsec tunnel<---->FreeBSD FW "B" with gre over ipsec tunnel 192.168.3.1<---> 192.168.3.86 linux workstation $ sudo traceroute 192.168.3.86 traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packets 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms 2 * * * 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms No response from the FreeBSD "B" box. When I do a tcpdump on "B" of the gre interface I see UDP packets with a TTL of 1 but no ICMP repsonse packets being sent back. If I do the traceroute from the linux workstation 192.168.3.86 I get similar results - I don't see a response from the FreeBSD "A" box. Regards, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 21:17:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39410106564A for ; Wed, 12 Nov 2008 21:17:07 +0000 (UTC) (envelope-from prvs=julian=195c31f52@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 21CBD8FC16 for ; Wed, 12 Nov 2008 21:17:07 +0000 (UTC) (envelope-from prvs=julian=195c31f52@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 12 Nov 2008 13:17:07 -0800 Message-ID: <491B47D2.6010804@elischer.org> Date: Wed, 12 Nov 2008 13:17:06 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: sclark46@earthlink.net References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> In-Reply-To: <491B4345.80106@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2008 21:17:07 -0000 Stephen Clark wrote: > Julian Elischer wrote: >> you will need to define the setup and question better. thanks.. cleaning it up a bit more... 10.0.129.1 FreeBSD workstation ^ | | ethernet | v 10.0.128.1 Freebsd FW "A" ^ | | gre / ipsec | v 192.168.3.1 FreeBSD FW "B" ^ | | ethernet | v 192.168.3.86 linux workstation > $ sudo traceroute 192.168.3.86 > traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packets > 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms > 2 * * * > 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms > > No response from the FreeBSD "B" box. > > When I do a tcpdump on "B" of the gre interface I see UDP packets > with a TTL of 1 but no ICMP response packets being sent back. > > If I do the traceroute from the linux workstation 192.168.3.86 I get > similar results - I don't see a response from the FreeBSD "A" box. could you try using just GRE encasulation? (i.e. turn off IPSEC for now) I think that is much more likely to be where the problem is.. From owner-freebsd-net@FreeBSD.ORG Wed Nov 12 21:56:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED918106564A for ; Wed, 12 Nov 2008 21:56:55 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 971CB8FC14 for ; Wed, 12 Nov 2008 21:56:55 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.166.46] ([68.0.14.34]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id mACLb2rC088120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2008 16:37:03 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Julian Elischer In-Reply-To: <491B47D2.6010804@elischer.org> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-q7pPc0w2JrezYaBnEuib" Organization: FreeBSD Date: Wed, 12 Nov 2008 16:36:56 -0500 Message-Id: <1226525816.61187.35.camel@squirrel.corp.cox.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: sclark46@earthlink.net, freebsd-net@freebsd.org Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2008 21:56:56 -0000 --=-q7pPc0w2JrezYaBnEuib Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-11-12 at 13:17 -0800, Julian Elischer wrote: > Stephen Clark wrote: > > Julian Elischer wrote: >=20 > >> you will need to define the setup and question better. >=20 > thanks.. cleaning it up a bit more... >=20 > 10.0.129.1 FreeBSD workstation > ^ > | > | ethernet > | > v > 10.0.128.1 Freebsd FW "A" > ^ > | > | gre / ipsec > | > v > 192.168.3.1 FreeBSD FW "B" > ^ > | > | ethernet > | > v > 192.168.3.86 linux workstation How are you mapping packets onto the gre? If firewall B doesn't know how to reach the FreeBSD workstation directly, you will see the issue that you describe. Can you ping 10.0.129.1 from Firewall B? The ttl expired will be generated by Firewall B. robert. > > $ sudo traceroute 192.168.3.86 > > traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packets > > 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms > > 2 * * * > > 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms > >=20 > > No response from the FreeBSD "B" box. > >=20 > > When I do a tcpdump on "B" of the gre interface I see UDP packets > > with a TTL of 1 but no ICMP response packets being sent back. >=20 > >=20 > > If I do the traceroute from the linux workstation 192.168.3.86 I get > > similar results - I don't see a response from the FreeBSD "A" box. >=20 > could you try using just GRE encasulation? > (i.e. turn off IPSEC for now) >=20 > I think that is much more likely to be where the problem is.. >=20 >=20 > _______________________________________________ > 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" --=-q7pPc0w2JrezYaBnEuib Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkkbTHgACgkQM4TrQ4qfRONpiACcDHSz5wIQ4DaeYa2o1BLSEhWr VAUAnizCkz1kCNTUT9ERFBYsFJ68Nq35 =j8lj -----END PGP SIGNATURE----- --=-q7pPc0w2JrezYaBnEuib-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 00:16:29 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 367871065673; Thu, 13 Nov 2008 00:16:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0AB3F8FC0C; Thu, 13 Nov 2008 00:16:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (rwatson@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAD0GSdb006110; Thu, 13 Nov 2008 00:16:28 GMT (envelope-from rwatson@freefall.freebsd.org) Received: (from rwatson@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAD0GSPw006106; Thu, 13 Nov 2008 00:16:28 GMT (envelope-from rwatson) Date: Thu, 13 Nov 2008 00:16:28 GMT Message-Id: <200811130016.mAD0GSPw006106@freefall.freebsd.org> To: rwatson@FreeBSD.org, freebsd-net@FreeBSD.org, rwatson@FreeBSD.org From: rwatson@FreeBSD.org Cc: Subject: Re: kern/128790: [netinet] [patch] bug in IP_MINTTL setsockopt() implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2008 00:16:29 -0000 Synopsis: [netinet] [patch] bug in IP_MINTTL setsockopt() implementation Responsible-Changed-From-To: freebsd-net->rwatson Responsible-Changed-By: rwatson Responsible-Changed-When: Thu Nov 13 00:15:55 UTC 2008 Responsible-Changed-Why: Grab ownership of this PR, I can take a look at this. http://www.freebsd.org/cgi/query-pr.cgi?pr=128790 From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 01:09:16 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2373E1065670; Thu, 13 Nov 2008 01:09:16 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EB3998FC1A; Thu, 13 Nov 2008 01:09:15 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAD19FVw043697; Thu, 13 Nov 2008 01:09:15 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAD19FDE043692; Thu, 13 Nov 2008 01:09:15 GMT (envelope-from linimon) Date: Thu, 13 Nov 2008 01:09:15 GMT Message-Id: <200811130109.mAD19FDE043692@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2008 01:09:16 -0000 Old Synopsis: Network packets corrupted when bge card is in 64-bit PCI slot New Synopsis: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 13 01:09:00 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128833 From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 12:46:24 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C22211065678 for ; Thu, 13 Nov 2008 12:46:24 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by mx1.freebsd.org (Postfix) with ESMTP id 78E068FC1A for ; Thu, 13 Nov 2008 12:46:24 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RM8yraMG73g8DC3PEwfvyWG7YnnHifC/m8DRcAamDO4KJz/pQGPlJvQQC3ue3cl2; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L0baX-00030g-9P; Thu, 13 Nov 2008 07:46:21 -0500 Message-ID: <491C219B.1050606@earthlink.net> Date: Thu, 13 Nov 2008 07:46:19 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Robert Noland References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <1226525816.61187.35.camel@squirrel.corp.cox.com> In-Reply-To: <1226525816.61187.35.camel@squirrel.corp.cox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec797487a0c0db311276bfe076d583af9b13350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Cc: freebsd-net@FreeBSD.org, Julian Elischer Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2008 12:46:24 -0000 Robert Noland wrote: > On Wed, 2008-11-12 at 13:17 -0800, Julian Elischer wrote: >> Stephen Clark wrote: >>> Julian Elischer wrote: >>>> you will need to define the setup and question better. >> thanks.. cleaning it up a bit more... >> >> 10.0.129.1 FreeBSD workstation >> ^ >> | >> | ethernet >> | >> v >> 10.0.128.1 Freebsd FW "A" >> ^ >> | >> | gre / ipsec >> | >> v >> 192.168.3.1 FreeBSD FW "B" >> ^ >> | >> | ethernet >> | >> v >> 192.168.3.86 linux workstation > > How are you mapping packets onto the gre? If firewall B doesn't know > how to reach the FreeBSD workstation directly, you will see the issue > that you describe. Can you ping 10.0.129.1 from Firewall B? The ttl > expired will be generated by Firewall B. ospf - I can ping 192.168.3.1 from the FreeBSD Workstation just fine in fact all the systems can ping just fine. > > robert. > >>> $ sudo traceroute 192.168.3.86 >>> traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packets >>> 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms >>> 2 * * * >>> 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms >>> >>> No response from the FreeBSD "B" box. >>> >>> When I do a tcpdump on "B" of the gre interface I see UDP packets >>> with a TTL of 1 but no ICMP response packets being sent back. >>> If I do the traceroute from the linux workstation 192.168.3.86 I get >>> similar results - I don't see a response from the FreeBSD "A" box. >> could you try using just GRE encasulation? >> (i.e. turn off IPSEC for now) >> >> I think that is much more likely to be where the problem is.. >> >> >> _______________________________________________ >> 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" -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 12:48:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 771EA1065670 for ; Thu, 13 Nov 2008 12:48:58 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by mx1.freebsd.org (Postfix) with ESMTP id 31CD88FC14 for ; Thu, 13 Nov 2008 12:48:58 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=DNc1KH53CEVcUoFAaCkeFlJ+qB/pN5THiO4DtGhx5+vPHUJzUv3wI0dJdiIZ/OOI; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L0bd0-0003yN-Vy; Thu, 13 Nov 2008 07:48:55 -0500 Message-ID: <491C2235.4090509@earthlink.net> Date: Thu, 13 Nov 2008 07:48:53 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Julian Elischer References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> In-Reply-To: <491B47D2.6010804@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec792a8bbfc10b2ed1945d0358e647a1c728350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2008 12:48:58 -0000 Julian Elischer wrote: > Stephen Clark wrote: >> Julian Elischer wrote: > >>> you will need to define the setup and question better. > > thanks.. cleaning it up a bit more... > > 10.0.129.1 FreeBSD workstation > ^ > | > | ethernet > | > v > 10.0.128.1 Freebsd FW "A" > ^ > | > | gre / ipsec > | > v > 192.168.3.1 FreeBSD FW "B" > ^ > | > | ethernet > | > v > 192.168.3.86 linux workstation > >> $ sudo traceroute 192.168.3.86 >> traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packets >> 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms >> 2 * * * >> 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms >> >> No response from the FreeBSD "B" box. >> >> When I do a tcpdump on "B" of the gre interface I see UDP packets >> with a TTL of 1 but no ICMP response packets being sent back. > >> >> If I do the traceroute from the linux workstation 192.168.3.86 I get >> similar results - I don't see a response from the FreeBSD "A" box. > > could you try using just GRE encasulation? > (i.e. turn off IPSEC for now) > > I think that is much more likely to be where the problem is.. > > I'll have to set this up to test it. What code in the FreeBSD kernel is responsible for generating the response ICMP dest unreachable message? -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 15:17:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B2051065672 for ; Thu, 13 Nov 2008 15:17:59 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id D4E2A8FC1B for ; Thu, 13 Nov 2008 15:17:58 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [10.63.4.100] (gw1.cox.com [24.248.74.254]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id mADFHtoL092916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2008 10:17:55 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: sclark46@earthlink.net In-Reply-To: <491C2235.4090509@earthlink.net> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oqrMt4NQs0se7ZPtGUVB" Organization: FreeBSD Date: Thu, 13 Nov 2008 10:17:48 -0500 Message-Id: <1226589468.1976.12.camel@wombat.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_XBL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2008 15:17:59 -0000 --=-oqrMt4NQs0se7ZPtGUVB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-11-13 at 07:48 -0500, Stephen Clark wrote: > Julian Elischer wrote: > > Stephen Clark wrote: > >> Julian Elischer wrote: > >=20 > >>> you will need to define the setup and question better. > >=20 > > thanks.. cleaning it up a bit more... > >=20 > > 10.0.129.1 FreeBSD workstation > > ^ > > | > > | ethernet > > | > > v > > 10.0.128.1 Freebsd FW "A" > > ^ > > | > > | gre / ipsec > > | > > v > > 192.168.3.1 FreeBSD FW "B" > > ^ > > | > > | ethernet > > | > > v > > 192.168.3.86 linux workstation > >=20 > >> $ sudo traceroute 192.168.3.86 > >> traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packet= s > >> 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms > >> 2 * * * > >> 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms > >> > >> No response from the FreeBSD "B" box. > >> > >> When I do a tcpdump on "B" of the gre interface I see UDP packets > >> with a TTL of 1 but no ICMP response packets being sent back. > >=20 > >> > >> If I do the traceroute from the linux workstation 192.168.3.86 I get > >> similar results - I don't see a response from the FreeBSD "A" box. > >=20 > > could you try using just GRE encasulation? > > (i.e. turn off IPSEC for now) > >=20 > > I think that is much more likely to be where the problem is.. > >=20 > >=20 > I'll have to set this up to test it. The ttl exceeded is triggered from one of two places. Either netinet/ip_fastfwd.c if fast_forwarding is enabled or in netinet/ip_input.c. Look for the code relating to IPTTLDEC. This isn't your problem though... If ttl were not being decremented, the packet would just be forwarded on to the next hop (IP_STEALTH), which would just make the firewalls invisible. The fact that you are seeing * * * indicates that you are not receiving the ttl exceeded message for the packet sent with that particular ttl. I still think that the issue you are seeing is that one way or another the generated ICMP response isn't making it back onto the tunnel. Either via security policy, firewall or routing. robert. > What code in the FreeBSD kernel is responsible for generating the respons= e ICMP=20 > dest unreachable message? >=20 --=-oqrMt4NQs0se7ZPtGUVB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkkcRRwACgkQM4TrQ4qfROMI2ACdHE8Aj5kP7FihhhkWLqZ/UCcy QpMAniijaIpVOjoRmzwEt3uUE9jmoZV3 =maqq -----END PGP SIGNATURE----- --=-oqrMt4NQs0se7ZPtGUVB-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 15:59:01 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06FF61065687; Thu, 13 Nov 2008 15:59:01 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9C8F98FC1D; Thu, 13 Nov 2008 15:59:00 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=NTgJfBHpf0wfvIsrKDUrR+18IlxDoSoP1rM1FjQQ2/XBPs72HgbmiET54N6MR2D9; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L0eax-0004Zm-Hp; Thu, 13 Nov 2008 10:58:59 -0500 Message-ID: <491C4EC2.2000802@earthlink.net> Date: Thu, 13 Nov 2008 10:58:58 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Robert Noland References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> In-Reply-To: <1226589468.1976.12.camel@wombat.2hip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec796380df5185e6bbbedf45d2d1a436eec3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Cc: freebsd-net@FreeBSD.org, Julian Elischer Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2008 15:59:01 -0000 Robert Noland wrote: > On Thu, 2008-11-13 at 07:48 -0500, Stephen Clark wrote: >> Julian Elischer wrote: >>> Stephen Clark wrote: >>>> Julian Elischer wrote: >>>>> you will need to define the setup and question better. >>> thanks.. cleaning it up a bit more... >>> >>> 10.0.129.1 FreeBSD workstation >>> ^ >>> | >>> | ethernet >>> | >>> v >>> 10.0.128.1 Freebsd FW "A" >>> ^ >>> | >>> | gre / ipsec >>> | >>> v >>> 192.168.3.1 FreeBSD FW "B" >>> ^ >>> | >>> | ethernet >>> | >>> v >>> 192.168.3.86 linux workstation >>> >>>> $ sudo traceroute 192.168.3.86 >>>> traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packets >>>> 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms >>>> 2 * * * >>>> 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms >>>> >>>> No response from the FreeBSD "B" box. >>>> >>>> When I do a tcpdump on "B" of the gre interface I see UDP packets >>>> with a TTL of 1 but no ICMP response packets being sent back. >>>> If I do the traceroute from the linux workstation 192.168.3.86 I get >>>> similar results - I don't see a response from the FreeBSD "A" box. >>> could you try using just GRE encasulation? >>> (i.e. turn off IPSEC for now) >>> >>> I think that is much more likely to be where the problem is.. >>> >>> >> I'll have to set this up to test it. > > The ttl exceeded is triggered from one of two places. Either > netinet/ip_fastfwd.c if fast_forwarding is enabled or in > netinet/ip_input.c. Look for the code relating to IPTTLDEC. This isn't > your problem though... If ttl were not being decremented, the packet > would just be forwarded on to the next hop (IP_STEALTH), which would > just make the firewalls invisible. The fact that you are seeing * * * > indicates that you are not receiving the ttl exceeded message for the > packet sent with that particular ttl. I still think that the issue you > are seeing is that one way or another the generated ICMP response isn't > making it back onto the tunnel. Either via security policy, firewall or > routing. Your right, when I do a tcpdump on the gre interface I see the udp packet come in with a ttl=1 but I don't see a response icmp packet. I have tested this with all the firewalls disabled to make sure the icmp packet was not being blocked. I just ran another test and did tcpdump on all the other interfaces to make sure the icmp's were not being misrouted, it seems they are not being generated for some reason. Also just using gre's without the underlying ipsec tunnels seems to work properly. > > robert. > >> What code in the FreeBSD kernel is responsible for generating the response ICMP >> dest unreachable message? >> -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Thu Nov 13 22:30:12 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF18C106567D for ; Thu, 13 Nov 2008 22:30:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 73D178FC16 for ; Thu, 13 Nov 2008 22:30:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mADMUCqP038545 for ; Thu, 13 Nov 2008 22:30:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mADMUC45038539; Thu, 13 Nov 2008 22:30:12 GMT (envelope-from gnats) Date: Thu, 13 Nov 2008 22:30:12 GMT Message-Id: <200811132230.mADMUC45038539@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Marius Strobl Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marius Strobl List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2008 22:30:12 -0000 The following reply was made to PR kern/128833; it has been noted by GNATS. From: Marius Strobl To: bug-followup@FreeBSD.org, freebsd@amc-os.com Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Thu, 13 Nov 2008 23:14:46 +0100 Hrm, I could be that the BCM5701 data corruption bug actually is 64-bit rather than only PCI-X bus specific. Could you please give the patch at: http://people.freebsd.org/~marius/bge_5701.diff a try? From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 02:18:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FFBF1065680; Fri, 14 Nov 2008 02:18:34 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id E803D8FC12; Fri, 14 Nov 2008 02:18:33 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.45]) by smtp-outbound.ironport.com with ESMTP; 13 Nov 2008 17:50:09 -0800 Message-ID: <491CD94F.3020207@elischer.org> Date: Thu, 13 Nov 2008 17:50:07 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: FreeBSD Net , ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: rc.firewall quick change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 02:18:34 -0000 At home I use the following change. basically, instead of doing 8 rules before and after the nat, use a table and to 1 rule on each side. any objections? (warning, cut-n-paste patch.. will not apply) Index: rc.firewall =================================================================== --- rc.firewall (revision 184948) +++ rc.firewall (working copy) @@ -231,19 +231,24 @@ ${fwcmd} add deny all from ${onet} to any in via ${iif} # Stop RFC1918 nets on the outside interface - ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} - ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} - ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} + ${fwcmd} table 1 add 10.0.0.0/8 + ${fwcmd} table 1 add 172.16.0.0/12 + ${fwcmd} table 1 add 192.168.0.0/16 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) # on the outside interface - ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} - ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} - ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} - ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} - ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} + ${fwcmd} table 1 add 0.0.0.0/8 + ${fwcmd} table 1 add 169.254.0.0/16 + ${fwcmd} table 1 add 192.0.2.0/24 + ${fwcmd} table 1 add 224.0.0.0/4 + ${fwcmd} table 1 add 240.0.0.0/4 + # Stop the above nets with the table + + ${fwcmd} add deny all from any to "table(1)" via ${oif} + + # Network Address Translation. This rule is placed here deliberately # so that it does not interfere with the surrounding address-checking # rules. If for example one of your internal LAN machines had its IP @@ -260,19 +265,8 @@ esac # Stop RFC1918 nets on the outside interface - ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} - ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} - ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} + ${fwcmd} add deny all from "table(1)" to any via ${oif} - # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, - # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) - # on the outside interface - ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} - ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} - ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} - ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} - ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} - # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 03:11:13 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16980106564A; Fri, 14 Nov 2008 03:11:13 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 5A34A8FC0A; Fri, 14 Nov 2008 03:11:12 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id mAE2rSLe051643; Fri, 14 Nov 2008 13:53:28 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 14 Nov 2008 13:53:28 +1100 (EST) From: Ian Smith To: net@freebsd.org, ipfw@freebsd.org Message-ID: <20081114134925.E70117@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Subject: Re: Speaking of rc.firewall .. (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 03:11:13 -0000 ---------- Forwarded message ---------- Date: Fri, 17 Oct 2008 05:24:43 +1100 (EST) From: Ian Smith To: freebsd-ipfw@freebsd.org Subject: Re: Speaking of rc.firewall .. On Thu, 16 Oct 2008, Ian Smith wrote: > I see that both HEAD and RELENG_7 rc.firewall have been updated for in- > kernel NAT functionality, but only for the 'open' and 'client' rulesets. > > Is there any (functional) reason that the ${firewall_nat_enable} case is > not also included in the 'simple' rules, where its different placement > is determined by being preceded and anteceded by anti-spoofing rules? > > I'm also slightly bemused by the lack (still) of any rules to allow any > ICMP (especially necessary icmptypes for MTU discovery) in 'simple'? To put my patch where my mouth is, assuming that the answer to my first question is likely 'no', this is against the present RELENG_7 version. It addresses the second (ICMP) issue for 'client' and 'simple', and I see no harm in enabling outbound pings for such out-of-the-box setups? Hope this format's useful (just diff -u), and also that inline is ok. cheers, Ian --- rc.firewall.1.52.2.3 Fri Oct 17 01:34:56 2008 +++ rc.firewall Fri Oct 17 04:27:36 2008 @@ -116,15 +116,14 @@ # will then be run again on each packet after translation by natd # starting at the rule number following the divert rule. # -# For ``simple'' firewall type the divert rule should be put to a +# For ``simple'' firewall type the divert rule is included in a # different place to not interfere with address-checking rules. # -case ${firewall_type} in -[Oo][Pp][Ee][Nn]|[Cc][Ll][Ii][Ee][Nn][Tt]) +setup_nat () { case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then - ${fwcmd} add 50 divert natd ip4 from any to any via ${natd_interface} + ${fwcmd} add $1 divert natd ip4 from any to any via ${natd_interface} fi ;; esac @@ -138,11 +137,11 @@ firewall_nat_flags="if ${firewall_nat_interface} ${firewall_nat_flags}" fi ${fwcmd} nat 123 config log ${firewall_nat_flags} - ${fwcmd} add 50 nat 123 ip4 from any to any via ${firewall_nat_interface} + ${fwcmd} add $1 nat 123 ip4 from any to any via ${firewall_nat_interface} fi ;; esac -esac +} ############ # If you just configured ipfw in the kernel as a tool to solve network @@ -157,6 +156,7 @@ # case ${firewall_type} in [Oo][Pp][Ee][Nn]) + setup_nat 50 ${fwcmd} add 65000 pass all from any to any ;; @@ -172,6 +172,8 @@ # set this to your local network net="$firewall_client_net" + setup_nat 50 + # Allow any traffic to or from my own net. ${fwcmd} add pass all from me to ${net} ${fwcmd} add pass all from ${net} to me @@ -197,6 +199,12 @@ # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state + # Allow outbound pings + ${fwcmd} add pass icmp from me to any out icmptypes 8 keep-state + + # Allow essential ICMP: unreachable, source quench, TTL exceeded + ${fwcmd} add pass icmp from any to any icmptypes 3,4,11 + # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel # config file. @@ -248,13 +256,7 @@ # translated by natd(8) would match the `deny' rule above. Similarly # an outgoing packet originated from it before being translated would # match the `deny' rule below. - case ${natd_enable} in - [Yy][Ee][Ss]) - if [ -n "${natd_interface}" ]; then - ${fwcmd} add divert natd all from any to any via ${natd_interface} - fi - ;; - esac + setup_nat # Stop RFC1918 nets on the outside interface ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} @@ -298,6 +300,12 @@ # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state + + # Allow outbound pings from our net + ${fwcmd} add pass icmp from any to any out icmptypes 8 keep-state + + # Allow essential ICMP: unreachable, source quench, TTL exceeded + ${fwcmd} add pass icmp from any to any icmptypes 3,4,11 # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 03:11:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61F301065678; Fri, 14 Nov 2008 03:11:14 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id A5E388FC1C; Fri, 14 Nov 2008 03:11:13 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id mAE2mfhe051406; Fri, 14 Nov 2008 13:48:41 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 14 Nov 2008 13:48:41 +1100 (EST) From: Ian Smith To: Julian Elischer In-Reply-To: <491CD94F.3020207@elischer.org> Message-ID: <20081114133913.K70117@sola.nimnet.asn.au> References: <491CD94F.3020207@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: rc.firewall quick change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 03:11:14 -0000 On Thu, 13 Nov 2008, Julian Elischer wrote: > At home I use the following change. > > > basically, instead of doing 8 rules before and after the nat, > use a table and to 1 rule on each side. > > > any objections? Only that if people are already using tables for anything, chances are they've already used table 1 (well, it's the first one I used :) How about using table 127 for this as a rather less likely prior choice? Apart from that, this will speed up 'simple' on a path every packet takes, which has to be a good thing. While I'm at it, I'll offer my own rc.firewall patch again in the following message. Perhaps you'd care to review it in this context? cheers, Ian > (warning, cut-n-paste patch.. will not apply) > > Index: rc.firewall > =================================================================== > --- rc.firewall (revision 184948) > +++ rc.firewall (working copy) > @@ -231,19 +231,24 @@ > ${fwcmd} add deny all from ${onet} to any in via ${iif} > > # Stop RFC1918 nets on the outside interface > - ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} > - ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} > - ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} > + ${fwcmd} table 1 add 10.0.0.0/8 > + ${fwcmd} table 1 add 172.16.0.0/12 > + ${fwcmd} table 1 add 192.168.0.0/16 > > # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > RESERVED-1, > # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class > E) > # on the outside interface > - ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} > - ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} > - ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} > - ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} > - ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} > + ${fwcmd} table 1 add 0.0.0.0/8 > + ${fwcmd} table 1 add 169.254.0.0/16 > + ${fwcmd} table 1 add 192.0.2.0/24 > + ${fwcmd} table 1 add 224.0.0.0/4 > + ${fwcmd} table 1 add 240.0.0.0/4 > > + # Stop the above nets with the table > + > + ${fwcmd} add deny all from any to "table(1)" via ${oif} > + > + > # Network Address Translation. This rule is placed here deliberately > # so that it does not interfere with the surrounding address-checking > # rules. If for example one of your internal LAN machines had its IP > @@ -260,19 +265,8 @@ > esac > > # Stop RFC1918 nets on the outside interface > - ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} > - ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} > - ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} > + ${fwcmd} add deny all from "table(1)" to any via ${oif} > > - # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > RESERVED-1, > - # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class > E) > - # on the outside interface > - ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} > - ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} > - ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} > - ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} > - ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} > - > # Allow TCP through if setup succeeded > ${fwcmd} add pass tcp from any to any established > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 08:31:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7AD81065675; Fri, 14 Nov 2008 08:31:26 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9EA8FC17; Fri, 14 Nov 2008 08:31:26 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.45]) by smtp-outbound.ironport.com with ESMTP; 14 Nov 2008 00:31:26 -0800 Message-ID: <491D375D.1070809@elischer.org> Date: Fri, 14 Nov 2008 00:31:25 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Ian Smith References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> In-Reply-To: <20081114133913.K70117@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: rc.firewall quick change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 08:31:26 -0000 Ian Smith wrote: > On Thu, 13 Nov 2008, Julian Elischer wrote: > > At home I use the following change. > > > > > > basically, instead of doing 8 rules before and after the nat, > > use a table and to 1 rule on each side. > > > > > > any objections? > > Only that if people are already using tables for anything, chances are > they've already used table 1 (well, it's the first one I used :) How > about using table 127 for this as a rather less likely prior choice? yes I thought of that.. in fact it should be ${BLOCKTABLE} and let the user define what he wants. (defaulting to 99 or something). Remember though that a user wouldn't be using 'simple' if he's using his own tables etc. > > Apart from that, this will speed up 'simple' on a path every packet > takes, which has to be a good thing. > > While I'm at it, I'll offer my own rc.firewall patch again in the > following message. Perhaps you'd care to review it in this context? > > cheers, Ian > > > (warning, cut-n-paste patch.. will not apply) > > > > Index: rc.firewall > > =================================================================== > > --- rc.firewall (revision 184948) > > +++ rc.firewall (working copy) > > @@ -231,19 +231,24 @@ > > ${fwcmd} add deny all from ${onet} to any in via ${iif} > > > > # Stop RFC1918 nets on the outside interface > > - ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} > > - ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} > > - ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} > > + ${fwcmd} table 1 add 10.0.0.0/8 > > + ${fwcmd} table 1 add 172.16.0.0/12 > > + ${fwcmd} table 1 add 192.168.0.0/16 > > > > # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > > RESERVED-1, > > # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class > > E) > > # on the outside interface > > - ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} > > - ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} > > - ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} > > - ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} > > - ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} > > + ${fwcmd} table 1 add 0.0.0.0/8 > > + ${fwcmd} table 1 add 169.254.0.0/16 > > + ${fwcmd} table 1 add 192.0.2.0/24 > > + ${fwcmd} table 1 add 224.0.0.0/4 > > + ${fwcmd} table 1 add 240.0.0.0/4 > > > > + # Stop the above nets with the table > > + > > + ${fwcmd} add deny all from any to "table(1)" via ${oif} > > + > > + > > # Network Address Translation. This rule is placed here deliberately > > # so that it does not interfere with the surrounding address-checking > > # rules. If for example one of your internal LAN machines had its IP > > @@ -260,19 +265,8 @@ > > esac > > > > # Stop RFC1918 nets on the outside interface > > - ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} > > - ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} > > - ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} > > + ${fwcmd} add deny all from "table(1)" to any via ${oif} > > > > - # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > > RESERVED-1, > > - # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class > > E) > > - # on the outside interface > > - ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} > > - ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} > > - ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} > > - ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} > > - ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} > > - > > # Allow TCP through if setup succeeded > > ${fwcmd} add pass tcp from any to any established > > > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 09:10:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF67F106564A; Fri, 14 Nov 2008 09:10:08 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 9F4878FC08; Fri, 14 Nov 2008 09:10:08 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.45]) by smtp-outbound.ironport.com with ESMTP; 14 Nov 2008 01:10:08 -0800 Message-ID: <491D406F.5030806@elischer.org> Date: Fri, 14 Nov 2008 01:10:07 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Ian Smith References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> In-Reply-To: <491D375D.1070809@elischer.org> Content-Type: multipart/mixed; boundary="------------030006060207050901060508" Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: rc.firewall quick change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 09:10:09 -0000 This is a multi-part message in MIME format. --------------030006060207050901060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Julian Elischer wrote: > Ian Smith wrote: >> On Thu, 13 Nov 2008, Julian Elischer wrote: >> > At home I use the following change. >> > > > basically, instead of doing 8 rules before and after the nat, >> > use a table and to 1 rule on each side. >> > > > any objections? >> >> Only that if people are already using tables for anything, chances are >> they've already used table 1 (well, it's the first one I used :) How >> about using table 127 for this as a rather less likely prior choice? > > yes I thought of that.. > in fact it should be ${BLOCKTABLE} and let the user define what he > wants. (defaulting to 99 or something). > Remember though that a user wouldn't be using 'simple' if he's using his > own tables etc. > so here's a slightly improved diff: --------------030006060207050901060508 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="ipfw.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipfw.diff" Index: rc.firewall =================================================================== --- rc.firewall (revision 184948) +++ rc.firewall (working copy) @@ -216,11 +216,13 @@ # firewall_simple_inet: Inside network address. # firewall_simple_oif: Outside network interface. # firewall_simple_onet: Outside network address. + # firewall_block_table: Table to use blocking stuff. ############ # set these to your outside interface network oif="$firewall_simple_oif" onet="$firewall_simple_onet" + tbl=${firewall_block_table:-99} # set these to your inside interface network iif="$firewall_simple_iif" @@ -231,19 +233,24 @@ ${fwcmd} add deny all from ${onet} to any in via ${iif} # Stop RFC1918 nets on the outside interface - ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} - ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} - ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} + ${fwcmd} table ${tbl} add 10.0.0.0/8 + ${fwcmd} table ${tbl} add 172.16.0.0/12 + ${fwcmd} table ${tbl} add 192.168.0.0/16 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) # on the outside interface - ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} - ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} - ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} - ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} - ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} + ${fwcmd} table ${tbl} add 0.0.0.0/8 + ${fwcmd} table ${tbl} add 169.254.0.0/16 + ${fwcmd} table ${tbl} add 192.0.2.0/24 + ${fwcmd} table ${tbl} add 224.0.0.0/4 + ${fwcmd} table ${tbl} add 240.0.0.0/4 + # Stop the above nets with the table + + ${fwcmd} add deny all from any to "table(${tbl})" via ${oif} + + # Network Address Translation. This rule is placed here deliberately # so that it does not interfere with the surrounding address-checking # rules. If for example one of your internal LAN machines had its IP @@ -260,19 +267,8 @@ esac # Stop RFC1918 nets on the outside interface - ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} - ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} - ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} + ${fwcmd} add deny all from "table(${tbl})" to any via ${oif} - # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, - # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) - # on the outside interface - ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} - ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} - ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} - ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} - ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} - # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established --------------030006060207050901060508-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 10:38:29 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E67FF1065674; Fri, 14 Nov 2008 10:38:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 382A78FC1A; Fri, 14 Nov 2008 10:38:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mAEAM3PT022097; Fri, 14 Nov 2008 21:22:03 +1100 Received: from c122-106-151-199.carlnfd1.nsw.optusnet.com.au (c122-106-151-199.carlnfd1.nsw.optusnet.com.au [122.106.151.199]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mAEALt9I015701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2008 21:21:58 +1100 Date: Fri, 14 Nov 2008 21:21:55 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Julian Elischer In-Reply-To: <491D375D.1070809@elischer.org> Message-ID: <20081114211043.W54700@delplex.bde.org> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net , ipfw@FreeBSD.org, Ian Smith Subject: Re: rc.firewall quick change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 10:38:30 -0000 On Fri, 14 Nov 2008, Julian Elischer wrote: > Ian Smith wrote: >> On Thu, 13 Nov 2008, Julian Elischer wrote: >> > At home I use the following change. >> > > > basically, instead of doing 8 rules before and after the nat, >> > use a table and to 1 rule on each side. >> > > > any objections? >> >> Only that if people are already using tables for anything, chances are >> they've already used table 1 (well, it's the first one I used :) How about >> using table 127 for this as a rather less likely prior choice? > > yes I thought of that.. Separate rules provide more statistics. > in fact it should be ${BLOCKTABLE} and let the user define what he wants. > (defaulting to 99 or something). I use shell variables giving lists of interfaces to be blocked so that there aren't very many rules: %%% rfc1918n=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 dmanningn=0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 ${fwcmd} add deny log all from any to ${rfc1918n} via ${oif} ${fwcmd} add deny log all from any to ${dmanningn} via ${oif} ... (divert rule) ${fwcmd} add deny log all from ${rfc1918n} to any via ${oif} ${fwcmd} add deny log all from ${dmanningn} to any via ${oif} %%% I use separate lists mainly for documentation purposes but they also provide separate statistics. > Remember though that a user wouldn't be using 'simple' if he's using his own > tables etc. Separate rules are also simplest for documentation purposes. >> Apart from that, this will speed up 'simple' on a path every packet takes, >> which has to be a good thing. Are tables faster than lists of addresses? I would expect lists to be slightly more efficient. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 11:43:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C10E1065670 for ; Fri, 14 Nov 2008 11:43:51 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from n6.bullet.mud.yahoo.com (n6.bullet.mud.yahoo.com [216.252.100.57]) by mx1.freebsd.org (Postfix) with SMTP id 3DD0F8FC0C for ; Fri, 14 Nov 2008 11:43:51 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from [68.142.200.226] by n6.bullet.mud.yahoo.com with NNFMP; 14 Nov 2008 11:30:11 -0000 Received: from [68.142.201.243] by t7.bullet.mud.yahoo.com with NNFMP; 14 Nov 2008 11:30:10 -0000 Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 14 Nov 2008 11:30:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 883409.55532.bm@omp404.mail.mud.yahoo.com Received: (qmail 77148 invoked by uid 60001); 14 Nov 2008 11:30:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=eEq/RjgdiNSv3WojhDEJfT44+SJjHfM0Tw9mP+9huVEdJLskq1UfUbv3u1Sw7ILl7B1F9UhGR7i53vBSvi00XmJixZ6fsuUIewXEGWlJhJMsyPDSx/oZqPWo94IxPlCGjVa4KObI0nmvm0cdU161gkLahWqovJ2nZd/jd4j8HzI=; X-YMail-OSG: pz_Ei3kVM1nqJS_7_q7b9SlPAnBH51L5eHd5kISihmCJ9g3DFMlnS7wlpPMhkDKpZE2hG8Xvgy2aO178VCIGc.2uqdrPzQVRfYHynhMJTgzkRiDULEZjmL5uKnwbH8a.ePvkBr3ykuCmp7EVdNR40eqAPBs- Received: from [58.71.34.137] by web45809.mail.sp1.yahoo.com via HTTP; Fri, 14 Nov 2008 03:30:10 PST X-Mailer: YahooMailRC/1155.20 YahooMailWebService/0.7.260.1 Date: Fri, 14 Nov 2008 03:30:10 -0800 (PST) From: Won De Erick To: Jeremy Chadwick MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <305614.76266.qm@web45809.mail.sp1.yahoo.com> X-Mailman-Approved-At: Fri, 14 Nov 2008 12:19:57 +0000 Cc: freebsd-net@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 11:43:51 -0000 > ----- Original Message ---- > From: Won De Erick > To: Jeremy Chadwick > Cc: freebsd-hardware@freebsd.org > Sent: Thursday, November 13, 2008 4:07:37 PM > Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage > > Noted on this, I will update you through this thread. With FreeBSD 7.1 Beta2, here is the result: 52 root 1 -68 - 0K 16K CPU11 b 38:43 95.36% irq32: bce1 51 root 1 -68 - 0K 16K CPU10 a 25:50 85.16% irq31: bce0 There's a slight difference w/ the previous result though, but I observed that overall CPU utilization didn't change. ### Complete result: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 21 root 1 171 ki31 0K 16K CPU5 5 91:29 100.00% idle: cpu5 14 root 1 171 ki31 0K 16K CPU12 c 91:29 100.00% idle: cpu12 22 root 1 171 ki31 0K 16K CPU4 4 91:29 100.00% idle: cpu4 17 root 1 171 ki31 0K 16K CPU9 9 91:28 100.00% idle: cpu9 12 root 1 171 ki31 0K 16K CPU14 e 91:27 100.00% idle: cpu14 23 root 1 171 ki31 0K 16K CPU3 3 90:58 100.00% idle: cpu3 25 root 1 171 ki31 0K 16K CPU1 1 86:41 100.00% idle: cpu1 19 root 1 171 ki31 0K 16K CPU7 7 84:00 100.00% idle: cpu7 24 root 1 171 ki31 0K 16K CPU2 2 83:53 100.00% idle: cpu2 18 root 1 171 ki31 0K 16K CPU8 8 79:01 100.00% idle: cpu8 26 root 1 171 ki31 0K 16K RUN 0 74:18 100.00% idle: cpu0 11 root 1 171 ki31 0K 16K CPU15 0 0:00 100.00% idle: cpu15 13 root 1 171 ki31 0K 16K CPU13 0 0:00 100.00% idle: cpu13 20 root 1 171 ki31 0K 16K CPU6 6 90:18 99.27% idle: cpu6 52 root 1 -68 - 0K 16K CPU11 b 38:43 95.36% irq32: bce1 51 root 1 -68 - 0K 16K CPU10 a 25:50 85.16% irq31: bce0 16 root 1 171 ki31 0K 16K RUN a 65:39 15.97% idle: cpu10 28 root 1 -32 - 0K 16K WAIT 8 12:28 5.18% swi4: clock sio 15 root 1 171 ki31 0K 16K RUN b 52:46 3.76% idle: cpu11 45 root 1 -64 - 0K 16K WAIT 7 7:29 1.17% irq17: uhci0 47 root 1 -64 - 0K 16K WAIT 6 1:11 0.10% irq16: ciss0 Is there some ways how the intensive [network] load can be distributed among the IDLE processors? Another thing, I observed that in the above test, the net.isr is enabled by default. When I tried disabling this, # sysctl net.isr.direct=0 net.isr.direct: 1 -> 0 the result: 52 root 1 -68 - 0K 16K WAIT b 64:00 42.97% irq32: bce1 51 root 1 -68 - 0K 16K WAIT a 38:22 12.26% irq31: bce0 The CPU utilizations considerably dropped! What was changed in the fbsd7.1? How useful this net.isr is? Is this needed in an environment with heavy network traffic? Can someone explain? > However is there any possibility of the following: > > > I don't know if there's a way to split the interrupt request for each bce's Rx and Tx, > > which means a total of four IRQs, and eventually four cores (or 4 CPUs) > > for the transactions. With this way, the IDLE processors would be utilized. > > What I mean here is, for the two interfaces: > > one IRQ for bce0 Rx > one IRQ for bce0 Tx > one IRQ for bce1 Rx > one IRQ for bce1 Tx > > > Thanks, > > Won > > > > ________________________________ > From: Jeremy Chadwick > To: Won De Erick > Cc: freebsd-hardware@freebsd.org > Sent: Thursday, November 13, 2008 3:46:02 PM > Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage > > On Wed, Nov 12, 2008 at 11:38:15PM -0800, Won De Erick wrote: > > I am conducting a CPU utilization testing with my box(HP DL 585 running FreeBSD 7.0), and come up with the results below: > > > > 52 root 1 -68 - 0K 16K CPU11 b 123:53 100.00% irq32: bce1 > > 51 root 1 -68 - 0K 16K CPU10 a 119:28 89.06% irq31: bce0 > > > > irq31 and irq32 are consuming high CPU usage, which i think the cause of hard reset. > > There was a ***major*** bce(4) cleanup that just happened. Your 7.0 box > will not have these changes. Please upgrade your box to RELENG_7 > (a.k.a. 7.1-PRERELEASE), csup'd recently (today preferably), and try > your tests again: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-November/046482.html > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 12:20:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C6C4106564A; Fri, 14 Nov 2008 12:20:02 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by mx1.freebsd.org (Postfix) with ESMTP id 378398FC13; Fri, 14 Nov 2008 12:20:02 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=IwbhOQ6H4EBtyGj5jBbKA4fUMaG4rq59hhK5YLhV6UQMcU4sBlIGQX1glIlGLTmQ; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L0xeZ-0000AJ-52; Fri, 14 Nov 2008 07:19:59 -0500 Message-ID: <491D6CED.50006@earthlink.net> Date: Fri, 14 Nov 2008 07:19:57 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: sclark46@earthlink.net References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> In-Reply-To: <491C4EC2.2000802@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79345431f6a6dfb6738d00235df17b1d8d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Cc: freebsd-net@freebsd.org, FreeBSD Stable , Julian Elischer , Robert Noland Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 12:20:02 -0000 Stephen Clark wrote: > Robert Noland wrote: >> On Thu, 2008-11-13 at 07:48 -0500, Stephen Clark wrote: >>> Julian Elischer wrote: >>>> Stephen Clark wrote: >>>>> Julian Elischer wrote: >>>>>> you will need to define the setup and question better. >>>> thanks.. cleaning it up a bit more... >>>> >>>> 10.0.129.1 FreeBSD workstation >>>> ^ >>>> | >>>> | ethernet >>>> | >>>> v >>>> 10.0.128.1 Freebsd FW "A" >>>> ^ >>>> | >>>> | gre / ipsec >>>> | >>>> v >>>> 192.168.3.1 FreeBSD FW "B" >>>> ^ >>>> | >>>> | ethernet >>>> | >>>> v >>>> 192.168.3.86 linux workstation >>>> >>>>> $ sudo traceroute 192.168.3.86 >>>>> traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte >>>>> packets >>>>> 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms >>>>> 2 * * * >>>>> 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms >>>>> >>>>> No response from the FreeBSD "B" box. >>>>> >>>>> When I do a tcpdump on "B" of the gre interface I see UDP packets >>>>> with a TTL of 1 but no ICMP response packets being sent back. >>>>> If I do the traceroute from the linux workstation 192.168.3.86 I get >>>>> similar results - I don't see a response from the FreeBSD "A" box. >>>> could you try using just GRE encasulation? >>>> (i.e. turn off IPSEC for now) >>>> >>>> I think that is much more likely to be where the problem is.. >>>> >>>> >>> I'll have to set this up to test it. >> >> The ttl exceeded is triggered from one of two places. Either >> netinet/ip_fastfwd.c if fast_forwarding is enabled or in >> netinet/ip_input.c. Look for the code relating to IPTTLDEC. This isn't >> your problem though... If ttl were not being decremented, the packet >> would just be forwarded on to the next hop (IP_STEALTH), which would >> just make the firewalls invisible. The fact that you are seeing * * * >> indicates that you are not receiving the ttl exceeded message for the >> packet sent with that particular ttl. I still think that the issue you >> are seeing is that one way or another the generated ICMP response isn't >> making it back onto the tunnel. Either via security policy, firewall or >> routing. > Your right, when I do a tcpdump on the gre interface I see the udp > packet come > in with a ttl=1 but I don't see a response icmp packet. I have tested > this with > all the firewalls disabled to make sure the icmp packet was not being > blocked. > I just ran another test and did tcpdump on all the other interfaces to > make sure > the icmp's were not being misrouted, it seems they are not being > generated for some reason. Also just using gre's without the underlying > ipsec tunnels seems to > work properly. >> >> robert. >> >>> What code in the FreeBSD kernel is responsible for generating the >>> response ICMP dest unreachable message? >>> > > Another data point I had been using option FILTER_GIF I tried a kernel without that option and it behaved the same. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 12:58:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3184D106567B for ; Fri, 14 Nov 2008 12:58:59 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from n70.bullet.mail.sp1.yahoo.com (n70.bullet.mail.sp1.yahoo.com [98.136.44.38]) by mx1.freebsd.org (Postfix) with SMTP id 191828FC0C for ; Fri, 14 Nov 2008 12:58:59 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from [69.147.65.171] by n70.bullet.mail.sp1.yahoo.com with NNFMP; 14 Nov 2008 12:46:39 -0000 Received: from [69.147.65.154] by t13.bullet.mail.sp1.yahoo.com with NNFMP; 14 Nov 2008 12:46:39 -0000 Received: from [127.0.0.1] by omp402.mail.sp1.yahoo.com with NNFMP; 14 Nov 2008 12:46:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 766365.41122.bm@omp402.mail.sp1.yahoo.com Received: (qmail 71360 invoked by uid 60001); 14 Nov 2008 12:46:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=6SZdsnWb9tYh24v7/F/vKd/tkRDS+iD50DG27BzgJsbrBwSRfveJ9iEvarhFuMFGU9B7MKuJKZ13neXgowUWD7hCOfbMErVBEdcebB5+y1LUQvbZ/A5WM4rwwA02fJU8Ni3kY5NC7y+Ymrjz95GfQZwaxuxN7wRObvb4/xFp2yI=; X-YMail-OSG: 9fVYlgQVM1kft5b2vXyxbzjOsOWq_9W92k.C_b5_3wwls5U3y2K73ig5HyxWPpSeUbKZf9w.bZZAp4U8dGqi7g54olZ8NigT1ijtmqSVCDooE6o65AMg29bghtUCFWzUkG89DI7TKIlr4V_4xwTVcdg0eBc- Received: from [58.71.34.137] by web45806.mail.sp1.yahoo.com via HTTP; Fri, 14 Nov 2008 04:46:39 PST X-Mailer: YahooMailRC/1155.20 YahooMailWebService/0.7.260.1 References: <305614.76266.qm@web45809.mail.sp1.yahoo.com> Date: Fri, 14 Nov 2008 04:46:39 -0800 (PST) From: Won De Erick To: Ivan Voras , freebsd-hardware@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <555333.76711.qm@web45806.mail.sp1.yahoo.com> X-Mailman-Approved-At: Fri, 14 Nov 2008 13:04:56 +0000 Cc: freebsd-net@freebsd.org Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 12:58:59 -0000 > ----- Original Message ----=0A=0A> From: Ivan Voras = =0A> To: freebsd-hardware@freebsd.org=0A> Cc: freebsd-net@freebsd.org=0A> S= ent: Friday, November 14, 2008 7:49:13 PM=0A> Subject: Re: IRQ31 and IRQ32 = on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage=0A> =0A> Won De= Erick wrote:=0A> =0A> > Another thing, I observed that in the above test, = the net.isr is enabled by default. When I tried disabling this,=0A> > =0A> = > # sysctl net.isr.direct=3D0=0A> > net.isr.direct: 1 -> 0=0A> > =0A> > the= result:=0A> > =0A> > 52 root 1 -68 - 0K 16K WAIT b 64:= 00 42.97% irq32: bce1=0A> > 51 root 1 -68 - 0K 16K WAIT = a 38:22 12.26% irq31: bce0=0A> > =0A> > The CPU utilizations considerably = dropped!=0A> =0A> You will probably find a "swi" process that has picked up= the difference=0A> (when isr.direct is disabled, some of network protocol = processing is=0A> offloaded to a swi thread). This might help spread the lo= ad across CPU=0A> but in my testing it didn't help real-world throughput.= =0A>=0A=0AYou are right. I noticed the following when net.isr is diabled, l= owering the idle time of cpu0.=0A=0A 27 root 1 -44 - 0K = 16K WAIT 0 52:20 76.37% swi1: net=0A 26 root 1 171 ki31 0K = 16K CPU0 0 111:58 64.36% idle: cpu0=0A=0A=0AAnother thing,=0APacket dr= ops on Intel NIC ( Intel=AE PRO/1000 PT Dual Port Server Adapter w/ control= processor 82571GB) did not occur when the net.isr was disabled, while the = overall CPU utilization remains considerably low.=0A=0ANote: The following = result was obtained during a transition from a disabled to enabled net.isr.= Hence the first part=0A=0Apackets errs bytes packets errs b= ytes colls drops=0A 10844 0 15603850 7940 0 582934 = 0 0=0A 11659 0 16800328 8503 0 630330 0= 0=0A 11778 0 17033560 8998 0 677934 0 = 0=0A 12149 0 17592134 9504 0 728094 0 0=0A = 12551 0 18223550 9974 0 774164 0 0=0A 1= 3127 0 19093604 10413 0 811858 0 0=0A 13712 = 0 20010140 10924 0 848014 0 0=0A 14499 0= 21153538 11407 0 878252 0 0=0A 14818 0 21= 740270 11979 0 915374 0 0=0A 15831 0 2313644= 6 12376 0 950636 0 0=0A 15912 0 23365454 = 12852 0 997242 0 0=0A 16257 0 23848866 132= 82 0 1041878 0 0=0A 16384 0 24084782 13666 = 0 1079790 0 0=0A 16670 0 24508980 14078 0 = 1106886 0 0=0A 17845 0 26255548 14486 0 113= 4700 0 0=0A 18097 0 26705634 15064 0 1163308 = 0 0=0A 18470 0 27283000 15365 0 1198828 0= 0=0A 18139 0 26842676 15596 0 1225540 0 = 0=0A 18792 0 27799564 16000 0 1264568 0 0=0A = 17854 178 26454106 16521 0 1298714 0 0=0A 1= 6741 1542 24820298 16770 0 1343328 0 0=0A = input (em0) output=0A packets errs bytes pac= kets errs bytes colls drops=0A 15288 1667 22683486 17231 = 0 1422690 0 0=0A 15539 1718 23250372 17282 0= 1495058 0 0=0A 14379 545 21541954 17364 0 1= 508696 0 0=0A 14312 1733 21546776 17276 0 150337= 2 0 0=0A 14269 1744 21498908 17516 0 1508294 = 0 0=0A 14444 1729 21766812 17175 0 1482130 0 = 0=0A 15023 1724 22643198 16987 0 1432048 0 0= =0A 15279 1703 23036294 16909 0 1395094 0 0=0A = 15325 1701 23118536 16938 0 1380268 0 0=0A 15= 572 1684 23494362 16909 0 1344214 0 0=0A 15798 = 1699 23845972 16857 0 1303200 0 0=0A 16195 1683 = 24497790 17059 0 1291586 0 0=0A 16431 1674 248= 51278 16826 0 1245320 0 0=0A 16683 1643 25231910= 16675 0 1204450 0 0=0A 16728 1647 25302534 = 16672 0 1178930 0 0=0A 16826 1649 25455662 1666= 2 0 1178140 0 0=0A 16760 1653 25352830 16480 = 0 1161086 0 0=0A 17002 1634 25720672 16423 0 = 1143508 0 0=0A 16943 1643 25629892 16642 0 1160= 858 0 0=0A 16995 1644 25708823 16539 0 1153782 = 0 0=0A 17026 1643 25758462 16606 0 1153342 0 = 0=0A=0AHowever, network throughput didn't change in the two scenarios a= bove.=0AIs there anything that I can test to improve my network throughput.= =0A=0AThanks,=0A=0AWon=0A=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 13:14:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B4C4106567D for ; Fri, 14 Nov 2008 13:14:14 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from n59.bullet.mail.sp1.yahoo.com (n59.bullet.mail.sp1.yahoo.com [98.136.44.43]) by mx1.freebsd.org (Postfix) with SMTP id 1144D8FC18 for ; Fri, 14 Nov 2008 13:14:13 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from [69.147.65.171] by n59.bullet.mail.sp1.yahoo.com with NNFMP; 14 Nov 2008 13:14:13 -0000 Received: from [69.147.84.34] by t13.bullet.mail.sp1.yahoo.com with NNFMP; 14 Nov 2008 13:14:13 -0000 Received: from [127.0.0.1] by omp210.mail.sp1.yahoo.com with NNFMP; 14 Nov 2008 13:14:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 843272.49549.bm@omp210.mail.sp1.yahoo.com Received: (qmail 7387 invoked by uid 60001); 14 Nov 2008 13:14:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=bFhWQ2GM3juB3+Jus3z0xAjeneHicjhzNi9YY5Mx5oRdGqepMTudFkB5c3mGhCjw/1dwlmb7rTnABcZK76gZx3Oh+znAJjBtRqKQR5VqpbWOIp3s13w5Xx8ofdoSYodoMyuGQyU74CfwvPpmvSZCLqGBJhiMROuEhFZQ15UUcUM=; X-YMail-OSG: ONhFMVkVM1naSNJhlt2e6USwxXd.S8GC0Ju.F6gok7TloSoqrUYZe.6_MS6Gi9.wSKg2IAteFYjIcK1N1veTPYutw8n44gz1IrWHmPTbPjJM.hR9Bl7CisKPmwrYMlGSrTDfnDI2Wr1bmY9kBIz8cwjQGoM- Received: from [58.71.34.137] by web45801.mail.sp1.yahoo.com via HTTP; Fri, 14 Nov 2008 05:14:13 PST X-Mailer: YahooMailRC/1155.20 YahooMailWebService/0.7.260.1 References: <305614.76266.qm@web45809.mail.sp1.yahoo.com> <555333.76711.qm@web45806.mail.sp1.yahoo.com> Date: Fri, 14 Nov 2008 05:14:13 -0800 (PST) From: Won De Erick To: Ivan Voras , freebsd-hardware@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <674901.2796.qm@web45801.mail.sp1.yahoo.com> X-Mailman-Approved-At: Fri, 14 Nov 2008 14:10:36 +0000 Cc: freebsd-net@freebsd.org Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 13:14:14 -0000 > From: Ivan Voras =0A=0A> To: freebsd-hardware@freebsd= ..org=0A> Cc: freebsd-net@freebsd.org=0A> Sent: Friday, November 14, 2008 8:= 55:13 PM=0A> Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 ar= e consuming HIGH CPU usage=0A> =0A> Won De Erick wrote:=0A> =0A> > 170= 02 1634 25720672 16423 0 1143508 0 0=0A> > 1694= 3 1643 25629892 16642 0 1160858 0 0=0A> > 16995= 1644 25708823 16539 0 1153782 0 0=0A> > 17026 = 1643 25758462 16606 0 1153342 0 0=0A> =0A> What do y= ou use for generating the traffic?=0A> =0A=0AI used w-get in bombarding tcp= traffic w/ thousand of sessions.=0A=0A> > However, network throughput didn= 't change in the two scenarios above.=0A> > Is there anything that I can te= st to improve my network throughput.=0A> =0A> I'm not sure but you could ma= ybe try disabling all but one of your CPUs=0A> and see if anything changes.= It looks like you have at least 16 CPUs. On=0A> my machine, with 8 CPUs (2= xquad core) I get roughly 150,000 PPS before I=0A> hit a similar single-CPU= -bound network processing bottleneck (also with=0A> Intel=AE PRO/1000 PT/Se= rver) - which is too low for my needs so I'm=0A> searching for a solution. = In my case I don't see transmission errors.=0A=0Awill try this.=0A=0A=0A=0A= From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 18:16:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBD8C106567A; Fri, 14 Nov 2008 18:16:27 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id C8E298FC13; Fri, 14 Nov 2008 18:16:27 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 14 Nov 2008 10:16:28 -0800 Message-ID: <491DC07B.6070304@elischer.org> Date: Fri, 14 Nov 2008 10:16:27 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Bruce Evans References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <20081114211043.W54700@delplex.bde.org> In-Reply-To: <20081114211043.W54700@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@FreeBSD.org, Ian Smith Subject: Re: rc.firewall quick change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 18:16:28 -0000 Bruce Evans wrote: > On Fri, 14 Nov 2008, Julian Elischer wrote: > >> Ian Smith wrote: >>> On Thu, 13 Nov 2008, Julian Elischer wrote: >>> > At home I use the following change. >>> > > > basically, instead of doing 8 rules before and after the nat, >>> > use a table and to 1 rule on each side. >>> > > > any objections? >>> >>> Only that if people are already using tables for anything, chances >>> are they've already used table 1 (well, it's the first one I used :) >>> How about using table 127 for this as a rather less likely prior choice? >> >> yes I thought of that.. > > Separate rules provide more statistics. true but generally people don't need to distinguish between those, and if you do then you probably want to log them. > >> in fact it should be ${BLOCKTABLE} and let the user define what he >> wants. (defaulting to 99 or something). > > I use shell variables giving lists of interfaces to be blocked so that > there aren't very many rules: > > %%% > rfc1918n=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 > dmanningn=0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 > > ${fwcmd} add deny log all from any to ${rfc1918n} via ${oif} > ${fwcmd} add deny log all from any to ${dmanningn} via ${oif} > > ... (divert rule) > > ${fwcmd} add deny log all from ${rfc1918n} to any via ${oif} > ${fwcmd} add deny log all from ${dmanningn} to any via ${oif} > %%% > > I use separate lists mainly for documentation purposes but they also > provide separate statistics. > >> Remember though that a user wouldn't be using 'simple' if he's using >> his own tables etc. > > Separate rules are also simplest for documentation purposes. > >>> Apart from that, this will speed up 'simple' on a path every packet >>> takes, which has to be a good thing. > > Are tables faster than lists of addresses? I would expect lists to be > slightly more efficient. I think the table is faster for mor ethan about 8 addresses (so we are borderline) but it's be hard to test.. You however use two rules so that would be slower. In my sites I tend to have other stuff put in those tables too > > Bruce From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 18:25:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EE5D106567A for ; Fri, 14 Nov 2008 18:25:37 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id DFC648FC0C for ; Fri, 14 Nov 2008 18:25:36 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 14 Nov 2008 10:25:18 -0800 Message-ID: <491DC28E.80804@elischer.org> Date: Fri, 14 Nov 2008 10:25:18 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: sclark46@earthlink.net References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> In-Reply-To: <491D6CED.50006@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, FreeBSD Stable , Robert Noland Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 18:25:37 -0000 Stephen Clark wrote: > Stephen Clark wrote: >>>>> >>>>> 10.0.129.1 FreeBSD workstation >>>>> ^ >>>>> | >>>>> | ethernet >>>>> | >>>>> v >>>>> 10.0.128.1 Freebsd FW "A" >>>>> ^ >>>>> | >>>>> | gre / ipsec >>>>> | >>>>> v >>>>> 192.168.3.1 FreeBSD FW "B" >>>>> ^ >>>>> | >>>>> | ethernet >>>>> | >>>>> v >>>>> 192.168.3.86 linux workstation >>>>> >> Also just using gre's without the >> underlying ipsec tunnels seems to >> work properly. This is the crux of the matter. IPSEC happens INSIDE the IP stack. The IP stack is responsible for the ICMP generation so it is much more likely that there is an interaction there. Now is there an IPSEC rule to make sure that the ICMP packet can get back? It could b ehtat in teh IP stack there is some confusion as to whether the return packet should be encrypted or not and it might get dropped. the code involved is in /sys/netinet and /sys/netipsec but you'll probably regret looking in there ;-) >> >> > Another data point I had been using option FILTER_GIF I tried a kernel > without that option and it behaved the same. > > Steve > From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 18:37:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F4A31065673; Fri, 14 Nov 2008 18:37:03 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by mx1.freebsd.org (Postfix) with ESMTP id F0ACA8FC16; Fri, 14 Nov 2008 18:37:02 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=f1MKOuXTBLm+ZKI7xMLkhZ10seC+RYKdxOVJkCpaYoxJLOW3Ai8tP69kgyKR8U5R; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L13XP-0006Rw-OF; Fri, 14 Nov 2008 13:36:59 -0500 Message-ID: <491DC54A.1090907@earthlink.net> Date: Fri, 14 Nov 2008 13:36:58 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Julian Elischer References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> In-Reply-To: <491DC28E.80804@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec7902bd0cf6eff9e584ec18d5e033017cb2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Cc: freebsd-net@freebsd.org, FreeBSD Stable , Robert Noland Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 18:37:03 -0000 Julian Elischer wrote: > Stephen Clark wrote: >> Stephen Clark wrote: > >>>>>> >>>>>> 10.0.129.1 FreeBSD workstation >>>>>> ^ >>>>>> | >>>>>> | ethernet >>>>>> | >>>>>> v >>>>>> 10.0.128.1 Freebsd FW "A" >>>>>> ^ >>>>>> | >>>>>> | gre / ipsec >>>>>> | >>>>>> v >>>>>> 192.168.3.1 FreeBSD FW "B" >>>>>> ^ >>>>>> | >>>>>> | ethernet >>>>>> | >>>>>> v >>>>>> 192.168.3.86 linux workstation >>>>>> > >>> Also just using gre's without the underlying ipsec tunnels seems to >>> work properly. > > > This is the crux of the matter. > IPSEC happens INSIDE the IP stack. The IP stack is responsible for > the ICMP generation so it is much more likely that there is an > interaction there. > > Now is there an IPSEC rule to make sure that the ICMP packet can get > back? It could b ehtat in teh IP stack there is some confusion as to > whether the return packet should be encrypted or not and it might get > dropped. > > the code involved is in /sys/netinet and /sys/netipsec but you'll > probably regret looking in there ;-) > > > >>> >>> >> Another data point I had been using option FILTER_GIF I tried a kernel >> without that option and it behaved the same. >> >> Steve >> > I agree I put a diag in ip_input.c if (ip->ip_ttl <= IPTTLDEC) { icmp_error(m, ICMP_TIMXCEED, ICMP_TIMXCEED_INTRANS, 0, 0); return; and sure enough it is calling icmp_error, but I think it can't figure out how to route the packet back. I been looking at my SPD to see if I can make some adjustment to the policy that would help. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 18:42:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21DA2106567A for ; Fri, 14 Nov 2008 18:42:54 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id CA4AF8FC0A for ; Fri, 14 Nov 2008 18:42:53 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.166.46] ([68.0.14.34]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id mAEIgcLL000454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Nov 2008 13:42:38 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Julian Elischer In-Reply-To: <491DC28E.80804@elischer.org> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-tc069wmrKhgBioXbSO26" Organization: FreeBSD Date: Fri, 14 Nov 2008 13:42:33 -0500 Message-Id: <1226688153.1719.23.camel@squirrel.corp.cox.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: sclark46@earthlink.net, FreeBSD Stable , freebsd-net@freebsd.org Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 18:42:54 -0000 --=-tc069wmrKhgBioXbSO26 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2008-11-14 at 10:25 -0800, Julian Elischer wrote: > Stephen Clark wrote: > > Stephen Clark wrote: >=20 > >>>>> > >>>>> 10.0.129.1 FreeBSD workstation > >>>>> ^ > >>>>> | > >>>>> | ethernet > >>>>> | > >>>>> v > >>>>> 10.0.128.1 Freebsd FW "A" > >>>>> ^ > >>>>> | > >>>>> | gre / ipsec > >>>>> | > >>>>> v > >>>>> 192.168.3.1 FreeBSD FW "B" > >>>>> ^ > >>>>> | > >>>>> | ethernet > >>>>> | > >>>>> v > >>>>> 192.168.3.86 linux workstation > >>>>> >=20 > >> Also just using gre's without the=20 > >> underlying ipsec tunnels seems to > >> work properly. >=20 >=20 > This is the crux of the matter. > IPSEC happens INSIDE the IP stack. The IP stack is responsible for > the ICMP generation so it is much more likely that there is an=20 > interaction there. >=20 > Now is there an IPSEC rule to make sure that the ICMP packet can get=20 > back? It could b ehtat in teh IP stack there is some confusion as to=20 > whether the return packet should be encrypted or not and it might get=20 > dropped. >=20 > the code involved is in /sys/netinet and /sys/netipsec but you'll > probably regret looking in there ;-) Right, I don't really know the IPSEC code, but I was told by someone who is familiar with it that this is a known problem and that the use of GRE is not relevant. Hopefully he will have a moment to respond to this thread with a bit more detail. robert. >=20 >=20 > >> > >> > > Another data point I had been using option FILTER_GIF I tried a kernel > > without that option and it behaved the same. > >=20 > > Steve > >=20 >=20 --=-tc069wmrKhgBioXbSO26 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkkdxpkACgkQM4TrQ4qfROOSoACaAokr54u0DNH/moMLIh/OcHnu AD4An37Pckf5o83ALDHlDC+BSC7/BpaW =KaC6 -----END PGP SIGNATURE----- --=-tc069wmrKhgBioXbSO26-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 20:34:10 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82C8A1065674 for ; Fri, 14 Nov 2008 20:34:10 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 20DE78FC17 for ; Fri, 14 Nov 2008 20:34:10 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 6497 invoked by uid 399); 14 Nov 2008 20:07:29 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 14 Nov 2008 20:07:29 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <491DDA7F.1040004@FreeBSD.org> Date: Fri, 14 Nov 2008 12:07:27 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.17 (X11/20081010) MIME-Version: 1.0 To: Julian Elischer References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <20081114211043.W54700@delplex.bde.org> <491DC07B.6070304@elischer.org> In-Reply-To: <491DC07B.6070304@elischer.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@FreeBSD.org, Ian Smith Subject: Re: rc.firewall quick change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 20:34:10 -0000 Julian Elischer wrote: > I think the table is faster for mor ethan about 8 addresses (so we > are borderline) but it's be hard to test.. You however use two rules > so that would be slower. I'm not a firewall expert so I won't comment on the specifics but I do want to say that as a general rule "it works + fast/efficient" is MUCH more important for default settings than "it works really well" or "it works + more features." For better or worse we live in a world where most users don't read the manuals, and that includes the ones running "benchmarks" with default settings. OTOH I do think it would be entirely appropriate to include a "better" example commented out next to the "fast" default. I take a similar approach with the default named.conf and have had good feedback from users who appreciate pointers to more information when they actually do get curious. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Fri Nov 14 20:49:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C093106564A; Fri, 14 Nov 2008 20:49:50 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 03F568FC08; Fri, 14 Nov 2008 20:49:49 +0000 (UTC) (envelope-from prvs=julian=1973cfe30@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 14 Nov 2008 12:49:50 -0800 Message-ID: <491DE46D.8070205@elischer.org> Date: Fri, 14 Nov 2008 12:49:49 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Doug Barton References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <20081114211043.W54700@delplex.bde.org> <491DC07B.6070304@elischer.org> <491DDA7F.1040004@FreeBSD.org> In-Reply-To: <491DDA7F.1040004@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@FreeBSD.org, Ian Smith Subject: Re: rc.firewall quick change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2008 20:49:50 -0000 Doug Barton wrote: > Julian Elischer wrote: >> I think the table is faster for mor ethan about 8 addresses (so we >> are borderline) but it's be hard to test.. You however use two rules >> so that would be slower. > > I'm not a firewall expert so I won't comment on the specifics but I do > want to say that as a general rule "it works + fast/efficient" is MUCH > more important for default settings than "it works really well" or "it > works + more features." For better or worse we live in a world where > most users don't read the manuals, and that includes the ones running > "benchmarks" with default settings. I think the change is better from the point of view that it is easier to read (for me) and behaves better. > > OTOH I do think it would be entirely appropriate to include a "better" > example commented out next to the "fast" default. I take a similar > approach with the default named.conf and have had good feedback from > users who appreciate pointers to more information when they actually > do get curious. > > > hth, > > Doug > From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 01:30:08 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFDF41065676 for ; Sat, 15 Nov 2008 01:30:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B51398FC19 for ; Sat, 15 Nov 2008 01:30:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAF1U8VG072914 for ; Sat, 15 Nov 2008 01:30:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAF1U8CG072911; Sat, 15 Nov 2008 01:30:08 GMT (envelope-from gnats) Date: Sat, 15 Nov 2008 01:30:08 GMT Message-Id: <200811150130.mAF1U8CG072911@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: =?iso-8859-1?B?QXVy6WxpZW4gTely6Q==?= Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?iso-8859-1?B?QXVy6WxpZW4gTely6Q==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2008 01:30:09 -0000 The following reply was made to PR kern/128833; it has been noted by GNATS. From: =?iso-8859-1?B?QXVy6WxpZW4gTely6Q==?= To: "Marius Strobl" , Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Sat, 15 Nov 2008 02:01:50 +0100 Hi I installed the patch there are still the same issues : 0x0060: 6965 2d68 656c 6c6d 616e 2d67 726f 7570 ie-hellman-group 0x0070: 2d65 7863 6861 6e67 2c64 6966 6669 652d -exchang,diffie- 0x0080: 2c64 6966 6669 652d 6865 6c6c 6d61 6e2d ,diffie-hellman- 0x0090: 6772 6f75 702d 6578 6368 616e 6765 2d73 group-exchange-s 0x00a0: 6861 312c 6469 6666 6965 2d68 656c 6c6d ha1,diffie-hellm 0x00b0: 616e 2d67 726f 7570 3134 2d73 6861 312c an-group14-sha1, 0x00c0: 6469 6666 6965 2d68 656c 6c6d 616e 2d67 diffie-hellman-g 0x0060: 6965 2d68 656c 6c6d 616e 2d67 726f 7570 ie-hellman-group 0x0070: 2d65 7863 6861 6e67 652d 7368 6132 3536 -exchange-sha256 0x0080: 2c64 6966 6669 652d 6865 6c6c 6d61 6e2d ,diffie-hellman- 0x0090: 6772 6f75 702d 6578 6368 616e 6765 2d73 group-exchange-s 0x00a0: 6861 312c 6469 6666 6965 2d68 656c 6c6d ha1,diffie-hellm 0x00b0: 616e 2d67 726f 7570 3134 2d73 6861 312c an-group14-sha1, 0x00c0: 6469 6666 6965 2d68 656c 6c6d 616e 2d67 diffie-hellman-g I will try to add some debug, don't hesitate to tell me if you have other ideas so i can do more tests. Thanks, Aurélien ----- Original Message ----- From: "Marius Strobl" To: ; Sent: Thursday, November 13, 2008 11:14 PM Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot > Hrm, I could be that the BCM5701 data corruption bug actually is > 64-bit rather than only PCI-X bus specific. Could you please give > the patch at: > http://people.freebsd.org/~marius/bge_5701.diff > a try? From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 05:51:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DC1B1065670; Sat, 15 Nov 2008 05:51:58 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 78A298FC12; Sat, 15 Nov 2008 05:51:57 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id mAF5pp4a005289; Sat, 15 Nov 2008 16:51:52 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 15 Nov 2008 16:51:51 +1100 (EST) From: Ian Smith To: Julian Elischer In-Reply-To: <491D406F.5030806@elischer.org> Message-ID: <20081115024024.O70117@sola.nimnet.asn.au> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <491D406F.5030806@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: rc.firewall quick change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2008 05:51:58 -0000 On Fri, 14 Nov 2008, Julian Elischer wrote: > Julian Elischer wrote: > > Ian Smith wrote: > > > On Thu, 13 Nov 2008, Julian Elischer wrote: > > > > At home I use the following change. > > > > > > basically, instead of doing 8 rules before and after the nat, > > > > use a table and to 1 rule on each side. > > > > > > any objections? > > > > > > Only that if people are already using tables for anything, chances are > > > they've already used table 1 (well, it's the first one I used :) How > > > about using table 127 for this as a rather less likely prior choice? > > > > yes I thought of that.. > > in fact it should be ${BLOCKTABLE} and let the user define what he wants. > > (defaulting to 99 or something). I prefer binary, but whatever :) > > Remember though that a user wouldn't be using 'simple' if he's using his > > own tables etc. This is an important point. Please allow me a little pent-up critique: Originally, eg for me over 10 years ago, till recently, the only way to use the 'client' or 'simple' rulesets was to hack rc.firewall, which I did relentlessly, like many people I'm sure .. that is, we treated it more as a starter example, not something that could be used as is. More recent updates have introduced rc vars that concievably make these rulesets usable out of the box, in as much as you could tell a newbie to FreeBSD firewalls and ipfw in particular, "setup these vars for your network, select the 'client' or 'simple' ruleset as appropriate, and you have a fair chance of having a fairly functional and reasonably secure firewall to get yourself online and going until you learn a bit more". Combined with the deprecatory and in many instances just plain erroneous info in the only section of the Handbook that I've felt to try rewriting more or less from scratch - ie the ipfw part of the firewall chapter 31, which suggests some quite (to me) bizarre example rulesets after having dissed using the rc.firewall rulesets out of hand - we're not doing much good at advocating new users trying ipfw, which I think does it some injustice. Not intending here to deprecate pf or ipf in any way. Anyhow, this leaves us with two good reasons that 'client' and 'simple' sections ought to work effectively: secondly as an example illustrating good techniques - and I think your use of a table that the user can add entries to out of band for such as blackholing hosts/nets without having to reconfigure or restart the firewall IS good technique - but firstly as a basically functional and secure minimal firewall in and of itself. It's for both those reasons (and fixing an apparent oversight) that I've offered my unreviewed patch (which I'll do properly by PR if anyone says it's worth pursuing), after years of not being able to fathom supposedly usable firewall configuration for a client or small net, with or without NAT, that has never passed =ANY= ICMP traffic, not even to or from the hosts in one's own net! Am I missing something, thinking that matters, and that functioning path MTU discovery matters? > so here's a slightly improved diff: This may be a bit nitpicky, but how about keeping the firewall_simple_* varset naming consistent, maybe firewall_simple_blocktable or something? The 'workstation' vars have kinda busted that idea anyway, but still .. Also maybe rephrase mentioning the draft-manning-blah after the divert? HTH, Ian From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 08:01:26 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25626106568B; Sat, 15 Nov 2008 08:01:26 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EF8EA8FC08; Sat, 15 Nov 2008 08:01:25 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAF81PIT006722; Sat, 15 Nov 2008 08:01:25 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAF81P5L006718; Sat, 15 Nov 2008 08:01:25 GMT (envelope-from linimon) Date: Sat, 15 Nov 2008 08:01:25 GMT Message-Id: <200811150801.mAF81P5L006718@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/128884: [msk] if_msk page fault while in kernel mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2008 08:01:26 -0000 Synopsis: [msk] if_msk page fault while in kernel mode Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Nov 15 08:01:13 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128884 From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 08:14:01 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF32D1065678 for ; Sat, 15 Nov 2008 08:14:01 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE2F8FC17 for ; Sat, 15 Nov 2008 08:14:00 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from via.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sat, 15 Nov 2008 09:12:35 +0100 id 0002E00F.491E8473.0000924A From: Milan Obuch To: freebsd-net@freebsd.org, pyunyh@gmail.com Date: Sat, 15 Nov 2008 09:13:15 +0100 User-Agent: KMail/1.9.10 References: <200810300829.35980.freebsd-net@dino.sk> <200811032339.07412.freebsd-net@dino.sk> <20081104014604.GB98154@cdnetworks.co.kr> In-Reply-To: <20081104014604.GB98154@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811150913.16407.freebsd-net@dino.sk> Cc: Subject: Re: re weird bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2008 08:14:01 -0000 On Tuesday 04 November 2008 02:46:04 Pyun YongHyeon wrote: > On Mon, Nov 03, 2008 at 11:39:06PM +0100, Milan Obuch wrote: > > On Monday 03 November 2008 04:59:08 Pyun YongHyeon wrote: > > > > [ snip ] > > > > > I vaguely guess hardware was not properly initialized. How about > > > this one? > > > http://people.freebsd.org/~yongari/re/re.phy.patch.20081103 > > > > This bug seems again to disappear - csup two days ago, kernel built with > > no patches and everything works. Something like this happened already in > > the > > Yeah, this is one of reason that makes it hard to fix. > > > past. No idea whether it has something with if_re being built as module, > > but if it happens again, I will test this possibility, too. > > Ok. Please let me know your findings. Strange. This trouble occured again. Two days ago, fresh csup, rebuilt whole system, re works only when with verbose boot logging. Yesterday, fresh csup, full rebuild, re works again. There is no change in if_re.c at all - it is dated Sep 9, 2008. This is coming from somewhere else, but I have no idea how this could be debugged. One possibility is there is some weird issue with code or maybe more probably buffer placement in memory, but this is just a shot in the wild, and no idea what means could be used to trace that. It occurs to me from time to time, only with -current, everytime verbose boot logging masks the trouble, at least everytime I tried. Really weird, not predictable. And maybe only difference tracking one per one could give some clue, but this is really time consuming (apply change, rebuild kernel, reboot, test... grrr). Regards, Milan From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 10:40:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED6A41065674; Sat, 15 Nov 2008 10:40:17 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id A0FE08FC14; Sat, 15 Nov 2008 10:40:17 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 4065741C438; Sat, 15 Nov 2008 11:40:15 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id sBBYSULNQQaa; Sat, 15 Nov 2008 11:40:12 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 5857241C62D; Sat, 15 Nov 2008 11:40:12 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id ECF61444888; Sat, 15 Nov 2008 10:38:34 +0000 (UTC) Date: Sat, 15 Nov 2008 10:38:34 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: sclark46@earthlink.net In-Reply-To: <1226688153.1719.23.camel@squirrel.corp.cox.com> Message-ID: <20081115102746.K61259@maildrop.int.zabbadoz.net> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, FreeBSD Stable Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2008 10:40:18 -0000 On Fri, 14 Nov 2008, Robert Noland wrote: Hi, >>>> Also just using gre's without the >>>> underlying ipsec tunnels seems to >>>> work properly. The reason for this to my knowledge is: http://www.kame.net/dev/cvsweb2.cgi/kame/freebsd2/sys/netinet/ip_icmp.c#rev1.4 or looking at recent freebsd code: http://fxr.watson.org/fxr/source/netinet/ip_icmp.c#L164 Look for M_DECRYPTED. Now what happens in your case: you receive an IPSec ESP packet, which gets decryped, that sets M_DECRYPTED on the mbuf passes through various parts, gets up to gre, gets decapsulated is an IP packet (again) gets to ip_input, TTL expired, icmp_error and it's still the same mbuf that originally got the M_DECRYPTED set. Thus the packets is just freed and you never see anything. So thinking about this has nothing to do with gre (or gif for example as well) in first place. It's arguably that passing it on to another decapsulation the flag should be cleared when entering gre() for example. The other question of course is why we do not send the icmp error back even on plain ipsec? Is it because we could possibly leak information as it's not caught by the policy sending it back? /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 11:46:39 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C14E9106567B; Sat, 15 Nov 2008 11:46:39 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 953628FC13; Sat, 15 Nov 2008 11:46:39 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAFBkdsc072932; Sat, 15 Nov 2008 11:46:39 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAFBkddn072928; Sat, 15 Nov 2008 11:46:39 GMT (envelope-from linimon) Date: Sat, 15 Nov 2008 11:46:39 GMT Message-Id: <200811151146.mAFBkddn072928@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/128840: [igb] page fault under load with igb/LRO X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2008 11:46:39 -0000 Synopsis: [igb] page fault under load with igb/LRO Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Nov 15 11:46:24 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128840 From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 20:22:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 906A81065673 for ; Sat, 15 Nov 2008 20:22:14 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 2C92D8FC28 for ; Sat, 15 Nov 2008 20:22:13 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [129.247.12.6] ([129.247.12.6]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Nov 2008 21:08:56 +0100 Message-ID: <491F2C47.4050500@dlr.de> Date: Sat, 15 Nov 2008 21:08:39 +0100 From: Hartmut Brandt User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2008 20:08:56.0118 (UTC) FILETIME=[FD223D60:01C9475D] Subject: TCP and syncache question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2008 20:22:14 -0000 Hi, in tcp_syncache.c:syncache_expand() there is a test that the acknowledgement number and the sequence number of an incoming ACK segment are in the expected range. If they are not, syncache_expand() returns 0 and tcp_input drops the segment and sets a reset. So far so good. But syncache_expand() also deletes the syncache entry, and so destroys the connection. I cannot see why it does it. It seems to me that such a wrong segment should be interpreted as to be from another connection and as such the segment should be ignored (but a reset sent). When the correct ACK comes, the connection could still be established. As it is now, the establishment of incoming connections can seriously be disturbed by someone sending fake ACK packets. The same test (for the ack number, not for the sequence number) is also further down in tcp_input.c:tcp_do_segment() (just after the header prediction stuff) and here the handling is correct: the goto dropwithreset just sends a reset and drops the segment but leaves the connection in the SYN-RECEIVED state. This test is probably never reached now, because of syncache_expand(), though. Maybe I fail to see something obvious, though... harti From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 21:30:58 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6687F1065677 for ; Sat, 15 Nov 2008 21:30:58 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3D7628FC12 for ; Sat, 15 Nov 2008 21:30:58 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id EFDB01B5E02; Sat, 15 Nov 2008 16:11:58 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 15 Nov 2008 16:11:58 -0500 X-Sasl-enc: FkYqHkJ4n2ABc2rGZBl5sWV6SiG1ptMFkW0H6rpgnmPm 1226783518 Received: from empiric.lon.incunabulum.net (unknown [81.168.51.182]) by mail.messagingengine.com (Postfix) with ESMTPSA id 5DB8C2A720; Sat, 15 Nov 2008 16:11:58 -0500 (EST) Message-ID: <491F3B1B.2040503@incunabulum.net> Date: Sat, 15 Nov 2008 21:11:55 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: Marius Strobl References: <200811132230.mADMUC45038539@freefall.freebsd.org> In-Reply-To: <200811132230.mADMUC45038539@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2008 21:30:58 -0000 Marius Strobl wrote: > ... > Hrm, I could be that the BCM5701 data corruption bug actually is > 64-bit rather than only PCI-X bus specific. Could you please give > the patch at: > http://people.freebsd.org/~marius/bge_5701.diff > a try? > This patch looks syntactically OK, though I don't know about bge register set, perhaps it should go in to 7.1. From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 22:19:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FDD91065679 for ; Sat, 15 Nov 2008 22:19:58 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 2DC348FC12 for ; Sat, 15 Nov 2008 22:19:57 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so151308ugs.39 for ; Sat, 15 Nov 2008 14:19:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=2UsOZcjROuxSFOP4g9T30RBY50wAWsv82td1D1DPsXc=; b=s5PNcpyfGLPkihw+H7mDWZZpOD78Bp5GnlT12XnBT1jTnAB1oKalJiDpjMUyw6s7D0 k933bvvLR/GfahxxkbulSQbVfHzX58x9qgGxCio9e3SZ7NlSG98f8qapnSaGOj2osE32 +tJadME48NqJAFu7Xo0KN7FAvSBjycHtHNBIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=BpmPSwHzheEowNTXfmNxk9uR07xKrojTP/LOgkMLBfzpK4s75ODpz/tuoFZ62F/2vV 4Zx6TgSzdEDrVAoz1+AAbrgnpR3PmsGUscadOPfcyHyvwqkqWUG40Z6lQj5SoHos66ee p7zP09J1rhVkPjtdUTROKnFz/PSejgNZthB8g= Received: by 10.210.73.12 with SMTP id v12mr2475334eba.107.1226785897732; Sat, 15 Nov 2008 13:51:37 -0800 (PST) Received: from ?10.0.0.15? ([83.144.140.192]) by mx.google.com with ESMTPS id t2sm3785163gve.5.2008.11.15.13.51.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 15 Nov 2008 13:51:36 -0800 (PST) Message-Id: <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> From: Rui Paulo To: Hartmut Brandt In-Reply-To: <491F2C47.4050500@dlr.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 15 Nov 2008 21:51:33 +0000 References: <491F2C47.4050500@dlr.de> X-Mailer: Apple Mail (2.929.2) Sender: Rui Paulo Cc: freebsd-net@freebsd.org Subject: Re: TCP and syncache question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2008 22:19:58 -0000 On 15 Nov 2008, at 20:08, Hartmut Brandt wrote: > Hi, > > in tcp_syncache.c:syncache_expand() there is a test that the > acknowledgement number and the sequence number of an incoming ACK > segment are in the expected range. If they are not, > syncache_expand() returns 0 and tcp_input drops the segment and sets > a reset. So far so good. But syncache_expand() also deletes the > syncache entry, and so destroys the connection. I cannot see why it > does it. It seems to me that such a wrong segment should be > interpreted as to be from another connection and as such the segment > should be ignored (but a reset sent). When the correct ACK comes, > the connection could still be established. As it is now, the > establishment of incoming connections can seriously be disturbed by > someone sending fake ACK packets. > > The same test (for the ack number, not for the sequence number) is > also further down in tcp_input.c:tcp_do_segment() (just after the > header prediction stuff) and here the handling is correct: the goto > dropwithreset just sends a reset and drops the segment but leaves > the connection in the SYN-RECEIVED state. This test is probably > never reached now, because of syncache_expand(), though. > > Maybe I fail to see something obvious, though... Well, if the RST is sent, why should we keep the syncache entry? Regards, -- Rui Paulo