From owner-freebsd-net@FreeBSD.ORG Sun Jul 8 02:20:06 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67B4716A468 for ; Sun, 8 Jul 2007 02:20:06 +0000 (UTC) (envelope-from gloomygroup@hotmail.com) Received: from bay0-omc2-s38.bay0.hotmail.com (bay0-omc2-s38.bay0.hotmail.com [65.54.246.174]) by mx1.freebsd.org (Postfix) with ESMTP id 5199C13C43E for ; Sun, 8 Jul 2007 02:20:06 +0000 (UTC) (envelope-from gloomygroup@hotmail.com) Received: from BAY131-W29 ([65.55.136.64]) by bay0-omc2-s38.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 7 Jul 2007 19:20:06 -0700 Message-ID: X-Originating-IP: [202.79.53.71] From: Gloomy Group To: Alexander Motin Date: Sun, 8 Jul 2007 02:20:06 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jul 2007 02:20:06.0184 (UTC) FILETIME=[7FD2E280:01C7C106] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , mpd-users@lists.sourceforge.net, Julian Elischer Subject: RE: Mpd daemon stop when rotating mpd.log file with newsyslog.conf 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, 08 Jul 2007 02:20:06 -0000 Thanks to all of you. Keeping "N" option solved.Thanks again.> Date: Sat, 7= Jul 2007 16:10:00 +0300> From: mav@freebsd.org> To: gloomygroup@hotmail.co= m> CC: freebsd-net@freebsd.org; mpd-users@lists.sourceforge.net; julian@eli= scher.org> Subject: Re: Mpd daemon stop when rotating mpd.log file with new= syslog.conf> > Julian Elischer wrote:> >> Hello all, I have installed mpd4.= 2.2 in freebsd 6.2. Everything is> >> working fine except when I make an en= try in newsyslog.conf for> >> rotating mpd.log file the mpd daemon process = stops. and I have to> >> restart the process again manually. Any one knows = what wrong? Below> >> is the newsyslog.conf> > > > /var/log/mpd.log 664 7 1= 0900 * JC /var/run/mpd4.pid> > > > try add the 'N' option.> > I don't know= if mpd needs to be signalled if its log file is changed..> > Mpd does not = write logs by itself, it uses syslog. So it needs not to be > signalled. Mp= d shutdowns itself on HUP signal.> > -- > Alexander Motin> ________________= _______________________________> 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" _________________________________________________________________ PC Magazine=92s 2007 editors=92 choice for best web mail=97award-winning Wi= ndows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=3Den-us&ocid=3DTXT_TAGHM_mig= ration_HMWL_mini_pcmag_0707= From owner-freebsd-net@FreeBSD.ORG Sun Jul 8 06:11:21 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3BD5316A400 for ; Sun, 8 Jul 2007 06:11:21 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 8DFF013C447 for ; Sun, 8 Jul 2007 06:11:19 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id QAA13163; Sun, 8 Jul 2007 16:11:12 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 8 Jul 2007 16:11:11 +1000 (EST) From: Ian Smith To: Gloomy Group In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD Net , Alexander Motin , mpd-users@lists.sourceforge.net, Julian Elischer Subject: RE: Mpd daemon stop when rotating mpd.log file with newsyslog.conf 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, 08 Jul 2007 06:11:21 -0000 On Sun, 8 Jul 2007, Gloomy Group wrote: > Thanks to all of you. Keeping "N" option solved.Thanks again. (trying to recover the format, more or less) Alexander Motin wrote: > Julian Elischer wrote: > > >> Hello all, I have installed mpd4.2.2 in freebsd 6.2. Everything is > >> working fine except when I make an entry in newsyslog.conf for > >> rotating mpd.log file the mpd daemon process stops. and I have to > >> restart the process again manually. Any one knows what wrong? Below > >> is the newsyslog.conf > >> /var/log/mpd.log 664 7 10900 * JC /var/run/mpd4.pid > > try add the 'N' option. > > I don't know if mpd needs to be signalled if its log file is changed.. > Mpd does not write logs by itself, it uses syslog. So it needs not to be > signalled. Mpd shutdowns itself on HUP signal. Which is a little non-POLA, but then I guess rereading its config and restarting, like most things do on -HUP, probably doesn't make sense. Anyhow, I think 'N' isn't needed if you don't specify a pidfile in the first place .. then only syslogd gets sent a SIGHUP, which never hurts. (if I'm reading newsyslog.conf right) Cheers, Ian (due to upgrade to mpd 4.2.2 on 5.5-S soon .. will report) From owner-freebsd-net@FreeBSD.ORG Sun Jul 8 09:04:13 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7541616A400; Sun, 8 Jul 2007 09:04:13 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id 3523313C46A; Sun, 8 Jul 2007 09:04:13 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [87.240.16.199] (helo=solem.sem-home.ciam.ru) by mail.ciam.ru with esmtpa (Exim 4.x) id 1I7SMw-000HtO-F6; Sun, 08 Jul 2007 12:43:50 +0400 Message-ID: <4690A363.1050307@FreeBSD.org> Date: Sun, 08 Jul 2007 12:42:11 +0400 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.0 (X11/20070602) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , freebsd-current@freebsd.org Subject: iwi loses ssid 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, 08 Jul 2007 09:04:13 -0000 Hi. After I upgraded to Jul 1 CURRENT my notebook's iwi adapter started work unstable. It loses carrier. When I take a look at ifconfig output I see a strange ssid. After I make ifconfig iwi0 ssid myssid, everything is recovered. Time between ssid losses is accidental. Sometimes minutes, sometimes hours. PS. While I wrote this message it resets ssid again to ZXDSL531BII-1A0EE6. It looks like the ssid is always the same. -- Dixi. Sem. From owner-freebsd-net@FreeBSD.ORG Mon Jul 9 11:08:42 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1688A16A4A6 for ; Mon, 9 Jul 2007 11:08:42 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE7513C489 for ; Mon, 9 Jul 2007 11:08:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l69B8d5H044866 for ; Mon, 9 Jul 2007 11:08:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l69B8c3h044862 for freebsd-net@FreeBSD.org; Mon, 9 Jul 2007 11:08:38 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Jul 2007 11:08:38 GMT Message-Id: <200707091108.l69B8c3h044862@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 you 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, 09 Jul 2007 11:08:42 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi o kern/110959 net [ipsec] Filtering incoming packets with enc0 does not o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net IP v4 udp fragmented packet reject o kern/113359 net [ipv6] panic sbdrop after ICMP6, packet too big o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi 16 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/103253 net inconsistent behaviour in arp reply of a bridge o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/112612 net [lo] Traffic via additional lo(4) interface shows up o o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/112886 net [broadcom]: Wifi card not detected o kern/114095 net [carp] carp+pf delay with high state limit 15 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 9 16:06:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A94D016A41F for ; Mon, 9 Jul 2007 16:06:47 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from mail29.bluewin.ch (mail29.bluewin.ch [195.186.18.70]) by mx1.freebsd.org (Postfix) with ESMTP id E975D13C4B0 for ; Mon, 9 Jul 2007 16:06:46 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from ps8zhh.bluewin.ch (195.186.19.195) by mail29.bluewin.ch (Bluewin 7.3.121) id 467A74DC004E3418 for freebsd-net@freebsd.org; Mon, 9 Jul 2007 15:46:30 +0000 Received: from ps8zhh (localhost [127.0.0.1]) by ps8zhh.bluewin.ch (Postfix) with ESMTP id 92841EA4 for ; Mon, 9 Jul 2007 15:46:30 +0000 (GMT) Message-ID: <13471228.91981183995990597.JavaMail.webmail@ps8zhh.bluewin.ch> Date: Mon, 9 Jul 2007 15:46:30 +0000 (GMT) From: "paketix@bluewin.ch" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-FXIT-IP: 138.190.32.7 Subject: 6.2-RELENG/7.0-CURRENT: em(4) fails on 82571EB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: paketix@bluewin.ch List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 16:06:47 -0000 hello everybody i encountered some problems with the intel 82571EB chipset when i tried to upgrade from FreeBSD 6.1-RELENG to 6.2-RELENG/7.0-CURRENT on a network appliance (NEXCOM 1108GL) the appliance has 3 different intel ethernet controllers soldered to the motherboard E1000_DEV_ID_82541GI 0x1076 E1000_DEV_ID_82571EB_COPPER 0x105E E1000_DEV_ID_82571EB_SERDES 0x1060 current intel driver version: 6.5.3 (from 7.0-CURRENT) problem description: chipset initialisation seems to work OK ifconfig displays the devices / link state seems to be OK 'ifconfig up' and 'tcpdump' are NOK (>no packets recieved on interface - leds indicate packet reception) interrupts seem to be OK (link up/down triggers em_intr on 6.2- RELENG - behaviour on 7.0-CURRENT unknown yet) affected releases: it seems to be the same problem on 6.2-RELENG/7.0-CURRENT 6.1-RELENG works fine... anyone interested in tracking this down...? any experience with this behaviour @intel? i have a server in the lab which is ready to act as a guinea pig for tests/paches... ------- rgds, pat freebsd# uname -a FreeBSD freebsd.sharedtcs.net 7.0-CURRENT-200706 FreeBSD 7.0-CURRENT-200706 #0: Sun Jun 3 18:41:02 UTC 2007 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 freebsd# pciconf -l | grep em em0@pci6:0:0: class=0x020000 card=0x10761903 chip=0x105e8086 rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) em1@pci6:0:1: class=0x020000 card=0x10761903 chip=0x105e8086 rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) em2@pci7:0:0: class=0x020000 card=0x10761903 chip=0x105e8086 rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) em3@pci7:0:1: class=0x020000 card=0x10761903 chip=0x105e8086 rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) em4@pci8:0:0: class=0x020000 card=0x10761903 chip=0x10608086 rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. ext. SERDES for SFP modules) em5@pci8:0:1: class=0x020000 card=0x10761903 chip=0x10608086 rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. ext. SERDES for SFP modules) em6@pci9:0:0: class=0x020000 card=0x10761903 chip=0x105e8086 rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) em7@pci9:0:1: class=0x020000 card=0x10761903 chip=0x105e8086 rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) em8@pci13:7:0: class=0x020000 card=0x10761903 chip=0x10768086 rev=0x05 hdr=0x00 (82541EI Gigabit Ethernet Controller w. int. PHY) em9@pci13:9:0: class=0x020000 card=0x10761903 chip=0x10768086 rev=0x05 hdr=0x00 (82541EI Gigabit Ethernet Controller w. int. PHY) freebsd# cat /var/run/dmesg.boot Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT-200706 #0: Sun Jun 3 18:41:02 UTC 2007 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Using 32 colors for the VM-PQ tuning (1024, 8) Preloaded elf kernel "/boot/kernel.orig/kernel" at 0xc0c95000. MP Configuration Table version 1.4 found at 0xc00f1400 APIC: Using the MPTable enumerator. SMP: Added CPU 0 (BSP) SMP: Added CPU 1 (AP) MPTable: Calibrating clock(s) ... i8254 clock: 1193199 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3200127568 Hz CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3200.13-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf49 Stepping = 9 Features=0xbfebfbff Features2=0x641d AMD Features=0x20100000 AMD Features2=0x1 Logical CPUs per core: 2 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 64 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 16 KB, 8-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 1 MB, 8-way set associative, sectored cache, 64 byte line size L2 cache: 1024 kbytes, 8-way associative, 64 bytes/line real memory = 1065287680 (1015 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001028000 - 0x000000003e5cbfff, 1029324800 bytes (251300 pages) avail memory = 1028886528 (981 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00f9350 bios32: Entry = 0xf9960 (c00f9960) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x9990 pnpbios: Found PnP BIOS data at 0xc00fa550 pnpbios: Entry = f0000:a580 Rev = 1.0 Other BIOS signatures found: ioapic0: Changing APIC ID to 4 ioapic0: Assuming intbase of 0 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 9 trigger: level lapic: Routing ExtINT -> LINT0 lapic: Routing NMI -> LINT1 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 wlan_amrr: wlan: <802.11 Link Layer> ath_rate: version 1.2 null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Jun 3 2007 18:40: 23) npx0: INT 16 interface cpu0 on motherboard cpu1 on motherboard pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27708086) pcibios: BIOS version 3.00 pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x2770, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2772, revid=0x02 bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0xfdf00000, size 19, enabled map[14]: type I/O Port, range 32, base 0xff00, size 3, enabled map[18]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, enabled map[1c]: type Memory, range 32, base 0xfdf80000, size 18, enabled pcib0: slot 2 INTA routed to irq 16 found-> vendor=0x8086, dev=0x27d0, revid=0x01 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: slot 28 INTA routed to irq 16 found-> vendor=0x8086, dev=0x27e2, revid=0x01 bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: slot 28 INTB routed to irq 17 found-> vendor=0x8086, dev=0x27c8, revid=0x01 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 map[20]: type I/O Port, range 32, base 0xfe00, size 5, enabled pcib0: slot 29 INTA routed to irq 23 found-> vendor=0x8086, dev=0x27c9, revid=0x01 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0xfd00, size 5, enabled pcib0: slot 29 INTB routed to irq 19 found-> vendor=0x8086, dev=0x27ca, revid=0x01 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 map[20]: type I/O Port, range 32, base 0xfc00, size 5, enabled pcib0: slot 29 INTC routed to irq 18 found-> vendor=0x8086, dev=0x27cb, revid=0x01 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=3 map[20]: type I/O Port, range 32, base 0xfb00, size 5, enabled pcib0: slot 29 INTD routed to irq 16 found-> vendor=0x8086, dev=0x27cc, revid=0x01 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfdfff000, size 10, enabled pcib0: slot 29 INTA routed to irq 23 found-> vendor=0x8086, dev=0x244e, revid=0xe1 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b8, revid=0x01 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27c0, revid=0x01 bus=0, slot=31, func=2 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xf800, size 4, enabled map[24]: type Memory, range 32, base 0xfdffc000, size 10, enabled found-> vendor=0x8086, dev=0x27da, revid=0x01 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0x500, size 5, enabled pcib0: slot 31 INTB routed to irq 19 vgapci0: port 0xff00-0xff07 mem 0xfdf00000- 0xfdf7ffff,0xd0000000-0xdfffffff,0xfdf80000-0xfdfbffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xfdf00000 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xfdf00000 vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at 0xfdf80000 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000 agp0: detected 7932k stolen memory agp0: aperture size is 256M pcib1: irq 16 at device 28.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 9 pcib1: I/O decode 0x6000-0xcfff pcib1: memory decode 0xfd700000-0xfdefffff pcib1: prefetched decode 0xfce00000-0xfd4fffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x10b5, dev=0x8524, revid=0xbb bus=1, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 1 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfdee0000, size 17, enabled pcib1: requested memory range 0xfdee0000-0xfdefffff: good pcib1: slot 0 INTA routed to irq 16 pcib2: mem 0xfdee0000-0xfdefffff irq 16 at device 0.0 on pci1 pcib2: secondary bus 2 pcib2: subordinate bus 9 pcib2: I/O decode 0x6000-0xcfff pcib2: memory decode 0xfd700000-0xfddfffff pcib2: prefetched decode 0xfce00000-0xfd4fffff pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x10b5, dev=0x8524, revid=0xbb bus=2, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 1 supports D0 D3 current D0 MSI supports 1 message, 64 bit pcib2: slot 1 INTA routed to irq 16 found-> vendor=0x10b5, dev=0x8524, revid=0xbb bus=2, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 1 supports D0 D3 current D0 MSI supports 1 message, 64 bit pcib2: slot 2 INTA routed to irq 16 found-> vendor=0x10b5, dev=0x8524, revid=0xbb bus=2, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 1 supports D0 D3 current D0 MSI supports 1 message, 64 bit pcib2: slot 3 INTA routed to irq 16 found-> vendor=0x10b5, dev=0x8524, revid=0xbb bus=2, slot=8, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 1 supports D0 D3 current D0 MSI supports 1 message, 64 bit pcib2: slot 8 INTA routed to irq 16 found-> vendor=0x10b5, dev=0x8524, revid=0xbb bus=2, slot=9, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 1 supports D0 D3 current D0 MSI supports 1 message, 64 bit pcib2: slot 9 INTA routed to irq 16 found-> vendor=0x10b5, dev=0x8524, revid=0xbb bus=2, slot=10, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 1 supports D0 D3 current D0 MSI supports 1 message, 64 bit pcib2: slot 10 INTA routed to irq 16 found-> vendor=0x10b5, dev=0x8524, revid=0xbb bus=2, slot=11, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 1 supports D0 D3 current D0 MSI supports 1 message, 64 bit pcib2: slot 11 INTA routed to irq 16 pcib3: irq 16 at device 1.0 on pci2 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xc000-0xcfff pcib3: memory decode 0xfdd00000-0xfddfffff pcib3: prefetched decode 0xfd400000-0xfd4fffff pci3: on pcib3 pci3: physical bus=3 pcib4: irq 16 at device 2.0 on pci2 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xb000-0xbfff pcib4: memory decode 0xfdc00000-0xfdcfffff pcib4: prefetched decode 0xfd300000-0xfd3fffff pci4: on pcib4 pci4: physical bus=4 pcib5: irq 16 at device 3.0 on pci2 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0xa000-0xafff pcib5: memory decode 0xfdb00000-0xfdbfffff pcib5: prefetched decode 0xfd200000-0xfd2fffff pci5: on pcib5 pci5: physical bus=5 pcib6: irq 16 at device 8.0 on pci2 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: I/O decode 0x9000-0x9fff pcib6: memory decode 0xfda00000-0xfdafffff pcib6: prefetched decode 0xfd100000-0xfd1fffff pci6: on pcib6 pci6: physical bus=6 found-> vendor=0x8086, dev=0x105e, revid=0x06 bus=6, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0, size 17, memory disabled map[14]: type Memory, range 32, base 0, size 17, memory disabled map[18]: type I/O Port, range 32, base 0, size 5, port disabled found-> vendor=0x8086, dev=0x105e, revid=0x06 bus=6, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0, size 17, memory disabled map[14]: type Memory, range 32, base 0, size 17, memory disabled map[18]: type I/O Port, range 32, base 0, size 5, port disabled em0: at device 0.0 on pci6 pcib6: em0 requested memory range 0xfda00000-0xfdafffff: good pcib2: em0 requested memory range 0xfda00000-0xfdafffff: good pcib1: em0 requested memory range 0xfda00000-0xfdafffff: good em0: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at 0xfda00000 pcib6: slot 0 INTA routed to irq 16 em0: bpf attached em0: Ethernet address: 00:10:f3:0c:5b:36 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 48 em0: [FILTER] em1: at device 0.1 on pci6 pcib6: em1 requested memory range 0xfda00000-0xfdafffff: good pcib2: em1 requested memory range 0xfda00000-0xfdafffff: good pcib1: em1 requested memory range 0xfda00000-0xfdafffff: good em1: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at 0xfda20000 pcib6: slot 0 INTB routed to irq 17 em1: bpf attached em1: Ethernet address: 00:10:f3:0c:5b:37 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 49 em1: [FILTER] pcib7: irq 16 at device 9.0 on pci2 pcib7: secondary bus 7 pcib7: subordinate bus 7 pcib7: I/O decode 0x8000-0x8fff pcib7: memory decode 0xfd900000-0xfd9fffff pcib7: prefetched decode 0xfd000000-0xfd0fffff pci7: on pcib7 pci7: physical bus=7 found-> vendor=0x8086, dev=0x105e, revid=0x06 bus=7, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0, size 17, memory disabled map[14]: type Memory, range 32, base 0, size 17, memory disabled map[18]: type I/O Port, range 32, base 0, size 5, port disabled found-> vendor=0x8086, dev=0x105e, revid=0x06 bus=7, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0, size 17, memory disabled map[14]: type Memory, range 32, base 0, size 17, memory disabled map[18]: type I/O Port, range 32, base 0, size 5, port disabled em2: at device 0.0 on pci7 pcib7: em2 requested memory range 0xfd900000-0xfd9fffff: good pcib2: em2 requested memory range 0xfd900000-0xfd9fffff: good pcib1: em2 requested memory range 0xfd900000-0xfd9fffff: good em2: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at 0xfd900000 pcib7: slot 0 INTA routed to irq 17 em2: bpf attached em2: Ethernet address: 00:10:f3:0c:5b:38 em2: [FILTER] em3: at device 0.1 on pci7 pcib7: em3 requested memory range 0xfd900000-0xfd9fffff: good pcib2: em3 requested memory range 0xfd900000-0xfd9fffff: good pcib1: em3 requested memory range 0xfd900000-0xfd9fffff: good em3: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at 0xfd920000 pcib7: slot 0 INTB routed to irq 18 em3: bpf attached em3: Ethernet address: 00:10:f3:0c:5b:39 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 50 em3: [FILTER] pcib8: irq 16 at device 10.0 on pci2 pcib8: secondary bus 8 pcib8: subordinate bus 8 pcib8: I/O decode 0x7000-0x7fff pcib8: memory decode 0xfd800000-0xfd8fffff pcib8: prefetched decode 0xfcf00000-0xfcffffff pci8: on pcib8 pci8: physical bus=8 pcib9: irq 16 at device 11.0 on pci2 pcib9: secondary bus 9 pcib9: subordinate bus 9 pcib9: I/O decode 0x6000-0x6fff pcib9: memory decode 0xfd700000-0xfd7fffff pcib9: prefetched decode 0xfce00000-0xfcefffff pci9: on pcib9 pci9: physical bus=9 found-> vendor=0x8086, dev=0x105e, revid=0x06 bus=9, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0, size 17, memory disabled map[14]: type Memory, range 32, base 0, size 17, memory disabled map[18]: type I/O Port, range 32, base 0, size 5, port disabled found-> vendor=0x8086, dev=0x105e, revid=0x06 bus=9, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0, size 17, memory disabled map[14]: type Memory, range 32, base 0, size 17, memory disabled map[18]: type I/O Port, range 32, base 0, size 5, port disabled em4: at device 0.0 on pci9 pcib9: em4 requested memory range 0xfd700000-0xfd7fffff: good pcib2: em4 requested memory range 0xfd700000-0xfd7fffff: good pcib1: em4 requested memory range 0xfd700000-0xfd7fffff: good em4: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at 0xfd700000 pcib9: slot 0 INTA routed to irq 19 em4: bpf attached em4: Ethernet address: 00:10:f3:0c:5b:34 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 51 em4: [FILTER] em5: at device 0.1 on pci9 pcib9: em5 requested memory range 0xfd700000-0xfd7fffff: good pcib2: em5 requested memory range 0xfd700000-0xfd7fffff: good pcib1: em5 requested memory range 0xfd700000-0xfd7fffff: good em5: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at 0xfd720000 pcib9: slot 0 INTB routed to irq 16 em5: bpf attached em5: Ethernet address: 00:10:f3:0c:5b:35 em5: [FILTER] pcib10: irq 17 at device 28.5 on pci0 pcib10: secondary bus 10 pcib10: subordinate bus 12 pcib10: I/O decode 0x4000-0x5fff pcib10: memory decode 0xfcc00000-0xfcdfffff pcib10: prefetched decode 0xfca00000-0xfcbfffff pci10: on pcib10 pci10: physical bus=10 found-> vendor=0x8086, dev=0x0340, revid=0x09 bus=10, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit found-> vendor=0x8086, dev=0x0341, revid=0x09 bus=10, slot=0, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit pcib11: at device 0.0 on pci10 pcib11: secondary bus 11 pcib11: subordinate bus 11 pcib11: I/O decode 0x5000-0x5fff pcib11: memory decode 0xfcd00000-0xfcdfffff pcib11: prefetched decode 0xfcb00000-0xfcbfffff pci11: on pcib11 pci11: physical bus=11 pcib12: at device 0.2 on pci10 pcib12: secondary bus 12 pcib12: subordinate bus 12 pcib12: I/O decode 0x4000-0x4fff pcib12: memory decode 0xfcc00000-0xfccfffff pcib12: prefetched decode 0xfca00000-0xfcafffff pci12: on pcib12 pci12: physical bus=12 uhci0: port 0xfe00-0xfe1f irq 23 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfe00 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 52 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xfd00-0xfd1f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfd00 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xfc00-0xfc1f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfc00 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xfb00-0xfb1f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfb00 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfdfff000- 0xfdfff3ff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfdfff000 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib13: at device 30.0 on pci0 pcib13: secondary bus 13 pcib13: subordinate bus 13 pcib13: I/O decode 0xd000-0xdfff pcib13: memory decode 0xfd600000-0xfd6fffff pcib13: prefetched decode 0xfd500000-0xfd5fffff pcib13: Subtractively decoded bridge. pci13: on pcib13 pci13: physical bus=13 found-> vendor=0x8086, dev=0x1076, revid=0x05 bus=13, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0xfc (7560 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfd6e0000, size 17, enabled pcib13: requested memory range 0xfd6e0000-0xfd6fffff: good map[14]: type Memory, range 32, base 0xfd6c0000, size 17, enabled pcib13: requested memory range 0xfd6c0000-0xfd6dffff: good map[18]: type I/O Port, range 32, base 0xdf00, size 6, enabled pcib13: requested I/O range 0xdf00-0xdf3f: in range pcib13: slot 7 INTA routed to irq 17 found-> vendor=0x8086, dev=0x1076, revid=0x05 bus=13, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0xfc (7560 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfd6a0000, size 17, enabled pcib13: requested memory range 0xfd6a0000-0xfd6bffff: good map[14]: type Memory, range 32, base 0xfd680000, size 17, enabled pcib13: requested memory range 0xfd680000-0xfd69ffff: good map[18]: type I/O Port, range 32, base 0xde00, size 6, enabled pcib13: requested I/O range 0xde00-0xde3f: in range pcib13: slot 9 INTA routed to irq 19 em6: port 0xdf00-0xdf3f mem 0xfd6e0000-0xfd6fffff,0xfd6c0000-0xfd6dffff irq 17 at device 7.0 on pci13 em6: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfd6e0000 em6: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdf00 em6: bpf attached em6: Ethernet address: 00:10:f3:0c:5b:33 em6: [FILTER] em7: port 0xde00-0xde3f mem 0xfd6a0000-0xfd6bffff,0xfd680000-0xfd69ffff irq 19 at device 9.0 on pci13 em7: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfd6a0000 em7: Reserved 0x40 bytes for rid 0x18 type 4 at 0xde00 em7: bpf attached em7: Ethernet address: 00:10:f3:0c:5b:32 em7: [FILTER] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6, 0x170-0x177,0x376,0xf800-0xf80f mem 0xfdffc000-0xfdffc3ff at device 31.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf800 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 53 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=7f ostat1=7f ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat1=0x7f err=0xff lsb=0xff msb=0xff ata1: reset tp2 stat0=ff stat1=ff devices=0x0 ioapic0: routing intpin 15 (ISA IRQ 15) to vector 54 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete pnpbios: 13 devices, largest 92 bytes PNP0200: adding dma mask 0x10 PNP0200: adding io range 0-0xf, size=0x10, align=0 PNP0200: adding io range 0x81-0x83, size=0x3, align=0 PNP0200: adding io range 0x87-0x87, size=0x1, align=0 PNP0200: adding io range 0x89-0x8b, size=0x3, align=0 PNP0200: adding io range 0x8f-0x91, size=0x3, align=0 PNP0200: adding io range 0xc0-0xdf, size=0x20, align=0 pnpbios: handle 1 device ID PNP0200 (0002d041) PNP0100: adding irq mask 0x1 PNP0100: adding io range 0x40-0x43, size=0x4, align=0 pnpbios: handle 2 device ID PNP0100 (0001d041) PNP0b00: adding irq mask 0x100 PNP0b00: adding io range 0x70-0x71, size=0x2, align=0 pnpbios: handle 3 device ID PNP0b00 (000bd041) PNP0303: adding irq mask 0x2 PNP0303: adding io range 0x60-0x60, size=0x1, align=0 PNP0303: adding io range 0x64-0x64, size=0x1, align=0 pnpbios: handle 4 device ID PNP0303 (0303d041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0 pnpbios: handle 5 device ID PNP0800 (0008d041) PNP0c04: adding irq mask 0x2000 PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0 pnpbios: handle 6 device ID PNP0c04 (040cd041) INT0800: adding fixed memory32 range 0xffb80000-0xffbfffff, size=0x80000 pnpbios: handle 7 device ID INT0800 (0008d425) PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 PNP0c01: adding fixed memory32 range 0xffb00000-0xffb7ffff, size=0x80000 PNP0c01: adding fixed memory32 range 0xfff00000-0xffffffff, size=0x100000 PNP0c01: adding fixed memory32 range 0xfec00000-0xfec0ffff, size=0x10000 PNP0c01: adding fixed memory32 range 0xfee00000-0xfee0ffff, size=0x10000 PNP0c01: adding fixed memory32 range 0x100000-0xffffff, size=0xf00000 pnpbios: handle 8 device ID PNP0c01 (010cd041) PNP0c02: adding fixed memory32 range 0xf0000-0xf3fff, size=0x4000 PNP0c02: adding fixed memory32 range 0xf4000-0xf7fff, size=0x4000 PNP0c02: adding fixed memory32 range 0xf8000-0xfffff, size=0x8000 PNP0c02: adding fixed memory32 range 0xcc000-0xcffff, size=0x4000 pnpbios: handle 9 device ID PNP0c02 (020cd041) PNP0a03: adding io range 0x290-0x29f, size=0x10, align=0 PNP0a03: adding io range 0x4d0-0x4d1, size=0x2, align=0 PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0 PNP0a03: adding io range 0x400-0x4bf, size=0xc0, align=0 pnpbios: handle 10 device ID PNP0a03 (030ad041) PNP0501: adding irq mask 0x10 PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0 pnpbios: handle 12 device ID PNP0501 (0105d041) PNP0400: adding irq mask 0x80 PNP0400: adding io range 0x378-0x37f, size=0x8, align=0 PNP0400: adding io range 0x778-0x77f, size=0x8, align=0 pnpbios: handle 13 device ID PNP0400 (0004d041) sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xcc000-0xd3fff pnpid ORM0000 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 55 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0067 psm0: strange result for test aux port (2). psm0: failed to reset the aux device. bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port found at 0x378 ppc0: using extended I/O port range ppc0: SPP ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 56 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio0: irq maps: 0x841 0x851 0x841 0x841 sio0: irq maps: 0x841 0x851 0x841 0x841 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x841 0x841 0x841 0x841 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices unknown: can't assign resources (port) unknown: at port 0x60 pnpid PNP0303 on isa0 unknown: failed to probe at port 0x61 pnpid PNP0800 on isa0 unknown: failed to probe at iomem 0xffb80000-0xffbfffff pnpid INT0800 on isa0 unknown: can't assign resources (memory) unknown: at iomem 0-0x9ffff pnpid PNP0c01 on isa0 unknown: can't assign resources (memory) unknown: at iomem 0xf0000-0xf3fff,0xf4000-0xf7fff,0xf8000- 0xfffff,0xcc000-0xcffff pnpid PNP0c02 on isa0 unknown: can't assign resources (port) unknown: at port 0x3f8-0x3ff pnpid PNP0501 on isa0 unknown: can't assign resources (port) unknown: at port 0x378-0x37f pnpid PNP0400 on isa0 ukbd0: on uhub0 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 ums0: on uhub0 ums0: 5 buttons and Z dir. Device configuration finished. procfs registered lapic: Divisor 2, Frequency 100003988 hz Timecounter "TSC" frequency 3200127568 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: no controller detected. ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad0: 238475MB at ata0-master SATA150 ad0: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad0: Intel check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 Trying to mount root from ufs:/dev/ad0s1a start_init: trying /sbin/init em4: Link is up 1000 Mbps Full Duplex em6: Link is up 10 Mbps Half Duplex em7: Link is up 100 Mbps Full Duplex From owner-freebsd-net@FreeBSD.ORG Mon Jul 9 17:19:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 061DF16A400 for ; Mon, 9 Jul 2007 17:19:25 +0000 (UTC) (envelope-from rahman.sazzadur@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id D710A13C484 for ; Mon, 9 Jul 2007 17:19:24 +0000 (UTC) (envelope-from rahman.sazzadur@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so1461536waf for ; Mon, 09 Jul 2007 10:19:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=OcB9Z00cckoT3hKZG7OEy4LzLa5conqVMVqgcULG4JKX6u86wmnn2+DspMXsoktBuXGYNCGAlYvmLNTFP5iUGSAqzD8QCDRaHFP3JbA00u0JjXfgB30X7yjFUxCx0mV72XMSl7R1AZE5M1BamjjEj60/qr1ktokZ8Y7jVLThqpw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=feVhizt67kK42qLF402jbdcXpnRYgfVRPNituB5qkqdxKDV9IrRFBl3ct2+QTYhrhTZm7bfIy1bP8d77fBUHgwzVMGWTW9A3/mh51qz24TxudXlWIaIMrLBSu+ijHubxU7yqhBi27XRyzJcCGAEB4CVyrd1HjbsFbd0SJeGPrUY= Received: by 10.114.154.1 with SMTP id b1mr3323911wae.1184001562393; Mon, 09 Jul 2007 10:19:22 -0700 (PDT) Received: by 10.115.75.4 with HTTP; Mon, 9 Jul 2007 10:19:22 -0700 (PDT) Message-ID: <82bdb5ec0707091019o3f938c05m934acadbaa855876@mail.gmail.com> Date: Mon, 9 Jul 2007 12:19:22 -0500 From: "sazzadur rahman" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: A query regarding compilation IPv6 in SCTP library 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, 09 Jul 2007 17:19:25 -0000 Hi, Is there any way compiling SCTP library without IPv6? I have specified -UAF_INET6 in libnetworking Makefile DEFS, but it didn't work :(. I have found that there is #ifdef AF_INET6 condition in sctp_header.h and in socket.h, there is #define AF_INET6 28. So, the prior condition is a tautology. We couldn't afford removing #define AF_INET6 28 statement as well, because it would create a lot of compilation issues then. I would appriciate any help in this regard. Best regards, Sazzad. From owner-freebsd-net@FreeBSD.ORG Mon Jul 9 17:36:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A29016A46D for ; Mon, 9 Jul 2007 17:36:25 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.230]) by mx1.freebsd.org (Postfix) with ESMTP id 9DCE213C46E for ; Mon, 9 Jul 2007 17:36:24 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so670661nzf for ; Mon, 09 Jul 2007 10:36:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hpXAjDR3u9P/zOnz758CpjIkVWwUWHbY1aQNCOOhc/Pi2kIgfZWmqoo+kkxF3n1ORc/ikU0br7S+JAyGGRWdI9EJL0bq+MtKo6wPEYQ4bNLdlfoM1j/PGan9qSmQwQDBrpoKC9fikL5ANoeSs/kzhjpXXJW8aaaW23tKSayE7wI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rUUygrMplH49Xmt1M/TwSH4vjHTVhE/uRQPmlfkAzMgQBaLGNi9EBR6nBP8tJ8BAtYkKDNryX/zpNXnWS9CmWBxkQ4KWU5tESWmFgFzbuZKTK+VhjV+L3j+lBVPe5jRqR3SfmGES9Esh8yuMUsphw+LmAwAYcMA/uU7neONhW4U= Received: by 10.114.125.2 with SMTP id x2mr3315364wac.1184002583197; Mon, 09 Jul 2007 10:36:23 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Mon, 9 Jul 2007 10:36:22 -0700 (PDT) Message-ID: <2a41acea0707091036k51497883s17ce853d9a68d973@mail.gmail.com> Date: Mon, 9 Jul 2007 10:36:22 -0700 From: "Jack Vogel" To: paketix@bluewin.ch In-Reply-To: <13471228.91981183995990597.JavaMail.webmail@ps8zhh.bluewin.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <13471228.91981183995990597.JavaMail.webmail@ps8zhh.bluewin.ch> Cc: freebsd-net@freebsd.org Subject: Re: 6.2-RELENG/7.0-CURRENT: em(4) fails on 82571EB 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, 09 Jul 2007 17:36:25 -0000 The 82571 device has been supported for a long time, the trick comes when you have a gang of them how the thing is all wired up, we have had issues even with our quad port adapters and some vendor BIOS's. This is a custom so I'm only going to be able to guess that its interrupts. You say no traffic works, on NONE of the ports?? Do you have anyway to disable part of them? Do the 541's work? I need more debugging, assign address to em0, instrument it however you need to, does anything get transmitted, what interrupt handling is done, etc etc... Jack On 7/9/07, paketix@bluewin.ch wrote: > hello everybody > i encountered some problems with the intel 82571EB chipset when i > tried to upgrade from FreeBSD 6.1-RELENG to 6.2-RELENG/7.0-CURRENT on > a network appliance (NEXCOM 1108GL) > the appliance has 3 different intel ethernet controllers soldered > to the motherboard > E1000_DEV_ID_82541GI 0x1076 > E1000_DEV_ID_82571EB_COPPER 0x105E > E1000_DEV_ID_82571EB_SERDES 0x1060 > current intel driver version: > 6.5.3 (from 7.0-CURRENT) > > problem description: > chipset initialisation seems to work OK > ifconfig displays the devices / link state seems to be OK > 'ifconfig up' and 'tcpdump' are NOK (>no packets recieved on > interface - leds indicate packet reception) > interrupts seem to be OK (link up/down triggers em_intr on 6.2- > RELENG - behaviour on 7.0-CURRENT unknown yet) > > affected releases: > it seems to be the same problem on 6.2-RELENG/7.0-CURRENT > 6.1-RELENG works fine... > > anyone interested in tracking this down...? > any experience with this behaviour @intel? > i have a server in the lab which is ready to act as a guinea pig > for tests/paches... > ------- > rgds, pat > > freebsd# uname -a > FreeBSD freebsd.sharedtcs.net 7.0-CURRENT-200706 > FreeBSD 7.0-CURRENT-200706 #0: Sun Jun 3 18:41:02 UTC 2007 > root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > freebsd# pciconf -l | grep em > em0@pci6:0:0: class=0x020000 card=0x10761903 chip=0x105e8086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) > em1@pci6:0:1: class=0x020000 card=0x10761903 chip=0x105e8086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) > em2@pci7:0:0: class=0x020000 card=0x10761903 chip=0x105e8086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) > em3@pci7:0:1: class=0x020000 card=0x10761903 chip=0x105e8086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) > em4@pci8:0:0: class=0x020000 card=0x10761903 chip=0x10608086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. ext. SERDES > for SFP modules) > em5@pci8:0:1: class=0x020000 card=0x10761903 chip=0x10608086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. ext. SERDES > for SFP modules) > em6@pci9:0:0: class=0x020000 card=0x10761903 chip=0x105e8086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) > em7@pci9:0:1: class=0x020000 card=0x10761903 chip=0x105e8086 > rev=0x06 hdr=0x00 (82571EB Gigabit Ethernet Controller w. int. PHY) > em8@pci13:7:0: class=0x020000 card=0x10761903 chip=0x10768086 > rev=0x05 hdr=0x00 (82541EI Gigabit Ethernet Controller w. int. PHY) > em9@pci13:9:0: class=0x020000 card=0x10761903 chip=0x10768086 > rev=0x05 hdr=0x00 (82541EI Gigabit Ethernet Controller w. int. PHY) > > freebsd# cat /var/run/dmesg.boot > Copyright (c) 1992-2007 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 > The Regents of the University of California. All rights > reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-CURRENT-200706 #0: Sun Jun 3 18:41:02 UTC 2007 > root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > Using 32 colors for the VM-PQ tuning (1024, 8) > Preloaded elf kernel "/boot/kernel.orig/kernel" at 0xc0c95000. > MP Configuration Table version 1.4 found at 0xc00f1400 > APIC: Using the MPTable enumerator. > SMP: Added CPU 0 (BSP) > SMP: Added CPU 1 (AP) > MPTable: > Calibrating clock(s) ... i8254 clock: 1193199 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 3200127568 Hz > CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3200.13-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf49 Stepping = 9 > Features=0xbfebfbff MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT, > TM,PBE> > Features2=0x641d > AMD Features=0x20100000 > AMD Features2=0x1 > Logical CPUs per core: 2 > > Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 64 > entries > Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries > 1st-level data cache: 16 KB, 8-way set associative, sectored cache, > 64 byte line size > Trace cache: 12K-uops, 8-way set associative > 2nd-level cache: 1 MB, 8-way set associative, sectored cache, 64 > byte line size > L2 cache: 1024 kbytes, 8-way associative, 64 bytes/line > real memory = 1065287680 (1015 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000001028000 - 0x000000003e5cbfff, 1029324800 bytes (251300 > pages) > avail memory = 1028886528 (981 MB) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > bios32: Found BIOS32 Service Directory header at 0xc00f9350 > bios32: Entry = 0xf9960 (c00f9960) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xf0000+0x9990 > pnpbios: Found PnP BIOS data at 0xc00fa550 > pnpbios: Entry = f0000:a580 Rev = 1.0 > Other BIOS signatures found: > ioapic0: Changing APIC ID to 4 > ioapic0: Assuming intbase of 0 > ioapic0: Routing external 8259A's -> intpin 0 > ioapic0: Routing IRQ 0 -> intpin 2 > ioapic0: intpin 9 trigger: level > lapic: Routing ExtINT -> LINT0 > lapic: Routing NMI -> LINT1 > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: > 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: > 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: > 0x00010000 > wlan_amrr: > wlan: <802.11 Link Layer> > ath_rate: version 1.2 > null: > random: > nfslock: pseudo-device > io: > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > Pentium Pro MTRR support enabled > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413) > rr232x: RocketRAID 232x controller driver v1.02 (Jun 3 2007 18:40: > 23) > npx0: INT 16 interface > cpu0 on motherboard > cpu1 on motherboard > pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 > pci_open(1a): mode1res=0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=060000] [hdr=00] is there > (id=27708086) > pcibios: BIOS version 3.00 > pcib0: pcibus 0 on motherboard > pci0: on pcib0 > pci0: physical bus=0 > found-> vendor=0x8086, dev=0x2770, revid=0x02 > bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > found-> vendor=0x8086, dev=0x2772, revid=0x02 > bus=0, slot=2, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=3 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > map[10]: type Memory, range 32, base 0xfdf00000, size 19, > enabled > map[14]: type I/O Port, range 32, base 0xff00, size 3, > enabled > map[18]: type Prefetchable Memory, range 32, base > 0xd0000000, size 28, enabled > map[1c]: type Memory, range 32, base 0xfdf80000, size 18, > enabled > pcib0: slot 2 INTA routed to irq 16 > found-> vendor=0x8086, dev=0x27d0, revid=0x01 > bus=0, slot=28, func=0 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=3 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > pcib0: slot 28 INTA routed to irq 16 > found-> vendor=0x8086, dev=0x27e2, revid=0x01 > bus=0, slot=28, func=5 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=b, irq=10 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > pcib0: slot 28 INTB routed to irq 17 > found-> vendor=0x8086, dev=0x27c8, revid=0x01 > bus=0, slot=29, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=6 > map[20]: type I/O Port, range 32, base 0xfe00, size 5, > enabled > pcib0: slot 29 INTA routed to irq 23 > found-> vendor=0x8086, dev=0x27c9, revid=0x01 > bus=0, slot=29, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=b, irq=11 > map[20]: type I/O Port, range 32, base 0xfd00, size 5, > enabled > pcib0: slot 29 INTB routed to irq 19 > found-> vendor=0x8086, dev=0x27ca, revid=0x01 > bus=0, slot=29, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=c, irq=5 > map[20]: type I/O Port, range 32, base 0xfc00, size 5, > enabled > pcib0: slot 29 INTC routed to irq 18 > found-> vendor=0x8086, dev=0x27cb, revid=0x01 > bus=0, slot=29, func=3 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=d, irq=3 > map[20]: type I/O Port, range 32, base 0xfb00, size 5, > enabled > pcib0: slot 29 INTD routed to irq 16 > found-> vendor=0x8086, dev=0x27cc, revid=0x01 > bus=0, slot=29, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=6 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xfdfff000, size 10, > enabled > pcib0: slot 29 INTA routed to irq 23 > found-> vendor=0x8086, dev=0x244e, revid=0xe1 > bus=0, slot=30, func=0 > class=06-04-01, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > found-> vendor=0x8086, dev=0x27b8, revid=0x01 > bus=0, slot=31, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > found-> vendor=0x8086, dev=0x27c0, revid=0x01 > bus=0, slot=31, func=2 > class=01-01-8a, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=b, irq=255 > powerspec 2 supports D0 D3 current D0 > map[20]: type I/O Port, range 32, base 0xf800, size 4, > enabled > map[24]: type Memory, range 32, base 0xfdffc000, size 10, > enabled > found-> vendor=0x8086, dev=0x27da, revid=0x01 > bus=0, slot=31, func=3 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=b, irq=11 > map[20]: type I/O Port, range 32, base 0x500, size 5, > enabled > pcib0: slot 31 INTB routed to irq 19 > vgapci0: port 0xff00-0xff07 mem 0xfdf00000- > 0xfdf7ffff,0xd0000000-0xdfffffff,0xfdf80000-0xfdfbffff irq 16 at > device 2.0 on pci0 > agp0: on vgapci0 > vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xfdf00000 > vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xfdf00000 > vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at 0xfdf80000 > vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at > 0xd0000000 > agp0: detected 7932k stolen memory > agp0: aperture size is 256M > pcib1: irq 16 at device 28.0 on pci0 > pcib1: secondary bus 1 > pcib1: subordinate bus 9 > pcib1: I/O decode 0x6000-0xcfff > pcib1: memory decode 0xfd700000-0xfdefffff > pcib1: prefetched decode 0xfce00000-0xfd4fffff > pci1: on pcib1 > pci1: physical bus=1 > found-> vendor=0x10b5, dev=0x8524, revid=0xbb > bus=1, slot=0, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0xfdee0000, size 17, > enabled > pcib1: requested memory range 0xfdee0000-0xfdefffff: good > pcib1: slot 0 INTA routed to irq 16 > pcib2: mem 0xfdee0000-0xfdefffff irq 16 at > device 0.0 on pci1 > pcib2: secondary bus 2 > pcib2: subordinate bus 9 > pcib2: I/O decode 0x6000-0xcfff > pcib2: memory decode 0xfd700000-0xfddfffff > pcib2: prefetched decode 0xfce00000-0xfd4fffff > pci2: on pcib2 > pci2: physical bus=2 > found-> vendor=0x10b5, dev=0x8524, revid=0xbb > bus=2, slot=1, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 1 INTA routed to irq 16 > found-> vendor=0x10b5, dev=0x8524, revid=0xbb > bus=2, slot=2, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 2 INTA routed to irq 16 > found-> vendor=0x10b5, dev=0x8524, revid=0xbb > bus=2, slot=3, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 3 INTA routed to irq 16 > found-> vendor=0x10b5, dev=0x8524, revid=0xbb > bus=2, slot=8, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 8 INTA routed to irq 16 > found-> vendor=0x10b5, dev=0x8524, revid=0xbb > bus=2, slot=9, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 9 INTA routed to irq 16 > found-> vendor=0x10b5, dev=0x8524, revid=0xbb > bus=2, slot=10, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 10 INTA routed to irq 16 > found-> vendor=0x10b5, dev=0x8524, revid=0xbb > bus=2, slot=11, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 11 INTA routed to irq 16 > pcib3: irq 16 at device 1.0 on pci2 > pcib3: secondary bus 3 > pcib3: subordinate bus 3 > pcib3: I/O decode 0xc000-0xcfff > pcib3: memory decode 0xfdd00000-0xfddfffff > pcib3: prefetched decode 0xfd400000-0xfd4fffff > pci3: on pcib3 > pci3: physical bus=3 > pcib4: irq 16 at device 2.0 on pci2 > pcib4: secondary bus 4 > pcib4: subordinate bus 4 > pcib4: I/O decode 0xb000-0xbfff > pcib4: memory decode 0xfdc00000-0xfdcfffff > pcib4: prefetched decode 0xfd300000-0xfd3fffff > pci4: on pcib4 > pci4: physical bus=4 > pcib5: irq 16 at device 3.0 on pci2 > pcib5: secondary bus 5 > pcib5: subordinate bus 5 > pcib5: I/O decode 0xa000-0xafff > pcib5: memory decode 0xfdb00000-0xfdbfffff > pcib5: prefetched decode 0xfd200000-0xfd2fffff > pci5: on pcib5 > pci5: physical bus=5 > pcib6: irq 16 at device 8.0 on pci2 > pcib6: secondary bus 6 > pcib6: subordinate bus 6 > pcib6: I/O decode 0x9000-0x9fff > pcib6: memory decode 0xfda00000-0xfdafffff > pcib6: prefetched decode 0xfd100000-0xfd1fffff > pci6: on pcib6 > pci6: physical bus=6 > found-> vendor=0x8086, dev=0x105e, revid=0x06 > bus=6, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > found-> vendor=0x8086, dev=0x105e, revid=0x06 > bus=6, slot=0, func=1 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=b, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > em0: at > device 0.0 on pci6 > pcib6: em0 requested memory range 0xfda00000-0xfdafffff: good > pcib2: em0 requested memory range 0xfda00000-0xfdafffff: good > pcib1: em0 requested memory range 0xfda00000-0xfdafffff: good > em0: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfda00000 > pcib6: slot 0 INTA routed to irq 16 > em0: bpf attached > em0: Ethernet address: 00:10:f3:0c:5b:36 > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 48 > em0: [FILTER] > em1: at > device 0.1 on pci6 > pcib6: em1 requested memory range 0xfda00000-0xfdafffff: good > pcib2: em1 requested memory range 0xfda00000-0xfdafffff: good > pcib1: em1 requested memory range 0xfda00000-0xfdafffff: good > em1: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfda20000 > pcib6: slot 0 INTB routed to irq 17 > em1: bpf attached > em1: Ethernet address: 00:10:f3:0c:5b:37 > ioapic0: routing intpin 17 (PCI IRQ 17) to vector 49 > em1: [FILTER] > pcib7: irq 16 at device 9.0 on pci2 > pcib7: secondary bus 7 > pcib7: subordinate bus 7 > pcib7: I/O decode 0x8000-0x8fff > pcib7: memory decode 0xfd900000-0xfd9fffff > pcib7: prefetched decode 0xfd000000-0xfd0fffff > pci7: on pcib7 > pci7: physical bus=7 > found-> vendor=0x8086, dev=0x105e, revid=0x06 > bus=7, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > found-> vendor=0x8086, dev=0x105e, revid=0x06 > bus=7, slot=0, func=1 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=b, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > em2: at > device 0.0 on pci7 > pcib7: em2 requested memory range 0xfd900000-0xfd9fffff: good > pcib2: em2 requested memory range 0xfd900000-0xfd9fffff: good > pcib1: em2 requested memory range 0xfd900000-0xfd9fffff: good > em2: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfd900000 > pcib7: slot 0 INTA routed to irq 17 > em2: bpf attached > em2: Ethernet address: 00:10:f3:0c:5b:38 > em2: [FILTER] > em3: at > device 0.1 on pci7 > pcib7: em3 requested memory range 0xfd900000-0xfd9fffff: good > pcib2: em3 requested memory range 0xfd900000-0xfd9fffff: good > pcib1: em3 requested memory range 0xfd900000-0xfd9fffff: good > em3: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfd920000 > pcib7: slot 0 INTB routed to irq 18 > em3: bpf attached > em3: Ethernet address: 00:10:f3:0c:5b:39 > ioapic0: routing intpin 18 (PCI IRQ 18) to vector 50 > em3: [FILTER] > pcib8: irq 16 at device 10.0 on pci2 > pcib8: secondary bus 8 > pcib8: subordinate bus 8 > pcib8: I/O decode 0x7000-0x7fff > pcib8: memory decode 0xfd800000-0xfd8fffff > pcib8: prefetched decode 0xfcf00000-0xfcffffff > pci8: on pcib8 > pci8: physical bus=8 > pcib9: irq 16 at device 11.0 on pci2 > pcib9: secondary bus 9 > pcib9: subordinate bus 9 > pcib9: I/O decode 0x6000-0x6fff > pcib9: memory decode 0xfd700000-0xfd7fffff > pcib9: prefetched decode 0xfce00000-0xfcefffff > pci9: on pcib9 > pci9: physical bus=9 > found-> vendor=0x8086, dev=0x105e, revid=0x06 > bus=9, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > found-> vendor=0x8086, dev=0x105e, revid=0x06 > bus=9, slot=0, func=1 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > intpin=b, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > em4: at > device 0.0 on pci9 > pcib9: em4 requested memory range 0xfd700000-0xfd7fffff: good > pcib2: em4 requested memory range 0xfd700000-0xfd7fffff: good > pcib1: em4 requested memory range 0xfd700000-0xfd7fffff: good > em4: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfd700000 > pcib9: slot 0 INTA routed to irq 19 > em4: bpf attached > em4: Ethernet address: 00:10:f3:0c:5b:34 > ioapic0: routing intpin 19 (PCI IRQ 19) to vector 51 > em4: [FILTER] > em5: at > device 0.1 on pci9 > pcib9: em5 requested memory range 0xfd700000-0xfd7fffff: good > pcib2: em5 requested memory range 0xfd700000-0xfd7fffff: good > pcib1: em5 requested memory range 0xfd700000-0xfd7fffff: good > em5: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfd720000 > pcib9: slot 0 INTB routed to irq 16 > em5: bpf attached > em5: Ethernet address: 00:10:f3:0c:5b:35 > em5: [FILTER] > pcib10: irq 17 at device 28.5 on pci0 > pcib10: secondary bus 10 > pcib10: subordinate bus 12 > pcib10: I/O decode 0x4000-0x5fff > pcib10: memory decode 0xfcc00000-0xfcdfffff > pcib10: prefetched decode 0xfca00000-0xfcbfffff > pci10: on pcib10 > pci10: physical bus=10 > found-> vendor=0x8086, dev=0x0340, revid=0x09 > bus=10, slot=0, func=0 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > found-> vendor=0x8086, dev=0x0341, revid=0x09 > bus=10, slot=0, func=2 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 > ns) > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib11: at device 0.0 on pci10 > pcib11: secondary bus 11 > pcib11: subordinate bus 11 > pcib11: I/O decode 0x5000-0x5fff > pcib11: memory decode 0xfcd00000-0xfcdfffff > pcib11: prefetched decode 0xfcb00000-0xfcbfffff > pci11: on pcib11 > pci11: physical bus=11 > pcib12: at device 0.2 on pci10 > pcib12: secondary bus 12 > pcib12: subordinate bus 12 > pcib12: I/O decode 0x4000-0x4fff > pcib12: memory decode 0xfcc00000-0xfccfffff > pcib12: prefetched decode 0xfca00000-0xfcafffff > pci12: on pcib12 > pci12: physical bus=12 > uhci0: port 0xfe00-0xfe1f irq 23 at > device 29.0 on pci0 > uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfe00 > ioapic0: routing intpin 23 (PCI IRQ 23) to vector 52 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on > usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0xfd00-0xfd1f irq 19 at > device 29.1 on pci0 > uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfd00 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on > usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0xfc00-0xfc1f irq 18 at > device 29.2 on pci0 > uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfc00 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: on > usb2 > uhub2: 2 ports with 2 removable, self powered > uhci3: port 0xfb00-0xfb1f irq 16 at > device 29.3 on pci0 > uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfb00 > uhci3: [GIANT-LOCKED] > uhci3: [ITHREAD] > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: on > usb3 > uhub3: 2 ports with 2 removable, self powered > ehci0: mem 0xfdfff000- > 0xfdfff3ff irq 23 at device 29.7 on pci0 > ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfdfff000 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb4: EHCI version 1.0 > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > usb4: on ehci0 > usb4: USB revision 2.0 > uhub4: on > usb4 > uhub4: 8 ports with 8 removable, self powered > pcib13: at device 30.0 on pci0 > pcib13: secondary bus 13 > pcib13: subordinate bus 13 > pcib13: I/O decode 0xd000-0xdfff > pcib13: memory decode 0xfd600000-0xfd6fffff > pcib13: prefetched decode 0xfd500000-0xfd5fffff > pcib13: Subtractively decoded bridge. > pci13: on pcib13 > pci13: physical bus=13 > found-> vendor=0x8086, dev=0x1076, revid=0x05 > bus=13, slot=7, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0230, cachelnsz=16 (dwords) > lattimer=0xfc (7560 ns), mingnt=0xff (63750 ns), > maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xfd6e0000, size 17, > enabled > pcib13: requested memory range 0xfd6e0000-0xfd6fffff: good > map[14]: type Memory, range 32, base 0xfd6c0000, size 17, > enabled > pcib13: requested memory range 0xfd6c0000-0xfd6dffff: good > map[18]: type I/O Port, range 32, base 0xdf00, size 6, > enabled > pcib13: requested I/O range 0xdf00-0xdf3f: in range > pcib13: slot 7 INTA routed to irq 17 > found-> vendor=0x8086, dev=0x1076, revid=0x05 > bus=13, slot=9, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0230, cachelnsz=16 (dwords) > lattimer=0xfc (7560 ns), mingnt=0xff (63750 ns), > maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xfd6a0000, size 17, > enabled > pcib13: requested memory range 0xfd6a0000-0xfd6bffff: good > map[14]: type Memory, range 32, base 0xfd680000, size 17, > enabled > pcib13: requested memory range 0xfd680000-0xfd69ffff: good > map[18]: type I/O Port, range 32, base 0xde00, size 6, > enabled > pcib13: requested I/O range 0xde00-0xde3f: in range > pcib13: slot 9 INTA routed to irq 19 > em6: port > 0xdf00-0xdf3f mem 0xfd6e0000-0xfd6fffff,0xfd6c0000-0xfd6dffff irq 17 > at device 7.0 on pci13 > em6: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfd6e0000 > em6: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdf00 > em6: bpf attached > em6: Ethernet address: 00:10:f3:0c:5b:33 > em6: [FILTER] > em7: port > 0xde00-0xde3f mem 0xfd6a0000-0xfd6bffff,0xfd680000-0xfd69ffff irq 19 > at device 9.0 on pci13 > em7: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfd6a0000 > em7: Reserved 0x40 bytes for rid 0x18 type 4 at 0xde00 > em7: bpf attached > em7: Ethernet address: 00:10:f3:0c:5b:32 > em7: [FILTER] > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6, > 0x170-0x177,0x376,0xf800-0xf80f mem 0xfdffc000-0xfdffc3ff at device > 31.2 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf800 > ata0: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=03 ostat0=50 ostat1=00 > ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 > ata0: reset tp2 stat0=50 stat1=00 devices=0x1 > ioapic0: routing intpin 14 (ISA IRQ 14) to vector 53 > ata0: [MPSAFE] > ata0: [ITHREAD] > ata1: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 > atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 > ata1: reset tp1 mask=03 ostat0=7f ostat1=7f > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff > ata1: stat1=0x7f err=0xff lsb=0xff msb=0xff > ata1: reset tp2 stat0=ff stat1=ff devices=0x0 > ioapic0: routing intpin 15 (ISA IRQ 15) to vector 54 > ata1: [MPSAFE] > ata1: [ITHREAD] > pci0: at device 31.3 (no driver attached) > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > ex_isa_identify() > ata: ata0 already exists; skipping it > ata: ata1 already exists; skipping it > pnp_identify: Trying Read_Port at 203 > pnp_identify: Trying Read_Port at 243 > pnp_identify: Trying Read_Port at 283 > pnp_identify: Trying Read_Port at 2c3 > pnp_identify: Trying Read_Port at 303 > pnp_identify: Trying Read_Port at 343 > pnp_identify: Trying Read_Port at 383 > pnp_identify: Trying Read_Port at 3c3 > PNP Identify complete > pnpbios: 13 devices, largest 92 bytes > PNP0200: adding dma mask 0x10 > PNP0200: adding io range 0-0xf, size=0x10, align=0 > PNP0200: adding io range 0x81-0x83, size=0x3, align=0 > PNP0200: adding io range 0x87-0x87, size=0x1, align=0 > PNP0200: adding io range 0x89-0x8b, size=0x3, align=0 > PNP0200: adding io range 0x8f-0x91, size=0x3, align=0 > PNP0200: adding io range 0xc0-0xdf, size=0x20, align=0 > pnpbios: handle 1 device ID PNP0200 (0002d041) > PNP0100: adding irq mask 0x1 > PNP0100: adding io range 0x40-0x43, size=0x4, align=0 > pnpbios: handle 2 device ID PNP0100 (0001d041) > PNP0b00: adding irq mask 0x100 > PNP0b00: adding io range 0x70-0x71, size=0x2, align=0 > pnpbios: handle 3 device ID PNP0b00 (000bd041) > PNP0303: adding irq mask 0x2 > PNP0303: adding io range 0x60-0x60, size=0x1, align=0 > PNP0303: adding io range 0x64-0x64, size=0x1, align=0 > pnpbios: handle 4 device ID PNP0303 (0303d041) > PNP0800: adding io range 0x61-0x61, size=0x1, align=0 > pnpbios: handle 5 device ID PNP0800 (0008d041) > PNP0c04: adding irq mask 0x2000 > PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0 > pnpbios: handle 6 device ID PNP0c04 (040cd041) > INT0800: adding fixed memory32 range 0xffb80000-0xffbfffff, > size=0x80000 > pnpbios: handle 7 device ID INT0800 (0008d425) > PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 > PNP0c01: adding fixed memory32 range 0xffb00000-0xffb7ffff, > size=0x80000 > PNP0c01: adding fixed memory32 range 0xfff00000-0xffffffff, > size=0x100000 > PNP0c01: adding fixed memory32 range 0xfec00000-0xfec0ffff, > size=0x10000 > PNP0c01: adding fixed memory32 range 0xfee00000-0xfee0ffff, > size=0x10000 > PNP0c01: adding fixed memory32 range 0x100000-0xffffff, > size=0xf00000 > pnpbios: handle 8 device ID PNP0c01 (010cd041) > PNP0c02: adding fixed memory32 range 0xf0000-0xf3fff, size=0x4000 > PNP0c02: adding fixed memory32 range 0xf4000-0xf7fff, size=0x4000 > PNP0c02: adding fixed memory32 range 0xf8000-0xfffff, size=0x8000 > PNP0c02: adding fixed memory32 range 0xcc000-0xcffff, size=0x4000 > pnpbios: handle 9 device ID PNP0c02 (020cd041) > PNP0a03: adding io range 0x290-0x29f, size=0x10, align=0 > PNP0a03: adding io range 0x4d0-0x4d1, size=0x2, align=0 > PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0 > PNP0a03: adding io range 0x400-0x4bf, size=0xc0, align=0 > pnpbios: handle 10 device ID PNP0a03 (030ad041) > PNP0501: adding irq mask 0x10 > PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0 > pnpbios: handle 12 device ID PNP0501 (0105d041) > PNP0400: adding irq mask 0x80 > PNP0400: adding io range 0x378-0x37f, size=0x8, align=0 > PNP0400: adding io range 0x778-0x77f, size=0x8, align=0 > pnpbios: handle 13 device ID PNP0400 (0004d041) > sc: sc0 already exists; skipping it > vga: vga0 already exists; skipping it > isa_probe_children: disabling PnP devices > isa_probe_children: probing non-PnP devices > pmtimer0 on isa0 > orm0: at iomem 0xcc000-0xd3fff pnpid ORM0000 on > isa0 > adv0: not probed (disabled) > aha0: not probed (disabled) > aic0: not probed (disabled) > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to vector 55 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: current command byte:0067 > psm0: strange result for test aux port (2). > psm0: failed to reset the aux device. > bt0: not probed (disabled) > cs0: not probed (disabled) > ed0: not probed (disabled) > fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > fe0: not probed (disabled) > ie0: not probed (disabled) > le0: not probed (disabled) > ppc0: parallel port found at 0x378 > ppc0: using extended I/O port range > ppc0: SPP > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: bpf attached > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ioapic0: routing intpin 7 (ISA IRQ 7) to vector 56 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) > sio0: irq maps: 0x841 0x851 0x841 0x841 > sio0: irq maps: 0x841 0x851 0x841 0x841 > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57 > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: irq maps: 0x841 0x841 0x841 0x841 > sio1: probe failed test(s): 0 1 2 4 6 7 9 > sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > sio2: not probed (disabled) > sio3: not probed (disabled) > sn0: not probed (disabled) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff > on isa0 > vt0: not probed (disabled) > isa_probe_children: probing PnP devices > unknown: can't assign resources (port) > unknown: at port 0x60 pnpid PNP0303 on isa0 > unknown: failed to probe at port 0x61 pnpid PNP0800 on > isa0 > unknown: failed to probe at iomem 0xffb80000-0xffbfffff > pnpid INT0800 on isa0 > unknown: can't assign resources (memory) > unknown: at iomem 0-0x9ffff pnpid PNP0c01 on isa0 > unknown: can't assign resources (memory) > unknown: at iomem 0xf0000-0xf3fff,0xf4000-0xf7fff,0xf8000- > 0xfffff,0xcc000-0xcffff pnpid PNP0c02 on isa0 > unknown: can't assign resources (port) > unknown: at port 0x3f8-0x3ff pnpid PNP0501 on isa0 > unknown: can't assign resources (port) > unknown: at port 0x378-0x37f pnpid PNP0400 on isa0 > ukbd0: on > uhub0 > kbd2 at ukbd0 > kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 > ums0: on > uhub0 > ums0: 5 buttons and Z dir. > Device configuration finished. > procfs registered > lapic: Divisor 2, Frequency 100003988 hz > Timecounter "TSC" frequency 3200127568 Hz quality -100 > Timecounters tick every 1.000 msec > lo0: bpf attached > rr232x: no controller detected. > ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire > ad0: 238475MB at ata0-master SATA150 > ad0: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 > depth queue > GEOM: new disk ad0 > ad0: Intel check1 failed > ad0: Adaptec check1 failed > ad0: LSI (v3) check1 failed > ad0: LSI (v2) check1 failed > ad0: FreeBSD check1 failed > ATA PseudoRAID loaded > SMP: AP CPU #1 Launched! > cpu1 AP: > ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: > 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: > 0x000001ff > timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: > 0x00010000 > Trying to mount root from ufs:/dev/ad0s1a > start_init: trying /sbin/init > em4: Link is up 1000 Mbps Full Duplex > em6: Link is up 10 Mbps Half Duplex > em7: Link is up 100 Mbps Full Duplex > > > _______________________________________________ > 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" > From owner-freebsd-net@FreeBSD.ORG Mon Jul 9 17:36:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0E8C16A41F for ; Mon, 9 Jul 2007 17:36:48 +0000 (UTC) (envelope-from peter.lei@ieee.org) Received: from alnrmhc15.comcast.net (alnrmhc15.comcast.net [204.127.225.95]) by mx1.freebsd.org (Postfix) with ESMTP id 7CEA913C447 for ; Mon, 9 Jul 2007 17:36:48 +0000 (UTC) (envelope-from peter.lei@ieee.org) Received: from macbookpro.lei.chicago.il.us (c-24-13-182-11.hsd1.il.comcast.net[24.13.182.11]) by comcast.net (alnrmhc15) with ESMTP id <20070709173646b1500e2ahde>; Mon, 9 Jul 2007 17:36:46 +0000 Message-ID: <4692721E.6000909@ieee.org> Date: Mon, 09 Jul 2007 12:36:30 -0500 From: Peter Lei User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: sazzadur rahman References: <82bdb5ec0707091019o3f938c05m934acadbaa855876@mail.gmail.com> In-Reply-To: <82bdb5ec0707091019o3f938c05m934acadbaa855876@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: A query regarding compilation IPv6 in SCTP library 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, 09 Jul 2007 17:36:48 -0000 From the "NOTES" file in /usr/src/sys/conf: # Note YOU MUST have both INET and INET6 defined. # you don't have to enable V6, but SCTP is # dual stacked and so far we have not teased apart # the V6 and V4.. since an association can span # both a V6 and V4 address at the SAME time :-) This includes the library portion... We simply have not gone through all of the code to #ifdef properly to do a INET or INET6 only build; it's only minimally done so far. --peter sazzadur rahman wrote: > Hi, > > Is there any way compiling SCTP library without IPv6? I have specified > -UAF_INET6 in libnetworking Makefile DEFS, but it didn't work :(. > I have found that there is #ifdef AF_INET6 condition in sctp_header.h > and in > socket.h, there is #define AF_INET6 28. So, the prior condition is a > tautology. We couldn't afford removing #define AF_INET6 28 statement as > well, because it would create a lot of compilation issues then. > > I would appriciate any help in this regard. > > Best regards, > Sazzad. > _______________________________________________ > 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" > From owner-freebsd-net@FreeBSD.ORG Mon Jul 9 20:06:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2512F16A421 for ; Mon, 9 Jul 2007 20:06:32 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mx1.freebsd.org (Postfix) with ESMTP id F12E713C457 for ; Mon, 9 Jul 2007 20:06:31 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 09 Jul 2007 13:06:31 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFMxkkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,517,1175497200"; d="scan'208"; a="384443073:sNHT177672358" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l69K6UWI002933; Mon, 9 Jul 2007 13:06:30 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l69K6GnM028885; Mon, 9 Jul 2007 20:06:30 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:06:30 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:06:29 -0700 Message-ID: <469295A6.8070004@cisco.com> Date: Mon, 09 Jul 2007 16:08:06 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070626 FreeBSD/i386 SeaMonkey/2.0a1pre MIME-Version: 1.0 To: sazzadur rahman References: <82bdb5ec0707091019o3f938c05m934acadbaa855876@mail.gmail.com> In-Reply-To: <82bdb5ec0707091019o3f938c05m934acadbaa855876@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 20:06:30.0115 (UTC) FILETIME=[A3A1B330:01C7C264] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1198; t=1184011590; x=1184875590; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20A=20query=20regarding=20compilation=20IPv6=20in=20SCT P=20library |Sender:=20; bh=DigjTm1XZpKEoq+Ga3j4wTo1VQqN+O3KkGd/RFsOxNM=; b=eNIUReMbOR8F/QCegtMyyBT2L0qvqXEvcVs8TgLwK1SOSZDtsYFz1AxwMWLnWc98kBm4gFdb 2LbvHznq0kqVD4zwEeHsAYdzK5kQ681Ms/ISH0I/Sod1kk4/B/N5QLA+; Authentication-Results: sj-dkim-2; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); Cc: freebsd-net@freebsd.org Subject: Re: A query regarding compilation IPv6 in SCTP library 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, 09 Jul 2007 20:06:32 -0000 sazzadur rahman wrote: > Hi, > > Is there any way compiling SCTP library without IPv6? I have specified > -UAF_INET6 in libnetworking Makefile DEFS, but it didn't work :(. > I have found that there is #ifdef AF_INET6 condition in sctp_header.h > and in Nope.. sorry .. the stack is dual stack only. We had someone on our small team at one time work a little bit towards making it so you could compile it without AF_INET or without AF_INET6... but that work never got completed :-( Besides.. its no big deal compile in IPv6.. but just dont enable it.. :-D R > socket.h, there is #define AF_INET6 28. So, the prior condition is a > tautology. We couldn't afford removing #define AF_INET6 28 statement as > well, because it would create a lot of compilation issues then. > > I would appriciate any help in this regard. > > Best regards, > Sazzad. > _______________________________________________ > 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" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 04:08:21 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B6E516A400 for ; Tue, 10 Jul 2007 04:08:21 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from mail29.bluewin.ch (mail29.bluewin.ch [195.186.18.70]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC3413C487 for ; Tue, 10 Jul 2007 04:08:20 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from ps19zhb.bluewin.ch (195.186.18.201) by mail29.bluewin.ch (Bluewin 7.3.121) id 467A74DC004FEB0E; Tue, 10 Jul 2007 04:08:19 +0000 Received: from ps19zhb (localhost [127.0.0.1]) by ps19zhb.bluewin.ch (Postfix) with ESMTP id 98BE2FB6; Tue, 10 Jul 2007 04:08:19 +0000 (GMT) Message-ID: <10349913.150741184040499622.JavaMail.webmail@ps19zhb.bluewin.ch> Date: Tue, 10 Jul 2007 04:08:19 +0000 (GMT) From: "paketix@bluewin.ch" To: MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-FXIT-IP: 85.5.220.152 Cc: freebsd-net@freebsd.org Subject: AW: Re: 6.2-RELENG/7.0-CURRENT: em(4) fails on 82571EB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: paketix@bluewin.ch List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 04:08:21 -0000 many thanks for your feedback jack you might well be right with the problems popping up when using a=20 bunch of 571's ...anyway - its just that on 6.1-RELENG we never had a problem with=20 the 571's [ You say no traffic works, on NONE of the ports?? Do you have anyway to disable part of them? Do the 541's work? ] the 541's work - the problem affects only the 571's will try to disable some of the 571's in the bios today [I need more debugging, assign address to em0, instrument it however you need to] i can do that - plus kernel recompilation/patching and testing=20 whatever you might need i can provide you access to the box over internet if you like [does anything get transmitted] as far as i remember this causes some 'watchdog - timer' messages=20 because of the transmit buffer not being emptied not checked recently - will do this today [what interrupt handling is done, etc etc...] as far as i remember *only* link up/down interrupt is working -=20 recieve interrupts 'fails'. will test this for transmit today for=20 transmit not checked recently - will insert a printf into=20 em_intr/em_fast_intr today to check this rgds, pat ----Urspr=C3=BCngliche Nachricht---- Von: jfvogel@gmail.com Datum: 09.07.2007 19:36 An: Kopie: Betreff: Re: 6.2-RELENG/7.0-CURRENT: em(4) fails on 82571EB The 82571 device has been supported for a long time, the trick comes when you have a gang of them how the thing is all wired up, we have had issues even with our quad port adapters and some vendor BIOS's. This is a custom so I'm only going to be able to guess that its interrupts. You say no traffic works, on NONE of the ports?? Do you have anyway to disable part of them? Do the 541's work? I need more debugging, assign address to em0, instrument it however you need to, does anything get transmitted, what interrupt handling is done, etc etc... Jack On 7/9/07, paketix@bluewin.ch wrote: > hello everybody > i encountered some problems with the intel 82571EB chipset when=20 i > tried to upgrade from FreeBSD 6.1-RELENG to 6.2-RELENG/7.0- CURRENT on > a network appliance (NEXCOM 1108GL) > the appliance has 3 different intel ethernet controllers=20 soldered > to the motherboard > E1000_DEV_ID_82541GI 0x1076 > E1000_DEV_ID_82571EB_COPPER 0x105E > E1000_DEV_ID_82571EB_SERDES 0x1060 > current intel driver version: > 6.5.3 (from 7.0-CURRENT) > > problem description: > chipset initialisation seems to work OK > ifconfig displays the devices / link state seems to be OK > 'ifconfig up' and 'tcpdump' are NOK (>no packets recieved on > interface - leds indicate packet reception) > interrupts seem to be OK (link up/down triggers em_intr on=20 6.2- > RELENG - behaviour on 7.0-CURRENT unknown yet) > > affected releases: > it seems to be the same problem on 6.2-RELENG/7.0-CURRENT > 6.1-RELENG works fine... > > anyone interested in tracking this down...? > any experience with this behaviour @intel? > i have a server in the lab which is ready to act as a guinea pig > for tests/paches... > ------- > rgds, pat > > freebsd# uname -a > FreeBSD freebsd.sharedtcs.net 7.0-CURRENT-200706 > FreeBSD 7.0-CURRENT-200706 #0: Sun Jun 3 18:41:02 UTC 2007 > root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > freebsd# pciconf -l | grep em > em0@pci6:0:0: class=3D0x020000 card=3D0x10761903 chip=3D0x105e8086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. int.=20 PHY) > em1@pci6:0:1: class=3D0x020000 card=3D0x10761903 chip=3D0x105e8086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. int.=20 PHY) > em2@pci7:0:0: class=3D0x020000 card=3D0x10761903 chip=3D0x105e8086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. int.=20 PHY) > em3@pci7:0:1: class=3D0x020000 card=3D0x10761903 chip=3D0x105e8086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. int.=20 PHY) > em4@pci8:0:0: class=3D0x020000 card=3D0x10761903 chip=3D0x10608086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. ext.=20 SERDES > for SFP modules) > em5@pci8:0:1: class=3D0x020000 card=3D0x10761903 chip=3D0x10608086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. ext.=20 SERDES > for SFP modules) > em6@pci9:0:0: class=3D0x020000 card=3D0x10761903 chip=3D0x105e8086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. int.=20 PHY) > em7@pci9:0:1: class=3D0x020000 card=3D0x10761903 chip=3D0x105e8086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. int.=20 PHY) > em8@pci13:7:0: class=3D0x020000 card=3D0x10761903 chip=3D0x10768086 > rev=3D0x05 hdr=3D0x00 (82541EI Gigabit Ethernet Controller w. int.=20 PHY) > em9@pci13:9:0: class=3D0x020000 card=3D0x10761903 chip=3D0x10768086 > rev=3D0x05 hdr=3D0x00 (82541EI Gigabit Ethernet Controller w. int.=20 PHY) > > freebsd# cat /var/run/dmesg.boot > Copyright (c) 1992-2007 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,=20 1993, > 1994 > The Regents of the University of California. All rights > reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-CURRENT-200706 #0: Sun Jun 3 18:41:02 UTC 2007 > root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > Using 32 colors for the VM-PQ tuning (1024, 8) > Preloaded elf kernel "/boot/kernel.orig/kernel" at 0xc0c95000. > MP Configuration Table version 1.4 found at 0xc00f1400 > APIC: Using the MPTable enumerator. > SMP: Added CPU 0 (BSP) > SMP: Added CPU 1 (AP) > MPTable: > Calibrating clock(s) ... i8254 clock: 1193199 Hz > CLK_USE_I8254_CALIBRATION not specified - using default=20 frequency > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 3200127568 Hz > CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3200.13-MHz 686-class=20 CPU) > Origin =3D "GenuineIntel" Id =3D 0xf49 Stepping =3D 9 > Features=3D0xbfebfbff MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS, HTT, > TM,PBE> > Features2=3D0x641d > AMD Features=3D0x20100000 > AMD Features2=3D0x1 > Logical CPUs per core: 2 > > Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 64 > entries > Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries > 1st-level data cache: 16 KB, 8-way set associative, sectored=20 cache, > 64 byte line size > Trace cache: 12K-uops, 8-way set associative > 2nd-level cache: 1 MB, 8-way set associative, sectored cache, 64 > byte line size > L2 cache: 1024 kbytes, 8-way associative, 64 bytes/line > real memory =3D 1065287680 (1015 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157=20 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768=20 pages) > 0x0000000001028000 - 0x000000003e5cbfff, 1029324800 bytes=20 (251300 > pages) > avail memory =3D 1028886528 (981 MB) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > bios32: Found BIOS32 Service Directory header at 0xc00f9350 > bios32: Entry =3D 0xf9960 (c00f9960) Rev =3D 0 Len =3D 1 > pcibios: PCI BIOS entry at 0xf0000+0x9990 > pnpbios: Found PnP BIOS data at 0xc00fa550 > pnpbios: Entry =3D f0000:a580 Rev =3D 1.0 > Other BIOS signatures found: > ioapic0: Changing APIC ID to 4 > ioapic0: Assuming intbase of 0 > ioapic0: Routing external 8259A's -> intpin 0 > ioapic0: Routing IRQ 0 -> intpin 2 > ioapic0: intpin 9 trigger: level > lapic: Routing ExtINT -> LINT0 > lapic: Routing NMI -> LINT1 > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: > 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: > 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: > 0x00010000 > wlan_amrr: > wlan: <802.11 Link Layer> > ath_rate: version 1.2 > null: > random: > nfslock: pseudo-device > io: > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > Pentium Pro MTRR support enabled > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112,=20 RF2413, > RF5413) > rr232x: RocketRAID 232x controller driver v1.02 (Jun 3 2007 18: 40: > 23) > npx0: INT 16 interface > cpu0 on motherboard > cpu1 on motherboard > pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 > pci_open(1a): mode1res=3D0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there > (id=3D27708086) > pcibios: BIOS version 3.00 > pcib0: pcibus 0 on motherboard > pci0: on pcib0 > pci0: physical bus=3D0 > found-> vendor=3D0x8086, dev=3D0x2770, revid=3D0x02 > bus=3D0, slot=3D0, func=3D0 > class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0006, statreg=3D0x2090, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > found-> vendor=3D0x8086, dev=3D0x2772, revid=3D0x02 > bus=3D0, slot=3D2, func=3D0 > class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0090, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > map[10]: type Memory, range 32, base 0xfdf00000, size=20 19, > enabled > map[14]: type I/O Port, range 32, base 0xff00, size 3, > enabled > map[18]: type Prefetchable Memory, range 32, base > 0xd0000000, size 28, enabled > map[1c]: type Memory, range 32, base 0xfdf80000, size=20 18, > enabled > pcib0: slot 2 INTA routed to irq 16 > found-> vendor=3D0x8086, dev=3D0x27d0, revid=3D0x01 > bus=3D0, slot=3D28, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > pcib0: slot 28 INTA routed to irq 16 > found-> vendor=3D0x8086, dev=3D0x27e2, revid=3D0x01 > bus=3D0, slot=3D28, func=3D5 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Db, irq=3D10 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > pcib0: slot 28 INTB routed to irq 17 > found-> vendor=3D0x8086, dev=3D0x27c8, revid=3D0x01 > bus=3D0, slot=3D29, func=3D0 > class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D6 > map[20]: type I/O Port, range 32, base 0xfe00, size 5, > enabled > pcib0: slot 29 INTA routed to irq 23 > found-> vendor=3D0x8086, dev=3D0x27c9, revid=3D0x01 > bus=3D0, slot=3D29, func=3D1 > class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Db, irq=3D11 > map[20]: type I/O Port, range 32, base 0xfd00, size 5, > enabled > pcib0: slot 29 INTB routed to irq 19 > found-> vendor=3D0x8086, dev=3D0x27ca, revid=3D0x01 > bus=3D0, slot=3D29, func=3D2 > class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Dc, irq=3D5 > map[20]: type I/O Port, range 32, base 0xfc00, size 5, > enabled > pcib0: slot 29 INTC routed to irq 18 > found-> vendor=3D0x8086, dev=3D0x27cb, revid=3D0x01 > bus=3D0, slot=3D29, func=3D3 > class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Dd, irq=3D3 > map[20]: type I/O Port, range 32, base 0xfb00, size 5, > enabled > pcib0: slot 29 INTD routed to irq 16 > found-> vendor=3D0x8086, dev=3D0x27cc, revid=3D0x01 > bus=3D0, slot=3D29, func=3D7 > class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D6 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xfdfff000, size=20 10, > enabled > pcib0: slot 29 INTA routed to irq 23 > found-> vendor=3D0x8086, dev=3D0x244e, revid=3D0xe1 > bus=3D0, slot=3D30, func=3D0 > class=3D06-04-01, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > found-> vendor=3D0x8086, dev=3D0x27b8, revid=3D0x01 > bus=3D0, slot=3D31, func=3D0 > class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0107, statreg=3D0x0210, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > found-> vendor=3D0x8086, dev=3D0x27c0, revid=3D0x01 > bus=3D0, slot=3D31, func=3D2 > class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x02b0, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Db, irq=3D255 > powerspec 2 supports D0 D3 current D0 > map[20]: type I/O Port, range 32, base 0xf800, size 4, > enabled > map[24]: type Memory, range 32, base 0xfdffc000, size=20 10, > enabled > found-> vendor=3D0x8086, dev=3D0x27da, revid=3D0x01 > bus=3D0, slot=3D31, func=3D3 > class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0001, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Db, irq=3D11 > map[20]: type I/O Port, range 32, base 0x500, size 5, > enabled > pcib0: slot 31 INTB routed to irq 19 > vgapci0: port 0xff00-0xff07 mem=20 0xfdf00000- > 0xfdf7ffff,0xd0000000-0xdfffffff,0xfdf80000-0xfdfbffff irq 16 at > device 2.0 on pci0 > agp0: on vgapci0 > vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at=20 0xfdf00000 > vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at=20 0xfdf00000 > vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at=20 0xfdf80000 > vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at > 0xd0000000 > agp0: detected 7932k stolen memory > agp0: aperture size is 256M > pcib1: irq 16 at device 28.0 on pci0 > pcib1: secondary bus 1 > pcib1: subordinate bus 9 > pcib1: I/O decode 0x6000-0xcfff > pcib1: memory decode 0xfd700000-0xfdefffff > pcib1: prefetched decode 0xfce00000-0xfd4fffff > pci1: on pcib1 > pci1: physical bus=3D1 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D1, slot=3D0, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0xfdee0000, size=20 17, > enabled > pcib1: requested memory range 0xfdee0000-0xfdefffff: good > pcib1: slot 0 INTA routed to irq 16 > pcib2: mem 0xfdee0000-0xfdefffff irq 16=20 at > device 0.0 on pci1 > pcib2: secondary bus 2 > pcib2: subordinate bus 9 > pcib2: I/O decode 0x6000-0xcfff > pcib2: memory decode 0xfd700000-0xfddfffff > pcib2: prefetched decode 0xfce00000-0xfd4fffff > pci2: on pcib2 > pci2: physical bus=3D2 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D2, slot=3D1, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 1 INTA routed to irq 16 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D2, slot=3D2, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 2 INTA routed to irq 16 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D2, slot=3D3, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 3 INTA routed to irq 16 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D2, slot=3D8, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 8 INTA routed to irq 16 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D2, slot=3D9, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 9 INTA routed to irq 16 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D2, slot=3D10, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 10 INTA routed to irq 16 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D2, slot=3D11, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 11 INTA routed to irq 16 > pcib3: irq 16 at device 1.0 on pci2 > pcib3: secondary bus 3 > pcib3: subordinate bus 3 > pcib3: I/O decode 0xc000-0xcfff > pcib3: memory decode 0xfdd00000-0xfddfffff > pcib3: prefetched decode 0xfd400000-0xfd4fffff > pci3: on pcib3 > pci3: physical bus=3D3 > pcib4: irq 16 at device 2.0 on pci2 > pcib4: secondary bus 4 > pcib4: subordinate bus 4 > pcib4: I/O decode 0xb000-0xbfff > pcib4: memory decode 0xfdc00000-0xfdcfffff > pcib4: prefetched decode 0xfd300000-0xfd3fffff > pci4: on pcib4 > pci4: physical bus=3D4 > pcib5: irq 16 at device 3.0 on pci2 > pcib5: secondary bus 5 > pcib5: subordinate bus 5 > pcib5: I/O decode 0xa000-0xafff > pcib5: memory decode 0xfdb00000-0xfdbfffff > pcib5: prefetched decode 0xfd200000-0xfd2fffff > pci5: on pcib5 > pci5: physical bus=3D5 > pcib6: irq 16 at device 8.0 on pci2 > pcib6: secondary bus 6 > pcib6: subordinate bus 6 > pcib6: I/O decode 0x9000-0x9fff > pcib6: memory decode 0xfda00000-0xfdafffff > pcib6: prefetched decode 0xfd100000-0xfd1fffff > pci6: on pcib6 > pci6: physical bus=3D6 > found-> vendor=3D0x8086, dev=3D0x105e, revid=3D0x06 > bus=3D6, slot=3D0, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > found-> vendor=3D0x8086, dev=3D0x105e, revid=3D0x06 > bus=3D6, slot=3D0, func=3D1 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Db, irq=3D255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > em0: at > device 0.0 on pci6 > pcib6: em0 requested memory range 0xfda00000-0xfdafffff: good > pcib2: em0 requested memory range 0xfda00000-0xfdafffff: good > pcib1: em0 requested memory range 0xfda00000-0xfdafffff: good > em0: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfda00000 > pcib6: slot 0 INTA routed to irq 16 > em0: bpf attached > em0: Ethernet address: 00:10:f3:0c:5b:36 > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 48 > em0: [FILTER] > em1: at > device 0.1 on pci6 > pcib6: em1 requested memory range 0xfda00000-0xfdafffff: good > pcib2: em1 requested memory range 0xfda00000-0xfdafffff: good > pcib1: em1 requested memory range 0xfda00000-0xfdafffff: good > em1: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfda20000 > pcib6: slot 0 INTB routed to irq 17 > em1: bpf attached > em1: Ethernet address: 00:10:f3:0c:5b:37 > ioapic0: routing intpin 17 (PCI IRQ 17) to vector 49 > em1: [FILTER] > pcib7: irq 16 at device 9.0 on pci2 > pcib7: secondary bus 7 > pcib7: subordinate bus 7 > pcib7: I/O decode 0x8000-0x8fff > pcib7: memory decode 0xfd900000-0xfd9fffff > pcib7: prefetched decode 0xfd000000-0xfd0fffff > pci7: on pcib7 > pci7: physical bus=3D7 > found-> vendor=3D0x8086, dev=3D0x105e, revid=3D0x06 > bus=3D7, slot=3D0, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > found-> vendor=3D0x8086, dev=3D0x105e, revid=3D0x06 > bus=3D7, slot=3D0, func=3D1 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Db, irq=3D255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > em2: at > device 0.0 on pci7 > pcib7: em2 requested memory range 0xfd900000-0xfd9fffff: good > pcib2: em2 requested memory range 0xfd900000-0xfd9fffff: good > pcib1: em2 requested memory range 0xfd900000-0xfd9fffff: good > em2: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfd900000 > pcib7: slot 0 INTA routed to irq 17 > em2: bpf attached > em2: Ethernet address: 00:10:f3:0c:5b:38 > em2: [FILTER] > em3: at > device 0.1 on pci7 > pcib7: em3 requested memory range 0xfd900000-0xfd9fffff: good > pcib2: em3 requested memory range 0xfd900000-0xfd9fffff: good > pcib1: em3 requested memory range 0xfd900000-0xfd9fffff: good > em3: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfd920000 > pcib7: slot 0 INTB routed to irq 18 > em3: bpf attached > em3: Ethernet address: 00:10:f3:0c:5b:39 > ioapic0: routing intpin 18 (PCI IRQ 18) to vector 50 > em3: [FILTER] > pcib8: irq 16 at device 10.0 on pci2 > pcib8: secondary bus 8 > pcib8: subordinate bus 8 > pcib8: I/O decode 0x7000-0x7fff > pcib8: memory decode 0xfd800000-0xfd8fffff > pcib8: prefetched decode 0xfcf00000-0xfcffffff > pci8: on pcib8 > pci8: physical bus=3D8 > pcib9: irq 16 at device 11.0 on pci2 > pcib9: secondary bus 9 > pcib9: subordinate bus 9 > pcib9: I/O decode 0x6000-0x6fff > pcib9: memory decode 0xfd700000-0xfd7fffff > pcib9: prefetched decode 0xfce00000-0xfcefffff > pci9: on pcib9 > pci9: physical bus=3D9 > found-> vendor=3D0x8086, dev=3D0x105e, revid=3D0x06 > bus=3D9, slot=3D0, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > found-> vendor=3D0x8086, dev=3D0x105e, revid=3D0x06 > bus=3D9, slot=3D0, func=3D1 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Db, irq=3D255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > em4: at > device 0.0 on pci9 > pcib9: em4 requested memory range 0xfd700000-0xfd7fffff: good > pcib2: em4 requested memory range 0xfd700000-0xfd7fffff: good > pcib1: em4 requested memory range 0xfd700000-0xfd7fffff: good > em4: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfd700000 > pcib9: slot 0 INTA routed to irq 19 > em4: bpf attached > em4: Ethernet address: 00:10:f3:0c:5b:34 > ioapic0: routing intpin 19 (PCI IRQ 19) to vector 51 > em4: [FILTER] > em5: at > device 0.1 on pci9 > pcib9: em5 requested memory range 0xfd700000-0xfd7fffff: good > pcib2: em5 requested memory range 0xfd700000-0xfd7fffff: good > pcib1: em5 requested memory range 0xfd700000-0xfd7fffff: good > em5: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfd720000 > pcib9: slot 0 INTB routed to irq 16 > em5: bpf attached > em5: Ethernet address: 00:10:f3:0c:5b:35 > em5: [FILTER] > pcib10: irq 17 at device 28.5 on pci0 > pcib10: secondary bus 10 > pcib10: subordinate bus 12 > pcib10: I/O decode 0x4000-0x5fff > pcib10: memory decode 0xfcc00000-0xfcdfffff > pcib10: prefetched decode 0xfca00000-0xfcbfffff > pci10: on pcib10 > pci10: physical bus=3D10 > found-> vendor=3D0x8086, dev=3D0x0340, revid=3D0x09 > bus=3D10, slot=3D0, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > found-> vendor=3D0x8086, dev=3D0x0341, revid=3D0x09 > bus=3D10, slot=3D0, func=3D2 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib11: at device 0.0 on pci10 > pcib11: secondary bus 11 > pcib11: subordinate bus 11 > pcib11: I/O decode 0x5000-0x5fff > pcib11: memory decode 0xfcd00000-0xfcdfffff > pcib11: prefetched decode 0xfcb00000-0xfcbfffff > pci11: on pcib11 > pci11: physical bus=3D11 > pcib12: at device 0.2 on pci10 > pcib12: secondary bus 12 > pcib12: subordinate bus 12 > pcib12: I/O decode 0x4000-0x4fff > pcib12: memory decode 0xfcc00000-0xfccfffff > pcib12: prefetched decode 0xfca00000-0xfcafffff > pci12: on pcib12 > pci12: physical bus=3D12 > uhci0: port 0xfe00-0xfe1f irq 23=20 at > device 29.0 on pci0 > uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfe00 > ioapic0: routing intpin 23 (PCI IRQ 23) to vector 52 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: =20 on > usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0xfd00-0xfd1f irq 19=20 at > device 29.1 on pci0 > uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfd00 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: =20 on > usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0xfc00-0xfc1f irq 18=20 at > device 29.2 on pci0 > uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfc00 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: =20 on > usb2 > uhub2: 2 ports with 2 removable, self powered > uhci3: port 0xfb00-0xfb1f irq 16=20 at > device 29.3 on pci0 > uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfb00 > uhci3: [GIANT-LOCKED] > uhci3: [ITHREAD] > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: =20 on > usb3 > uhub3: 2 ports with 2 removable, self powered > ehci0: mem=20 0xfdfff000- > 0xfdfff3ff irq 23 at device 29.7 on pci0 > ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfdfff000 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb4: EHCI version 1.0 > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > usb4: on ehci0 > usb4: USB revision 2.0 > uhub4: =20 on > usb4 > uhub4: 8 ports with 8 removable, self powered > pcib13: at device 30.0 on pci0 > pcib13: secondary bus 13 > pcib13: subordinate bus 13 > pcib13: I/O decode 0xd000-0xdfff > pcib13: memory decode 0xfd600000-0xfd6fffff > pcib13: prefetched decode 0xfd500000-0xfd5fffff > pcib13: Subtractively decoded bridge. > pci13: on pcib13 > pci13: physical bus=3D13 > found-> vendor=3D0x8086, dev=3D0x1076, revid=3D0x05 > bus=3D13, slot=3D7, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0230, cachelnsz=3D16 (dwords) > lattimer=3D0xfc (7560 ns), mingnt=3D0xff (63750 ns), > maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D10 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xfd6e0000, size=20 17, > enabled > pcib13: requested memory range 0xfd6e0000-0xfd6fffff: good > map[14]: type Memory, range 32, base 0xfd6c0000, size=20 17, > enabled > pcib13: requested memory range 0xfd6c0000-0xfd6dffff: good > map[18]: type I/O Port, range 32, base 0xdf00, size 6, > enabled > pcib13: requested I/O range 0xdf00-0xdf3f: in range > pcib13: slot 7 INTA routed to irq 17 > found-> vendor=3D0x8086, dev=3D0x1076, revid=3D0x05 > bus=3D13, slot=3D9, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0230, cachelnsz=3D16 (dwords) > lattimer=3D0xfc (7560 ns), mingnt=3D0xff (63750 ns), > maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D11 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xfd6a0000, size=20 17, > enabled > pcib13: requested memory range 0xfd6a0000-0xfd6bffff: good > map[14]: type Memory, range 32, base 0xfd680000, size=20 17, > enabled > pcib13: requested memory range 0xfd680000-0xfd69ffff: good > map[18]: type I/O Port, range 32, base 0xde00, size 6, > enabled > pcib13: requested I/O range 0xde00-0xde3f: in range > pcib13: slot 9 INTA routed to irq 19 > em6: port > 0xdf00-0xdf3f mem 0xfd6e0000-0xfd6fffff,0xfd6c0000-0xfd6dffff irq=20 17 > at device 7.0 on pci13 > em6: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfd6e0000 > em6: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdf00 > em6: bpf attached > em6: Ethernet address: 00:10:f3:0c:5b:33 > em6: [FILTER] > em7: port > 0xde00-0xde3f mem 0xfd6a0000-0xfd6bffff,0xfd680000-0xfd69ffff irq=20 19 > at device 9.0 on pci13 > em7: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfd6a0000 > em7: Reserved 0x40 bytes for rid 0x18 type 4 at 0xde00 > em7: bpf attached > em7: Ethernet address: 00:10:f3:0c:5b:32 > em7: [FILTER] > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6, > 0x170-0x177,0x376,0xf800-0xf80f mem 0xfdffc000-0xfdffc3ff at=20 device > 31.2 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf800 > ata0: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 > ata0: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 > ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 > ata0: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 > ioapic0: routing intpin 14 (ISA IRQ 14) to vector 53 > ata0: [MPSAFE] > ata0: [ITHREAD] > ata1: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 > atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 > ata1: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D7f > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat1=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: reset tp2 stat0=3Dff stat1=3Dff devices=3D0x0 > ioapic0: routing intpin 15 (ISA IRQ 15) to vector 54 > ata1: [MPSAFE] > ata1: [ITHREAD] > pci0: at device 31.3 (no driver attached) > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > ex_isa_identify() > ata: ata0 already exists; skipping it > ata: ata1 already exists; skipping it > pnp_identify: Trying Read_Port at 203 > pnp_identify: Trying Read_Port at 243 > pnp_identify: Trying Read_Port at 283 > pnp_identify: Trying Read_Port at 2c3 > pnp_identify: Trying Read_Port at 303 > pnp_identify: Trying Read_Port at 343 > pnp_identify: Trying Read_Port at 383 > pnp_identify: Trying Read_Port at 3c3 > PNP Identify complete > pnpbios: 13 devices, largest 92 bytes > PNP0200: adding dma mask 0x10 > PNP0200: adding io range 0-0xf, size=3D0x10, align=3D0 > PNP0200: adding io range 0x81-0x83, size=3D0x3, align=3D0 > PNP0200: adding io range 0x87-0x87, size=3D0x1, align=3D0 > PNP0200: adding io range 0x89-0x8b, size=3D0x3, align=3D0 > PNP0200: adding io range 0x8f-0x91, size=3D0x3, align=3D0 > PNP0200: adding io range 0xc0-0xdf, size=3D0x20, align=3D0 > pnpbios: handle 1 device ID PNP0200 (0002d041) > PNP0100: adding irq mask 0x1 > PNP0100: adding io range 0x40-0x43, size=3D0x4, align=3D0 > pnpbios: handle 2 device ID PNP0100 (0001d041) > PNP0b00: adding irq mask 0x100 > PNP0b00: adding io range 0x70-0x71, size=3D0x2, align=3D0 > pnpbios: handle 3 device ID PNP0b00 (000bd041) > PNP0303: adding irq mask 0x2 > PNP0303: adding io range 0x60-0x60, size=3D0x1, align=3D0 > PNP0303: adding io range 0x64-0x64, size=3D0x1, align=3D0 > pnpbios: handle 4 device ID PNP0303 (0303d041) > PNP0800: adding io range 0x61-0x61, size=3D0x1, align=3D0 > pnpbios: handle 5 device ID PNP0800 (0008d041) > PNP0c04: adding irq mask 0x2000 > PNP0c04: adding io range 0xf0-0xff, size=3D0x10, align=3D0 > pnpbios: handle 6 device ID PNP0c04 (040cd041) > INT0800: adding fixed memory32 range 0xffb80000-0xffbfffff, > size=3D0x80000 > pnpbios: handle 7 device ID INT0800 (0008d425) > PNP0c01: adding fixed memory32 range 0-0x9ffff, size=3D0xa0000 > PNP0c01: adding fixed memory32 range 0xffb00000-0xffb7ffff, > size=3D0x80000 > PNP0c01: adding fixed memory32 range 0xfff00000-0xffffffff, > size=3D0x100000 > PNP0c01: adding fixed memory32 range 0xfec00000-0xfec0ffff, > size=3D0x10000 > PNP0c01: adding fixed memory32 range 0xfee00000-0xfee0ffff, > size=3D0x10000 > PNP0c01: adding fixed memory32 range 0x100000-0xffffff, > size=3D0xf00000 > pnpbios: handle 8 device ID PNP0c01 (010cd041) > PNP0c02: adding fixed memory32 range 0xf0000-0xf3fff,=20 size=3D0x4000 > PNP0c02: adding fixed memory32 range 0xf4000-0xf7fff,=20 size=3D0x4000 > PNP0c02: adding fixed memory32 range 0xf8000-0xfffff,=20 size=3D0x8000 > PNP0c02: adding fixed memory32 range 0xcc000-0xcffff,=20 size=3D0x4000 > pnpbios: handle 9 device ID PNP0c02 (020cd041) > PNP0a03: adding io range 0x290-0x29f, size=3D0x10, align=3D0 > PNP0a03: adding io range 0x4d0-0x4d1, size=3D0x2, align=3D0 > PNP0a03: adding io range 0xcf8-0xcff, size=3D0x8, align=3D0 > PNP0a03: adding io range 0x400-0x4bf, size=3D0xc0, align=3D0 > pnpbios: handle 10 device ID PNP0a03 (030ad041) > PNP0501: adding irq mask 0x10 > PNP0501: adding io range 0x3f8-0x3ff, size=3D0x8, align=3D0 > pnpbios: handle 12 device ID PNP0501 (0105d041) > PNP0400: adding irq mask 0x80 > PNP0400: adding io range 0x378-0x37f, size=3D0x8, align=3D0 > PNP0400: adding io range 0x778-0x77f, size=3D0x8, align=3D0 > pnpbios: handle 13 device ID PNP0400 (0004d041) > sc: sc0 already exists; skipping it > vga: vga0 already exists; skipping it > isa_probe_children: disabling PnP devices > isa_probe_children: probing non-PnP devices > pmtimer0 on isa0 > orm0: at iomem 0xcc000-0xd3fff pnpid ORM0000 on > isa0 > adv0: not probed (disabled) > aha0: not probed (disabled) > aic0: not probed (disabled) > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to vector 55 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: current command byte:0067 > psm0: strange result for test aux port (2). > psm0: failed to reset the aux device. > bt0: not probed (disabled) > cs0: not probed (disabled) > ed0: not probed (disabled) > fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on=20 isa0 > fe0: not probed (disabled) > ie0: not probed (disabled) > le0: not probed (disabled) > ppc0: parallel port found at 0x378 > ppc0: using extended I/O port range > ppc0: SPP > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: bpf attached > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ioapic0: routing intpin 7 (ISA IRQ 7) to vector 56 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) > sio0: irq maps: 0x841 0x851 0x841 0x841 > sio0: irq maps: 0x841 0x851 0x841 0x841 > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57 > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: irq maps: 0x841 0x841 0x841 0x841 > sio1: probe failed test(s): 0 1 2 4 6 7 9 > sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > sio2: not probed (disabled) > sio3: not probed (disabled) > sn0: not probed (disabled) > vga0: at port 0x3c0-0x3df iomem 0xa0000- 0xbffff > on isa0 > vt0: not probed (disabled) > isa_probe_children: probing PnP devices > unknown: can't assign resources (port) > unknown: at port 0x60 pnpid PNP0303 on isa0 > unknown: failed to probe at port 0x61 pnpid PNP0800 on > isa0 > unknown: failed to probe at iomem 0xffb80000- 0xffbfffff > pnpid INT0800 on isa0 > unknown: can't assign resources (memory) > unknown: at iomem 0-0x9ffff pnpid PNP0c01 on isa0 > unknown: can't assign resources (memory) > unknown: at iomem 0xf0000-0xf3fff,0xf4000-0xf7fff, 0xf8000- > 0xfffff,0xcc000-0xcffff pnpid PNP0c02 on isa0 > unknown: can't assign resources (port) > unknown: at port 0x3f8-0x3ff pnpid PNP0501 on isa0 > unknown: can't assign resources (port) > unknown: at port 0x378-0x37f pnpid PNP0400 on isa0 > ukbd0: =20 on > uhub0 > kbd2 at ukbd0 > kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 > ums0: =20 on > uhub0 > ums0: 5 buttons and Z dir. > Device configuration finished. > procfs registered > lapic: Divisor 2, Frequency 100003988 hz > Timecounter "TSC" frequency 3200127568 Hz quality -100 > Timecounters tick every 1.000 msec > lo0: bpf attached > rr232x: no controller detected. > ata0-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D40 wire > ad0: 238475MB at ata0-master SATA150 > ad0: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 > depth queue > GEOM: new disk ad0 > ad0: Intel check1 failed > ad0: Adaptec check1 failed > ad0: LSI (v3) check1 failed > ad0: LSI (v2) check1 failed > ad0: FreeBSD check1 failed > ATA PseudoRAID loaded > SMP: AP CPU #1 Launched! > cpu1 AP: > ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: > 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: > 0x000001ff > timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: > 0x00010000 > Trying to mount root from ufs:/dev/ad0s1a > start_init: trying /sbin/init > em4: Link is up 1000 Mbps Full Duplex > em6: Link is up 10 Mbps Half Duplex > em7: Link is up 100 Mbps Full Duplex > > > _______________________________________________ > 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" > From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 05:47:42 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0C0416A46D for ; Tue, 10 Jul 2007 05:47:42 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id 522A313C4AE for ; Tue, 10 Jul 2007 05:47:42 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 26673 invoked from network); 10 Jul 2007 05:20:59 -0000 Received: from 209.68.2.70 (HELO localhost) (209.68.2.70) by relay03.pair.com with SMTP; 10 Jul 2007 05:20:59 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 10 Jul 2007 00:20:49 -0500 (CDT) From: Mike Silbersack To: current@freebsd.org, net@freebsd.org Message-ID: <20070709234401.S29353@odysseus.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1185318269-1184043945=:29353" Content-ID: <20070710000720.E29353@odysseus.silby.com> Cc: Robert Watson , Andre Oppermann Subject: FreeBSD 7 TCP syncache fix: request for testers 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: Tue, 10 Jul 2007 05:47:42 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1185318269-1184043945=:29353 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: <20070710000720.U29353@odysseus.silby.com> I've found one of the causes of the network instability of FreeBSD 7; the tcp syncache fails to retransmit SYN-ACK packets. This causes interesting problems when packet loss is experienced during connection setup. The symptoms that I have witnessed are twofold: 1. If the third part of the 3WHS is lost, the client will believe that the connection is in the ESTABLISHED state, while the server will still have the connection in the syncache. 2. Subsequently, the above syncache entry will stay stuck in the syncache forever. If you attempt to re-use that same 4-tuple, the syncache will ack the new SYN with the old sequence number. Anyway, the attached patch simplifies the syncache structure a bit and makes it retransmit properly. I'd appreciate testing from anyone who has experienced TCP problems with FreeBSD 7, as well as anyone who is pushing significant traffic through FreeBSD 7. I'm not interested in FreeBSD 6 testers, since the FreeBSD 6 syncache has a different structure and is not affected by this bug. FWIW, here's how to prove the existence of the bug. Install nemesis from ports, then use it to send SYN packets at your FreeBSD 7 machine. As of now, you should see only one SYN-ACK reply, and you should also notice that the sysctl net.inet.tcp.syncache.count goes up, but does not come back down. Once you have applied the patch, you should see the behavior demonstrated below: >From your client machine: (nemesis will pick an IP to spoof, change that if you wish.) nemesis tcp -y 80 -D 10.1.1.6 TCP Packet Injected On your FreeBSD 7 machine: patrocles# tcpdump -n port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on nve0, link-type EN10MB (Ethernet), capture size 96 bytes 23:49:02.075118 IP 133.120.85.92.48922 > 10.1.1.6.80: S 1519649939:1519649939(0) win 4096 23:49:02.075165 IP 10.1.1.6.80 > 133.120.85.92.48922: S 269601671:269601671(0) ack 1519649940 win 65535 23:49:05.164195 IP 10.1.1.6.80 > 133.120.85.92.48922: S 269601671:269601671(0) ack 1519649940 win 65535 23:49:11.264245 IP 10.1.1.6.80 > 133.120.85.92.48922: S 269601671:269601671(0) ack 1519649940 win 65535 23:49:23.364342 IP 10.1.1.6.80 > 133.120.85.92.48922: S 269601671:269601671(0) ack 1519649940 win 65535 Thanks, Mike "Silby" Silbersack --0-1185318269-1184043945=:29353 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=tcp_syncache.c-timerfix.patch Content-Transfer-Encoding: BASE64 Content-ID: <20070710000545.B29353@odysseus.silby.com> Content-Description: Content-Disposition: ATTACHMENT; FILENAME=tcp_syncache.c-timerfix.patch LS0tIC91c3Ivc3JjL3N5cy5vbGQvbmV0aW5ldC90Y3Bfc3luY2FjaGUuYwky MDA3LTA2LTI0IDIwOjE3OjMxLjAwMDAwMDAwMCAtMDUwMA0KKysrIC91c3Iv c3JjL3N5cy9uZXRpbmV0L3RjcF9zeW5jYWNoZS5jCTIwMDctMDctMDkgMDA6 NDY6MTguMDAwMDAwMDAwIC0wNTAwDQpAQCAtMTQ5LDcgKzE1MCw2IEBADQog CXN0cnVjdCBtdHgJc2NoX210eDsNCiAJVEFJTFFfSEVBRChzY2hfaGVhZCwg c3luY2FjaGUpCXNjaF9idWNrZXQ7DQogCXN0cnVjdCBjYWxsb3V0CXNjaF90 aW1lcjsNCi0JaW50CQlzY2hfbmV4dGM7DQogCXVfaW50CQlzY2hfbGVuZ3Ro Ow0KIAl1X2ludAkJc2NoX29kZGV2ZW47DQogCXVfaW50MzJfdAlzY2hfc2Vj Yml0c19vZGRbU1lOQ09PS0lFX1NFQ1JFVF9TSVpFXTsNCkBAIC0yNDAsMTYg KzI0MCwxMCBAQA0KIA0KICNkZWZpbmUgRU5EUFRTNl9FUShhLCBiKSAobWVt Y21wKGEsIGIsIHNpemVvZigqYSkpID09IDApDQogDQotI2RlZmluZSBTWU5D QUNIRV9USU1FT1VUKHNjLCBzY2gsIGNvKSBkbyB7CQkJCVwNCisjZGVmaW5l IFNZTkNBQ0hFX1RJTUVPVVQoc2MpIGRvIHsJCQkJCVwNCiAJKHNjKS0+c2Nf cnhtaXRzKys7CQkJCQkJXA0KIAkoc2MpLT5zY19yeHR0aW1lID0gdGlja3Mg KwkJCQkJXA0KIAkJVENQVFZfUlRPQkFTRSAqIHRjcF9iYWNrb2ZmWyhzYykt PnNjX3J4bWl0cyAtIDFdOwlcDQotCWlmICgoc2NoKS0+c2NoX25leHRjID4g KHNjKS0+c2Nfcnh0dGltZSkJCQlcDQotCQkoc2NoKS0+c2NoX25leHRjID0g KHNjKS0+c2Nfcnh0dGltZTsJCQlcDQotCWlmICghVEFJTFFfRU1QVFkoJihz Y2gpLT5zY2hfYnVja2V0KSAmJiAhKGNvKSkJCQlcDQotCQljYWxsb3V0X3Jl c2V0KCYoc2NoKS0+c2NoX3RpbWVyLAkJCVwNCi0JCQkoc2NoKS0+c2NoX25l eHRjIC0gdGlja3MsCQkJXA0KLQkJCXN5bmNhY2hlX3RpbWVyLCAodm9pZCAq KShzY2gpKTsJCQlcDQogfSB3aGlsZSAoMCkNCiANCiAjZGVmaW5lCVNDSF9M T0NLKHNjaCkJCW10eF9sb2NrKCYoc2NoKS0+c2NoX210eCkNCkBAIC0yNzUs NiArMjY5LDcgQEANCiBzeW5jYWNoZV9pbml0KHZvaWQpDQogew0KIAlpbnQg aTsNCisJc3RydWN0IHN5bmNhY2hlX2hlYWQgKnNjaDsNCiANCiAJdGNwX3N5 bmNhY2hlLmNhY2hlX2NvdW50ID0gMDsNCiAJdGNwX3N5bmNhY2hlLmhhc2hz aXplID0gVENQX1NZTkNBQ0hFX0hBU0hTSVpFOw0KQEAgLTMxNyw2ICszMTIs MTcgQEANCiAJdGNwX3N5bmNhY2hlLnpvbmUgPSB1bWFfemNyZWF0ZSgic3lu Y2FjaGUiLCBzaXplb2Yoc3RydWN0IHN5bmNhY2hlKSwNCiAJICAgIE5VTEws IE5VTEwsIE5VTEwsIE5VTEwsIFVNQV9BTElHTl9QVFIsIDApOw0KIAl1bWFf em9uZV9zZXRfbWF4KHRjcF9zeW5jYWNoZS56b25lLCB0Y3Bfc3luY2FjaGUu Y2FjaGVfbGltaXQpOw0KKw0KKwkvKg0KKwkgKiBTdGFydCB0aGUgc3luY2Fj aGUgaGVhZCB0aW1lcnMgcnVubmluZy4gIFRoZXkgZWFjaCBydW4gdGVuIHRp bWVzDQorCSAqIGEgc2Vjb25kLCBhbmQgYXJlIHNwcmVhZCBvdXQgc28gdGhh dCB0aGV5IGFyZSBub3QgYWxsIHJ1bm5pbmcgb24NCisJICogdGhlIHNhbWUg Y2xvY2sgdGljay4NCisJICovDQorCWZvciAoaSA9IDA7IGkgPCB0Y3Bfc3lu Y2FjaGUuaGFzaHNpemU7IGkrKykgew0KKwkJc2NoID0gJnRjcF9zeW5jYWNo ZS5oYXNoYmFzZVtpXTsNCisJCWNhbGxvdXRfcmVzZXQoJihzY2gpLT5zY2hf dGltZXIsIGkgKiAoaHogLyAxMCksICAgIA0KKyAgICAgICAgICAgICAgICBz eW5jYWNoZV90aW1lciwgKHZvaWQgKikoc2NoKSk7DQorCX0NCiB9DQogDQog LyoNCkBAIC0zNDYsOCArMzUyLDggQEANCiAJVEFJTFFfSU5TRVJUX0hFQUQo JnNjaC0+c2NoX2J1Y2tldCwgc2MsIHNjX2hhc2gpOw0KIAlzY2gtPnNjaF9s ZW5ndGgrKzsNCiANCi0JLyogUmVpbml0aWFsaXplIHRoZSBidWNrZXQgcm93 J3MgdGltZXIuICovDQotCVNZTkNBQ0hFX1RJTUVPVVQoc2MsIHNjaCwgMSk7 DQorCS8qIFNldCB0aGUgcmV0cmFuc21pdCB0aW1lciBmb3IgdGhpcyBzb2Nr ZXQuICovDQorCVNZTkNBQ0hFX1RJTUVPVVQoc2MpOw0KIA0KIAlTQ0hfVU5M T0NLKHNjaCk7DQogDQpAQCAtMzk4LDggKzQwNCw2IEBADQogCQkgKiBob3N0 IGRvZXMgdGhlIFNZTi9BQ0stPkFDSy4NCiAJCSAqLw0KIAkJaWYgKHNjLT5z Y19yeHR0aW1lID49IHRpY2spIHsNCi0JCQlpZiAoc2MtPnNjX3J4dHRpbWUg PCBzY2gtPnNjaF9uZXh0YykNCi0JCQkJc2NoLT5zY2hfbmV4dGMgPSBzYy0+ c2Nfcnh0dGltZTsNCiAJCQljb250aW51ZTsNCiAJCX0NCiANCkBAIC00MTYs MTEgKzQyMCwxMCBAQA0KIA0KIAkJKHZvaWQpIHN5bmNhY2hlX3Jlc3BvbmQo c2MpOw0KIAkJdGNwc3RhdC50Y3BzX3NjX3JldHJhbnNtaXR0ZWQrKzsNCi0J CVNZTkNBQ0hFX1RJTUVPVVQoc2MsIHNjaCwgMCk7DQorCQlTWU5DQUNIRV9U SU1FT1VUKHNjKTsNCiAJfQ0KLQlpZiAoIVRBSUxRX0VNUFRZKCYoc2NoKS0+ c2NoX2J1Y2tldCkpDQotCQljYWxsb3V0X3Jlc2V0KCYoc2NoKS0+c2NoX3Rp bWVyLCAoc2NoKS0+c2NoX25leHRjIC0gdGljaywNCi0JCQlzeW5jYWNoZV90 aW1lciwgKHZvaWQgKikoc2NoKSk7DQorCWNhbGxvdXRfcmVzZXQoJihzY2gp LT5zY2hfdGltZXIsIGh6IC8gMTAsDQorCQlzeW5jYWNoZV90aW1lciwgKHZv aWQgKikoc2NoKSk7DQogfQ0KIA0KIC8qDQpAQCAtMTAwNyw3ICsxMDEwLDcg QEANCiAJCSAgICAoIiVzOiBsYWJlbCBub3QgaW5pdGlhbGl6ZWQiLCBfX2Z1 bmNfXykpOw0KICNlbmRpZg0KIAkJaWYgKHN5bmNhY2hlX3Jlc3BvbmQoc2Mp ID09IDApIHsNCi0JCQlTWU5DQUNIRV9USU1FT1VUKHNjLCBzY2gsIDEpOw0K KwkJCVNZTkNBQ0hFX1RJTUVPVVQoc2MpOw0KIAkJCXRjcHN0YXQudGNwc19z bmRhY2tzKys7DQogCQkJdGNwc3RhdC50Y3BzX3NuZHRvdGFsKys7DQogCQl9 DQo= --0-1185318269-1184043945=:29353-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 06:26:04 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F4BB16A400; Tue, 10 Jul 2007 06:26:04 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id E642613C44B; Tue, 10 Jul 2007 06:26:03 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.13.8) with ESMTP id l6A6OZ4N062970; Mon, 9 Jul 2007 23:24:36 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.13.8/Submit) id l6A6OZav062969; Mon, 9 Jul 2007 23:24:35 -0700 (PDT) (envelope-from sgk) Date: Mon, 9 Jul 2007 23:24:35 -0700 From: Steve Kargl To: Mike Silbersack Message-ID: <20070710062435.GA62925@troutmask.apl.washington.edu> References: <20070709234401.S29353@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070709234401.S29353@odysseus.silby.com> User-Agent: Mutt/1.4.2.2i Cc: Andre Oppermann , Robert Watson , current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers 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: Tue, 10 Jul 2007 06:26:04 -0000 On Tue, Jul 10, 2007 at 12:20:49AM -0500, Mike Silbersack wrote: > > I've found one of the causes of the network instability of FreeBSD 7; the > tcp syncache fails to retransmit SYN-ACK packets. This causes interesting > problems when packet loss is experienced during connection setup. The > symptoms that I have witnessed are twofold: > > 1. If the third part of the 3WHS is lost, the client will believe that > the connection is in the ESTABLISHED state, while the server will still > have the connection in the syncache. > 2. Subsequently, the above syncache entry will stay stuck in the syncache > forever. If you attempt to re-use that same 4-tuple, the syncache will > ack the new SYN with the old sequence number. > > Anyway, the attached patch simplifies the syncache structure a bit and > makes it retransmit properly. I'd appreciate testing from anyone who has > experienced TCP problems with FreeBSD 7, as well as anyone who is pushing > significant traffic through FreeBSD 7. Mike, Thanks for tracking this problem down. I can't test this patch for a few weeks due to deadlines. I'll run some tests when I can. From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 09:06:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13D5C16A41F for ; Tue, 10 Jul 2007 09:06:43 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from mail30.bluewin.ch (mail30.bluewin.ch [195.186.19.70]) by mx1.freebsd.org (Postfix) with ESMTP id 5B41913C43E for ; Tue, 10 Jul 2007 09:06:42 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from ps1zhb.bluewin.ch (195.186.18.192) by mail30.bluewin.ch (Bluewin 7.3.121) id 467B85F10056E72C for freebsd-net@freebsd.org; Tue, 10 Jul 2007 09:06:41 +0000 Received: from ps1zhb (localhost [127.0.0.1]) by ps1zhb.bluewin.ch (Postfix) with ESMTP id 82A25E9C for ; Tue, 10 Jul 2007 09:06:41 +0000 (GMT) Message-ID: <17324021.52021184058401532.JavaMail.webmail@ps1zhb.bluewin.ch> Date: Tue, 10 Jul 2007 09:06:41 +0000 (GMT) From: "paketix@bluewin.ch" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-FXIT-IP: 138.190.32.7 Subject: 6.2-RELENG/7.0-CURRENT: em(4) fails on 82571EB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: paketix@bluewin.ch List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2007 09:06:43 -0000 many thanks for your feedback jack you might well be right with the problems popping up when using a=20 bunch of 571's ...anyway - its just that on 6.1-RELENG we never had a problem=20 with=20 the 571's [ You say no traffic works, on NONE of the ports?? Do you have anyway to disable part of them? Do the 541's work? ] the 541's work - the problem affects only the 571's will try to disable some of the 571's in the bios today [I need more debugging, assign address to em0, instrument it however you need to] i can do that - plus kernel recompilation/patching and testing=20 whatever you might need i can provide you access to the box over internet if you like [does anything get transmitted] as far as i remember this causes some 'watchdog - timer' messages=20 because of the transmit buffer not being emptied not checked recently - will do this today [what interrupt handling is done, etc etc...] as far as i remember *only* link up/down interrupt is working -=20 recieve interrupts 'fails'. will test this for transmit today for=20 transmit not checked recently - will insert a printf into=20 em_intr/em_fast_intr today to check this rgds, pat ----Urspr=C3=BCngliche Nachricht---- Von: jfvogel@gmail.com Datum: 09.07.2007 19:36 An: Kopie: Betreff: Re: 6.2-RELENG/7.0-CURRENT: em(4) fails on 82571EB The 82571 device has been supported for a long time, the trick comes when you have a gang of them how the thing is all wired up, we have had issues even with our quad port adapters and some vendor BIOS's. This is a custom so I'm only going to be able to guess that its interrupts. You say no traffic works, on NONE of the ports?? Do you have anyway to disable part of them? Do the 541's work? I need more debugging, assign address to em0, instrument it however you need to, does anything get transmitted, what interrupt handling is done, etc etc... Jack On 7/9/07, paketix@bluewin.ch wrote: > hello everybody > i encountered some problems with the intel 82571EB chipset when=20 i > tried to upgrade from FreeBSD 6.1-RELENG to 6.2-RELENG/7.0- CURRENT on > a network appliance (NEXCOM 1108GL) > the appliance has 3 different intel ethernet controllers=20 soldered > to the motherboard > E1000_DEV_ID_82541GI 0x1076 > E1000_DEV_ID_82571EB_COPPER 0x105E > E1000_DEV_ID_82571EB_SERDES 0x1060 > current intel driver version: > 6.5.3 (from 7.0-CURRENT) > > problem description: > chipset initialisation seems to work OK > ifconfig displays the devices / link state seems to be OK > 'ifconfig up' and 'tcpdump' are NOK (>no packets recieved on > interface - leds indicate packet reception) > interrupts seem to be OK (link up/down triggers em_intr on=20 6.2- > RELENG - behaviour on 7.0-CURRENT unknown yet) > > affected releases: > it seems to be the same problem on 6.2-RELENG/7.0-CURRENT > 6.1-RELENG works fine... > > anyone interested in tracking this down...? > any experience with this behaviour @intel? > i have a server in the lab which is ready to act as a guinea pig > for tests/paches... > ------- > rgds, pat > > freebsd# uname -a > FreeBSD freebsd.sharedtcs.net 7.0-CURRENT-200706 > FreeBSD 7.0-CURRENT-200706 #0: Sun Jun 3 18:41:02 UTC 2007 > root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > freebsd# pciconf -l | grep em > em0@pci6:0:0: class=3D0x020000 card=3D0x10761903 chip=3D0x105e8086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. int.=20 PHY) > em1@pci6:0:1: class=3D0x020000 card=3D0x10761903 chip=3D0x105e8086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. int.=20 PHY) > em2@pci7:0:0: class=3D0x020000 card=3D0x10761903 chip=3D0x105e8086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. int.=20 PHY) > em3@pci7:0:1: class=3D0x020000 card=3D0x10761903 chip=3D0x105e8086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. int.=20 PHY) > em4@pci8:0:0: class=3D0x020000 card=3D0x10761903 chip=3D0x10608086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. ext.=20 SERDES > for SFP modules) > em5@pci8:0:1: class=3D0x020000 card=3D0x10761903 chip=3D0x10608086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. ext.=20 SERDES > for SFP modules) > em6@pci9:0:0: class=3D0x020000 card=3D0x10761903 chip=3D0x105e8086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. int.=20 PHY) > em7@pci9:0:1: class=3D0x020000 card=3D0x10761903 chip=3D0x105e8086 > rev=3D0x06 hdr=3D0x00 (82571EB Gigabit Ethernet Controller w. int.=20 PHY) > em8@pci13:7:0: class=3D0x020000 card=3D0x10761903 chip=3D0x10768086 > rev=3D0x05 hdr=3D0x00 (82541EI Gigabit Ethernet Controller w. int.=20 PHY) > em9@pci13:9:0: class=3D0x020000 card=3D0x10761903 chip=3D0x10768086 > rev=3D0x05 hdr=3D0x00 (82541EI Gigabit Ethernet Controller w. int.=20 PHY) > > freebsd# cat /var/run/dmesg.boot > Copyright (c) 1992-2007 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,=20 1993, > 1994 > The Regents of the University of California. All rights > reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-CURRENT-200706 #0: Sun Jun 3 18:41:02 UTC 2007 > root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > Using 32 colors for the VM-PQ tuning (1024, 8) > Preloaded elf kernel "/boot/kernel.orig/kernel" at 0xc0c95000. > MP Configuration Table version 1.4 found at 0xc00f1400 > APIC: Using the MPTable enumerator. > SMP: Added CPU 0 (BSP) > SMP: Added CPU 1 (AP) > MPTable: > Calibrating clock(s) ... i8254 clock: 1193199 Hz > CLK_USE_I8254_CALIBRATION not specified - using default=20 frequency > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 3200127568 Hz > CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3200.13-MHz 686-class=20 CPU) > Origin =3D "GenuineIntel" Id =3D 0xf49 Stepping =3D 9 > Features=3D0xbfebfbff MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2, SS, HTT, > TM,PBE> > Features2=3D0x641d > AMD Features=3D0x20100000 > AMD Features2=3D0x1 > Logical CPUs per core: 2 > > Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 64 > entries > Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries > 1st-level data cache: 16 KB, 8-way set associative, sectored=20 cache, > 64 byte line size > Trace cache: 12K-uops, 8-way set associative > 2nd-level cache: 1 MB, 8-way set associative, sectored cache, 64 > byte line size > L2 cache: 1024 kbytes, 8-way associative, 64 bytes/line > real memory =3D 1065287680 (1015 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157=20 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768=20 pages) > 0x0000000001028000 - 0x000000003e5cbfff, 1029324800 bytes=20 (251300 > pages) > avail memory =3D 1028886528 (981 MB) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > bios32: Found BIOS32 Service Directory header at 0xc00f9350 > bios32: Entry =3D 0xf9960 (c00f9960) Rev =3D 0 Len =3D 1 > pcibios: PCI BIOS entry at 0xf0000+0x9990 > pnpbios: Found PnP BIOS data at 0xc00fa550 > pnpbios: Entry =3D f0000:a580 Rev =3D 1.0 > Other BIOS signatures found: > ioapic0: Changing APIC ID to 4 > ioapic0: Assuming intbase of 0 > ioapic0: Routing external 8259A's -> intpin 0 > ioapic0: Routing IRQ 0 -> intpin 2 > ioapic0: intpin 9 trigger: level > lapic: Routing ExtINT -> LINT0 > lapic: Routing NMI -> LINT1 > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: > 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: > 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: > 0x00010000 > wlan_amrr: > wlan: <802.11 Link Layer> > ath_rate: version 1.2 > null: > random: > nfslock: pseudo-device > io: > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > Pentium Pro MTRR support enabled > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112,=20 RF2413, > RF5413) > rr232x: RocketRAID 232x controller driver v1.02 (Jun 3 2007 18: 40: > 23) > npx0: INT 16 interface > cpu0 on motherboard > cpu1 on motherboard > pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 > pci_open(1a): mode1res=3D0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there > (id=3D27708086) > pcibios: BIOS version 3.00 > pcib0: pcibus 0 on motherboard > pci0: on pcib0 > pci0: physical bus=3D0 > found-> vendor=3D0x8086, dev=3D0x2770, revid=3D0x02 > bus=3D0, slot=3D0, func=3D0 > class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0006, statreg=3D0x2090, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > found-> vendor=3D0x8086, dev=3D0x2772, revid=3D0x02 > bus=3D0, slot=3D2, func=3D0 > class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0090, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > map[10]: type Memory, range 32, base 0xfdf00000, size=20 19, > enabled > map[14]: type I/O Port, range 32, base 0xff00, size 3, > enabled > map[18]: type Prefetchable Memory, range 32, base > 0xd0000000, size 28, enabled > map[1c]: type Memory, range 32, base 0xfdf80000, size=20 18, > enabled > pcib0: slot 2 INTA routed to irq 16 > found-> vendor=3D0x8086, dev=3D0x27d0, revid=3D0x01 > bus=3D0, slot=3D28, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > pcib0: slot 28 INTA routed to irq 16 > found-> vendor=3D0x8086, dev=3D0x27e2, revid=3D0x01 > bus=3D0, slot=3D28, func=3D5 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Db, irq=3D10 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > pcib0: slot 28 INTB routed to irq 17 > found-> vendor=3D0x8086, dev=3D0x27c8, revid=3D0x01 > bus=3D0, slot=3D29, func=3D0 > class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D6 > map[20]: type I/O Port, range 32, base 0xfe00, size 5, > enabled > pcib0: slot 29 INTA routed to irq 23 > found-> vendor=3D0x8086, dev=3D0x27c9, revid=3D0x01 > bus=3D0, slot=3D29, func=3D1 > class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Db, irq=3D11 > map[20]: type I/O Port, range 32, base 0xfd00, size 5, > enabled > pcib0: slot 29 INTB routed to irq 19 > found-> vendor=3D0x8086, dev=3D0x27ca, revid=3D0x01 > bus=3D0, slot=3D29, func=3D2 > class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Dc, irq=3D5 > map[20]: type I/O Port, range 32, base 0xfc00, size 5, > enabled > pcib0: slot 29 INTC routed to irq 18 > found-> vendor=3D0x8086, dev=3D0x27cb, revid=3D0x01 > bus=3D0, slot=3D29, func=3D3 > class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Dd, irq=3D3 > map[20]: type I/O Port, range 32, base 0xfb00, size 5, > enabled > pcib0: slot 29 INTD routed to irq 16 > found-> vendor=3D0x8086, dev=3D0x27cc, revid=3D0x01 > bus=3D0, slot=3D29, func=3D7 > class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D6 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xfdfff000, size=20 10, > enabled > pcib0: slot 29 INTA routed to irq 23 > found-> vendor=3D0x8086, dev=3D0x244e, revid=3D0xe1 > bus=3D0, slot=3D30, func=3D0 > class=3D06-04-01, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > found-> vendor=3D0x8086, dev=3D0x27b8, revid=3D0x01 > bus=3D0, slot=3D31, func=3D0 > class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0107, statreg=3D0x0210, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > found-> vendor=3D0x8086, dev=3D0x27c0, revid=3D0x01 > bus=3D0, slot=3D31, func=3D2 > class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x02b0, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Db, irq=3D255 > powerspec 2 supports D0 D3 current D0 > map[20]: type I/O Port, range 32, base 0xf800, size 4, > enabled > map[24]: type Memory, range 32, base 0xfdffc000, size=20 10, > enabled > found-> vendor=3D0x8086, dev=3D0x27da, revid=3D0x01 > bus=3D0, slot=3D31, func=3D3 > class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0001, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Db, irq=3D11 > map[20]: type I/O Port, range 32, base 0x500, size 5, > enabled > pcib0: slot 31 INTB routed to irq 19 > vgapci0: port 0xff00-0xff07 mem=20 0xfdf00000- > 0xfdf7ffff,0xd0000000-0xdfffffff,0xfdf80000-0xfdfbffff irq 16 at > device 2.0 on pci0 > agp0: on vgapci0 > vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at=20 0xfdf00000 > vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at=20 0xfdf00000 > vgapci0: Reserved 0x40000 bytes for rid 0x1c type 3 at=20 0xfdf80000 > vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at > 0xd0000000 > agp0: detected 7932k stolen memory > agp0: aperture size is 256M > pcib1: irq 16 at device 28.0 on pci0 > pcib1: secondary bus 1 > pcib1: subordinate bus 9 > pcib1: I/O decode 0x6000-0xcfff > pcib1: memory decode 0xfd700000-0xfdefffff > pcib1: prefetched decode 0xfce00000-0xfd4fffff > pci1: on pcib1 > pci1: physical bus=3D1 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D1, slot=3D0, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0xfdee0000, size=20 17, > enabled > pcib1: requested memory range 0xfdee0000-0xfdefffff: good > pcib1: slot 0 INTA routed to irq 16 > pcib2: mem 0xfdee0000-0xfdefffff irq=20 16=20 at > device 0.0 on pci1 > pcib2: secondary bus 2 > pcib2: subordinate bus 9 > pcib2: I/O decode 0x6000-0xcfff > pcib2: memory decode 0xfd700000-0xfddfffff > pcib2: prefetched decode 0xfce00000-0xfd4fffff > pci2: on pcib2 > pci2: physical bus=3D2 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D2, slot=3D1, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 1 INTA routed to irq 16 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D2, slot=3D2, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 2 INTA routed to irq 16 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D2, slot=3D3, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 3 INTA routed to irq 16 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D2, slot=3D8, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 8 INTA routed to irq 16 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D2, slot=3D9, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 9 INTA routed to irq 16 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D2, slot=3D10, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 10 INTA routed to irq 16 > found-> vendor=3D0x10b5, dev=3D0x8524, revid=3D0xbb > bus=3D2, slot=3D11, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D3 > powerspec 1 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib2: slot 11 INTA routed to irq 16 > pcib3: irq 16 at device 1.0 on pci2 > pcib3: secondary bus 3 > pcib3: subordinate bus 3 > pcib3: I/O decode 0xc000-0xcfff > pcib3: memory decode 0xfdd00000-0xfddfffff > pcib3: prefetched decode 0xfd400000-0xfd4fffff > pci3: on pcib3 > pci3: physical bus=3D3 > pcib4: irq 16 at device 2.0 on pci2 > pcib4: secondary bus 4 > pcib4: subordinate bus 4 > pcib4: I/O decode 0xb000-0xbfff > pcib4: memory decode 0xfdc00000-0xfdcfffff > pcib4: prefetched decode 0xfd300000-0xfd3fffff > pci4: on pcib4 > pci4: physical bus=3D4 > pcib5: irq 16 at device 3.0 on pci2 > pcib5: secondary bus 5 > pcib5: subordinate bus 5 > pcib5: I/O decode 0xa000-0xafff > pcib5: memory decode 0xfdb00000-0xfdbfffff > pcib5: prefetched decode 0xfd200000-0xfd2fffff > pci5: on pcib5 > pci5: physical bus=3D5 > pcib6: irq 16 at device 8.0 on pci2 > pcib6: secondary bus 6 > pcib6: subordinate bus 6 > pcib6: I/O decode 0x9000-0x9fff > pcib6: memory decode 0xfda00000-0xfdafffff > pcib6: prefetched decode 0xfd100000-0xfd1fffff > pci6: on pcib6 > pci6: physical bus=3D6 > found-> vendor=3D0x8086, dev=3D0x105e, revid=3D0x06 > bus=3D6, slot=3D0, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > found-> vendor=3D0x8086, dev=3D0x105e, revid=3D0x06 > bus=3D6, slot=3D0, func=3D1 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Db, irq=3D255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > em0: at > device 0.0 on pci6 > pcib6: em0 requested memory range 0xfda00000-0xfdafffff: good > pcib2: em0 requested memory range 0xfda00000-0xfdafffff: good > pcib1: em0 requested memory range 0xfda00000-0xfdafffff: good > em0: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfda00000 > pcib6: slot 0 INTA routed to irq 16 > em0: bpf attached > em0: Ethernet address: 00:10:f3:0c:5b:36 > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 48 > em0: [FILTER] > em1: at > device 0.1 on pci6 > pcib6: em1 requested memory range 0xfda00000-0xfdafffff: good > pcib2: em1 requested memory range 0xfda00000-0xfdafffff: good > pcib1: em1 requested memory range 0xfda00000-0xfdafffff: good > em1: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfda20000 > pcib6: slot 0 INTB routed to irq 17 > em1: bpf attached > em1: Ethernet address: 00:10:f3:0c:5b:37 > ioapic0: routing intpin 17 (PCI IRQ 17) to vector 49 > em1: [FILTER] > pcib7: irq 16 at device 9.0 on pci2 > pcib7: secondary bus 7 > pcib7: subordinate bus 7 > pcib7: I/O decode 0x8000-0x8fff > pcib7: memory decode 0xfd900000-0xfd9fffff > pcib7: prefetched decode 0xfd000000-0xfd0fffff > pci7: on pcib7 > pci7: physical bus=3D7 > found-> vendor=3D0x8086, dev=3D0x105e, revid=3D0x06 > bus=3D7, slot=3D0, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > found-> vendor=3D0x8086, dev=3D0x105e, revid=3D0x06 > bus=3D7, slot=3D0, func=3D1 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Db, irq=3D255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > em2: at > device 0.0 on pci7 > pcib7: em2 requested memory range 0xfd900000-0xfd9fffff: good > pcib2: em2 requested memory range 0xfd900000-0xfd9fffff: good > pcib1: em2 requested memory range 0xfd900000-0xfd9fffff: good > em2: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfd900000 > pcib7: slot 0 INTA routed to irq 17 > em2: bpf attached > em2: Ethernet address: 00:10:f3:0c:5b:38 > em2: [FILTER] > em3: at > device 0.1 on pci7 > pcib7: em3 requested memory range 0xfd900000-0xfd9fffff: good > pcib2: em3 requested memory range 0xfd900000-0xfd9fffff: good > pcib1: em3 requested memory range 0xfd900000-0xfd9fffff: good > em3: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfd920000 > pcib7: slot 0 INTB routed to irq 18 > em3: bpf attached > em3: Ethernet address: 00:10:f3:0c:5b:39 > ioapic0: routing intpin 18 (PCI IRQ 18) to vector 50 > em3: [FILTER] > pcib8: irq 16 at device 10.0 on pci2 > pcib8: secondary bus 8 > pcib8: subordinate bus 8 > pcib8: I/O decode 0x7000-0x7fff > pcib8: memory decode 0xfd800000-0xfd8fffff > pcib8: prefetched decode 0xfcf00000-0xfcffffff > pci8: on pcib8 > pci8: physical bus=3D8 > pcib9: irq 16 at device 11.0 on pci2 > pcib9: secondary bus 9 > pcib9: subordinate bus 9 > pcib9: I/O decode 0x6000-0x6fff > pcib9: memory decode 0xfd700000-0xfd7fffff > pcib9: prefetched decode 0xfce00000-0xfcefffff > pci9: on pcib9 > pci9: physical bus=3D9 > found-> vendor=3D0x8086, dev=3D0x105e, revid=3D0x06 > bus=3D9, slot=3D0, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Da, irq=3D255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > found-> vendor=3D0x8086, dev=3D0x105e, revid=3D0x06 > bus=3D9, slot=3D0, func=3D1 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > intpin=3Db, irq=3D255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory > disabled > map[14]: type Memory, range 32, base 0, size 17, memory > disabled > map[18]: type I/O Port, range 32, base 0, size 5, port > disabled > em4: at > device 0.0 on pci9 > pcib9: em4 requested memory range 0xfd700000-0xfd7fffff: good > pcib2: em4 requested memory range 0xfd700000-0xfd7fffff: good > pcib1: em4 requested memory range 0xfd700000-0xfd7fffff: good > em4: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfd700000 > pcib9: slot 0 INTA routed to irq 19 > em4: bpf attached > em4: Ethernet address: 00:10:f3:0c:5b:34 > ioapic0: routing intpin 19 (PCI IRQ 19) to vector 51 > em4: [FILTER] > em5: at > device 0.1 on pci9 > pcib9: em5 requested memory range 0xfd700000-0xfd7fffff: good > pcib2: em5 requested memory range 0xfd700000-0xfd7fffff: good > pcib1: em5 requested memory range 0xfd700000-0xfd7fffff: good > em5: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at > 0xfd720000 > pcib9: slot 0 INTB routed to irq 16 > em5: bpf attached > em5: Ethernet address: 00:10:f3:0c:5b:35 > em5: [FILTER] > pcib10: irq 17 at device 28.5 on pci0 > pcib10: secondary bus 10 > pcib10: subordinate bus 12 > pcib10: I/O decode 0x4000-0x5fff > pcib10: memory decode 0xfcc00000-0xfcdfffff > pcib10: prefetched decode 0xfca00000-0xfcbfffff > pci10: on pcib10 > pci10: physical bus=3D10 > found-> vendor=3D0x8086, dev=3D0x0340, revid=3D0x09 > bus=3D10, slot=3D0, func=3D0 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > found-> vendor=3D0x8086, dev=3D0x0341, revid=3D0x09 > bus=3D10, slot=3D0, func=3D2 > class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 > ns) > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pcib11: at device 0.0 on pci10 > pcib11: secondary bus 11 > pcib11: subordinate bus 11 > pcib11: I/O decode 0x5000-0x5fff > pcib11: memory decode 0xfcd00000-0xfcdfffff > pcib11: prefetched decode 0xfcb00000-0xfcbfffff > pci11: on pcib11 > pci11: physical bus=3D11 > pcib12: at device 0.2 on pci10 > pcib12: secondary bus 12 > pcib12: subordinate bus 12 > pcib12: I/O decode 0x4000-0x4fff > pcib12: memory decode 0xfcc00000-0xfccfffff > pcib12: prefetched decode 0xfca00000-0xfcafffff > pci12: on pcib12 > pci12: physical bus=3D12 > uhci0: port 0xfe00-0xfe1f irq=20 23=20 at > device 29.0 on pci0 > uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfe00 > ioapic0: routing intpin 23 (PCI IRQ 23) to vector 52 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: =20 on > usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0xfd00-0xfd1f irq=20 19=20 at > device 29.1 on pci0 > uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfd00 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: =20 on > usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0xfc00-0xfc1f irq=20 18=20 at > device 29.2 on pci0 > uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfc00 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: =20 on > usb2 > uhub2: 2 ports with 2 removable, self powered > uhci3: port 0xfb00-0xfb1f irq=20 16=20 at > device 29.3 on pci0 > uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfb00 > uhci3: [GIANT-LOCKED] > uhci3: [ITHREAD] > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: =20 on > usb3 > uhub3: 2 ports with 2 removable, self powered > ehci0: mem=20 0xfdfff000- > 0xfdfff3ff irq 23 at device 29.7 on pci0 > ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfdfff000 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb4: EHCI version 1.0 > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > usb4: on ehci0 > usb4: USB revision 2.0 > uhub4: =20 on > usb4 > uhub4: 8 ports with 8 removable, self powered > pcib13: at device 30.0 on pci0 > pcib13: secondary bus 13 > pcib13: subordinate bus 13 > pcib13: I/O decode 0xd000-0xdfff > pcib13: memory decode 0xfd600000-0xfd6fffff > pcib13: prefetched decode 0xfd500000-0xfd5fffff > pcib13: Subtractively decoded bridge. > pci13: on pcib13 > pci13: physical bus=3D13 > found-> vendor=3D0x8086, dev=3D0x1076, revid=3D0x05 > bus=3D13, slot=3D7, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0230, cachelnsz=3D16 (dwords) > lattimer=3D0xfc (7560 ns), mingnt=3D0xff (63750 ns), > maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D10 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xfd6e0000, size=20 17, > enabled > pcib13: requested memory range 0xfd6e0000-0xfd6fffff: good > map[14]: type Memory, range 32, base 0xfd6c0000, size=20 17, > enabled > pcib13: requested memory range 0xfd6c0000-0xfd6dffff: good > map[18]: type I/O Port, range 32, base 0xdf00, size 6, > enabled > pcib13: requested I/O range 0xdf00-0xdf3f: in range > pcib13: slot 7 INTA routed to irq 17 > found-> vendor=3D0x8086, dev=3D0x1076, revid=3D0x05 > bus=3D13, slot=3D9, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0230, cachelnsz=3D16 (dwords) > lattimer=3D0xfc (7560 ns), mingnt=3D0xff (63750 ns), > maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D11 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xfd6a0000, size=20 17, > enabled > pcib13: requested memory range 0xfd6a0000-0xfd6bffff: good > map[14]: type Memory, range 32, base 0xfd680000, size=20 17, > enabled > pcib13: requested memory range 0xfd680000-0xfd69ffff: good > map[18]: type I/O Port, range 32, base 0xde00, size 6, > enabled > pcib13: requested I/O range 0xde00-0xde3f: in range > pcib13: slot 9 INTA routed to irq 19 > em6: port > 0xdf00-0xdf3f mem 0xfd6e0000-0xfd6fffff,0xfd6c0000-0xfd6dffff=20 irq=20 17 > at device 7.0 on pci13 > em6: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfd6e0000 > em6: Reserved 0x40 bytes for rid 0x18 type 4 at 0xdf00 > em6: bpf attached > em6: Ethernet address: 00:10:f3:0c:5b:33 > em6: [FILTER] > em7: port > 0xde00-0xde3f mem 0xfd6a0000-0xfd6bffff,0xfd680000-0xfd69ffff=20 irq=20 19 > at device 9.0 on pci13 > em7: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfd6a0000 > em7: Reserved 0x40 bytes for rid 0x18 type 4 at 0xde00 > em7: bpf attached > em7: Ethernet address: 00:10:f3:0c:5b:32 > em7: [FILTER] > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6, > 0x170-0x177,0x376,0xf800-0xf80f mem 0xfdffc000-0xfdffc3ff at=20 device > 31.2 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf800 > ata0: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 > ata0: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 > ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 > ata0: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 > ioapic0: routing intpin 14 (ISA IRQ 14) to vector 53 > ata0: [MPSAFE] > ata0: [ITHREAD] > ata1: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 > atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 > ata1: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D7f > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: stat1=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff > ata1: reset tp2 stat0=3Dff stat1=3Dff devices=3D0x0 > ioapic0: routing intpin 15 (ISA IRQ 15) to vector 54 > ata1: [MPSAFE] > ata1: [ITHREAD] > pci0: at device 31.3 (no driver attached) > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > ex_isa_identify() > ata: ata0 already exists; skipping it > ata: ata1 already exists; skipping it > pnp_identify: Trying Read_Port at 203 > pnp_identify: Trying Read_Port at 243 > pnp_identify: Trying Read_Port at 283 > pnp_identify: Trying Read_Port at 2c3 > pnp_identify: Trying Read_Port at 303 > pnp_identify: Trying Read_Port at 343 > pnp_identify: Trying Read_Port at 383 > pnp_identify: Trying Read_Port at 3c3 > PNP Identify complete > pnpbios: 13 devices, largest 92 bytes > PNP0200: adding dma mask 0x10 > PNP0200: adding io range 0-0xf, size=3D0x10, align=3D0 > PNP0200: adding io range 0x81-0x83, size=3D0x3, align=3D0 > PNP0200: adding io range 0x87-0x87, size=3D0x1, align=3D0 > PNP0200: adding io range 0x89-0x8b, size=3D0x3, align=3D0 > PNP0200: adding io range 0x8f-0x91, size=3D0x3, align=3D0 > PNP0200: adding io range 0xc0-0xdf, size=3D0x20, align=3D0 > pnpbios: handle 1 device ID PNP0200 (0002d041) > PNP0100: adding irq mask 0x1 > PNP0100: adding io range 0x40-0x43, size=3D0x4, align=3D0 > pnpbios: handle 2 device ID PNP0100 (0001d041) > PNP0b00: adding irq mask 0x100 > PNP0b00: adding io range 0x70-0x71, size=3D0x2, align=3D0 > pnpbios: handle 3 device ID PNP0b00 (000bd041) > PNP0303: adding irq mask 0x2 > PNP0303: adding io range 0x60-0x60, size=3D0x1, align=3D0 > PNP0303: adding io range 0x64-0x64, size=3D0x1, align=3D0 > pnpbios: handle 4 device ID PNP0303 (0303d041) > PNP0800: adding io range 0x61-0x61, size=3D0x1, align=3D0 > pnpbios: handle 5 device ID PNP0800 (0008d041) > PNP0c04: adding irq mask 0x2000 > PNP0c04: adding io range 0xf0-0xff, size=3D0x10, align=3D0 > pnpbios: handle 6 device ID PNP0c04 (040cd041) > INT0800: adding fixed memory32 range 0xffb80000-0xffbfffff, > size=3D0x80000 > pnpbios: handle 7 device ID INT0800 (0008d425) > PNP0c01: adding fixed memory32 range 0-0x9ffff, size=3D0xa0000 > PNP0c01: adding fixed memory32 range 0xffb00000-0xffb7ffff, > size=3D0x80000 > PNP0c01: adding fixed memory32 range 0xfff00000-0xffffffff, > size=3D0x100000 > PNP0c01: adding fixed memory32 range 0xfec00000-0xfec0ffff, > size=3D0x10000 > PNP0c01: adding fixed memory32 range 0xfee00000-0xfee0ffff, > size=3D0x10000 > PNP0c01: adding fixed memory32 range 0x100000-0xffffff, > size=3D0xf00000 > pnpbios: handle 8 device ID PNP0c01 (010cd041) > PNP0c02: adding fixed memory32 range 0xf0000-0xf3fff,=20 size=3D0x4000 > PNP0c02: adding fixed memory32 range 0xf4000-0xf7fff,=20 size=3D0x4000 > PNP0c02: adding fixed memory32 range 0xf8000-0xfffff,=20 size=3D0x8000 > PNP0c02: adding fixed memory32 range 0xcc000-0xcffff,=20 size=3D0x4000 > pnpbios: handle 9 device ID PNP0c02 (020cd041) > PNP0a03: adding io range 0x290-0x29f, size=3D0x10, align=3D0 > PNP0a03: adding io range 0x4d0-0x4d1, size=3D0x2, align=3D0 > PNP0a03: adding io range 0xcf8-0xcff, size=3D0x8, align=3D0 > PNP0a03: adding io range 0x400-0x4bf, size=3D0xc0, align=3D0 > pnpbios: handle 10 device ID PNP0a03 (030ad041) > PNP0501: adding irq mask 0x10 > PNP0501: adding io range 0x3f8-0x3ff, size=3D0x8, align=3D0 > pnpbios: handle 12 device ID PNP0501 (0105d041) > PNP0400: adding irq mask 0x80 > PNP0400: adding io range 0x378-0x37f, size=3D0x8, align=3D0 > PNP0400: adding io range 0x778-0x77f, size=3D0x8, align=3D0 > pnpbios: handle 13 device ID PNP0400 (0004d041) > sc: sc0 already exists; skipping it > vga: vga0 already exists; skipping it > isa_probe_children: disabling PnP devices > isa_probe_children: probing non-PnP devices > pmtimer0 on isa0 > orm0: at iomem 0xcc000-0xd3fff pnpid ORM0000 on > isa0 > adv0: not probed (disabled) > aha0: not probed (disabled) > aic0: not probed (disabled) > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to vector 55 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: current command byte:0067 > psm0: strange result for test aux port (2). > psm0: failed to reset the aux device. > bt0: not probed (disabled) > cs0: not probed (disabled) > ed0: not probed (disabled) > fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on=20 isa0 > fe0: not probed (disabled) > ie0: not probed (disabled) > le0: not probed (disabled) > ppc0: parallel port found at 0x378 > ppc0: using extended I/O port range > ppc0: SPP > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: bpf attached > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ioapic0: routing intpin 7 (ISA IRQ 7) to vector 56 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) > sio0: irq maps: 0x841 0x851 0x841 0x841 > sio0: irq maps: 0x841 0x851 0x841 0x841 > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57 > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: irq maps: 0x841 0x841 0x841 0x841 > sio1: probe failed test(s): 0 1 2 4 6 7 9 > sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > sio2: not probed (disabled) > sio3: not probed (disabled) > sn0: not probed (disabled) > vga0: at port 0x3c0-0x3df iomem 0xa0000- 0xbffff > on isa0 > vt0: not probed (disabled) > isa_probe_children: probing PnP devices > unknown: can't assign resources (port) > unknown: at port 0x60 pnpid PNP0303 on isa0 > unknown: failed to probe at port 0x61 pnpid PNP0800 on > isa0 > unknown: failed to probe at iomem 0xffb80000- 0xffbfffff > pnpid INT0800 on isa0 > unknown: can't assign resources (memory) > unknown: at iomem 0-0x9ffff pnpid PNP0c01 on isa0 > unknown: can't assign resources (memory) > unknown: at iomem 0xf0000-0xf3fff,0xf4000-0xf7fff, 0xf8000- > 0xfffff,0xcc000-0xcffff pnpid PNP0c02 on isa0 > unknown: can't assign resources (port) > unknown: at port 0x3f8-0x3ff pnpid PNP0501 on isa0 > unknown: can't assign resources (port) > unknown: at port 0x378-0x37f pnpid PNP0400 on isa0 > ukbd0: =20 on > uhub0 > kbd2 at ukbd0 > kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 > ums0: =20 on > uhub0 > ums0: 5 buttons and Z dir. > Device configuration finished. > procfs registered > lapic: Divisor 2, Frequency 100003988 hz > Timecounter "TSC" frequency 3200127568 Hz quality -100 > Timecounters tick every 1.000 msec > lo0: bpf attached > rr232x: no controller detected. > ata0-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D40 wire > ad0: 238475MB at ata0-master SATA150 > ad0: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 > depth queue > GEOM: new disk ad0 > ad0: Intel check1 failed > ad0: Adaptec check1 failed > ad0: LSI (v3) check1 failed > ad0: LSI (v2) check1 failed > ad0: FreeBSD check1 failed > ATA PseudoRAID loaded > SMP: AP CPU #1 Launched! > cpu1 AP: > ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: > 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: > 0x000001ff > timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: > 0x00010000 > Trying to mount root from ufs:/dev/ad0s1a > start_init: trying /sbin/init > em4: Link is up 1000 Mbps Full Duplex > em6: Link is up 10 Mbps Half Duplex > em7: Link is up 100 Mbps Full Duplex > > > _______________________________________________ > 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" > From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 12:45:08 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09BFE16A475 for ; Tue, 10 Jul 2007 12:45:08 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog13.obsmtp.com (s200aog13.obsmtp.com [207.126.144.127]) by mx1.freebsd.org (Postfix) with SMTP id 6D9DF13C484 for ; Tue, 10 Jul 2007 12:44:59 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob013.postini.com ([207.126.147.11]) with SMTP; Tue, 10 Jul 2007 12:44:44 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 3F98E181422; Tue, 10 Jul 2007 13:44:44 +0100 (BST) Message-ID: <46937D97.7030507@tomjudge.com> Date: Tue, 10 Jul 2007 13:37:43 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Tom Judge References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030414B1EC@NT-IRVA-0750.brcm.ad.broadcom.com> <466873FA.9030800@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030423EE13@NT-IRVA-0750.brcm.ad.broadcom.com> <46823A78.7020501@tomjudge.com> <4683C578.6070009@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571430@NT-IRVA-0750.brcm.ad.broadcom.com> <09BFF2FA5EAB4A45B6655E151BBDD903045714EF@NT-IRVA-0750.brcm.ad.broadcom.com> <4684D5C0.3040709@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571BF1@NT-IRVA-0750.brcm.ad.broadcom.com> <468A2D55.60301@tomjudge.com> In-Reply-To: <468A2D55.60301@tomjudge.com> Content-Type: multipart/mixed; boundary="------------090901010000020407040001" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Sepherosa Ziehau , freebsd-net , David Christensen Subject: Re: Problems with BCE network adapter (Dell PE2950) 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: Tue, 10 Jul 2007 12:45:08 -0000 This is a multi-part message in MIME format. --------------090901010000020407040001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tom Judge wrote: > David Christensen wrote: >>> Sorry for the top post, please try following patch: >>> http://people.freebsd.org/~sephe/if_bce.c.diff >>> >>> This is probably the cause; I noticed it when bce(4) was ported to >>> DragonFly. >>> >> >> Thanks Sephe, I think you're on to something. I have some >> debug code in the driver to simulate mbuf allocation >> failures and when I enable that I start receiving the same >> error messages Tom reported (along with various kernel >> panics), but when I include your change the system seems >> to keep humming along. >> I'll certainly add your code into an update shortly. >> >> Dave >> > > I'm not going to have a chance to test this patch until next week but I > will let you know what the results are. > > Tom So here goes, after 2 days testing we have come up with the following data. The configuration [PE[12]950] ----> [PowerConnect 5324] The system is running 8192 byte Jumbo Frames. sultan# ifconfig bce0 bce0: flags=8847 mtu 8192 options=3b inet 172.31.0.28 netmask 0xffffff00 broadcast 172.31.0.255 inet 172.31.0.163 netmask 0xffffffff broadcast 172.31.0.163 ether 00:19:b9:e4:4d:cc media: Ethernet autoselect (1000baseTX ) status: active After applying both David and Sephe's patches I have yet to get a system in a state where it is stable with jumbo frames enabled, the systems crash almost immediately after the switch changes the port state (Spanning tree) from LEARNING to FORWARDING. The output from this crash can be found attached as crash-1.txt.gz. If the frame size is left at 1500 then the interface seems stable, however I can't fully test this as the interface is connected to a GigE only network with an mtu of 8192. If BCE_DEBUG is remove from if_bcereg.h then the system just exhibits the original problem and may or may not crash. The next test was to try the kernel with BCE_DEBUG and with the following extra patch (so that the driver does not jump to the breakpoint when an unexpected mbuf is found in the rx buffer). --- if_bce.c (revision 62) +++ if_bce.c (revision 66) @@ -4050,7 +4050,8 @@ DBRUNIF((!(rxbd->rx_bd_flags & RX_BD_FLAGS_END)), BCE_PRINTF("%s(%d): Unexpected mbuf found in rx_bd[0x%04X]!\n", __FILE__, __LINE__, sw_chain_cons); - bce_breakpoint(sc)); + bce_dump_mbuf(sc, m)); +// bce_breakpoint(sc)); /* * ToDo: If the received packet is small enough With this patch the system boots and does not crash straight away, however it is almost completely unusable. The output with this kernel can be found attached as crash-2.txt.gz. Also this causes the following new error message: fgrep -n leak crash-2.txt 3194:bce0: /usr/src/sys/dev/bce/if_bce.c(3842): Memory leak! Lost 114 mbufs from rx chain! Has no one else come across this problem, or are Jumbo frames not widely used? Tom --------------090901010000020407040001-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 13:17:50 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7EBD16A400; Tue, 10 Jul 2007 13:17:50 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id 65A4213C468; Tue, 10 Jul 2007 13:17:50 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.11.242] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1I8FbB25Os-0003km; Tue, 10 Jul 2007 15:17:49 +0200 From: Max Laier Organization: FreeBSD To: Henrik Brix Andersen Date: Tue, 10 Jul 2007 15:20:05 +0200 User-Agent: KMail/1.9.7 References: <200706160347.33331.max@love2party.net> <20070710131224.GC64775@tirith.brixandersen.dk> In-Reply-To: <20070710131224.GC64775@tirith.brixandersen.dk> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8111653.yvzq8WG2mA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707101520.12272.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18zaS3Os+RK6qn+/8RLwKXXwe1dYd8nH46MAwo JceD6ExoqvJV5FudkDBjJ4JTH87RMJnK9/+06Tep1YpOW3H/fd cJy3UK2pOQwCu77NLyEDMxFE0vj8/qJ0iUQAWWkY4s= Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf 4.1 Update available for testing 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: Tue, 10 Jul 2007 13:17:51 -0000 --nextPart8111653.yvzq8WG2mA Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 10 July 2007, Henrik Brix Andersen wrote: > Hi, > > On Sat, Jun 16, 2007 at 03:47:24AM +0200, Max Laier wrote: > > To make testing easier I'm working on RELENG_6 patches as well, but > > it will be a bit to get through the fix/build/repeat-cycles. > > I can't seem to locate the patches for RELENG_6 on > http://people.freebsd.org/~mlaier/PF41/ - are they available for > testing? Oh ... forgot about that ... there are several problems with that. First=20 of all RELENG_6 is missing the interface group infrastructure which is=20 essential to pf now. This makes it difficult to produce patches. I=20 could do it, but ... > Do you plan on MFC'ing pf-4.1 to RELENG_6 before RELENG_6_3 is > branched? =2E.. it can never be MFCed due to the ABI breakage in several essential=20 places (ifnet and pf ioctls). There is some work going on in OpenBSD 4.2 to reduce userland ABI changes=20 in the future, but for now updating pf means breaking ABIs means no MFC=20 unfortunately. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart8111653.yvzq8WG2mA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGk4eMXyyEoT62BG0RAkz/AJ9SANVEvb/S/ELGkp62EyqAqwlC2gCeKZtB 03TEFA6KxpUuFefrEDM5kCs= =Io9k -----END PGP SIGNATURE----- --nextPart8111653.yvzq8WG2mA-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 13:22:57 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAF0C16A46E; Tue, 10 Jul 2007 13:22:57 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id A81CE13C45E; Tue, 10 Jul 2007 13:22:57 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from tirith.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by solow.pil.dk (Postfix) with ESMTP id DCA1F1CC0DF; Tue, 10 Jul 2007 15:22:56 +0200 (CEST) Received: by tirith.brixandersen.dk (Postfix, from userid 1001) id 5B6C7B84F; Tue, 10 Jul 2007 15:22:56 +0200 (CEST) Date: Tue, 10 Jul 2007 15:22:56 +0200 From: Henrik Brix Andersen To: Max Laier Message-ID: <20070710132256.GD64775@tirith.brixandersen.dk> Mail-Followup-To: Max Laier , freebsd-pf@freebsd.org, freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <200706160347.33331.max@love2party.net> <20070710131224.GC64775@tirith.brixandersen.dk> <200707101520.12272.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a2FkP9tdjPU2nyhF" Content-Disposition: inline In-Reply-To: <200707101520.12272.max@love2party.net> X-PGP-Key: http://www.brixandersen.dk/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf 4.1 Update available for testing 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: Tue, 10 Jul 2007 13:22:58 -0000 --a2FkP9tdjPU2nyhF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Max, On Tue, Jul 10, 2007 at 03:20:05PM +0200, Max Laier wrote: > On Tuesday 10 July 2007, Henrik Brix Andersen wrote: > Oh ... forgot about that ... there are several problems with that. First= =20 > of all RELENG_6 is missing the interface group infrastructure which is=20 > essential to pf now. This makes it difficult to produce patches. I=20 > could do it, but ... I see. > > Do you plan on MFC'ing pf-4.1 to RELENG_6 before RELENG_6_3 is > > branched? >=20 > ... it can never be MFCed due to the ABI breakage in several essential=20 > places (ifnet and pf ioctls). >=20 > There is some work going on in OpenBSD 4.2 to reduce userland ABI changes= =20 > in the future, but for now updating pf means breaking ABIs means no MFC= =20 > unfortunately. Ah, of course - didn't think of that. Guess we'll just have to wait for 7.0 to hit the streets, then :) Thank you for working on this. Regards, Brix --=20 Henrik Brix Andersen --a2FkP9tdjPU2nyhF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: GnuPG signed iD8DBQFGk4gvv+Q4flTiePgRAkFtAJ4gq+NFiEBbKJpn5LEbWipy+1bqZQCgwgYD 8mf3EydbfPIIoXpbnTsQw2o= =qRsq -----END PGP SIGNATURE----- --a2FkP9tdjPU2nyhF-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 13:35:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2D6F16A468; Tue, 10 Jul 2007 13:35:23 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id 5BC1913C469; Tue, 10 Jul 2007 13:35:23 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from tirith.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by solow.pil.dk (Postfix) with ESMTP id 68B471CC0B8; Tue, 10 Jul 2007 15:12:25 +0200 (CEST) Received: by tirith.brixandersen.dk (Postfix, from userid 1001) id D032EB84F; Tue, 10 Jul 2007 15:12:24 +0200 (CEST) Date: Tue, 10 Jul 2007 15:12:24 +0200 From: Henrik Brix Andersen To: Max Laier Message-ID: <20070710131224.GC64775@tirith.brixandersen.dk> Mail-Followup-To: Max Laier , freebsd-pf@freebsd.org, freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <200706160347.33331.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6zdv2QT/q3FMhpsV" Content-Disposition: inline In-Reply-To: <200706160347.33331.max@love2party.net> X-PGP-Key: http://www.brixandersen.dk/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf 4.1 Update available for testing 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: Tue, 10 Jul 2007 13:35:23 -0000 --6zdv2QT/q3FMhpsV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Jun 16, 2007 at 03:47:24AM +0200, Max Laier wrote: > To make testing easier I'm working on RELENG_6 patches as well, but it=20 > will be a bit to get through the fix/build/repeat-cycles. I can't seem to locate the patches for RELENG_6 on http://people.freebsd.org/~mlaier/PF41/ - are they available for testing? Do you plan on MFC'ing pf-4.1 to RELENG_6 before RELENG_6_3 is branched? Regards, Brix --=20 Henrik Brix Andersen --6zdv2QT/q3FMhpsV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: GnuPG signed iD8DBQFGk4W4v+Q4flTiePgRAgaXAJ437APnGT8qoMO5EiSswyzZ5Oo4jgCeL/32 NFejaEnZs+hmVOq8bCAz6do= =940L -----END PGP SIGNATURE----- --6zdv2QT/q3FMhpsV-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 13:42:50 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F32CF16A46E; Tue, 10 Jul 2007 13:42:49 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id A369913C483; Tue, 10 Jul 2007 13:42:49 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=pOGlJcHmKVh4VFLAezmrJPg8WFpOOGRWf+IjuWFix6yI3Z6RWqNeCrXFSdz87X7kredHYpH0ULntasHPfaPmFSlyV5jlQ5FaXHlcu52f4fhLx7xDnIk4pAE6hraBKK/9w0xrI6qRfw//fPNkfgxAOIRSZQwE45SqOUFvODV5ekk=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1I8FgA-0001Lj-Ib; Tue, 10 Jul 2007 17:22:58 +0400 Date: Tue, 10 Jul 2007 17:22:53 +0400 From: Eygene Ryabinkin To: Mike Silbersack Message-ID: <20070710132253.GJ1038@void.codelabs.ru> References: <20070709234401.S29353@odysseus.silby.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070709234401.S29353@odysseus.silby.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: Andre Oppermann , Robert Watson , current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers 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: Tue, 10 Jul 2007 13:42:50 -0000 Mike, good day. Tue, Jul 10, 2007 at 12:20:49AM -0500, Mike Silbersack wrote: > Anyway, the attached patch simplifies the syncache structure a bit and > makes it retransmit properly. I'd appreciate testing from anyone who > has experienced TCP problems with FreeBSD 7, as well as anyone who is > pushing significant traffic through FreeBSD 7. Can't say that I am pushing much traffic through my box, but after applying your patch and rebuilding the kernel I am still seeing the messages like ----- TCP: [209.132.176.NNN]:NNN to [144.206.NNN.NNN]:NNN tcpflags 0x19; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [201.90.65.NNN]:NNN to [144.206.NNN.NNN]:NNN; syncache_timer: Response timeout ----- But what had changed is that the lines with the 'syncache_timer' started to appear. There were no such lines prior to the patch, only the 'failed SYNCOOKIE' ones. But the patch received only half a day of testing, so I will continue the tests and will inform you if some other information will be available. Up to date I don't see problems that had appeared without the patch, but they tend to show up after a midnight ;)) Thank you! -- Eygene From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 13:56:54 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D55E816A41F for ; Tue, 10 Jul 2007 13:56:54 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog11.obsmtp.com (s200aog11.obsmtp.com [207.126.144.125]) by mx1.freebsd.org (Postfix) with SMTP id D67F713C44B for ; Tue, 10 Jul 2007 13:56:51 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob011.postini.com ([207.126.147.11]) with SMTP; Tue, 10 Jul 2007 13:56:43 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 80CC6181422; Tue, 10 Jul 2007 14:56:43 +0100 (BST) Message-ID: <46938E75.80900@tomjudge.com> Date: Tue, 10 Jul 2007 14:49:41 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Tom Judge References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030414B1EC@NT-IRVA-0750.brcm.ad.broadcom.com> <466873FA.9030800@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030423EE13@NT-IRVA-0750.brcm.ad.broadcom.com> <46823A78.7020501@tomjudge.com> <4683C578.6070009@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571430@NT-IRVA-0750.brcm.ad.broadcom.com> <09BFF2FA5EAB4A45B6655E151BBDD903045714EF@NT-IRVA-0750.brcm.ad.broadcom.com> <4684D5C0.3040709@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571BF1@NT-IRVA-0750.brcm.ad.broadcom.com> <468A2D55.60301@tomjudge.com> <46937D97.7030507@tomjudge.com> In-Reply-To: <46937D97.7030507@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sepherosa Ziehau , freebsd-net , David Christensen Subject: Re: Problems with BCE network adapter (Dell PE2950) 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: Tue, 10 Jul 2007 13:56:54 -0000 Tom Judge wrote: > Tom Judge wrote: >> David Christensen wrote: >>>> Sorry for the top post, please try following patch: >>>> http://people.freebsd.org/~sephe/if_bce.c.diff >>>> >>>> This is probably the cause; I noticed it when bce(4) was ported to >>>> DragonFly. >>>> >>> >>> Thanks Sephe, I think you're on to something. I have some >>> debug code in the driver to simulate mbuf allocation >>> failures and when I enable that I start receiving the same >>> error messages Tom reported (along with various kernel >>> panics), but when I include your change the system seems >>> to keep humming along. I'll certainly add your code into an update >>> shortly. >>> >>> Dave >>> >> >> I'm not going to have a chance to test this patch until next week but >> I will let you know what the results are. >> >> Tom > > > So here goes, after 2 days testing we have come up with the following > data. > > The configuration > > [PE[12]950] ----> [PowerConnect 5324] > > The system is running 8192 byte Jumbo Frames. > > sultan# ifconfig bce0 > bce0: flags=8847 mtu 8192 > options=3b > inet 172.31.0.28 netmask 0xffffff00 broadcast 172.31.0.255 > inet 172.31.0.163 netmask 0xffffffff broadcast 172.31.0.163 > ether 00:19:b9:e4:4d:cc > media: Ethernet autoselect (1000baseTX ) > status: active > > > After applying both David and Sephe's patches I have yet to get a system > in a state where it is stable with jumbo frames enabled, the systems > crash almost immediately after the switch changes the port state > (Spanning tree) from LEARNING to FORWARDING. The output from this crash > can be found attached as crash-1.txt.gz. > > If the frame size is left at 1500 then the interface seems stable, > however I can't fully test this as the interface is connected to a GigE > only network with an mtu of 8192. > > If BCE_DEBUG is remove from if_bcereg.h then the system just exhibits > the original problem and may or may not crash. > > The next test was to try the kernel with BCE_DEBUG and with the > following extra patch (so that the driver does not jump to the > breakpoint when an unexpected mbuf is found in the rx buffer). > > --- if_bce.c (revision 62) > +++ if_bce.c (revision 66) > @@ -4050,7 +4050,8 @@ > DBRUNIF((!(rxbd->rx_bd_flags & RX_BD_FLAGS_END)), > BCE_PRINTF("%s(%d): Unexpected mbuf > found in rx_bd[0x%04X]!\n", > __FILE__, __LINE__, sw_chain_cons); > - bce_breakpoint(sc)); > + bce_dump_mbuf(sc, m)); > +// bce_breakpoint(sc)); > > /* > * ToDo: If the received packet is small enough > > > With this patch the system boots and does not crash straight away, > however it is almost completely unusable. The output with this kernel > can be found attached as crash-2.txt.gz. Also this causes the following > new error message: > > fgrep -n leak crash-2.txt > 3194:bce0: /usr/src/sys/dev/bce/if_bce.c(3842): Memory leak! Lost 114 > mbufs from rx chain! > > Has no one else come across this problem, or are Jumbo frames not widely > used? > > Tom > It would seem that the crash can be simulated just by increasing the MTU above 1500 (tested in single user mode). Tom From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 16:51:49 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 464FB16A41F for ; Tue, 10 Jul 2007 16:51:49 +0000 (UTC) (envelope-from bth@higonnet.net) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id DA0AE13C43E for ; Tue, 10 Jul 2007 16:51:48 +0000 (UTC) (envelope-from bth@higonnet.net) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by postfix1-g20.free.fr (Postfix) with ESMTP id D287515FF2CE for ; Tue, 10 Jul 2007 18:19:27 +0200 (CEST) Received: from freebsd.paristolet.com (higonnet.net [82.238.41.134]) by smtp8-g19.free.fr (Postfix) with ESMTP id DACAD1AA55 for ; Tue, 10 Jul 2007 18:19:26 +0200 (CEST) Received: from montreal (montreal [192.168.0.110]) by freebsd.paristolet.com (Postfix) with ESMTP id 3E11285B863 for ; Tue, 10 Jul 2007 18:19:29 +0200 (CEST) Content-Disposition: inline From: "Bernard T. Higonnet" Organization: self To: freebsd-net@freebsd.org Date: Tue, 10 Jul 2007 18:19:27 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200707101819.28061.bth@higonnet.net> Subject: mpd isn't listening on 1723 because he can't get it thhough it isn't used 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: Tue, 10 Jul 2007 16:51:49 -0000 Hello, I want to set up a VPN server on a freebsd machine so Windows clients can use it. I am using FreeBSD 6.1 and mpd 3.18 from the ports collection. When I run mpd I get this: mpd Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 11377, version 3.18 (root@freebsd2.paristolet.com 10:10 8-Jul-2007) [bundle1] ppp node is "mpd11377-bundle1" mpd: bind: Can't assign requested address mpd: can't get PPTP listening socket mpd: bind: Can't assign requested address mpd: can't get PPTP listening socket [bundle1] using interface ng0 Of course since he couldn't get a hold of port 1723 he couldn't establish a socket and nothing happens. netstat shows no one is listening on 1723: netstat -a | fgrep LIS tcp4 0 0 freebsd2.ssh montreal.50547 ESTABLISHED tcp4 0 0 freebsd2.ssh montreal.61574 ESTABLISHED tcp4 0 0 *.ssh *.* LISTEN tcp6 0 0 *.ssh *.* LISTEN tcp4 0 0 *.smtp *.* LISTEN tcp6 0 0 *.nfsd *.* LISTEN tcp4 0 0 *.nfsd *.* LISTEN tcp6 0 0 *.636 *.* LISTEN tcp4 0 0 *.637 *.* LISTEN tcp4 0 0 *.sunrpc *.* LISTEN tcp6 0 0 *.sunrpc *.* LISTEN There is no other instance of mpd running Here are the mpd conf and link files: default: load pptp1conf # load pptp2conf pptp1conf: new -i ng0 bundle1 pptp1 set ipcp ranges 192.168.1.103/32 192.168.1.200/32 load common #pptp2conf: # new -i ng1 bundle2 pptp2 # set ipcp ranges 192.168.1.103/32 192.168.1.201/32 # load common common: set iface disable on-demand set iface enable proxy-arp set iface idle 0 set iface enable tcpmssfix set bundle enable multilink set link enable acfcomp protocomp set link no pap chap set link enable chap # set link mtu 1460 set link keep-alive 10 60 set ipcp yes vjcomp set ipcp dns 208.67.222.222 208.67.220.220 #set ipcp nbns 172.20.1.1 172.20.1.8 #set bundle enable compression #set ccp yes mppc #set ccp yes mpp-e40 #set ccp yes mpp-e128 #set ccp yes mpp-stateless pptp1: set link type pptp set pptp self 82.238.41.134 500 set pptp enable incoming set pptp disable originate pptp2: set link type pptp set pptp self 82.238.41.134 set pptp enable incoming set pptp disable originate As usual, all help appreciated Bernard Higonnet From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 17:16:39 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97FEA16A46C for ; Tue, 10 Jul 2007 17:16:39 +0000 (UTC) (envelope-from bth@higonnet.net) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by mx1.freebsd.org (Postfix) with ESMTP id 44FFE13C48A for ; Tue, 10 Jul 2007 17:16:39 +0000 (UTC) (envelope-from bth@higonnet.net) Received: from freebsd.paristolet.com (higonnet.net [82.238.41.134]) by smtp8-g19.free.fr (Postfix) with ESMTP id 9085E1B452 for ; Tue, 10 Jul 2007 19:16:38 +0200 (CEST) Received: from montreal (montreal [192.168.0.110]) by freebsd.paristolet.com (Postfix) with ESMTP id C0C3085B862 for ; Sun, 8 Jul 2007 19:47:37 +0200 (CEST) From: "Bernard T. Higonnet" Organization: self To: freebsd-net@freebsd.org Date: Sun, 8 Jul 2007 19:47:37 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707081947.37225.bth@higonnet.net> Subject: newbie problems mpd server on freebsd 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: Tue, 10 Jul 2007 17:16:39 -0000 Hello, I want to set up a VPN server on a freebsd machine so Windows clients can use it. I am using FreeBSD 6.1 and mpd 3.18 from the ports collection. My basic problem is that mpd does not do anything and doesn't complain about anything, so I'm not making much progress. I run mpd with "mpd -k -s higvpn" Here are various facts and/or symptoms 1) all the show commands show there isn't anything (bundles, links, etc. etc.) 2) netstat says nobody's listening on 1723 3) Windows VPN's produce error 678 ("There was no answer") which seems consonant with (2) 4) I can't find any trace info anywhere 5) there is no firewall issue because the freebsd vpn server and Windows machine are both on my own little network (192.168.0) and neither machine has one for the time being In an effort to embarrass myself here is my mpd.conf file default: load pptp1 load pptp2 pptp1: new -i ng0 pptp1 pptp1 load common pptp2: new -i ng1 pptp2 pptp2 load common common: set iface disable on-demand set iface enable proxy-arp set iface idle 0 set iface enable tcpmssfix set bundle enable multilink set link enable acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp set ipcp ranges 82.238.41.134/32 192.168.0.201/24 set ipcp dns 208.67.222.222 208.67.220.220 #set ipcp nbns 172.20.1.1 172.20.1.8 #set bundle enable compression #set ccp yes mppc #set ccp yes mpp-e40 #set ccp yes mpp-e128 #set ccp yes mpp-stateless TIA Bernard Higonnet From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 18:04:53 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 299D316A41F for ; Tue, 10 Jul 2007 18:04:53 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog14.obsmtp.com (s200aog14.obsmtp.com [207.126.144.128]) by mx1.freebsd.org (Postfix) with SMTP id 9875713C44C for ; Tue, 10 Jul 2007 18:04:49 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob014.postini.com ([207.126.147.11]) with SMTP; Tue, 10 Jul 2007 18:04:43 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 2F85A18141C; Tue, 10 Jul 2007 19:04:43 +0100 (BST) Message-ID: <4693C88F.8050204@tomjudge.com> Date: Tue, 10 Jul 2007 18:57:35 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Tom Judge References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030414B1EC@NT-IRVA-0750.brcm.ad.broadcom.com> <466873FA.9030800@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030423EE13@NT-IRVA-0750.brcm.ad.broadcom.com> <46823A78.7020501@tomjudge.com> <4683C578.6070009@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571430@NT-IRVA-0750.brcm.ad.broadcom.com> <09BFF2FA5EAB4A45B6655E151BBDD903045714EF@NT-IRVA-0750.brcm.ad.broadcom.com> <4684D5C0.3040709@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571BF1@NT-IRVA-0750.brcm.ad.broadcom.com> <468A2D55.60301@tomjudge.com> <46937D97.7030507@tomjudge.com> <46938E75.80900@tomjudge.com> In-Reply-To: <46938E75.80900@tomjudge.com> Content-Type: multipart/mixed; boundary="------------060500010901090709040408" Cc: Sepherosa Ziehau , freebsd-net , David Christensen Subject: Re: Problems with BCE network adapter (Dell PE2950) 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: Tue, 10 Jul 2007 18:04:53 -0000 This is a multi-part message in MIME format. --------------060500010901090709040408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tom Judge wrote: > Tom Judge wrote: >> Tom Judge wrote: >>> David Christensen wrote: >>>>> Sorry for the top post, please try following patch: >>>>> http://people.freebsd.org/~sephe/if_bce.c.diff >>>>> >>>>> This is probably the cause; I noticed it when bce(4) was ported to >>>>> DragonFly. >>>>> >>>> >>>> Thanks Sephe, I think you're on to something. I have some >>>> debug code in the driver to simulate mbuf allocation >>>> failures and when I enable that I start receiving the same >>>> error messages Tom reported (along with various kernel >>>> panics), but when I include your change the system seems >>>> to keep humming along. I'll certainly add your code into an update >>>> shortly. >>>> >>>> Dave >>>> >>> >>> I'm not going to have a chance to test this patch until next week but >>> I will let you know what the results are. >>> >>> Tom >> >> >> So here goes, after 2 days testing we have come up with the following >> data. >> >> The configuration >> >> [PE[12]950] ----> [PowerConnect 5324] >> >> The system is running 8192 byte Jumbo Frames. >> >> sultan# ifconfig bce0 >> bce0: flags=8847 mtu 8192 >> options=3b >> inet 172.31.0.28 netmask 0xffffff00 broadcast 172.31.0.255 >> inet 172.31.0.163 netmask 0xffffffff broadcast 172.31.0.163 >> ether 00:19:b9:e4:4d:cc >> media: Ethernet autoselect (1000baseTX ) >> status: active >> >> >> After applying both David and Sephe's patches I have yet to get a >> system in a state where it is stable with jumbo frames enabled, the >> systems crash almost immediately after the switch changes the port >> state (Spanning tree) from LEARNING to FORWARDING. The output from >> this crash can be found attached as crash-1.txt.gz. >> >> If the frame size is left at 1500 then the interface seems stable, >> however I can't fully test this as the interface is connected to a >> GigE only network with an mtu of 8192. >> >> If BCE_DEBUG is remove from if_bcereg.h then the system just exhibits >> the original problem and may or may not crash. >> >> The next test was to try the kernel with BCE_DEBUG and with the >> following extra patch (so that the driver does not jump to the >> breakpoint when an unexpected mbuf is found in the rx buffer). >> >> --- if_bce.c (revision 62) >> +++ if_bce.c (revision 66) >> @@ -4050,7 +4050,8 @@ >> DBRUNIF((!(rxbd->rx_bd_flags & RX_BD_FLAGS_END)), >> BCE_PRINTF("%s(%d): Unexpected mbuf >> found in rx_bd[0x%04X]!\n", >> __FILE__, __LINE__, sw_chain_cons); >> - bce_breakpoint(sc)); >> + bce_dump_mbuf(sc, m)); >> +// bce_breakpoint(sc)); >> >> /* >> * ToDo: If the received packet is small enough >> >> >> With this patch the system boots and does not crash straight away, >> however it is almost completely unusable. The output with this kernel >> can be found attached as crash-2.txt.gz. Also this causes the >> following new error message: >> >> fgrep -n leak crash-2.txt >> 3194:bce0: /usr/src/sys/dev/bce/if_bce.c(3842): Memory leak! Lost 114 >> mbufs from rx chain! >> >> Has no one else come across this problem, or are Jumbo frames not >> widely used? >> >> Tom >> > It would seem that the crash can be simulated just by increasing the MTU > above 1500 (tested in single user mode). > Ok so I think I have fix the problem with the rx_bd tracking. I have ported rboyer's patch to NetBSD's bnx driver to FreeBSD (patch attached). The patch seems to get rid of two problems: 1) Unexpected mbuf in rx_bd 2) Too many free rx_bd's However I am still faced with the problem of frames with missing ethernet headers: bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found. Min(60), Actual(0), Max(9022) bce0: mbuf: vaddr = 0xFFFFFF00:7B69AC00, m_len = 9216, m_flags = ( M_EXT M_PKTHDR ) m_data = 0xFFFFFFFF:86F76000 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bce0: - m_pkthdr: flags = ( ) csum_flags = ( ) bce0: - m_ext: vaddr = 0xFFFFFFFF:86F76000, ext_size = 9216, type = EXT_JUMBO9 bce0: discard frame w/o leading ethernet header (len 4294967292 pkt len 4294967292) bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found. Min(60), Actual(0), Max(9022) bce0: mbuf: vaddr = 0xFFFFFF00:5EB48B00, m_len = 9216, m_flags = ( M_EXT M_PKTHDR ) m_data = 0xFFFFFFFF:86F73000 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bce0: - m_pkthdr: flags = ( ) csum_flags = ( ) bce0: - m_ext: vaddr = 0xFFFFFFFF:86F73000, ext_size = 9216, type = EXT_JUMBO9 bce0: discard frame w/o leading ethernet header (len 4294967292 pkt len 4294967292) bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found. Min(60), Actual(27745), Max(9022) bce0: mbuf: vaddr = 0xFFFFFF00:5E9DDC00, m_len = 9216, m_flags = ( M_EXT M_PKTHDR ) m_data = 0xFFFFFFFF:86EF8000 0x00: 2C 6F 75 3D 50 65 72 73 6F 6E 61 6C 2C 6F 75 3D 0x10: 47 72 6F 75 70 73 2C 6F 3D 4D 69 6E 74 65 6C 30 0x20: 28 30 11 04 02 63 6E 31 0B 04 09 63 62 75 74 74 0x30: 72 6F 73 65 30 13 04 09 67 69 64 4E 75 6D 62 65 0x40: 72 31 06 04 04 31 31 30 38 30 5E 02 01 02 64 59 0x50: 04 31 63 6E 3D 6D 63 61 68 6D 2C 6F 75 3D 4C 6F 0x60: 6E 64 6F 6E 2C 6F 75 3D 50 65 72 73 6F 6E 61 6C 0x70: 2C 6F 75 3D 47 72 6F 75 70 73 2C 6F 3D 4D 69 6E bce0: - m_pkthl er0ror 9 67 69 64 4E 75 6D 62 65 72 31 06 04 04 31 30 0x70: 33 37 30 62 02 01 02 64 5D 04 33 63 6E 3D 72 63 bce0: - m_pkthdr: flags = ( ) csum_flags = ( ) bce0: - m_ext: vaddr = 0xFFFFFFFF:86E8C000, ext_size = 9216, type = EXT_JUMBO9 bce0: /usr/src/sys/dev/bce/if_bce.c(4081): Unexpected mbuf found in rx_bd[0x002A]! bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found. Min(60), Actual(28515), Max(9022) bce0: mbuf: vaddr = 0xFFFFFF00:5AB4C800, m_len = 9216, m_flags = ( M_EXT M_PKTHDR ) m_data = 0xFFFFFFFF:86F28000 0x00: 30 0E 04 02 63 6E 31 08 04 06 63 6F 68 61 72 61 0x10: 30 13 04 09 67 69 64 4E 75 6D 62 65 72 31 06 04 0x20: 04 31 30 37 32 30 65 02 01 02 64 60 04 35 63 6E 0x30: 3D 6A 70 69 65 6B 61 72 73 2C 6F 75 3D 43 68 69 0x40: 63 61 67 6F 2C 6F 75 3D 50 65 72 73 6F 6E 61 6C 0x50: 2C 6F 75 3D 47 72 6F 75 70 73 2C 6F 3D 4D 69 6E 0x60: 74 65 6C 30 27 30 10 04 02 63 6E 31 0A 04 08 6A 0x70: 70 69 65 6B 61 72 73 30 13 04 09 67 69 64 4E 75 bce0: - m_pkthdr: flags = ( ) csum_flags = ( ) bce0: - m_ext: vaddr = 0xFFFFFFFF:86F28000, ext_size = 9216, type = EXT_JUMBO9 bce0: /usr/src/sys/dev/bce/if_bce.c(4081): Unexpected mbuf found in rx_bd[0x002E]! bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found. Min(60), Actual(28460), Max(9022) bce0: mbuf: vaddr = 0xFFFFFF00:5EB9F200, m_len = 9216, m_flags = ( M_EXT M_PKTHDR ) m_data = 0xFFFFFFFF:86F70000 0x00: 04 32 63 6E 3D 69 6E 65 73 73 2C 6F 75 3D 43 68 0x10: 69 63 61 67 6F 2C 6F 75 3D 50 65 72 73 6F 6E 61 0x20: 6C 2C 6F 75 3D 47 72 6F 75 70 73 2C 6F 3D 4D 69 0x30: 6E 74 65 6C 30 24 30 0D 04 02 63 6E 31 07 04 05 0x40: 69 6E 65 73 73 30 13 04 09 67 69 64 4E 75 6D 62 0x50: 65 72 31 06 04 04 31 31 34 32 30 67 02 01 02 64 0x60: 62 04 36 63 6E 3D 70 6D 63 6E 61 6D 61 72 61 2C 0x70: 6F 75 3D 43 68 69 63 61 67 6F 2C 6F 75 3D 50 65 bce0: - m_pkthdr: flags = ( ) csum_flags = ( ) bce0: - m_ext: vaddr = 0xFFFFFFFF:86F70000, ext_size = 9216, type = EXT_JUMBO9 bce0: /usr/src/sys/dev/bce/if_bce.c(4081): Unexpected mbuf found in rx_bd[0x0032]! bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found. Min(60), Actual(28787), Max(9022) bce0: mbuf: vaddr = 0xFFFFFF00:5AB4CA00, m_len = 9216, m_flags = ( M_EXT M_PKTHDR ) m_data = 0xFFFFFFFF:86F6D000 0x00: 02 01 02 64 57 04 30 63 6E 3D 73 70 79 65 2C 6F 0x10: 75 3D 4C 6F 6E 64 6F 6E 2C 6F 75 3D 50 65 72 73 0x20: 6F 6E 61 6C 2C 6F 75 3D 47 72 6F 75 70 73 2C 6F 0x30: 3D 4D 69 6E 74 65 6C 30 23 30 0C 04 02 63 6E 31 0x40: 06 04 04 73 70 79 65 30 13 04 09 67 69 64 4E 75 0x50: 6D 62 65 72 31 06 04 04 31 32 30 39 30 59 02 01 0x60: 02 64 54 04 2F 63 6E 3D 71 61 2C 6F 75 3D 43 68 0x70: 69 63 61 67 6F 2C 6F 75 3D 50 65 72 73 6F 6E 61 bce0: - m_pkthdr: flags = ( ) csum_flags = ( ) bce0: - m_ext: vaddr = 0xFFFFFFFF:86F6D000, ext_size = 9216, type = EXT_JUMBO9 bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found. Min(60), Actual(12855), Max(9022) bce0: mbuf: vaddr =0 67 02 01 02 64 0x60: 62 04 36 63 6E 3D 70 6D 63 6E 61 6D 61 72 61 2C 0x70: 6F 75 3D 43 68 69 63 61 67 6F 2C 6F 75 3D 50 65 bce0: - m_pkthdr: flags = ( ) csum_flags = ( ) bce0: - m_ext: vaddr = 0xFFFFFFFF:86F70000, ext_size = 9216, type = EXT_JUMBO9 if_bnx.c - 1.4 -> 1.5 LOG: RX buffers are malloced memory of 9216 bytes. This can require from 1 to 4 DMA memory segments, depending on how the buffer is in memory. When receiving a packet, we allocate a new one to remplace the one we've used. It can need more segments than the one it remplace, leading to corrution of the RX descriptors, and a panic in bus_dmamap_sync() (DIAGNOSTIC kernels) or possibly memory corruption. Fix: - bce_get_buf() allocates as many buffer as possible, checking the number of free RX descriptors. Because one receive buffer is not guaranteed to be remplaced on receive, call bce_get_buf() from bce_tick() too. This also improve error handling from bce_get_buf(). - use MCLGET() instead of MEXTMALLOC() if we're running with the standard ethernet MTU. This gives us more receive buffers and waste less memory. Seem to be moving in the right direction slowly. Tom --------------060500010901090709040408 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" Index: if_bce.c =================================================================== --- if_bce.c (revision 67) +++ if_bce.c (revision 74) @@ -732,7 +732,7 @@ ifp->if_capenable = ifp->if_capabilities; /* Assume a standard 1500 byte MTU size for mbuf allocations. */ - sc->mbuf_alloc_size = MCLBYTES; +// sc->mbuf_alloc_size = MCLBYTES; #ifdef DEVICE_POLLING ifp->if_capabilities |= IFCAP_POLLING; #endif @@ -3475,10 +3475,12 @@ bus_dma_segment_t segs[4]; struct mbuf *m_new = NULL; struct rx_bd *rxbd; - int i, nsegs, error, rc = 0; + int i, nsegs, rc = 0; #ifdef BCE_DEBUG u16 debug_chain_prod = *chain_prod; #endif + u16 first_chain_prod; + u16 min_free_bd; DBPRINT(sc, (BCE_VERBOSE_RESET | BCE_VERBOSE_RECV), "Entering %s()\n", __FUNCTION__); @@ -3491,114 +3493,146 @@ DBPRINT(sc, BCE_VERBOSE_RECV, "%s(enter): prod = 0x%04X, chain_prod = 0x%04X, " "prod_bseq = 0x%08X\n", __FUNCTION__, *prod, *chain_prod, *prod_bseq); - if (m == NULL) { + /* try to get in as many mbufs as possible */ + if (sc->mbuf_alloc_size == MCLBYTES) + min_free_bd = (MCLBYTES + PAGE_SIZE - 1) / PAGE_SIZE; + else + min_free_bd = (BCE_MAX_MTU + PAGE_SIZE - 1) / PAGE_SIZE; + while (sc->free_rx_bd >= min_free_bd) { + if (m == NULL) { + DBRUNIF(DB_RANDOMTRUE(bce_debug_mbuf_allocation_failure), + BCE_PRINTF("%s(%d): Simulating mbuf allocation failure.\n", + __FILE__, __LINE__); + sc->mbuf_alloc_failed++; + rc = ENOBUFS; + goto bce_get_buf_exit); - DBRUNIF(DB_RANDOMTRUE(bce_debug_mbuf_allocation_failure), - BCE_PRINTF("%s(%d): Simulating mbuf allocation failure.\n", - __FILE__, __LINE__); - sc->mbuf_alloc_failed++; - rc = ENOBUFS; - goto bce_get_buf_exit); + /* This is a new mbuf allocation. */ + MGETHDR(m_new, M_DONTWAIT, MT_DATA); + if (m_new == NULL) { + DBPRINT(sc, BCE_WARN, + "%s(%d): RX mbuf header allocation failed!\n", + __FILE__, __LINE__); +// + DBRUNIF(1, sc->mbuf_alloc_failed++); +// - /* This is a new mbuf allocation. */ - MGETHDR(m_new, M_DONTWAIT, MT_DATA); - if (m_new == NULL) { + rc = ENOBUFS; + goto bce_get_buf_exit; + } +// + DBRUNIF(1, sc->rx_mbuf_alloc++); + if (sc->mbuf_alloc_size == MCLBYTES) + MCLGET(m_new, M_DONTWAIT); + else + m_cljget(m_new, M_DONTWAIT, sc->mbuf_alloc_size); + if (!(m_new->m_flags & M_EXT)) { + DBPRINT(sc, BCE_WARN, + "%s(%d): RX mbuf chain allocation failed!\n", + __FILE__, __LINE__); - DBPRINT(sc, BCE_WARN, "%s(%d): RX mbuf header allocation failed!\n", - __FILE__, __LINE__); + m_freem(m_new); +// + DBRUNIF(1, sc->rx_mbuf_alloc--); + DBRUNIF(1, sc->mbuf_alloc_failed++); - DBRUNIF(1, sc->mbuf_alloc_failed++); + rc = ENOBUFS; + goto bce_get_buf_exit; + } - rc = ENOBUFS; - goto bce_get_buf_exit; - } + } else { + m_new = m; + m = NULL; + m_new->m_data = m_new->m_ext.ext_buf; + } + m_new->m_len = m_new->m_pkthdr.len = sc->mbuf_alloc_size; +// - DBRUNIF(1, sc->rx_mbuf_alloc++); - m_cljget(m_new, M_DONTWAIT, sc->mbuf_alloc_size); - if (!(m_new->m_flags & M_EXT)) { - - DBPRINT(sc, BCE_WARN, "%s(%d): RX mbuf chain allocation failed!\n", - __FILE__, __LINE__); - + /* Map the mbuf cluster into device memory. */ + map = sc->rx_mbuf_map[*chain_prod]; + first_chain_prod = *chain_prod; + if (bus_dmamap_load_mbuf_sg(sc->rx_mbuf_tag, map, m_new, segs, &nsegs, BUS_DMA_NOWAIT)) { + BCE_PRINTF("%s(%d): Error mapping mbuf into RX chain!\n", + __FILE__, __LINE__); +// m_freem(m_new); DBRUNIF(1, sc->rx_mbuf_alloc--); - DBRUNIF(1, sc->mbuf_alloc_failed++); rc = ENOBUFS; goto bce_get_buf_exit; } - m_new->m_len = m_new->m_pkthdr.len = sc->mbuf_alloc_size; - } else { - m_new = m; - m_new->m_len = m_new->m_pkthdr.len = sc->mbuf_alloc_size; - m_new->m_data = m_new->m_ext.ext_buf; - } + bus_dmamap_sync(sc->rx_mbuf_tag, map, BUS_DMASYNC_PREREAD); +// - /* Map the mbuf cluster into device memory. */ - map = sc->rx_mbuf_map[*chain_prod]; - error = bus_dmamap_load_mbuf_sg(sc->rx_mbuf_tag, map, m_new, - segs, &nsegs, BUS_DMA_NOWAIT); - if (error) { - BCE_PRINTF("%s(%d): Error mapping mbuf into RX chain!\n", - __FILE__, __LINE__); + /* Watch for overflow. */ + DBRUNIF((sc->free_rx_bd > USABLE_RX_BD), + BCE_PRINTF("%s(%d): Too many free rx_bd (0x%04X > 0x%04X)!\n", + __FILE__, __LINE__, sc->free_rx_bd, (u16) USABLE_RX_BD)); - m_freem(m_new); + /* Update some debug statistic counters */ + DBRUNIF((sc->free_rx_bd < sc->rx_low_watermark), + sc->rx_low_watermark = sc->free_rx_bd); + DBRUNIF((sc->free_rx_bd == 0), sc->rx_empty_count++); - DBRUNIF(1, sc->rx_mbuf_alloc--); + /* + * Setup the rx_bd for the first segment + */ + rxbd = &sc->rx_bd_chain[RX_PAGE(*chain_prod)][RX_IDX(*chain_prod)]; - rc = ENOBUFS; - goto bce_get_buf_exit; - } + rxbd->rx_bd_haddr_lo = htole32(BCE_ADDR_LO(segs[0].ds_addr)); + rxbd->rx_bd_haddr_hi = htole32(BCE_ADDR_HI(segs[0].ds_addr)); + rxbd->rx_bd_len = htole32(segs[0].ds_len); + rxbd->rx_bd_flags = htole32(RX_BD_FLAGS_START); + *prod_bseq += segs[0].ds_len; + bus_dmamap_sync(sc->rx_mbuf_tag, + sc->rx_bd_chain_map[RX_PAGE(*chain_prod)], + BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + for (i = 1; i < nsegs; i++) { + *prod = NEXT_RX_BD(*prod); + *chain_prod = RX_CHAIN_IDX(*prod); - /* Watch for overflow. */ - DBRUNIF((sc->free_rx_bd > USABLE_RX_BD), - BCE_PRINTF("%s(%d): Too many free rx_bd (0x%04X > 0x%04X)!\n", - __FILE__, __LINE__, sc->free_rx_bd, (u16) USABLE_RX_BD)); + rxbd = &sc->rx_bd_chain[RX_PAGE(*chain_prod)][RX_IDX(*chain_prod)]; + rxbd->rx_bd_haddr_lo = htole32(BCE_ADDR_LO(segs[i].ds_addr)); + rxbd->rx_bd_haddr_hi = htole32(BCE_ADDR_HI(segs[i].ds_addr)); + rxbd->rx_bd_len = htole32(segs[i].ds_len); + rxbd->rx_bd_flags = 0; + *prod_bseq += segs[i].ds_len; - /* Update some debug statistic counters */ - DBRUNIF((sc->free_rx_bd < sc->rx_low_watermark), - sc->rx_low_watermark = sc->free_rx_bd); - DBRUNIF((sc->free_rx_bd == 0), sc->rx_empty_count++); + bus_dmamap_sync(sc->rx_mbuf_tag, + sc->rx_bd_chain_map[RX_PAGE(*chain_prod)], + BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + } - /* Setup the rx_bd for the first segment. */ - rxbd = &sc->rx_bd_chain[RX_PAGE(*chain_prod)][RX_IDX(*chain_prod)]; + rxbd->rx_bd_flags |= htole32(RX_BD_FLAGS_END); + bus_dmamap_sync(sc->rx_mbuf_tag, + sc->rx_bd_chain_map[RX_PAGE(*chain_prod)], + BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); - rxbd->rx_bd_haddr_lo = htole32(BCE_ADDR_LO(segs[0].ds_addr)); - rxbd->rx_bd_haddr_hi = htole32(BCE_ADDR_HI(segs[0].ds_addr)); - rxbd->rx_bd_len = htole32(segs[0].ds_len); - rxbd->rx_bd_flags = htole32(RX_BD_FLAGS_START); - *prod_bseq += segs[0].ds_len; + /* + * Save the mbuf, ajust the map pointer (swap map for first and + * last rx_bd entry to that rx_mbuf_ptr and rx_mbuf_map matches) + * and update counter. + */ + sc->rx_mbuf_ptr[*chain_prod] = m_new; + sc->rx_mbuf_map[first_chain_prod] = sc->rx_mbuf_map[*chain_prod]; + sc->rx_mbuf_map[*chain_prod] = map; + sc->free_rx_bd -= nsegs; - for (i = 1; i < nsegs; i++) { - *prod = NEXT_RX_BD(*prod); - *chain_prod = RX_CHAIN_IDX(*prod); + DBRUN(BCE_VERBOSE_RECV, bce_dump_rx_mbuf_chain(sc, debug_chain_prod, + nsegs)); + *prod = NEXT_RX_BD(*prod); + *chain_prod = RX_CHAIN_IDX(*prod); + } - rxbd = &sc->rx_bd_chain[RX_PAGE(*chain_prod)][RX_IDX(*chain_prod)]; - rxbd->rx_bd_haddr_lo = htole32(BCE_ADDR_LO(segs[i].ds_addr)); - rxbd->rx_bd_haddr_hi = htole32(BCE_ADDR_HI(segs[i].ds_addr)); - rxbd->rx_bd_len = htole32(segs[i].ds_len); - rxbd->rx_bd_flags = 0; - *prod_bseq += segs[i].ds_len; - } - - rxbd->rx_bd_flags |= htole32(RX_BD_FLAGS_END); - - /* Save the mbuf and update our counter. */ - sc->rx_mbuf_ptr[*chain_prod] = m_new; - sc->free_rx_bd -= nsegs; - - DBRUN(BCE_VERBOSE_RECV, bce_dump_rx_mbuf_chain(sc, debug_chain_prod, - nsegs)); - +bce_get_buf_exit: DBPRINT(sc, BCE_VERBOSE_RECV, "%s(exit): prod = 0x%04X, chain_prod = 0x%04X, " "prod_bseq = 0x%08X\n", __FUNCTION__, *prod, *chain_prod, *prod_bseq); -bce_get_buf_exit: DBPRINT(sc, (BCE_VERBOSE_RESET | BCE_VERBOSE_RECV), "Exiting %s()\n", __FUNCTION__); @@ -3773,16 +3807,11 @@ /* Allocate mbuf clusters for the rx_bd chain. */ prod = prod_bseq = 0; - while (prod < TOTAL_RX_BD) { - chain_prod = RX_CHAIN_IDX(prod); - if (bce_get_buf(sc, NULL, &prod, &chain_prod, &prod_bseq)) { - BCE_PRINTF("%s(%d): Error filling RX chain: rx_bd[0x%04X]!\n", - __FILE__, __LINE__, chain_prod); - rc = ENOBUFS; - break; - } - prod = NEXT_RX_BD(prod); - } + chain_prod = RX_CHAIN_IDX(prod); + if (bce_get_buf(sc, NULL, &prod, &chain_prod, &prod_bseq)) { + BCE_PRINTF( + "Error filling RX chain: rx_bd[0x%04X]!\n", chain_prod); + } /* Save the RX chain producer index. */ sc->rx_prod = prod; @@ -4045,13 +4074,14 @@ /* The mbuf is stored with the last rx_bd entry of a packet. */ if (sc->rx_mbuf_ptr[sw_chain_cons] != NULL) { - +#ifdef BCE_DEBUG /* Validate that this is the last rx_bd. */ - DBRUNIF((!(rxbd->rx_bd_flags & RX_BD_FLAGS_END)), + if ((rxbd->rx_bd_flags & RX_BD_FLAGS_END) == 0) { BCE_PRINTF("%s(%d): Unexpected mbuf found in rx_bd[0x%04X]!\n", __FILE__, __LINE__, sw_chain_cons); - bce_breakpoint(sc)); - +// bce_breakpoint(sc)); + } +#endif /* * ToDo: If the received packet is small enough * to fit into a single, non-M_EXT mbuf, @@ -4117,7 +4147,7 @@ } m = NULL; - goto bce_rx_int_next_rx; + continue; } /* @@ -4143,7 +4173,7 @@ } m = NULL; - goto bce_rx_int_next_rx; + continue; } /* Skip over the l2_fhdr when passing the data up the stack. */ @@ -4215,7 +4245,6 @@ /* Pass the mbuf off to the upper layers. */ ifp->if_ipackets++; -bce_rx_int_next_rx: sw_prod = NEXT_RX_BD(sw_prod); } @@ -4475,9 +4504,15 @@ bce_set_mac_addr(sc); /* Calculate and program the Ethernet MTU size. */ - ether_mtu = ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN + ifp->if_mtu + - ETHER_CRC_LEN; + if (ifp->if_mtu <= ETHERMTU) { + ether_mtu = BCE_MAX_STD_ETHER_MTU_VLAN; + sc->mbuf_alloc_size = MCLBYTES; + } else { + ether_mtu = BCE_MAX_JUMBO_ETHER_MTU_VLAN; + sc->mbuf_alloc_size = BCE_MAX_MTU; + } + DBPRINT(sc, BCE_INFO_MISC, "%s(): setting mtu = %d\n",__FUNCTION__, ether_mtu); /* @@ -4488,10 +4523,8 @@ if (ether_mtu > ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN) { REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, min(ether_mtu, BCE_MAX_JUMBO_ETHER_MTU) | BCE_EMAC_RX_MTU_SIZE_JUMBO_ENA); - sc->mbuf_alloc_size = MJUM9BYTES; } else { REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu); - sc->mbuf_alloc_size = MCLBYTES; } /* Calculate the RX Ethernet frame size for rx_bd's. */ @@ -5640,6 +5673,8 @@ struct bce_softc *sc = xsc; struct mii_data *mii; struct ifnet *ifp; + u16 prod, chain_prod; + u32 prod_bseq; ifp = sc->bce_ifp; @@ -5675,6 +5710,13 @@ } bce_tick_locked_exit: + /* try to get more RX buffers, just in case */ + prod = sc->rx_prod; + prod_bseq = sc->rx_prod_bseq; + chain_prod = RX_CHAIN_IDX(prod); + bce_get_buf(sc, NULL, &prod, &chain_prod, &prod_bseq); + sc->rx_prod = prod; + sc->rx_prod_bseq = prod_bseq; return; } Index: if_bcereg.h =================================================================== --- if_bcereg.h (revision 67) +++ if_bcereg.h (revision 74) @@ -4682,7 +4682,7 @@ #define BCE_MAX_JUMBO_ETHER_MTU 9018 #define BCE_MAX_JUMBO_ETHER_MTU_VLAN 9022 -// #define BCE_MAX_MTU ETHER_MAX_LEN_JUMBO + ETHER_VLAN_ENCAP_LEN /* 9022 */ +#define BCE_MAX_MTU 9216 /****************************************************************************/ /* BCE Device State Data Structure */ --------------060500010901090709040408-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 19:32:33 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5585716A41F for ; Tue, 10 Jul 2007 19:32:33 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [213.251.163.210]) by mx1.freebsd.org (Postfix) with ESMTP id 07A4E13C44C for ; Tue, 10 Jul 2007 19:32:32 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (ip-83-134-208-129.dsl.scarlet.be [83.134.208.129]) by tignes.restart.be (8.13.8/8.13.8) with ESMTP id l6AJWT47077527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jul 2007 21:32:30 +0200 (CEST) (envelope-from hlh@restart.be) Received: from morzine.restart.bel (morzine.restart.bel [192.168.24.2]) (authenticated bits=0) by restart.be (8.14.1/8.14.1) with ESMTP id l6AJWQNU036986; Tue, 10 Jul 2007 21:32:26 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1184095949; bh=AoEOairs2KiaNcS95hljj5A6DVZQJGaAJZZv7Ou kd6k=; h=DomainKey-Signature:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-Scanned-By; b=l52wiq7mYvq wmmkkGoxacTtOSj+0Q/OKM6/4RbczCl40wzWhvesOU5bk2u0Ozi+XHTy2CFQ1CLyw6p mUi19JJQ== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=pZqtLlzph9aulqVPKyKs6z7pEMmtoHKYQB5NNr9egT5k4KXSxbLR1fSrlCXrGY+Kn nJcZL7IJRKugb0t3/b6Jw== Message-ID: <4693DECA.2010106@restart.be> Date: Tue, 10 Jul 2007 21:32:26 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.4 (X11/20070616) MIME-Version: 1.0 To: "Bernard T. Higonnet" References: <200707101819.28061.bth@higonnet.net> In-Reply-To: <200707101819.28061.bth@higonnet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.61 on 192.168.24.1 Cc: freebsd-net@freebsd.org Subject: Re: mpd isn't listening on 1723 because he can't get it thhough it isn't used 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: Tue, 10 Jul 2007 19:32:33 -0000 Bernard T. Higonnet wrote: > Hello, > > I want to set up a VPN server on a freebsd machine so Windows clients can use > it. > > I am using FreeBSD 6.1 and mpd 3.18 from the ports collection. > > When I run mpd I get this: > > mpd > Multi-link PPP for FreeBSD, by Archie L. Cobbs. > Based on iij-ppp, by Toshiharu OHNO. > mpd: pid 11377, version 3.18 (root@freebsd2.paristolet.com 10:10 8-Jul-2007) > [bundle1] ppp node is "mpd11377-bundle1" > mpd: bind: Can't assign requested address > mpd: can't get PPTP listening socket > mpd: bind: Can't assign requested address > mpd: can't get PPTP listening socket > [bundle1] using interface ng0 > > Of course since he couldn't get a hold of port 1723 he couldn't establish a > socket and nothing happens. netstat shows no one is listening on 1723: > > netstat -a | fgrep LIS > tcp4 0 0 freebsd2.ssh montreal.50547 ESTABLISHED > tcp4 0 0 freebsd2.ssh montreal.61574 ESTABLISHED > tcp4 0 0 *.ssh *.* LISTEN > tcp6 0 0 *.ssh *.* LISTEN > tcp4 0 0 *.smtp *.* LISTEN > tcp6 0 0 *.nfsd *.* LISTEN > tcp4 0 0 *.nfsd *.* LISTEN > tcp6 0 0 *.636 *.* LISTEN > tcp4 0 0 *.637 *.* LISTEN > tcp4 0 0 *.sunrpc *.* LISTEN > tcp6 0 0 *.sunrpc *.* LISTEN > > There is no other instance of mpd running > > Here are the mpd conf and link files: > > default: > load pptp1conf > # load pptp2conf > > pptp1conf: > new -i ng0 bundle1 pptp1 > set ipcp ranges 192.168.1.103/32 192.168.1.200/32 ^^^^^^^^^^^^^ Is this address defined on your server ? Henri > load common > > #pptp2conf: > # new -i ng1 bundle2 pptp2 > # set ipcp ranges 192.168.1.103/32 192.168.1.201/32 > # load common > > common: > set iface disable on-demand > set iface enable proxy-arp > set iface idle 0 > set iface enable tcpmssfix > set bundle enable multilink > set link enable acfcomp protocomp > set link no pap chap > set link enable chap > # set link mtu 1460 > set link keep-alive 10 60 > set ipcp yes vjcomp > set ipcp dns 208.67.222.222 208.67.220.220 > #set ipcp nbns 172.20.1.1 172.20.1.8 > #set bundle enable compression > #set ccp yes mppc > #set ccp yes mpp-e40 > #set ccp yes mpp-e128 > #set ccp yes mpp-stateless > > > > pptp1: > set link type pptp > set pptp self 82.238.41.134 500 > set pptp enable incoming > set pptp disable originate > > pptp2: > set link type pptp > set pptp self 82.238.41.134 > set pptp enable incoming > set pptp disable originate > > > As usual, all help appreciated > Bernard Higonnet > _______________________________________________ > 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" From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 19:37:19 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 553E416A468 for ; Tue, 10 Jul 2007 19:37:19 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [213.251.163.210]) by mx1.freebsd.org (Postfix) with ESMTP id E357413C44B for ; Tue, 10 Jul 2007 19:37:18 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (ip-83-134-208-129.dsl.scarlet.be [83.134.208.129]) by tignes.restart.be (8.13.8/8.13.8) with ESMTP id l6AJbHHu077551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jul 2007 21:37:17 +0200 (CEST) (envelope-from hlh@restart.be) Received: from morzine.restart.bel (morzine.restart.bel [192.168.24.2]) (authenticated bits=0) by restart.be (8.14.1/8.14.1) with ESMTP id l6AJbESW037010; Tue, 10 Jul 2007 21:37:15 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1184096237; bh=ySQwo7S+tZoxa4V1+rbXChoc341gUaut8wEEyaR BAf0=; h=DomainKey-Signature:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-Scanned-By; b=lRBJCM/LSgP HE9GBJjD3h+uDiOtpEc3PbW3uqvNPIg7B3D+g0EbtXm8UKDibHecPM2f+b45LFnyxQA fHWsLWEw== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=vGBktOyc+z6NLvW3n51128BpHPTHLES84BVsxvh3pdfkKlgJTN8UB8/dv4AgzVpWZ XwMD/aziJjsk4Gyli+6nA== Message-ID: <4693DFEA.4020002@restart.be> Date: Tue, 10 Jul 2007 21:37:14 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.4 (X11/20070616) MIME-Version: 1.0 To: "Bernard T. Higonnet" References: <200707081947.37225.bth@higonnet.net> In-Reply-To: <200707081947.37225.bth@higonnet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.61 on 192.168.24.1 Cc: freebsd-net@freebsd.org Subject: Re: newbie problems mpd server on freebsd 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: Tue, 10 Jul 2007 19:37:19 -0000 Bernard T. Higonnet wrote: > Hello, > > I want to set up a VPN server on a freebsd machine so Windows clients can use > it. > > I am using FreeBSD 6.1 and mpd 3.18 from the ports collection. > > My basic problem is that mpd does not do anything and doesn't complain about > anything, so I'm not making much progress. > > I run mpd with "mpd -k -s higvpn" > > Here are various facts and/or symptoms > > 1) all the show commands show there isn't anything (bundles, links, etc. etc.) > 2) netstat says nobody's listening on 1723 > 3) Windows VPN's produce error 678 ("There was no answer") which seems > consonant with (2) > 4) I can't find any trace info anywhere > 5) there is no firewall issue because the freebsd vpn server and Windows > machine are both on my own little network (192.168.0) and neither machine has > one for the time being > > > In an effort to embarrass myself here is my mpd.conf file > > default: > load pptp1 > load pptp2 > > pptp1: > new -i ng0 pptp1 pptp1 > load common > > pptp2: > new -i ng1 pptp2 pptp2 > load common > > common: > set iface disable on-demand > set iface enable proxy-arp > set iface idle 0 > set iface enable tcpmssfix > set bundle enable multilink > set link enable acfcomp protocomp > set link no pap chap > set link enable chap > set link keep-alive 10 60 > set ipcp yes vjcomp > set ipcp ranges 82.238.41.134/32 192.168.0.201/24 ^^^^^^^^^^^^^ what is this address ? I would, as in your previous post put this statment after each new -i ngX. > set ipcp dns 208.67.222.222 208.67.220.220 > #set ipcp nbns 172.20.1.1 172.20.1.8 > #set bundle enable compression > #set ccp yes mppc > #set ccp yes mpp-e40 > #set ccp yes mpp-e128 > #set ccp yes mpp-stateless > > what about mdp.links ? Henri > > TIA > Bernard Higonnet > _______________________________________________ > 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" From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 19:52:09 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24FF016A469 for ; Tue, 10 Jul 2007 19:52:09 +0000 (UTC) (envelope-from bth@higonnet.net) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by mx1.freebsd.org (Postfix) with ESMTP id BC98113C480 for ; Tue, 10 Jul 2007 19:52:08 +0000 (UTC) (envelope-from bth@higonnet.net) Received: from freebsd.paristolet.com (higonnet.net [82.238.41.134]) by smtp8-g19.free.fr (Postfix) with ESMTP id 210EC1B562 for ; Tue, 10 Jul 2007 21:52:07 +0200 (CEST) Received: from montreal (montreal [192.168.0.110]) by freebsd.paristolet.com (Postfix) with ESMTP id A5CC985B852 for ; Tue, 10 Jul 2007 21:52:10 +0200 (CEST) From: "Bernard T. Higonnet" Organization: self To: freebsd-net@freebsd.org Date: Tue, 10 Jul 2007 21:52:10 +0200 User-Agent: KMail/1.9.1 References: <200707081947.37225.bth@higonnet.net> <4693DFEA.4020002@restart.be> In-Reply-To: <4693DFEA.4020002@restart.be> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707102152.10273.bth@higonnet.net> Subject: Re: newbie problems mpd server on freebsd 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: Tue, 10 Jul 2007 19:52:09 -0000 On Tuesday 10 July 2007 21:37, Henri Hennebert wrote: Please ignore this question. I only sent to the list by mistake. It is replaced by the question "mpd isn't listening on 1723 because he can't get it thhough it isn't used" I am sorry. Bernard T. Higonnet > Bernard T. Higonnet wrote: > > Hello, > > > > I want to set up a VPN server on a freebsd machine so Windows clients can > > use it. > > > > I am using FreeBSD 6.1 and mpd 3.18 from the ports collection. > > > > My basic problem is that mpd does not do anything and doesn't complain > > about anything, so I'm not making much progress. > > > > I run mpd with "mpd -k -s higvpn" > > > > Here are various facts and/or symptoms > > > > 1) all the show commands show there isn't anything (bundles, links, etc. > > etc.) 2) netstat says nobody's listening on 1723 > > 3) Windows VPN's produce error 678 ("There was no answer") which seems > > consonant with (2) > > 4) I can't find any trace info anywhere > > 5) there is no firewall issue because the freebsd vpn server and Windows > > machine are both on my own little network (192.168.0) and neither machine > > has one for the time being > > > > > > In an effort to embarrass myself here is my mpd.conf file > > > > default: > > load pptp1 > > load pptp2 > > > > pptp1: > > new -i ng0 pptp1 pptp1 > > load common > > > > pptp2: > > new -i ng1 pptp2 pptp2 > > load common > > > > common: > > set iface disable on-demand > > set iface enable proxy-arp > > set iface idle 0 > > set iface enable tcpmssfix > > set bundle enable multilink > > set link enable acfcomp protocomp > > set link no pap chap > > set link enable chap > > set link keep-alive 10 60 > > set ipcp yes vjcomp > > set ipcp ranges 82.238.41.134/32 192.168.0.201/24 > > ^^^^^^^^^^^^^ > > what is this address ? > > I would, as in your previous post put this statment after each new -i ngX. > > > set ipcp dns 208.67.222.222 208.67.220.220 > > #set ipcp nbns 172.20.1.1 172.20.1.8 > > #set bundle enable compression > > #set ccp yes mppc > > #set ccp yes mpp-e40 > > #set ccp yes mpp-e128 > > #set ccp yes mpp-stateless > > what about mdp.links ? > > Henri > > > TIA > > Bernard Higonnet > > _______________________________________________ > > 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" From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 20:32:27 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF4CF16A421 for ; Tue, 10 Jul 2007 20:32:27 +0000 (UTC) (envelope-from bth@higonnet.net) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by mx1.freebsd.org (Postfix) with ESMTP id 9734F13C4AE for ; Tue, 10 Jul 2007 20:32:27 +0000 (UTC) (envelope-from bth@higonnet.net) Received: from freebsd.paristolet.com (higonnet.net [82.238.41.134]) by smtp8-g19.free.fr (Postfix) with ESMTP id EA0071AE31 for ; Tue, 10 Jul 2007 22:32:26 +0200 (CEST) Received: from montreal (montreal [192.168.0.110]) by freebsd.paristolet.com (Postfix) with ESMTP id AE1F785B852 for ; Tue, 10 Jul 2007 22:32:29 +0200 (CEST) From: "Bernard T. Higonnet" Organization: self To: freebsd-net@freebsd.org Date: Tue, 10 Jul 2007 22:32:29 +0200 User-Agent: KMail/1.9.1 References: <200707101819.28061.bth@higonnet.net> <4693DECA.2010106@restart.be> In-Reply-To: <4693DECA.2010106@restart.be> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707102232.29460.bth@higonnet.net> Subject: Re: mpd isn't listening on 1723 because he can't get it thhough it isn't used 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: Tue, 10 Jul 2007 20:32:27 -0000 On Tuesday 10 July 2007 21:32, Henri Hennebert wrote: . . . > > set ipcp ranges 192.168.1.103/32 192.168.1.200/32 > > ^^^^^^^^^^^^^ > Is this address defined on your server ? You're quite right. This was a typing mistake and should be set ipcp ranges 192.168.0.103/32 192.168.0.200/32 Strangely enough, this did not fix the problem. Just to show that I did change this here's the output from show ipcp: [bundle1:pptp1] show ipcp [bundle1] IPCP [Initial] Allowed IP address ranges: Self: 192.168.0.103/32 Peer: 192.168.0.200/32 Current addressing: Self: 0.0.0.0 Peer: 0.0.0.0 Compression: Self: None Peer: None Server info we give to peer: DNS servers : 208.67.222.222 208.67.220.220 NBNS servers: 0.0.0.0 0.0.0.0 Server info peer gave to us: DNS servers : 0.0.0.0 0.0.0.0 NBNS servers: 0.0.0.0 0.0.0.0 IPCP Options: Name Self Peer ---------------------------------------- vjcomp enable accept req-pri-dns disable req-sec-dns disable req-pri-nbns disable req-sec-nbns disable pretend-ip disable radius-ip disable VJ Compression: Out comp : 0 Out total: 0 Missed : 0 Searched : 0 In comp : 0 In uncomp: 0 In error : 0 In tossed: 0 Thanks - every bit helps... Bernard Higonnet From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 21:21:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5327F16A46D for ; Tue, 10 Jul 2007 21:21:18 +0000 (UTC) (envelope-from jamebus@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.freebsd.org (Postfix) with ESMTP id 0E4FC13C4C6 for ; Tue, 10 Jul 2007 21:21:12 +0000 (UTC) (envelope-from jamebus@gmail.com) Received: by py-out-1112.google.com with SMTP id a73so2843308pye for ; Tue, 10 Jul 2007 14:21:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=DihihWxgHpyn1bfPa461oR1yMOoTzG9gtgfT7ls1aToFkLyjSdpbBINjsCGCsCZjmT1r4WJCGQzACe479uFZ7WUcC90L0rwtW4dNejI8fODjKHTeHyG7cVItA/UkZXYVHUAHfKMcoGE1R4FJ9UJJZl+wHhKMQIm/nFzg+dCiOUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=tQ7jknm1PCI3kKA+zYBCyAAxknKDLjWRCuS+Xtz9ezlqW4TtNZAvcHzg9txXBjrQVQBpXOB0JxgH85mxFd7ZH4xBUmY3SuhaldsaUcmLYebiXDtjzShNRfjSria5W+xr2UwZgpm57McyccluEmv5m0eCfe+atCJp/FpWJuNOKbk= Received: by 10.65.244.15 with SMTP id w15mr4483563qbr.1184100729929; Tue, 10 Jul 2007 13:52:09 -0700 (PDT) Received: by 10.65.132.18 with HTTP; Tue, 10 Jul 2007 13:52:09 -0700 (PDT) Message-ID: Date: Tue, 10 Jul 2007 15:52:09 -0500 From: James Sender: jamebus@gmail.com To: "FreeBSD Net" In-Reply-To: <4693C88F.8050204@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571430@NT-IRVA-0750.brcm.ad.broadcom.com> <09BFF2FA5EAB4A45B6655E151BBDD903045714EF@NT-IRVA-0750.brcm.ad.broadcom.com> <4684D5C0.3040709@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571BF1@NT-IRVA-0750.brcm.ad.broadcom.com> <468A2D55.60301@tomjudge.com> <46937D97.7030507@tomjudge.com> <46938E75.80900@tomjudge.com> <4693C88F.8050204@tomjudge.com> X-Google-Sender-Auth: d20d49f09735bea8 Subject: Re: Problems with BCE network adapter (Dell PE2950) 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: Tue, 10 Jul 2007 21:21:18 -0000 On 7/10/07, Tom Judge wrote: > Ok so I think I have fix the problem with the rx_bd tracking. I > have ported rboyer's patch to NetBSD's bnx driver to FreeBSD (patch > attached). The patch seems to get rid of two problems: > > 1) Unexpected mbuf in rx_bd > 2) Too many free rx_bd's Hi Tom. Thanks much for your work with this problem. I'm effected by major bce problems as well. Right now I'd be happy to get it working properly with an MTU of 1500. To that end I'm unable to get your patch to apply cleanly to my FreeBSD 6.2 tree. Most likely I've lost track of what patches in this thread to apply before your patch. If you have time, would you be so kind to cook a diff against a vanilla FreeBSD 6.2 tree or let me know which patches to apply first? Thanks! -- James. From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 21:55:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B0D916A46B for ; Tue, 10 Jul 2007 21:55:25 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp801.mail.ird.yahoo.com (smtp801.mail.ird.yahoo.com [217.146.188.61]) by mx1.freebsd.org (Postfix) with SMTP id B188013C468 for ; Tue, 10 Jul 2007 21:55:24 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 55031 invoked from network); 10 Jul 2007 21:55:23 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.139.149.183 with plain) by smtp801.mail.ird.yahoo.com with SMTP; 10 Jul 2007 21:55:22 -0000 X-YMail-OSG: B4GFB7EVM1nj3UGv2V9BJ8sYx_SnbHv31hZ4BwdMn0HhYSvk8l3zhxvsYOlepM.tlew8ddg7hBwdgHi4grY0w.g- Message-ID: <46940E74.4050601@tomjudge.com> Date: Tue, 10 Jul 2007 23:55:48 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: James References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571430@NT-IRVA-0750.brcm.ad.broadcom.com> <09BFF2FA5EAB4A45B6655E151BBDD903045714EF@NT-IRVA-0750.brcm.ad.broadcom.com> <4684D5C0.3040709@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571BF1@NT-IRVA-0750.brcm.ad.broadcom.com> <468A2D55.60301@tomjudge.com> <46937D97.7030507@tomjudge.com> <46938E75.80900@tomjudge.com> <4693C88F.8050204@tomjudge.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Problems with BCE network adapter (Dell PE2950) 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: Tue, 10 Jul 2007 21:55:25 -0000 James wrote: > On 7/10/07, Tom Judge wrote: >> Ok so I think I have fix the problem with the rx_bd tracking. I >> have ported rboyer's patch to NetBSD's bnx driver to FreeBSD (patch >> attached). The patch seems to get rid of two problems: >> >> 1) Unexpected mbuf in rx_bd >> 2) Too many free rx_bd's > > Hi Tom. Thanks much for your work with this problem. I'm > effected by major bce problems as well. Right now I'd be happy to > get it working properly with an MTU of 1500. To that end I'm > unable to get your patch to apply cleanly to my FreeBSD 6.2 tree. > Most likely I've lost track of what patches in this thread to > apply before your patch. > > If you have time, would you be so kind to cook a diff against a > vanilla FreeBSD 6.2 tree or let me know which patches to apply > first? > > Thanks! > A full patch against RELENG_6_2 (p5) is avaliable here: http://www.tomjudge.com/tmp/bce-patch-full-10-7-2007.gz You will also require this patch to sys/net/if_media.h that adds the 2.5Gb/s media definitions: http://www.tomjudge.com/tmp/if_media.h-patch-10-7-2007.gz These patches should be applied in /usr/src/sys/dev/bce and /usr/src/sys/net respectively. (e.g: cd /usr/src/sys/dev/bce; patch < /path/to/patch) This patch includes: * The latest driver from RELENG_6 (See http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bce/if_bce.c?only_with_tag=RELENG_6 for details ). NOTE: This does not include MSI support as 6.2 does not have MSI support. * David's patch to enable dumping the first 128 bytes of a bad packet * Stepherosa's patch which attempts to fix problems in the rx buffer (de)allocation during bce_rx_intr. * My patch from NetBSD that completely rewrites the way that the rx buffers are (de)allocated. Rather than allocate them on the fly in bce_rx_intr. Try to pre allocate as many as possible, and then allocate more during the bce_tick routine. Please let me know if you have any problems applying this patch, as this patch was generated from my subversion repository. On a side note, I have some systems (Dell PE2950's) running the vanilla 6.2 driver which are stable, they have a standard 1500 byte MTU. However these systems are not running such network intensive tasks as the ones with a 8192 byte MTU. On another side note it seems that OpenBSD removed Jumbo frame support from their driver 4 months ago as it was causing panics under high load however FreeBSD and NetBSD both have Jumbo frame support enabled. Tom From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 22:14:26 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD88016A400 for ; Tue, 10 Jul 2007 22:14:26 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from mail.alkar.net (mail.alkar.net [195.248.191.95]) by mx1.freebsd.org (Postfix) with ESMTP id 53C7C13C487 for ; Tue, 10 Jul 2007 22:14:26 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from [195.248.178.122] (HELO [192.168.3.2]) by mail.alkar.net (CommuniGate Pro SMTP 5.1.10) with ESMTPS id 798128049; Wed, 11 Jul 2007 01:14:25 +0300 Message-ID: <469404B2.7060505@freebsd.org> Date: Wed, 11 Jul 2007 01:14:10 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bernard T. Higonnet" References: <1184098989.00772035.1184086802@10.7.7.3> In-Reply-To: <1184098989.00772035.1184086802@10.7.7.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd isn't listening on 1723 because he can't get it thhough it isn't used 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: Tue, 10 Jul 2007 22:14:26 -0000 Bernard T. Higonnet wrote: > I want to set up a VPN server on a freebsd machine so Windows clients can use > it. > > I am using FreeBSD 6.1 and mpd 3.18 from the ports collection. I whould recommend you to use mpd 4.2.2 from the ports collection. > When I run mpd I get this: > > mpd: bind: Can't assign requested address > mpd: can't get PPTP listening socket It should mean that this is probably incorrect: > set pptp self 82.238.41.134 500 What do you mean by writing 500 here? Is the 82.238.41.134 is this router ip? -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 22:20:11 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F315816A421 for ; Tue, 10 Jul 2007 22:20:11 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from mail.alkar.net (mail.alkar.net [195.248.191.95]) by mx1.freebsd.org (Postfix) with ESMTP id 774C413C44C for ; Tue, 10 Jul 2007 22:20:11 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from [195.248.178.122] (HELO [192.168.3.2]) by mail.alkar.net (CommuniGate Pro SMTP 5.1.10) with ESMTPS id 798132240; Wed, 11 Jul 2007 01:20:10 +0300 Message-ID: <4694060B.7020602@freebsd.org> Date: Wed, 11 Jul 2007 01:19:55 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bernard T. Higonnet" References: <1184099003.00772049.1184088002@10.7.7.3> In-Reply-To: <1184099003.00772049.1184088002@10.7.7.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: newbie problems mpd server on freebsd 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: Tue, 10 Jul 2007 22:20:12 -0000 Bernard T. Higonnet wrote: > I run mpd with "mpd -k -s higvpn" As I can see, there is no higvpn label in your config. There is nothig to do for mpd on startup so it stays clean. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 22:23:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6ED3916A41F for ; Tue, 10 Jul 2007 22:23:48 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from smtp3.utdallas.edu (smtp3.utdallas.edu [129.110.10.49]) by mx1.freebsd.org (Postfix) with ESMTP id 4788A13C45A for ; Tue, 10 Jul 2007 22:23:48 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from utd59514.utdallas.edu (utd59514.utdallas.edu [129.110.3.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTP id 27C3A654F2 for ; Tue, 10 Jul 2007 17:04:03 -0500 (CDT) Date: Tue, 10 Jul 2007 17:04:02 -0500 From: Paul Schmehl To: FreeBSD Net Message-ID: X-Mailer: Mulberry/4.0.6 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========2EB115B57B4FD9DC8CE7==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Question about bce driver 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: Tue, 10 Jul 2007 22:23:48 -0000 --==========2EB115B57B4FD9DC8CE7========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I'm running 6.1 RELEASE (i386) and I've been replacing the if_bce.c file=20 with a slightly newer one that at least got the driver working without hard = lockups that required a reboot to fix. (Rather problematic on a remotely=20 located web server.) If I download the latest driver from cvs (1.33), should I also replace the=20 if_bcefw.h and if_bcereg.h files with the newer versions? Will the NIC=20 work without creating new problems? Right now I get an occasional=20 "flapping" of the NIC link state (down, up , down, up, etc.) but it at=20 least works most of the time. I don't want to buildworld and get suprised=20 by a non-functioning NIC. :-) If I use the newer versions, will I also need to use some other newer files = that are called by them? Or would it be better to upgrade the entire box=20 to 6.2? FreeBSD www.stovebolt.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #2: grep bce /var/run/dmesg.boot bce0: mem=20 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9 bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus0: on bce0 bce0: Ethernet address: 00:13:72:fb:2a:ad bce1: mem=20 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5 bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus1: on bce1 bce1: Ethernet address: 00:13:72:fb:2a:ab --=20 Paul Schmehl (pauls@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --==========2EB115B57B4FD9DC8CE7==========-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 22:36:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC94416A400 for ; Tue, 10 Jul 2007 22:36:03 +0000 (UTC) (envelope-from jamebus@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.freebsd.org (Postfix) with ESMTP id A83FB13C484 for ; Tue, 10 Jul 2007 22:36:03 +0000 (UTC) (envelope-from jamebus@gmail.com) Received: by py-out-1112.google.com with SMTP id a73so2881259pye for ; Tue, 10 Jul 2007 15:36:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=dbYPC/l/C02A/u8W06GeGvNW65ItGM+qv5heqrJTx1uQZ/4DkyV0QbCAWLFoVp04zjjpnIepFBgu7YiTYTUuTuQ3mQKrILPMSkizyEyINOvm9OgWkgZX5K9r3VY/cyUddDM09jz87FbFT3/eFvD05DWReGa8Y6ffHNzXYiH57+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=XyyNfMJtB5Lr1Ksjj49VDWtam9KhqIGJv+dDcZIKllF1vFPjy+czUZC8p1MMic79HwV/PlthFZGnVwhE8gWRp1rsnEnJ5JFQYyMXuLKnWXfY8ayZsx/sDHzRkCXyXqAmqLhM0X8oDUjyaIKlWce99cUM+b3JjbvUEylu7WE+f2s= Received: by 10.65.59.11 with SMTP id m11mr7617465qbk.1184106962030; Tue, 10 Jul 2007 15:36:02 -0700 (PDT) Received: by 10.65.132.18 with HTTP; Tue, 10 Jul 2007 15:36:01 -0700 (PDT) Message-ID: Date: Tue, 10 Jul 2007 17:36:01 -0500 From: James Sender: jamebus@gmail.com To: "Tom Judge" In-Reply-To: <46940E74.4050601@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46680DB1.9050905@tomjudge.com> <4684D5C0.3040709@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571BF1@NT-IRVA-0750.brcm.ad.broadcom.com> <468A2D55.60301@tomjudge.com> <46937D97.7030507@tomjudge.com> <46938E75.80900@tomjudge.com> <4693C88F.8050204@tomjudge.com> <46940E74.4050601@tomjudge.com> X-Google-Sender-Auth: 753ea71093a9fcf6 Cc: FreeBSD Net Subject: Re: Problems with BCE network adapter (Dell PE2950) 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: Tue, 10 Jul 2007 22:36:04 -0000 On 7/10/07, Tom Judge wrote: > A full patch against RELENG_6_2 (p5) is avaliable here: > http://www.tomjudge.com/tmp/bce-patch-full-10-7-2007.gz > > You will also require this patch to sys/net/if_media.h that adds the > 2.5Gb/s media definitions: > http://www.tomjudge.com/tmp/if_media.h-patch-10-7-2007.gz Thanks much. They both applied cleanly to my tree (also based on RELENG_6_2 p5). I'll start a build and give 'em a whirl tonight. -- James. From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 00:42:48 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E34516A41F for ; Wed, 11 Jul 2007 00:42:48 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8F5DB13C43E for ; Wed, 11 Jul 2007 00:42:47 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id SAA02181 for ; Tue, 10 Jul 2007 18:14:04 -0600 (MDT) Message-Id: <200707110014.SAA02181@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Jul 2007 18:13:48 -0600 To: net@freebsd.org From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Bug in userland PPP LQR? 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, 11 Jul 2007 00:42:48 -0000 I may have found a bug in the LQR code of FreeBSD's userland PPP. I've been noticing that PPTP sessions are dropping with messages saying "** Too many LQR packets lost **" on some important wireless links. Wireless links occasionally do drop a packet or two, but it's rare to see 5 dropped packets in a row (which is supposed to be when PPP gives up and kills the link). Yet, the links go down when there's even an occasional dropped packet. I'm using LQR with an interval of 12 seconds, and the built-in threshold for dropping the connection (not changeable in this implementation) is 5 lost packets. This means that the link pretty much has to be down for 60 seconds before the connection gets cut off. In practice, however, connections are dying when data was coming through only a few seconds before and there's a very low percentage of dropped packets. This leads me to suspect that either (a) the lost packet counter is cumulative for the session; that is, it's not resetting when a good response comes in; or (b) the LQR mechanism it may be getting out of sync (perhaps due to unexpected sequence numbers) and always count up to 5 after the first missed packet. The code in /usr/src/usr.sbin/ppp/lqr.c is quite cryptic, and I'd like some help in figuring out just why I'm seeing so many dropped connections due to LQR. Any folks out there willing to help me analyze it? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 01:29:30 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DBBA16A46E for ; Wed, 11 Jul 2007 01:29:30 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id A4C7B13C4B0 for ; Wed, 11 Jul 2007 01:29:29 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 57230 invoked from network); 11 Jul 2007 01:29:28 -0000 Received: from 209.68.2.70 (HELO localhost) (209.68.2.70) by relay03.pair.com with SMTP; 11 Jul 2007 01:29:28 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 10 Jul 2007 20:29:14 -0500 (CDT) From: Mike Silbersack To: Eygene Ryabinkin In-Reply-To: <20070710132253.GJ1038@void.codelabs.ru> Message-ID: <20070710202028.I34890@odysseus.silby.com> References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andre Oppermann , Robert Watson , current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers 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, 11 Jul 2007 01:29:30 -0000 On Tue, 10 Jul 2007, Eygene Ryabinkin wrote: > Can't say that I am pushing much traffic through my box, but after > applying your patch and rebuilding the kernel I am still seeing the > messages like > ----- > TCP: [209.132.176.NNN]:NNN to [144.206.NNN.NNN]:NNN tcpflags 0x19; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) > TCP: [201.90.65.NNN]:NNN to [144.206.NNN.NNN]:NNN; syncache_timer: Response timeout > ----- > But what had changed is that the lines with the 'syncache_timer' > started to appear. There were no such lines prior to the patch, > only the 'failed SYNCOOKIE' ones. The "syncache_timer: Response timeout" message means that the syncache sent a SYN-ACK response four times, but still didn't receive a response. This probably means that someone tried using a port scanner or was going through a faulty firewall. We'll definitely have to take that log message out before 7.0 is released. The fact that you're still getting the syncache_expand message tells me that there's another bug which I have not yet fixed still present. My suspicion is that the "Segment failed SYNCOOKIE authentication" message is the aftereffect of FreeBSD 7 randomly dropping TCP connections, and not the problem itself. My theory is that the connection is silently dropped, without the other endpoint knowing. That other endpoint then sends an ACK packet, which is then believed to be a syncookie. Since it is not, it obviously fails the verification. Finding that bug is my next goal. > But the patch received only half a day of testing, so I will continue > the tests and will inform you if some other information will be > available. Up to date I don't see problems that had appeared without > the patch, but they tend to show up after a midnight ;)) > > Thank you! Thanks for testing, I look forward to hearing how things work for you. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 04:40:33 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20E7D16A41F for ; Wed, 11 Jul 2007 04:40:33 +0000 (UTC) (envelope-from bth@higonnet.net) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by mx1.freebsd.org (Postfix) with ESMTP id DC24313C44B for ; Wed, 11 Jul 2007 04:40:32 +0000 (UTC) (envelope-from bth@higonnet.net) Received: from freebsd.paristolet.com (higonnet.net [82.238.41.134]) by smtp8-g19.free.fr (Postfix) with ESMTP id 1D77A16960; Wed, 11 Jul 2007 06:40:32 +0200 (CEST) Received: from [127.0.0.1] (unknown [192.168.0.52]) by freebsd.paristolet.com (Postfix) with ESMTP id B668985B852; Wed, 11 Jul 2007 06:40:25 +0200 (CEST) Message-ID: <46945F26.20609@higonnet.net> Date: Wed, 11 Jul 2007 06:40:06 +0200 From: "Bernard T. Higonnet" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Alexander Motin References: <1184098989.00772035.1184086802@10.7.7.3> <469404B2.7060505@freebsd.org> In-Reply-To: <469404B2.7060505@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000755-1, 11-07-2007), Outbound message X-Antivirus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: mpd isn't listening on 1723 because he can't get it thhough it isn't used 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, 11 Jul 2007 04:40:33 -0000 Alexander Motin wrote: > Bernard T. Higonnet wrote: >> I want to set up a VPN server on a freebsd machine so Windows clients >> can use >> it. >> >> I am using FreeBSD 6.1 and mpd 3.18 from the ports collection. > > I whould recommend you to use mpd 4.2.2 from the ports collection. I tried, but apparently when I created my freebsd I didn't ask for all the source code and 4.2.2 will not make... > It should mean that this is probably incorrect: > >> set pptp self 82.238.41.134 500 > > What do you mean by writing 500 here? Is the 82.238.41.134 is this > router ip? I had found this peculiar mistake after sending my mail. I have fixed it by removing the 500 but it makes no difference at all. Apologies & thanks Bernard Higonnet From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 05:46:41 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98E5D16A421 for ; Wed, 11 Jul 2007 05:46:41 +0000 (UTC) (envelope-from jamebus@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id 549A613C448 for ; Wed, 11 Jul 2007 05:46:41 +0000 (UTC) (envelope-from jamebus@gmail.com) Received: by py-out-1112.google.com with SMTP id a73so3055812pye for ; Tue, 10 Jul 2007 22:46:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=txLz8sYK18ioFrxO4LL2/Dnqvi2bUm0uxWNJB02LIRaXFlfKQdexdCS6Url2PE3amTjYSR9MSjFi4U6zqkBUUFXu0PoKMiPz+6oMiOJMMusYV0vWrq3uQ0xnQB8i/eBKtxpWhl2zB1CcngUSMvxAf4GtGh7XPuUB6fsy4DEP9+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=TJUZpR0VtaOM8nuYx5PXHxIgs3DJ5kTmObPM+g1efl/TYQzuhPwQ06Zi0DD9WIyoKwb5F2dpMWHcg6hCwP+vQkevL6e5e77PqCHRwy+jNNTPPmXqpZsm3phVqKLQz0mMdg5yJ7PU8lDKoqffFworyD4xLMgNCRQizLrTpbSP9nI= Received: by 10.64.210.3 with SMTP id i3mr7547496qbg.1184132800210; Tue, 10 Jul 2007 22:46:40 -0700 (PDT) Received: by 10.65.132.18 with HTTP; Tue, 10 Jul 2007 22:46:40 -0700 (PDT) Message-ID: Date: Wed, 11 Jul 2007 00:46:40 -0500 From: James Sender: jamebus@gmail.com To: "Tom Judge" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571BF1@NT-IRVA-0750.brcm.ad.broadcom.com> <468A2D55.60301@tomjudge.com> <46937D97.7030507@tomjudge.com> <46938E75.80900@tomjudge.com> <4693C88F.8050204@tomjudge.com> <46940E74.4050601@tomjudge.com> X-Google-Sender-Auth: 3342f44af1fa99a7 Cc: FreeBSD Net Subject: Re: Problems with BCE network adapter (Dell PE2950) 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, 11 Jul 2007 05:46:41 -0000 On 7/10/07, James wrote: > I'll start a build and give 'em a whirl tonight. hihi. I gave it a try by pxebooting a new release with the patches applied. During sysinstall the NIC comes up, gets a DHCP address, but fails to lookup my install server via DNS to install the minimal dist set. Running into the same problems as you at this point: bce1: discard frame w/o leading ethernet header (len 4294967292 pkt len 4294967) -- James. From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 06:04:31 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F29C016A46B; Wed, 11 Jul 2007 06:04:30 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id A226413C448; Wed, 11 Jul 2007 06:04:30 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=HI7NO6lta9Avbq1p2gObXk7MZd7AniavOXlkgISsvE1X6NrseJOIMH4JS1oy+Z9S4NCEz47Rxh6DsjTR5bRrjf3fwzQwguDgMEvYdnyiIoFT0Anq8T+0XQFy53nSOrqe55rKXqkNQ2ib7wop1STmhOI+x1fRehG3TeUQTwjBuZ8=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1I8VJM-0007wC-7S; Wed, 11 Jul 2007 10:04:28 +0400 Date: Wed, 11 Jul 2007 10:04:23 +0400 From: Eygene Ryabinkin To: Mike Silbersack Message-ID: <20070711060423.GV1038@void.codelabs.ru> References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070710202028.I34890@odysseus.silby.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: Andre Oppermann , Robert Watson , current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers 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, 11 Jul 2007 06:04:31 -0000 Mike, good day. Tue, Jul 10, 2007 at 08:29:14PM -0500, Mike Silbersack wrote: > The fact that you're still getting the syncache_expand message tells me that > there's another bug which I have not yet fixed still present. > > My suspicion is that the "Segment failed SYNCOOKIE authentication" message is > the aftereffect of FreeBSD 7 randomly dropping TCP connections, and not the > problem itself. My theory is that the connection is silently dropped, without > the other endpoint knowing. That other endpoint then sends an ACK packet, > which is then believed to be a syncookie. Since it is not, it obviously fails > the verification. OK, maybe I have something that can be related to this bug. It provokes another message, 'Spurious RST', but can be correlated with your guess. What is happening is that when one side closes the connection and releases the socket (running -CURRENT) while the other one is still pushing data through the connection, we are getting 'Spurious RST' messages. This happens, because we are checking the 'so->so_state' for the presence of the 'SS_NOFDREF' flag (tcp_input.c, version 1.361, line 1581) and dropping such connections with RST. But the connection was already closed (living in the FIN-WAIT-2 state, to be precise) from that side, so it provokes the debug message. If you're interested, I have the tcpdump trace and the relevant dmesg output for such a session: http://codelabs.ru/fbsd/session-with-close.tar.bz2 It was produced on the lo0 with client connecting to Apache instance and performing the close() on the socket after some (but not all) bytes of HTTP reply were received. > >But the patch received only half a day of testing, so I will continue > >the tests and will inform you if some other information will be > >available. Up to date I don't see problems that had appeared without > >the patch, but they tend to show up after a midnight ;)) > > Thanks for testing, You're welcome ;)) > I look forward to hearing how things work for you. My problem, as usual, showed up after midnight -- the sockets with the weird state: ----- tcp4 0 0 127.0.0.1.* 127.0.0.1.40001 CLOSED tcp4 0 0 127.0.0.1.* 127.0.0.1.40001 CLOSED ----- 127.0.0.1:40001 used to be the real connections to the service on the port 40001, but they lose their port association from the client side and are stuck in the CLOSED state. The effect is that I can not connect to the service listening to 127.0.0.1:40001 anymore. Only service restart helps. Perhaps that can give you some clue. Perhaps not: it may be totally unrelated to the syncache issues :(( This is also documented in the thread http://lists.freebsd.org/pipermail/freebsd-net/2007-June/014406.html Thank you! -- Eygene From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 07:25:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C21A16A400 for ; Wed, 11 Jul 2007 07:25:23 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp808.mail.ird.yahoo.com (smtp808.mail.ird.yahoo.com [217.146.188.68]) by mx1.freebsd.org (Postfix) with SMTP id 0807813C45A for ; Wed, 11 Jul 2007 07:25:22 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 57733 invoked from network); 11 Jul 2007 07:25:21 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.139.149.183 with plain) by smtp808.mail.ird.yahoo.com with SMTP; 11 Jul 2007 07:25:21 -0000 X-YMail-OSG: qeioWj4VM1nGggukR6JE8d8beQx_5c.l8vj2FxgnuUCCuAjw0lxAOgXIbIUgrnu1deUQuUOSW.gL9.bapLpdHGw- Message-ID: <4694940D.9050408@tomjudge.com> Date: Wed, 11 Jul 2007 09:25:49 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Paul Schmehl References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Question about bce driver 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, 11 Jul 2007 07:25:23 -0000 Paul Schmehl wrote: > I'm running 6.1 RELEASE (i386) and I've been replacing the if_bce.c file > with a slightly newer one that at least got the driver working without > hard lockups that required a reboot to fix. (Rather problematic on a > remotely located web server.) > > If I download the latest driver from cvs (1.33), should I also replace > the if_bcefw.h and if_bcereg.h files with the newer versions? Will the > NIC work without creating new problems? Right now I get an occasional > "flapping" of the NIC link state (down, up , down, up, etc.) but it at > least works most of the time. I don't want to buildworld and get > suprised by a non-functioning NIC. :-) > > If I use the newer versions, will I also need to use some other newer > files that are called by them? Or would it be better to upgrade the > entire box to 6.2? > > FreeBSD www.stovebolt.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #2: > > grep bce /var/run/dmesg.boot > bce0: mem > 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9 > bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz > miibus0: on bce0 > bce0: Ethernet address: 00:13:72:fb:2a:ad > bce1: mem > 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5 > bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz > miibus1: on bce1 > bce1: Ethernet address: 00:13:72:fb:2a:ab > Hi Paul, From the testing that I have been doing for the last few months the driver in 6.2 is stable if you are not using jumbo frames and there is a light-moderate network load. However if you want to use Jumbo frames the driver is very unstable. I posted a patch against 6.2 which should fix some load based issues in the driver with standard frame sizes. Tom From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 07:26:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCFAF16A41F for ; Wed, 11 Jul 2007 07:26:23 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp808.mail.ird.yahoo.com (smtp808.mail.ird.yahoo.com [217.146.188.68]) by mx1.freebsd.org (Postfix) with SMTP id 3BC5213C45D for ; Wed, 11 Jul 2007 07:26:23 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 58089 invoked from network); 11 Jul 2007 07:26:22 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.139.149.183 with plain) by smtp808.mail.ird.yahoo.com with SMTP; 11 Jul 2007 07:26:22 -0000 X-YMail-OSG: lV_PJN8VM1kLuCulDFMO7xCTfVN2aTF9RFLiq8dZgjLR0O2z Message-ID: <46949449.6010103@tomjudge.com> Date: Wed, 11 Jul 2007 09:26:49 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: James References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571BF1@NT-IRVA-0750.brcm.ad.broadcom.com> <468A2D55.60301@tomjudge.com> <46937D97.7030507@tomjudge.com> <46938E75.80900@tomjudge.com> <4693C88F.8050204@tomjudge.com> <46940E74.4050601@tomjudge.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Problems with BCE network adapter (Dell PE2950) 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, 11 Jul 2007 07:26:23 -0000 James wrote: > On 7/10/07, James wrote: >> I'll start a build and give 'em a whirl tonight. > > hihi. I gave it a try by pxebooting a new release with the > patches applied. During sysinstall the NIC comes up, gets a DHCP > address, but fails to lookup my install server via DNS to install > the minimal dist set. Running into the same problems as you at > this point: > > bce1: discard frame w/o leading ethernet header (len 4294967292 > pkt len 4294967) > Hi James, Was this with jumbo or standard frames? Tom From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 09:19:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E53D16A46D for ; Wed, 11 Jul 2007 09:19:25 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog13.obsmtp.com (s200aog13.obsmtp.com [207.126.144.127]) by mx1.freebsd.org (Postfix) with SMTP id 18E3F13C45D for ; Wed, 11 Jul 2007 09:19:21 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob013.postini.com ([207.126.147.11]) with SMTP; Wed, 11 Jul 2007 09:19:16 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 9D1AB18141B; Wed, 11 Jul 2007 10:19:15 +0100 (BST) Message-ID: <46949ED5.6000706@tomjudge.com> Date: Wed, 11 Jul 2007 10:11:49 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Tom Judge References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030414B1EC@NT-IRVA-0750.brcm.ad.broadcom.com> <466873FA.9030800@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030423EE13@NT-IRVA-0750.brcm.ad.broadcom.com> <46823A78.7020501@tomjudge.com> <4683C578.6070009@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571430@NT-IRVA-0750.brcm.ad.broadcom.com> <09BFF2FA5EAB4A45B6655E151BBDD903045714EF@NT-IRVA-0750.brcm.ad.broadcom.com> <4684D5C0.3040709@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571BF1@NT-IRVA-0750.brcm.ad.broadcom.com> <468A2D55.60301@tomjudge.com> <46937D97.7030507@tomjudge.com> <46938E75.80900@tomjudge.com> <4693C88F.8050204@tomjudge.com> In-Reply-To: <4693C88F.8050204@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sepherosa Ziehau , freebsd-net , David Christensen Subject: Re: Problems with BCE network adapter (Dell PE2950) 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, 11 Jul 2007 09:19:25 -0000 Tom Judge wrote: > Tom Judge wrote: >> Tom Judge wrote: >>> Tom Judge wrote: >>>> David Christensen wrote: >>>>>> Sorry for the top post, please try following patch: >>>>>> http://people.freebsd.org/~sephe/if_bce.c.diff >>>>>> >>>>>> This is probably the cause; I noticed it when bce(4) was ported to >>>>>> DragonFly. >>>>>> >>>>> >>>>> Thanks Sephe, I think you're on to something. I have some >>>>> debug code in the driver to simulate mbuf allocation >>>>> failures and when I enable that I start receiving the same >>>>> error messages Tom reported (along with various kernel >>>>> panics), but when I include your change the system seems >>>>> to keep humming along. I'll certainly add your code into an update >>>>> shortly. >>>>> >>>>> Dave >>>>> >>>> >>>> I'm not going to have a chance to test this patch until next week >>>> but I will let you know what the results are. >>>> >>>> Tom >>> >>> >>> So here goes, after 2 days testing we have come up with the >>> following data. >>> >>> The configuration >>> >>> [PE[12]950] ----> [PowerConnect 5324] >>> >>> The system is running 8192 byte Jumbo Frames. >>> >>> sultan# ifconfig bce0 >>> bce0: flags=8847 mtu 8192 >>> options=3b >>> inet 172.31.0.28 netmask 0xffffff00 broadcast 172.31.0.255 >>> inet 172.31.0.163 netmask 0xffffffff broadcast 172.31.0.163 >>> ether 00:19:b9:e4:4d:cc >>> media: Ethernet autoselect (1000baseTX ) >>> status: active >>> >>> >>> After applying both David and Sephe's patches I have yet to get a >>> system in a state where it is stable with jumbo frames enabled, the >>> systems crash almost immediately after the switch changes the port >>> state (Spanning tree) from LEARNING to FORWARDING. The output from >>> this crash can be found attached as crash-1.txt.gz. >>> >>> If the frame size is left at 1500 then the interface seems stable, >>> however I can't fully test this as the interface is connected to a >>> GigE only network with an mtu of 8192. >>> >>> If BCE_DEBUG is remove from if_bcereg.h then the system just exhibits >>> the original problem and may or may not crash. >>> >>> The next test was to try the kernel with BCE_DEBUG and with the >>> following extra patch (so that the driver does not jump to the >>> breakpoint when an unexpected mbuf is found in the rx buffer). >>> >>> --- if_bce.c (revision 62) >>> +++ if_bce.c (revision 66) >>> @@ -4050,7 +4050,8 @@ >>> DBRUNIF((!(rxbd->rx_bd_flags & >>> RX_BD_FLAGS_END)), >>> BCE_PRINTF("%s(%d): Unexpected mbuf >>> found in rx_bd[0x%04X]!\n", >>> __FILE__, __LINE__, sw_chain_cons); >>> - bce_breakpoint(sc)); >>> + bce_dump_mbuf(sc, m)); >>> +// bce_breakpoint(sc)); >>> >>> /* >>> * ToDo: If the received packet is small enough >>> >>> >>> With this patch the system boots and does not crash straight away, >>> however it is almost completely unusable. The output with this >>> kernel can be found attached as crash-2.txt.gz. Also this causes the >>> following new error message: >>> >>> fgrep -n leak crash-2.txt >>> 3194:bce0: /usr/src/sys/dev/bce/if_bce.c(3842): Memory leak! Lost 114 >>> mbufs from rx chain! >>> >>> Has no one else come across this problem, or are Jumbo frames not >>> widely used? >>> >>> Tom >>> >> It would seem that the crash can be simulated just by increasing the >> MTU above 1500 (tested in single user mode). >> > > > Ok so I think I have fix the problem with the rx_bd tracking. I have > ported rboyer's patch to NetBSD's bnx driver to FreeBSD (patch > attached). The patch seems to get rid of two problems: > > 1) Unexpected mbuf in rx_bd > 2) Too many free rx_bd's > > > However I am still faced with the problem of frames with missing > ethernet headers: > bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found. > Min(60), Actual(0), Max(9022) > bce0: mbuf: vaddr = 0xFFFFFF00:7B69AC00, m_len = 9216, m_flags = ( M_EXT > M_PKTHDR ) m_data = 0xFFFFFFFF:86F76000 > 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > bce0: - m_pkthdr: flags = ( ) csum_flags = ( ) > bce0: - m_ext: vaddr = 0xFFFFFFFF:86F76000, ext_size = 9216, type = > EXT_JUMBO9 > bce0: discard frame w/o leading ethernet header (len 4294967292 pkt len > 4294967292) > bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found. > Min(60), Actual(0), Max(9022) > bce0: mbuf: vaddr = 0xFFFFFF00:5EB48B00, m_len = 9216, m_flags = ( M_EXT > M_PKTHDR ) m_data = 0xFFFFFFFF:86F73000 > 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > bce0: - m_pkthdr: flags = ( ) csum_flags = ( ) > bce0: - m_ext: vaddr = 0xFFFFFFFF:86F73000, ext_size = 9216, type = > EXT_JUMBO9 > bce0: discard frame w/o leading ethernet header (len 4294967292 pkt len > 4294967292) > bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found. > Min(60), Actual(27745), Max(9022) > bce0: mbuf: vaddr = 0xFFFFFF00:5E9DDC00, m_len = 9216, m_flags = ( M_EXT > M_PKTHDR ) m_data = 0xFFFFFFFF:86EF8000 > 0x00: 2C 6F 75 3D 50 65 72 73 6F 6E 61 6C 2C 6F 75 3D > 0x10: 47 72 6F 75 70 73 2C 6F 3D 4D 69 6E 74 65 6C 30 > 0x20: 28 30 11 04 02 63 6E 31 0B 04 09 63 62 75 74 74 > 0x30: 72 6F 73 65 30 13 04 09 67 69 64 4E 75 6D 62 65 > 0x40: 72 31 06 04 04 31 31 30 38 30 5E 02 01 02 64 59 > 0x50: 04 31 63 6E 3D 6D 63 61 68 6D 2C 6F 75 3D 4C 6F > 0x60: 6E 64 6F 6E 2C 6F 75 3D 50 65 72 73 6F 6E 61 6C > 0x70: 2C 6F 75 3D 47 72 6F 75 70 73 2C 6F 3D 4D 69 6E > bce0: - m_pkthl er0ror > 9 67 69 64 4E 75 6D 62 65 72 31 06 04 04 31 30 > 0x70: 33 37 30 62 02 01 02 64 5D 04 33 63 6E 3D 72 63 > bce0: - m_pkthdr: flags = ( ) csum_flags = ( ) > bce0: - m_ext: vaddr = 0xFFFFFFFF:86E8C000, ext_size = 9216, type = > EXT_JUMBO9 > bce0: /usr/src/sys/dev/bce/if_bce.c(4081): Unexpected mbuf found in > rx_bd[0x002A]! > bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found. > Min(60), Actual(28515), Max(9022) > bce0: mbuf: vaddr = 0xFFFFFF00:5AB4C800, m_len = 9216, m_flags = ( M_EXT > M_PKTHDR ) m_data = 0xFFFFFFFF:86F28000 > 0x00: 30 0E 04 02 63 6E 31 08 04 06 63 6F 68 61 72 61 > 0x10: 30 13 04 09 67 69 64 4E 75 6D 62 65 72 31 06 04 > 0x20: 04 31 30 37 32 30 65 02 01 02 64 60 04 35 63 6E > 0x30: 3D 6A 70 69 65 6B 61 72 73 2C 6F 75 3D 43 68 69 > 0x40: 63 61 67 6F 2C 6F 75 3D 50 65 72 73 6F 6E 61 6C > 0x50: 2C 6F 75 3D 47 72 6F 75 70 73 2C 6F 3D 4D 69 6E > 0x60: 74 65 6C 30 27 30 10 04 02 63 6E 31 0A 04 08 6A > 0x70: 70 69 65 6B 61 72 73 30 13 04 09 67 69 64 4E 75 > bce0: - m_pkthdr: flags = ( ) csum_flags = ( ) > bce0: - m_ext: vaddr = 0xFFFFFFFF:86F28000, ext_size = 9216, type = > EXT_JUMBO9 > bce0: /usr/src/sys/dev/bce/if_bce.c(4081): Unexpected mbuf found in > rx_bd[0x002E]! > bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found. > Min(60), Actual(28460), Max(9022) > bce0: mbuf: vaddr = 0xFFFFFF00:5EB9F200, m_len = 9216, m_flags = ( M_EXT > M_PKTHDR ) m_data = 0xFFFFFFFF:86F70000 > 0x00: 04 32 63 6E 3D 69 6E 65 73 73 2C 6F 75 3D 43 68 > 0x10: 69 63 61 67 6F 2C 6F 75 3D 50 65 72 73 6F 6E 61 > 0x20: 6C 2C 6F 75 3D 47 72 6F 75 70 73 2C 6F 3D 4D 69 > 0x30: 6E 74 65 6C 30 24 30 0D 04 02 63 6E 31 07 04 05 > 0x40: 69 6E 65 73 73 30 13 04 09 67 69 64 4E 75 6D 62 > 0x50: 65 72 31 06 04 04 31 31 34 32 30 67 02 01 02 64 > 0x60: 62 04 36 63 6E 3D 70 6D 63 6E 61 6D 61 72 61 2C > 0x70: 6F 75 3D 43 68 69 63 61 67 6F 2C 6F 75 3D 50 65 > bce0: - m_pkthdr: flags = ( ) csum_flags = ( ) > bce0: - m_ext: vaddr = 0xFFFFFFFF:86F70000, ext_size = 9216, type = > EXT_JUMBO9 > bce0: /usr/src/sys/dev/bce/if_bce.c(4081): Unexpected mbuf found in > rx_bd[0x0032]! > bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found. > Min(60), Actual(28787), Max(9022) > bce0: mbuf: vaddr = 0xFFFFFF00:5AB4CA00, m_len = 9216, m_flags = ( M_EXT > M_PKTHDR ) m_data = 0xFFFFFFFF:86F6D000 > 0x00: 02 01 02 64 57 04 30 63 6E 3D 73 70 79 65 2C 6F > 0x10: 75 3D 4C 6F 6E 64 6F 6E 2C 6F 75 3D 50 65 72 73 > 0x20: 6F 6E 61 6C 2C 6F 75 3D 47 72 6F 75 70 73 2C 6F > 0x30: 3D 4D 69 6E 74 65 6C 30 23 30 0C 04 02 63 6E 31 > 0x40: 06 04 04 73 70 79 65 30 13 04 09 67 69 64 4E 75 > 0x50: 6D 62 65 72 31 06 04 04 31 32 30 39 30 59 02 01 > 0x60: 02 64 54 04 2F 63 6E 3D 71 61 2C 6F 75 3D 43 68 > 0x70: 69 63 61 67 6F 2C 6F 75 3D 50 65 72 73 6F 6E 61 > bce0: - m_pkthdr: flags = ( ) csum_flags = ( ) > bce0: - m_ext: vaddr = 0xFFFFFFFF:86F6D000, ext_size = 9216, type = > EXT_JUMBO9 > bce0: /usr/src/sys/dev/bce/if_bce.c(4128): Unusual frame size found. > Min(60), Actual(12855), Max(9022) > bce0: mbuf: vaddr =0 67 02 01 02 64 > 0x60: 62 04 36 63 6E 3D 70 6D 63 6E 61 6D 61 72 61 2C > 0x70: 6F 75 3D 43 68 69 63 61 67 6F 2C 6F 75 3D 50 65 > bce0: - m_pkthdr: flags = ( ) csum_flags = ( ) > bce0: - m_ext: vaddr = 0xFFFFFFFF:86F70000, ext_size = 9216, type = > EXT_JUMBO9 > > > > if_bnx.c - 1.4 -> 1.5 LOG: > > RX buffers are malloced memory of 9216 bytes. This can require from 1 to > 4 DMA memory segments, depending on how the buffer is in memory. > When receiving a packet, we allocate a new one to remplace the one we've > used. It can need more segments than the one it remplace, leading to > corrution of the RX descriptors, and a panic in bus_dmamap_sync() > (DIAGNOSTIC > kernels) or possibly memory corruption. > > Fix: > - bce_get_buf() allocates as many buffer as possible, checking the number > of free RX descriptors. Because one receive buffer is not guaranteed to > be remplaced on receive, call bce_get_buf() from bce_tick() too. > This also improve error handling from bce_get_buf(). > - use MCLGET() instead of MEXTMALLOC() if we're running with the standard > ethernet MTU. This gives us more receive buffers and waste less memory. > > > Seem to be moving in the right direction slowly. > > It seems I missed the rx_bd error, it is still present with this patch. Tom From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 12:08:15 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 993C816A469; Wed, 11 Jul 2007 12:08:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6872D13C4BC; Wed, 11 Jul 2007 12:08:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1583F46E5E; Wed, 11 Jul 2007 08:08:15 -0400 (EDT) Date: Wed, 11 Jul 2007 13:08:15 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Silbersack In-Reply-To: <20070710202028.I34890@odysseus.silby.com> Message-ID: <20070711130719.S68820@fledge.watson.org> References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andre Oppermann , current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers 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, 11 Jul 2007 12:08:15 -0000 On Tue, 10 Jul 2007, Mike Silbersack wrote: > On Tue, 10 Jul 2007, Eygene Ryabinkin wrote: > >> Can't say that I am pushing much traffic through my box, but after applying >> your patch and rebuilding the kernel I am still seeing the messages like >> ----- TCP: [209.132.176.NNN]:NNN to [144.206.NNN.NNN]:NNN tcpflags >> 0x19; syncache_expand: Segment failed SYNCOOKIE >> authentication, segment rejected (probably spoofed) TCP: >> [201.90.65.NNN]:NNN to [144.206.NNN.NNN]:NNN; syncache_timer: Response >> timeout ----- But what had changed is that the lines with the >> 'syncache_timer' started to appear. There were no such lines prior to the >> patch, only the 'failed SYNCOOKIE' ones. > > The "syncache_timer: Response timeout" message means that the syncache sent > a SYN-ACK response four times, but still didn't receive a response. This > probably means that someone tried using a port scanner or was going through > a faulty firewall. We'll definitely have to take that log message out > before 7.0 is released. As I mentioned to Andre before he committed the log message support, there needs to be an administrative twiddle for it, and pretty much all need to either be rate-limited or turned off by default when we get to the release. Otherwise they make very easy DoS opportunities, especially for systems with serial consoles. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 14:50:40 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12E9016A41F; Wed, 11 Jul 2007 14:50:40 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from hatert.nijmegen.internl.net (mailrelay1.nijmegen.internl.net [217.149.192.44]) by mx1.freebsd.org (Postfix) with ESMTP id 95EDD13C4B0; Wed, 11 Jul 2007 14:50:37 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtp20.nijmegen.internl.net by hatert.nijmegen.internl.net via smtp20.nijmegen.internl.net [217.149.192.18] with ESMTP id l6BBxJTU015696 (8.13.6/2.04); Wed, 11 Jul 2007 13:59:19 +0200 (MEST) Received: from mail.bsd4all.org (113-9.bbned.dsl.internl.net [82.215.9.113]) by smtp20.nijmegen.internl.net (8.13.8/2.04) with ESMTP id l6BBxHld016265; Wed, 11 Jul 2007 13:59:17 +0200 (CEST) Received: from localhost (localhost.homebrew.bsd4all.org [127.0.0.1]) by mail.bsd4all.org (Postfix) with ESMTP id 9E8541151E; Wed, 11 Jul 2007 13:59:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from mail.bsd4all.org ([127.0.0.1]) by localhost (fwgw.homebrew.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62SXczRNku34; Wed, 11 Jul 2007 13:59:01 +0200 (CEST) Received: from bsd4all.org (adexlinge10 [192.168.10.16]) by mail.bsd4all.org (Postfix) with ESMTP id 2823B1150E; Wed, 11 Jul 2007 13:59:01 +0200 (CEST) Date: Wed, 11 Jul 2007 13:49:37 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-TNEF-Correlator: Thread-Topic: FAST_IPSEC is now IPSEC, please be advised... Thread-Index: Ace9bWLf7Lz0rglzS5WQjb6tKGpYKQGQ42zw Content-class: urn:content-classes:message References: From: "Peter Blok" X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 To: , , Cc: Subject: RE: FAST_IPSEC is now IPSEC, please be advised... 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, 11 Jul 2007 14:50:40 -0000 Hi George, Is somebody looking at ipsec-tools? As far as I can see it requires a lot of kame definitions, although not used most of the times. I have tried to make sense of this, but it wasn't easy. Peter From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 15:15:59 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E742D16A469 for ; Wed, 11 Jul 2007 15:15:59 +0000 (UTC) (envelope-from jamebus@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.179]) by mx1.freebsd.org (Postfix) with ESMTP id 79E0613C469 for ; Wed, 11 Jul 2007 15:15:59 +0000 (UTC) (envelope-from jamebus@gmail.com) Received: by ik-out-1112.google.com with SMTP id c21so1307409ika for ; Wed, 11 Jul 2007 08:15:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=cpthUdTY2iOWsjxYfAD1efjrCTkqgqfSkvX8l4OI/bJMrD+n8uahtEWOBPowUzQ7SS3mNT6ROjVKnskFuOVD3PZh/6iMGU50FhTZCUWMpVrzLrM67D9Y4CZXuzNR7teEC2Ve3n24tYEbZ6BdvDjCwY0oLDdueppmDHqsGybNBAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=H6Wf4zSrjp/MSXqLrRk5FsVPyhbKKOnBuez18cn3Cnoum5WJtH2Hb76g6CpbL7DvbZ8A8l2rk+Ec+3/O91s3yhtOqdkjgxDYsJCa7GCDuQqOsPer7gBMg17SKWcNXMOl55i8bgBz+KL1tTjLMuf0cOnvSF29JOH/JXz3KJl6c0Q= Received: by 10.64.114.10 with SMTP id m10mr3220237qbc.1184166956960; Wed, 11 Jul 2007 08:15:56 -0700 (PDT) Received: by 10.65.132.18 with HTTP; Wed, 11 Jul 2007 08:15:56 -0700 (PDT) Message-ID: Date: Wed, 11 Jul 2007 10:15:56 -0500 From: James Sender: jamebus@gmail.com To: "Tom Judge" In-Reply-To: <46949449.6010103@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46680DB1.9050905@tomjudge.com> <468A2D55.60301@tomjudge.com> <46937D97.7030507@tomjudge.com> <46938E75.80900@tomjudge.com> <4693C88F.8050204@tomjudge.com> <46940E74.4050601@tomjudge.com> <46949449.6010103@tomjudge.com> X-Google-Sender-Auth: 3e148f367589d19a Cc: FreeBSD Net Subject: Re: Problems with BCE network adapter (Dell PE2950) 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, 11 Jul 2007 15:16:00 -0000 On 7/11/07, Tom Judge wrote: > Was this with jumbo or standard frames? Hi Tom. It was with standard frames. -- James. From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 17:37:54 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F44816A468 for ; Wed, 11 Jul 2007 17:37:54 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from smtp3.utdallas.edu (smtp3.utdallas.edu [129.110.10.49]) by mx1.freebsd.org (Postfix) with ESMTP id 4028413C4BB for ; Wed, 11 Jul 2007 17:37:54 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from utd59514.utdallas.edu (utd59514.utdallas.edu [129.110.3.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTP id CFACF654FD for ; Wed, 11 Jul 2007 12:37:53 -0500 (CDT) Date: Wed, 11 Jul 2007 12:37:53 -0500 From: Paul Schmehl To: freebsd-net@freebsd.org Message-ID: <0C1E29F62151D7884CFE26A2@utd59514.utdallas.edu> In-Reply-To: <200707111230.24975.josh@tcbug.org> References: <4694940D.9050408@tomjudge.com> <200707111230.24975.josh@tcbug.org> X-Mailer: Mulberry/4.0.6 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========863A1BABDF4141065CAD==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Question about bce driver 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, 11 Jul 2007 17:37:54 -0000 --==========863A1BABDF4141065CAD========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Wednesday, July 11, 2007 12:30:21 -0500 Josh Paetzel =20 wrote: > On Wednesday 11 July 2007, Tom Judge wrote: >> Paul Schmehl wrote: >> > I'm running 6.1 RELEASE (i386) and I've been replacing the >> > if_bce.c file with a slightly newer one that at least got the >> > driver working without hard lockups that required a reboot to >> > fix. (Rather problematic on a remotely located web server.) >> > >> > If I download the latest driver from cvs (1.33), should I also >> > replace the if_bcefw.h and if_bcereg.h files with the newer >> > versions? Will the NIC work without creating new problems? >> > Right now I get an occasional "flapping" of the NIC link state >> > (down, up , down, up, etc.) but it at least works most of the >> > time. I don't want to buildworld and get suprised by a >> > non-functioning NIC. :-) >> > >> > If I use the newer versions, will I also need to use some other >> > newer files that are called by them? Or would it be better to >> > upgrade the entire box to 6.2? >> > >> > FreeBSD www.stovebolt.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 >> > # 2: >> > >> > grep bce /var/run/dmesg.boot >> > bce0: mem >> > 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9 >> > bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz >> > miibus0: on bce0 >> > bce0: Ethernet address: 00:13:72:fb:2a:ad >> > bce1: mem >> > 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5 >> > bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz >> > miibus1: on bce1 >> > bce1: Ethernet address: 00:13:72:fb:2a:ab >> >> Hi Paul, >> >> From the testing that I have been doing for the last few months >> the driver in 6.2 is stable if you are not using jumbo frames and >> there is a light-moderate network load. >> >> However if you want to use Jumbo frames the driver is very >> unstable. I posted a patch against 6.2 which should fix some load >> based issues in the driver with standard frame sizes. >> >> Tom > > Paul, I was never able to solve the link up/link down problems with > the driver....I was using the drivers from STABLE for a while, and > without jumbo frames everything worked somewhat ok most of the > time....the ultimate solution was to just get the intel PCI-X card > and stop using the broadcoms. Ouch! So even updating to the latest driver doesn't solve the link state=20 issue? I don't use jumbo frames, but it's critical that this server remain = in service 24/7, so I don't want to upgrade if there's no improvement in=20 that issue. Switching to the Intel card would be a bit of a PITA on a=20 remote, rack-mount server. :-( --=20 Paul Schmehl (pauls@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --==========863A1BABDF4141065CAD==========-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 17:47:30 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1010316A468 for ; Wed, 11 Jul 2007 17:47:30 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from cenn-smtp.mc.mpls.visi.com (cenn.mc.mpls.visi.com [208.42.156.9]) by mx1.freebsd.org (Postfix) with ESMTP id D9C0D13C44B for ; Wed, 11 Jul 2007 17:47:29 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from mail.tcbug.org (mail.tcbug.org [208.42.70.163]) by cenn-smtp.mc.mpls.visi.com (Postfix) with ESMTP id 9DEE7811A; Wed, 11 Jul 2007 12:30:25 -0500 (CDT) Received: from [192.168.1.5] (unknown [192.168.2.1]) by mail.tcbug.org (Postfix) with ESMTP id 3AD56341C2B; Wed, 11 Jul 2007 12:30:25 -0500 (CDT) From: Josh Paetzel To: freebsd-net@freebsd.org Date: Wed, 11 Jul 2007 12:30:21 -0500 User-Agent: KMail/1.9.6 References: <4694940D.9050408@tomjudge.com> In-Reply-To: <4694940D.9050408@tomjudge.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart11726335.vzX6NaP99J"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707111230.24975.josh@tcbug.org> Cc: Tom Judge , Paul Schmehl Subject: Re: Question about bce driver 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, 11 Jul 2007 17:47:30 -0000 --nextPart11726335.vzX6NaP99J Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 11 July 2007, Tom Judge wrote: > Paul Schmehl wrote: > > I'm running 6.1 RELEASE (i386) and I've been replacing the > > if_bce.c file with a slightly newer one that at least got the > > driver working without hard lockups that required a reboot to > > fix. (Rather problematic on a remotely located web server.) > > > > If I download the latest driver from cvs (1.33), should I also > > replace the if_bcefw.h and if_bcereg.h files with the newer > > versions? Will the NIC work without creating new problems?=20 > > Right now I get an occasional "flapping" of the NIC link state > > (down, up , down, up, etc.) but it at least works most of the > > time. I don't want to buildworld and get suprised by a > > non-functioning NIC. :-) > > > > If I use the newer versions, will I also need to use some other > > newer files that are called by them? Or would it be better to > > upgrade the entire box to 6.2? > > > > FreeBSD www.stovebolt.com 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 > > #2: > > > > grep bce /var/run/dmesg.boot > > bce0: mem > > 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9 > > bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz > > miibus0: on bce0 > > bce0: Ethernet address: 00:13:72:fb:2a:ad > > bce1: mem > > 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5 > > bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz > > miibus1: on bce1 > > bce1: Ethernet address: 00:13:72:fb:2a:ab > > Hi Paul, > > From the testing that I have been doing for the last few months > the driver in 6.2 is stable if you are not using jumbo frames and > there is a light-moderate network load. > > However if you want to use Jumbo frames the driver is very > unstable. I posted a patch against 6.2 which should fix some load > based issues in the driver with standard frame sizes. > > Tom Paul, I was never able to solve the link up/link down problems with=20 the driver....I was using the drivers from STABLE for a while, and=20 without jumbo frames everything worked somewhat ok most of the=20 time....the ultimate solution was to just get the intel PCI-X card=20 and stop using the broadcoms. =2D-=20 Thanks, Josh Paetzel --nextPart11726335.vzX6NaP99J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGlROwJvkB8SevrssRAmscAJ0X5An4mp97FhO2VUMMw3zacyjj1QCfY1YS IPUKkRo0P/C5A6gvNkF5NI0= =xJJD -----END PGP SIGNATURE----- --nextPart11726335.vzX6NaP99J-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 17:52:49 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6D7516A41F for ; Wed, 11 Jul 2007 17:52:49 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from conn-smtp.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by mx1.freebsd.org (Postfix) with ESMTP id 78CC513C448 for ; Wed, 11 Jul 2007 17:52:49 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from mail.tcbug.org (mail.tcbug.org [208.42.70.163]) by conn-smtp.mc.mpls.visi.com (Postfix) with ESMTP id C865781A5; Wed, 11 Jul 2007 12:28:22 -0500 (CDT) Received: from [192.168.1.5] (unknown [192.168.2.1]) by mail.tcbug.org (Postfix) with ESMTP id B9ADD341C0C; Wed, 11 Jul 2007 12:28:21 -0500 (CDT) From: Josh Paetzel To: freebsd-net@freebsd.org Date: Wed, 11 Jul 2007 12:28:16 -0500 User-Agent: KMail/1.9.6 References: <46680DB1.9050905@tomjudge.com> <46949449.6010103@tomjudge.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart15183559.x0mtOvgcKM"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707111228.20354.josh@tcbug.org> Cc: Tom Judge Subject: Re: Problems with BCE network adapter (Dell PE2950) 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, 11 Jul 2007 17:52:49 -0000 --nextPart15183559.x0mtOvgcKM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 11 July 2007, James wrote: > On 7/11/07, Tom Judge wrote: > > Was this with jumbo or standard frames? > > Hi Tom. It was with standard frames. Having fought the PE1950/2950 bce problem for almost a year now I'll=20 give you a friendly piece of advice. Dell sells an intel dual port=20 gig-e card for these machines. If the PCI-X riser hasn't been=20 populated with anything else do yourself a favor and buy it. =2D-=20 Thanks, Josh Paetzel --nextPart15183559.x0mtOvgcKM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGlRM0JvkB8SevrssRAhFEAKCMOmylf+nW8KW5TnDW9dDm0WIwNACfcXcE tY48qVccZCARhnfcX0apdAo= =h+K1 -----END PGP SIGNATURE----- --nextPart15183559.x0mtOvgcKM-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 18:51:09 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF63D16A400 for ; Wed, 11 Jul 2007 18:51:09 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from conn-smtp.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by mx1.freebsd.org (Postfix) with ESMTP id 831FE13C448 for ; Wed, 11 Jul 2007 18:51:09 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from mail.tcbug.org (mail.tcbug.org [208.42.70.163]) by conn-smtp.mc.mpls.visi.com (Postfix) with ESMTP id C4B2081ED; Wed, 11 Jul 2007 13:51:08 -0500 (CDT) Received: from [192.168.1.5] (unknown [192.168.2.1]) by mail.tcbug.org (Postfix) with ESMTP id 62466341C0C; Wed, 11 Jul 2007 13:51:08 -0500 (CDT) From: Josh Paetzel To: freebsd-net@freebsd.org Date: Wed, 11 Jul 2007 13:51:04 -0500 User-Agent: KMail/1.9.6 References: <200707111230.24975.josh@tcbug.org> <0C1E29F62151D7884CFE26A2@utd59514.utdallas.edu> In-Reply-To: <0C1E29F62151D7884CFE26A2@utd59514.utdallas.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3054455.kzUs4E71mx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707111351.07733.josh@tcbug.org> Cc: Paul Schmehl Subject: Re: Question about bce driver 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, 11 Jul 2007 18:51:09 -0000 --nextPart3054455.kzUs4E71mx Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 11 July 2007, Paul Schmehl wrote: > > > > Paul, I was never able to solve the link up/link down problems > > with the driver....I was using the drivers from STABLE for a > > while, and without jumbo frames everything worked somewhat ok > > most of the time....the ultimate solution was to just get the > > intel PCI-X card and stop using the broadcoms. > > Ouch! So even updating to the latest driver doesn't solve the link > state issue? I don't use jumbo frames, but it's critical that this > server remain in service 24/7, so I don't want to upgrade if > there's no improvement in that issue. Switching to the Intel card > would be a bit of a PITA on a remote, rack-mount server. :-( I was running the driver from STABLE until about March and it would=20 bounce the link up and down a couple times a day even under=20 relatively moderate load. (50-60 mbps) So perhaps there have been=20 improvements since then, but I gave up dealing with it. The driver=20 was utterly broken in 6.1-R (0.9.5), by the time 6.2-R was getting=20 rolled the driver in STABLE would at least not tip over under TCP=20 load, but it was trivial to wedge it with even moderate amounts of=20 UDP. I eventually reached the conclusion (correct or not) that you can't=20 fix crap hardware with a driver. =2D-=20 Thanks, Josh Paetzel --nextPart3054455.kzUs4E71mx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGlSabJvkB8SevrssRAmt3AJ9ed1RInFRe5j8CmVc4OF0abA/MugCdGQbQ VDSykirW/n2BmdD4x16ReUQ= =Sd8c -----END PGP SIGNATURE----- --nextPart3054455.kzUs4E71mx-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 23:06:00 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 407BE16A41F for ; Wed, 11 Jul 2007 23:06:00 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp805.mail.ukl.yahoo.com (smtp805.mail.ukl.yahoo.com [217.12.12.195]) by mx1.freebsd.org (Postfix) with SMTP id 9E3E313C458 for ; Wed, 11 Jul 2007 23:05:59 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 21458 invoked from network); 11 Jul 2007 22:39:17 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.139.149.183 with plain) by smtp805.mail.ukl.yahoo.com with SMTP; 11 Jul 2007 22:39:16 -0000 X-YMail-OSG: 4XQS6DgVM1mrn7RDWLMQpwSeCml5Fiix84.XLYwLxCYttU1Q Message-ID: <46956A44.3000304@tomjudge.com> Date: Thu, 12 Jul 2007 00:39:48 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Josh Paetzel References: <4694940D.9050408@tomjudge.com> <200707111230.24975.josh@tcbug.org> In-Reply-To: <200707111230.24975.josh@tcbug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Paul Schmehl Subject: Re: Question about bce driver 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, 11 Jul 2007 23:06:00 -0000 Josh Paetzel wrote: > On Wednesday 11 July 2007, Tom Judge wrote: >> Hi Paul, >> >> From the testing that I have been doing for the last few months >> the driver in 6.2 is stable if you are not using jumbo frames and >> there is a light-moderate network load. >> >> However if you want to use Jumbo frames the driver is very >> unstable. I posted a patch against 6.2 which should fix some load >> based issues in the driver with standard frame sizes. >> >> Tom > > Paul, I was never able to solve the link up/link down problems with > the driver....I was using the drivers from STABLE for a while, and > without jumbo frames everything worked somewhat ok most of the > time....the ultimate solution was to just get the intel PCI-X card > and stop using the broadcoms. > > We have basically come to the same conclusion today, unfortunately this is 35 machines, but if it makes them stable at least we can use them. Tom From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 23:06:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F0C8D16A41F for ; Wed, 11 Jul 2007 23:06:23 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp805.mail.ukl.yahoo.com (smtp805.mail.ukl.yahoo.com [217.12.12.195]) by mx1.freebsd.org (Postfix) with SMTP id 5B0B613C480 for ; Wed, 11 Jul 2007 23:06:23 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 21557 invoked from network); 11 Jul 2007 22:39:41 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.139.149.183 with plain) by smtp805.mail.ukl.yahoo.com with SMTP; 11 Jul 2007 22:39:41 -0000 X-YMail-OSG: PRD5ax4VM1nJcu7MkZNaO1LywlWihTj.R7Z3VBbol9GEtu9f Message-ID: <46956A5D.7020401@tomjudge.com> Date: Thu, 12 Jul 2007 00:40:13 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Josh Paetzel References: <46680DB1.9050905@tomjudge.com> <46949449.6010103@tomjudge.com> <200707111228.20354.josh@tcbug.org> In-Reply-To: <200707111228.20354.josh@tcbug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Problems with BCE network adapter (Dell PE2950) 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, 11 Jul 2007 23:06:24 -0000 Josh Paetzel wrote: > On Wednesday 11 July 2007, James wrote: >> On 7/11/07, Tom Judge wrote: >>> Was this with jumbo or standard frames? >> Hi Tom. It was with standard frames. > > Having fought the PE1950/2950 bce problem for almost a year now I'll > give you a friendly piece of advice. Dell sells an intel dual port > gig-e card for these machines. If the PCI-X riser hasn't been > populated with anything else do yourself a favor and buy it. > We have basically come to the same conclusion today, unfortunately this is 35 machines, but if it makes them stable at least we can use them. Tom From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 23:08:31 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9564716A46E for ; Wed, 11 Jul 2007 23:08:31 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 03BE013C4C5 for ; Wed, 11 Jul 2007 23:08:30 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 48603 invoked from network); 11 Jul 2007 23:06:25 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Jul 2007 23:06:25 -0000 Message-ID: <469562F9.4060700@freebsd.org> Date: Thu, 12 Jul 2007 01:08:41 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Robert Watson References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <20070711130719.S68820@fledge.watson.org> In-Reply-To: <20070711130719.S68820@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers 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, 11 Jul 2007 23:08:31 -0000 Robert Watson wrote: > On Tue, 10 Jul 2007, Mike Silbersack wrote: > >> On Tue, 10 Jul 2007, Eygene Ryabinkin wrote: >> >>> Can't say that I am pushing much traffic through my box, but after >>> applying your patch and rebuilding the kernel I am still seeing the >>> messages like ----- TCP: [209.132.176.NNN]:NNN to >>> [144.206.NNN.NNN]:NNN tcpflags 0x19; syncache_expand: >>> Segment failed SYNCOOKIE authentication, segment rejected (probably >>> spoofed) TCP: [201.90.65.NNN]:NNN to [144.206.NNN.NNN]:NNN; >>> syncache_timer: Response timeout ----- But what had changed is that >>> the lines with the 'syncache_timer' started to appear. There were no >>> such lines prior to the patch, only the 'failed SYNCOOKIE' ones. >> >> The "syncache_timer: Response timeout" message means that the syncache >> sent a SYN-ACK response four times, but still didn't receive a >> response. This probably means that someone tried using a port scanner >> or was going through a faulty firewall. We'll definitely have to take >> that log message out before 7.0 is released. > > As I mentioned to Andre before he committed the log message support, > there needs to be an administrative twiddle for it, and pretty much all > need to either be rate-limited or turned off by default when we get to > the release. Otherwise they make very easy DoS opportunities, especially > for systems with serial consoles. Yes, I'm aware of that and will provide an appropriate patch shortly. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 00:23:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5165C16A41F for ; Thu, 12 Jul 2007 00:23:10 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 22DEE13C468 for ; Thu, 12 Jul 2007 00:23:09 +0000 (UTC) (envelope-from mike@sentex.net) Received: from BLUELAPIS.sentex.ca (cage.simianscience.com [64.7.134.1]) by smarthost2.sentex.ca (8.14.1/8.13.8) with SMTP id l6C0N8JV064533; Wed, 11 Jul 2007 20:23:08 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: Brett Glass Date: Wed, 11 Jul 2007 20:23:08 -0400 Message-ID: References: <200707110014.SAA02181@lariat.net> In-Reply-To: <200707110014.SAA02181@lariat.net> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Bug in userland PPP LQR? 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, 12 Jul 2007 00:23:10 -0000 On Tue, 10 Jul 2007 18:13:48 -0600, in sentex.lists.freebsd.net you wrote: >I may have found a bug in the LQR code of FreeBSD's userland PPP.=20 >I've been noticing that PPTP sessions are dropping with messages=20 >saying "** Too many LQR packets lost **" on some important wireless=20 >links. Wireless links occasionally do drop a packet or two, but=20 >it's rare to see 5 dropped packets in a row (which is supposed to=20 >be when PPP gives up and kills the link). Yet, the links go down=20 >when there's even an occasional dropped packet. Did you try and use just LCP echo mode instead ? I have come across a number of devices (especially GPRS/EVDO cards) that seem to say yes to supporting LQR, but do not. Try instead lcp echo ---Mike -------------------------------------------------------- Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 mike@sentex.net, (http://www.tancsa.com) From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 01:43:05 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07C2216A468 for ; Thu, 12 Jul 2007 01:43:05 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7C7DE13C469 for ; Thu, 12 Jul 2007 01:43:04 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id TAA28481; Wed, 11 Jul 2007 19:14:08 -0600 (MDT) Message-Id: <200707120114.TAA28481@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Jul 2007 19:14:03 -0600 To: Mike Tancsa From: Brett Glass In-Reply-To: References: <200707110014.SAA02181@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-net@freebsd.org Subject: Re: Bug in userland PPP LQR? 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, 12 Jul 2007 01:43:05 -0000 At 06:23 PM 7/11/2007, Mike Tancsa wrote: >Did you try and use just LCP echo mode instead ? I have come across a >number of devices (especially GPRS/EVDO cards) that seem to say yes to >supporting LQR, but do not. Try instead lcp echo I will try it. (To be more specific, I am going to try disable lqr allow lqr enable echo echoperiod 12 so that the peer can get LQR if it requests it.) But since this would just be working around the bug I think might be there, it would also be a good idea to look at how the LQR counter is managed. From what I can see, the problem is that the counter either is cumulative or counts irrevocably up to 5 after one LQR packet is missed. The reason why I'd like to see more eyes than my own on this is that it's difficult to see how and where the LQR routines are invoked and how they react to a pattern of missed and un-missed packets. --Brett From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 01:56:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 556F916A400 for ; Thu, 12 Jul 2007 01:56:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 3FAF413C45A for ; Thu, 12 Jul 2007 01:56:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 11 Jul 2007 18:56:17 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 565A9125ADD; Wed, 11 Jul 2007 18:56:17 -0700 (PDT) Message-ID: <46958A55.4020704@elischer.org> Date: Wed, 11 Jul 2007 18:56:37 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Tom Judge References: <4694940D.9050408@tomjudge.com> <200707111230.24975.josh@tcbug.org> <46956A44.3000304@tomjudge.com> In-Reply-To: <46956A44.3000304@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Josh Paetzel , Paul Schmehl , freebsd-net@freebsd.org Subject: Re: Question about bce driver 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, 12 Jul 2007 01:56:18 -0000 Tom Judge wrote: > Josh Paetzel wrote: >> On Wednesday 11 July 2007, Tom Judge wrote: >>> Hi Paul, >>> >>> From the testing that I have been doing for the last few months >>> the driver in 6.2 is stable if you are not using jumbo frames and >>> there is a light-moderate network load. >>> >>> However if you want to use Jumbo frames the driver is very >>> unstable. I posted a patch against 6.2 which should fix some load >>> based issues in the driver with standard frame sizes. >>> >>> Tom >> >> Paul, I was never able to solve the link up/link down problems with >> the driver....I was using the drivers from STABLE for a while, and >> without jumbo frames everything worked somewhat ok most of the >> time....the ultimate solution was to just get the intel PCI-X card and >> stop using the broadcoms. >> >> > > We have basically come to the same conclusion today, unfortunately this > is 35 machines, but if it makes them stable at least we can use them. I'm not seeing any problems on our 2950s running 6.1 plus some backpatches. > > Tom > _______________________________________________ > 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" From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 03:34:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E42816A421 for ; Thu, 12 Jul 2007 03:34:32 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from smtp3.utdallas.edu (smtp3.utdallas.edu [129.110.10.49]) by mx1.freebsd.org (Postfix) with ESMTP id 1EEEF13C465 for ; Thu, 12 Jul 2007 03:34:32 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from [192.168.2.102] (adsl-68-94-76-79.dsl.rcsntx.swbell.net [68.94.76.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTP id 0E2EC654FF for ; Wed, 11 Jul 2007 22:34:30 -0500 (CDT) Date: Wed, 11 Jul 2007 22:34:17 -0500 From: Paul Schmehl To: freebsd-net@freebsd.org Message-ID: In-Reply-To: <200707111351.07733.josh@tcbug.org> References: <200707111230.24975.josh@tcbug.org> <0C1E29F62151D7884CFE26A2@utd59514.utdallas.edu> <200707111351.07733.josh@tcbug.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========B8EE62A5AC511682BEA8==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Question about bce driver 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, 12 Jul 2007 03:34:32 -0000 --==========B8EE62A5AC511682BEA8========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On July 11, 2007 1:51:04 PM -0500 Josh Paetzel wrote: > > I was running the driver from STABLE until about March and it would > bounce the link up and down a couple times a day even under > relatively moderate load. (50-60 mbps) So perhaps there have been > improvements since then, but I gave up dealing with it. The driver > was utterly broken in 6.1-R (0.9.5), by the time 6.2-R was getting > rolled the driver in STABLE would at least not tip over under TCP > load, but it was trivial to wedge it with even moderate amounts of > UDP. > > I eventually reached the conclusion (correct or not) that you can't > fix crap hardware with a driver. No offense, but I think that's the incorrect conclusion. It pains me to=20 say it, but we have never had a single problem with the Broadcomms on=20 Windows servers, and we have a boatload of them (at least 100). That=20 seems to point to the driver being the source of the problem, not the=20 hardware. Furthermore, when I first got the 1950, the NIC was completely=20 unusable. It would lock up hard and require a reboot to function again.=20 That problem was fixed in the next iteration of the driver, and, except=20 for the link state problem, the NIC has functioned normally ever since.=20 (I don't use jumbo frames.) ISTM the driver is the source of all the problems associated with the=20 card(s). I wish I knew enough to work on driver code, but I do not. I=20 noticed that the guy writing the driver for FreeBSD works for Broadcomm.=20 Perhaps he could comment? Paul Schmehl (pauls@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --==========B8EE62A5AC511682BEA8==========-- From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 04:01:23 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1317816A400; Thu, 12 Jul 2007 04:01:23 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id B3CB313C44C; Thu, 12 Jul 2007 04:01:22 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=NFQraD/xZ20H3b8HoXlrxZXWQ+1LkdQXJV0Kww7AbGb+ngbkxGtsCo+eLTJUGoW9eifJwz3wufgMzvxpiKFge8aND+Tc5D6l53dQlKSLrg78NsdaVb5q5MQUVnOcMcT7eyPMeXCe14goiXETj49cIHC/oKFAnGq7ps/Y5/m8bqM=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1I8prk-0007wB-He; Thu, 12 Jul 2007 08:01:20 +0400 Date: Thu, 12 Jul 2007 08:01:15 +0400 From: Eygene Ryabinkin To: Mike Silbersack Message-ID: <20070712040115.GK1038@void.codelabs.ru> References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <20070711060423.GV1038@void.codelabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070711060423.GV1038@void.codelabs.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: Robert Watson , Andre Oppermann , current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers 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, 12 Jul 2007 04:01:23 -0000 Good day. Wed, Jul 11, 2007 at 10:04:23AM +0400, Eygene Ryabinkin wrote: > OK, maybe I have something that can be related to this bug. It > provokes another message, 'Spurious RST', but can be correlated > with your guess. What is happening is that when one side closes > the connection and releases the socket (running -CURRENT) while the > other one is still pushing data through the connection, we are > getting 'Spurious RST' messages. This happens, because we are > checking the 'so->so_state' for the presence of the 'SS_NOFDREF' > flag (tcp_input.c, version 1.361, line 1581) and dropping such > connections with RST. But the connection was already closed (living > in the FIN-WAIT-2 state, to be precise) from that side, so it > provokes the debug message. To clarify one point: the first RST is due to the SS_NOFDREF flag. The rest of RSTs are spitted out because the corresponding connection was closed by tcp_close() just before the first RST. -- Eygene From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 08:31:09 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C95E16A41F for ; Thu, 12 Jul 2007 08:31:09 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp811.mail.ukl.yahoo.com (smtp811.mail.ukl.yahoo.com [217.12.12.201]) by mx1.freebsd.org (Postfix) with SMTP id 0058C13C455 for ; Thu, 12 Jul 2007 08:31:08 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 58329 invoked from network); 12 Jul 2007 08:31:07 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.139.149.183 with plain) by smtp811.mail.ukl.yahoo.com with SMTP; 12 Jul 2007 08:31:07 -0000 X-YMail-OSG: HietuQ4VM1nvvKS0GTPIjXvT7IkvKeWDRIwwEGz98WeX6jby Message-ID: <4695F4FD.2010102@tomjudge.com> Date: Thu, 12 Jul 2007 10:31:41 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Julian Elischer References: <4694940D.9050408@tomjudge.com> <200707111230.24975.josh@tcbug.org> <46956A44.3000304@tomjudge.com> <46958A55.4020704@elischer.org> In-Reply-To: <46958A55.4020704@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Josh Paetzel , Paul Schmehl , freebsd-net@freebsd.org Subject: Re: Question about bce driver 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, 12 Jul 2007 08:31:09 -0000 Julian Elischer wrote: > Tom Judge wrote: >> Josh Paetzel wrote: >>> On Wednesday 11 July 2007, Tom Judge wrote: >>>> Hi Paul, >>>> >>>> From the testing that I have been doing for the last few months >>>> the driver in 6.2 is stable if you are not using jumbo frames and >>>> there is a light-moderate network load. >>>> >>>> However if you want to use Jumbo frames the driver is very >>>> unstable. I posted a patch against 6.2 which should fix some load >>>> based issues in the driver with standard frame sizes. >>>> >>>> Tom >>> >>> Paul, I was never able to solve the link up/link down problems with >>> the driver....I was using the drivers from STABLE for a while, and >>> without jumbo frames everything worked somewhat ok most of the >>> time....the ultimate solution was to just get the intel PCI-X card >>> and stop using the broadcoms. >>> >>> >> >> We have basically come to the same conclusion today, unfortunately >> this is 35 machines, but if it makes them stable at least we can use >> them. > > I'm not seeing any problems on our 2950s running 6.1 plus some backpatches. > I am very surprised at that. The driver in 6.1 was un-usable in our environment. 6.2 makes it usable with standard frames under moderate load. However use jumbo frames and it all falls apart, and unfortunately the network these systems are plugged into is GigE only with a 8192 Jumbo mtu. I have been trying to get some help with the problem for over a month now without luck. Firstly I was asked to enable some debugging in the driver, this just uncovered what seems to be memory management bug in the driver. A patch was suggest for this but it did not solve the problem. Next I noticed the NetBSD guys had we written the offending parts of code which I then ported to FreeBSD driver. Still no luck, although the problem was not as bad as before. Then I took a look at the OpenBSD driver, and it seems that they just completely disabled jumbo frames as they are just so ropey. If a patch was released today that fixed the problem then I may be able to fully test the driver and not have to replace the NIC's. However I am running out of time with deployment deadlines and I need this kit in production by the latest mid next week. Tom From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 10:53:21 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64CA016A469 for ; Thu, 12 Jul 2007 10:53:21 +0000 (UTC) (envelope-from ml@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id E02D413C45A for ; Thu, 12 Jul 2007 10:53:20 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.ventu ([151.77.235.121]) (authenticated bits=128) by parrot.aev.net (8.14.1/8.13.8) with ESMTP id l6CAQEGp057351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Jul 2007 12:26:21 +0200 (CEST) (envelope-from ml@netfence.it) Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.1/8.13.8) with ESMTP id l6CAF01x009717 for ; Thu, 12 Jul 2007 12:15:01 +0200 (CEST) (envelope-from ml@netfence.it) Message-ID: <4695FEF4.4030708@netfence.it> Date: Thu, 12 Jul 2007 12:14:12 +0200 From: Andrea Venturoli User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.61 on 212.31.247.179 Subject: Again two ADSL lines, routing problems 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, 12 Jul 2007 10:53:21 -0000 Hello. I have a setup where a FreeBSD box is connected to two ADSL routers: default gateway is set to the first and, in case of failure, is moved to the other one. This works perfectly for outgoing connections: in the event of the switch, I'll have to reconnect, but that's acceptable. The problem is in the incoming connections: if I get one on the "backup" router, this will reach the server, which will however answer through its "default" router. Thus the remote client will see packets coming back from a different host and things won't work. Just to be clear, the packets travel as follows (with source and dest IP in brackets): Client (x.x.x.x) -> Backup router (y.y.y.y) Backup router (x.x.x.x) -> Server (z.z.z.z) Server (z.z.z.z) -> Default router (x.x.x.x) Default router (v.v.v.v) -> Client (x.x.x.x) So the client (x.x.x.x) connects to y.y.y.y (the backup ADSL public IP), but gets answers from v.v.v.v (the master ADSL public IP). AFAIK there is no solution to this, but I tought I'd ask before giving my official opinion to my customer. Perhaps there's some sort of hack we could use, that through ipfw/natd/other diverting daemon/whatever delivers answers based on the MAC address of the incoming connections (if the MAC address belongs to the backup router, use that for answers)... does anyone know? bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 11:01:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E26B516A400 for ; Thu, 12 Jul 2007 11:01:23 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from snipe.secure-computing.net (snipe.secure-computing.net [209.240.66.149]) by mx1.freebsd.org (Postfix) with ESMTP id 7754713C483 for ; Thu, 12 Jul 2007 11:01:23 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from [192.168.1.2] (unknown [209.240.66.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ecrist@secure-computing.net) by snipe.secure-computing.net (Postfix) with ESMTP id 0096917021; Thu, 12 Jul 2007 06:01:22 -0500 (CDT) In-Reply-To: <4695FEF4.4030708@netfence.it> References: <4695FEF4.4030708@netfence.it> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Eric F Crist Date: Thu, 12 Jul 2007 06:01:21 -0500 To: Andrea Venturoli X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org Subject: Re: Again two ADSL lines, routing problems 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, 12 Jul 2007 11:01:24 -0000 On Jul 12, 2007, at 5:14 AMJul 12, 2007, Andrea Venturoli wrote: > Hello. > I have a setup where a FreeBSD box is connected to two ADSL > routers: default gateway is set to the first and, in case of > failure, is moved to the other one. This works perfectly for > outgoing connections: in the event of the switch, I'll have to > reconnect, but that's acceptable. > > The problem is in the incoming connections: if I get one on the > "backup" router, this will reach the server, which will however > answer through its "default" router. Thus the remote client will > see packets coming back from a different host and things won't work. > Just to be clear, the packets travel as follows (with source and > dest IP in brackets): > Client (x.x.x.x) -> Backup router (y.y.y.y) > Backup router (x.x.x.x) -> Server (z.z.z.z) > Server (z.z.z.z) -> Default router (x.x.x.x) > Default router (v.v.v.v) -> Client (x.x.x.x) > > So the client (x.x.x.x) connects to y.y.y.y (the backup ADSL public > IP), but gets answers from v.v.v.v (the master ADSL public IP). > > > AFAIK there is no solution to this, but I tought I'd ask before > giving my official opinion to my customer. > Perhaps there's some sort of hack we could use, that through ipfw/ > natd/other diverting daemon/whatever delivers answers based on the > MAC address of the incoming connections (if the MAC address belongs > to the backup router, use that for answers)... does anyone know? > > bye & Thanks > av. > The biggest problem one would have with this sort of setup, is the upstream provider support. I don't know of any ISP's that are going to be willing or even able to propagate routes for your static IPs through their DSL systems. If you want that sort of redundancy and support, you'll probably have to go to a higher-end business class solution, such as a T1 or even possibly an ISDN line. HTH ----- Eric F Crist Secure Computing Networks From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 11:55:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9CE416A46D for ; Thu, 12 Jul 2007 11:55:32 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id 16F8413C4CB for ; Thu, 12 Jul 2007 11:55:31 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from [10.100.0.23] (vl-office.vl.net.ua [194.44.81.189]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l6CBtRLX029743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jul 2007 14:55:28 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Message-ID: <469616B2.2020803@aws-net.org.ua> Date: Thu, 12 Jul 2007 14:55:30 +0300 From: Artyom Viklenko Organization: Art&Co. User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Andrea Venturoli References: <4695FEF4.4030708@netfence.it> In-Reply-To: <4695FEF4.4030708@netfence.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Thu, 12 Jul 2007 14:55:29 +0300 (EEST) X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on localhost X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: Again two ADSL lines, routing problems 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, 12 Jul 2007 11:55:33 -0000 Andrea Venturoli wrote: > Hello. > I have a setup where a FreeBSD box is connected to two ADSL routers: > default gateway is set to the first and, in case of failure, is moved to > the other one. This works perfectly for outgoing connections: in the > event of the switch, I'll have to reconnect, but that's acceptable. > > The problem is in the incoming connections: if I get one on the "backup" > router, this will reach the server, which will however answer through > its "default" router. Thus the remote client will see packets coming > back from a different host and things won't work. > Just to be clear, the packets travel as follows (with source and dest IP > in brackets): > Client (x.x.x.x) -> Backup router (y.y.y.y) > Backup router (x.x.x.x) -> Server (z.z.z.z) > Server (z.z.z.z) -> Default router (x.x.x.x) > Default router (v.v.v.v) -> Client (x.x.x.x) > > So the client (x.x.x.x) connects to y.y.y.y (the backup ADSL public IP), > but gets answers from v.v.v.v (the master ADSL public IP). > > > AFAIK there is no solution to this, but I tought I'd ask before giving > my official opinion to my customer. > Perhaps there's some sort of hack we could use, that through > ipfw/natd/other diverting daemon/whatever delivers answers based on the > MAC address of the incoming connections (if the MAC address belongs to > the backup router, use that for answers)... does anyone know? You have to enforce simmetrical routing on your FreeBSD box. You can use, for example, PF firewall Using such options and features as labels and route-to/reply-to statemens. Also it is possible with ipfw, but I prefer PF. :) -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 12:18:33 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C04416A421 for ; Thu, 12 Jul 2007 12:18:33 +0000 (UTC) (envelope-from ml@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id D888913C465 for ; Thu, 12 Jul 2007 12:18:32 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.ventu ([151.77.235.121]) (authenticated bits=128) by parrot.aev.net (8.14.1/8.13.8) with ESMTP id l6CCUNR4074325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Jul 2007 14:30:29 +0200 (CEST) (envelope-from ml@netfence.it) Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.1/8.13.8) with ESMTP id l6CCJ8Tx032645; Thu, 12 Jul 2007 14:19:08 +0200 (CEST) (envelope-from ml@netfence.it) Message-ID: <46961C0B.6060004@netfence.it> Date: Thu, 12 Jul 2007 14:18:19 +0200 From: Andrea Venturoli User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: Artyom Viklenko References: <4695FEF4.4030708@netfence.it> <469616B2.2020803@aws-net.org.ua> In-Reply-To: <469616B2.2020803@aws-net.org.ua> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.61 on 212.31.247.179 Cc: freebsd-net@freebsd.org Subject: Re: Again two ADSL lines, routing problems 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, 12 Jul 2007 12:18:33 -0000 Artyom Viklenko ha scritto: > You have to enforce simmetrical routing on your FreeBSD box. > You can use, for example, PF firewall Using such options and features > as labels and route-to/reply-to statemens. > > Also it is possible with ipfw, but I prefer PF. :) Thanks, this is interesting. However I failed to understand what you mean exactly. Do you have any pointer to a document that explains this? I searched in PF's and ipfw's manual, but found nothing that I could relate to this. Also, I'm right now using ipfw... bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 12:19:05 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 959EE16A468 for ; Thu, 12 Jul 2007 12:19:05 +0000 (UTC) (envelope-from ml@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id 1CAC513C44C for ; Thu, 12 Jul 2007 12:19:04 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.ventu ([151.77.235.121]) (authenticated bits=128) by parrot.aev.net (8.14.1/8.13.8) with ESMTP id l6CCUvka074404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Jul 2007 14:31:03 +0200 (CEST) (envelope-from ml@netfence.it) Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.1/8.13.8) with ESMTP id l6CCJhWC032760 for ; Thu, 12 Jul 2007 14:19:43 +0200 (CEST) (envelope-from ml@netfence.it) Message-ID: <46961C2E.4060300@netfence.it> Date: Thu, 12 Jul 2007 14:18:54 +0200 From: Andrea Venturoli User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 CC: freebsd-net@freebsd.org References: <4695FEF4.4030708@netfence.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.61 on 212.31.247.179 Subject: Re: Again two ADSL lines, routing problems 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, 12 Jul 2007 12:19:05 -0000 Eric F Crist ha scritto: > The biggest problem one would have with this sort of setup, is the upstream provider support. I don't know of any ISP's that are going to be willing or even able to propagate routes for your static IPs through their DSL systems. If you want that sort of redundancy and support, you'll probably have to go to a higher-end business class solution, such as a T1 or even possibly an ISDN line. In fact I was speaking about an hypotetical in-house solution. Some kind of stateful deamon on the line of natd that makes it so that if connection x comes from MAC address y, then answer through gateway z (the IP corresponding to MAC address y). bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 12:45:07 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 235D316A41F for ; Thu, 12 Jul 2007 12:45:07 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from conn-smtp.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by mx1.freebsd.org (Postfix) with ESMTP id EAD9313C46E for ; Thu, 12 Jul 2007 12:45:06 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from mail.tcbug.org (mail.tcbug.org [208.42.70.163]) by conn-smtp.mc.mpls.visi.com (Postfix) with ESMTP id F085281E1; Thu, 12 Jul 2007 07:45:05 -0500 (CDT) Received: from [192.168.1.5] (unknown [192.168.2.1]) by mail.tcbug.org (Postfix) with ESMTP id 6F674341C0C; Thu, 12 Jul 2007 07:45:04 -0500 (CDT) From: Josh Paetzel To: freebsd-net@freebsd.org Date: Thu, 12 Jul 2007 07:44:59 -0500 User-Agent: KMail/1.9.6 References: <4695FEF4.4030708@netfence.it> <469616B2.2020803@aws-net.org.ua> <46961C0B.6060004@netfence.it> In-Reply-To: <46961C0B.6060004@netfence.it> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1524610.0FQksEAgMv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707120745.03102.josh@tcbug.org> Cc: Eric F Crist , Artyom Viklenko Subject: Re: Again two ADSL lines, routing problems 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, 12 Jul 2007 12:45:07 -0000 --nextPart1524610.0FQksEAgMv Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 12 July 2007, Andrea Venturoli wrote: > Artyom Viklenko ha scritto: > > You have to enforce simmetrical routing on your FreeBSD box. > > You can use, for example, PF firewall Using such options and > > features as labels and route-to/reply-to statemens. > > > > Also it is possible with ipfw, but I prefer PF. :) > > Thanks, this is interesting. However I failed to understand what > you mean exactly. > Do you have any pointer to a document that explains this? > I searched in PF's and ipfw's manual, but found nothing that I > could relate to this. > > Also, I'm right now using ipfw... > > bye & Thanks > av. errrm, in pf I can give you a concrete example of how to deal with=20 this. Since you haven't given a concrete example I'll make one up. Say you=20 have a FBSD box with em0 connected to one DSL connection on=20 192.168.1.2 and the default route set to 192.168.1.1 and em1 on the=20 other DSL connection with IP 192.168.2.2 and the router for that=20 connection on 192.168.2.1 Your question seemed to imply that you don't want to load-balance or=20 really even do round-robin NAT and you're fine with manually cutting=20 over the default route in case a link fails, but the problem you are=20 having is that the responses to incoming connections go out the=20 default route, which doesn't work. Here's the fix to that in PF: pass out route-to (em1 192.168.2.1) from 192.168.2.2 to any This will not do load-balancing, fail-over, or round-robin NAT, but it=20 will make replies to incoming connections on the 'other' DSL=20 connection go out the same interface the incoming connection came in=20 on with the proper source address. HTH =2D-=20 Thanks, Josh Paetzel --nextPart1524610.0FQksEAgMv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGliJPJvkB8SevrssRAuPkAKCMw3XgGhJqGS5nS3vFEAlGUVvTQQCcDN10 E8MayelichryIkROHSNyS4g= =kCvZ -----END PGP SIGNATURE----- --nextPart1524610.0FQksEAgMv-- From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 12:59:27 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E84816A421 for ; Thu, 12 Jul 2007 12:59:27 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [213.251.163.210]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5F913C468 for ; Thu, 12 Jul 2007 12:59:26 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (ip-83-134-208-129.dsl.scarlet.be [83.134.208.129]) by tignes.restart.be (8.13.8/8.13.8) with ESMTP id l6CCxO1s085353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jul 2007 14:59:25 +0200 (CEST) (envelope-from hlh@restart.be) Received: from morzine.restart.bel (morzine.restart.bel [192.168.24.2]) (authenticated bits=0) by restart.be (8.14.1/8.14.1) with ESMTP id l6CCxLrt046241; Thu, 12 Jul 2007 14:59:22 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1184245164; bh=Z16pfz3RD7PWpB6Bo4IVQ0t8nRk8YvUDL7QimcC 5MnQ=; h=DomainKey-Signature:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-Scanned-By; b=kWfpf60enm5 2Oh3RhyM2uaK62NPGw1OAWxIokbczJPozYT/AIZ0oWUQrC+4q2Jf/SvVjvNemGtE1ke 1muNryBw== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=mXqQNh60JBDGqACInQgQJW1NRVqV9JB6W2UzXC37hg6fNB4ypjsCOdbcj/hghsa9x /Jln5UevKTf9oqlMEdFTA== Message-ID: <469625A9.3070703@restart.be> Date: Thu, 12 Jul 2007 14:59:21 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.4 (X11/20070616) MIME-Version: 1.0 To: Andrea Venturoli References: <4695FEF4.4030708@netfence.it> In-Reply-To: <4695FEF4.4030708@netfence.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.61 on 192.168.24.1 Cc: freebsd-net@freebsd.org Subject: Re: Again two ADSL lines, routing problems 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, 12 Jul 2007 12:59:27 -0000 Andrea Venturoli wrote: > Hello. > I have a setup where a FreeBSD box is connected to two ADSL routers: > default gateway is set to the first and, in case of failure, is moved to > the other one. This works perfectly for outgoing connections: in the > event of the switch, I'll have to reconnect, but that's acceptable. > > The problem is in the incoming connections: if I get one on the "backup" > router, this will reach the server, which will however answer through > its "default" router. Thus the remote client will see packets coming > back from a different host and things won't work. > Just to be clear, the packets travel as follows (with source and dest IP > in brackets): > Client (x.x.x.x) -> Backup router (y.y.y.y) > Backup router (x.x.x.x) -> Server (z.z.z.z) > Server (z.z.z.z) -> Default router (x.x.x.x) > Default router (v.v.v.v) -> Client (x.x.x.x) > > So the client (x.x.x.x) connects to y.y.y.y (the backup ADSL public IP), > but gets answers from v.v.v.v (the master ADSL public IP). > > > AFAIK there is no solution to this, but I tought I'd ask before giving > my official opinion to my customer. > Perhaps there's some sort of hack we could use, that through > ipfw/natd/other diverting daemon/whatever delivers answers based on the > MAC address of the incoming connections (if the MAC address belongs to > the backup router, use that for answers)... does anyone know? I would propose a nat on the internal interface on the backup router for all incomming trafic -- with pf: nat on $int_if proto tcp from !192.168.0.0/16 to $internal_server -> $int_if so the internal server see trafic comming from the backup router and the response go back this way. Henri > > bye & Thanks > av. > _______________________________________________ > 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" From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 14:19:45 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F5AF16A400 for ; Thu, 12 Jul 2007 14:19:45 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id 5F37413C489 for ; Thu, 12 Jul 2007 14:19:43 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from [10.100.0.23] (vl-office.vl.net.ua [194.44.81.189]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l6CEJee5031046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jul 2007 17:19:41 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Message-ID: <4696387F.4080404@aws-net.org.ua> Date: Thu, 12 Jul 2007 17:19:43 +0300 From: Artyom Viklenko Organization: Art&Co. User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Andrea Venturoli References: <4695FEF4.4030708@netfence.it> <469616B2.2020803@aws-net.org.ua> <46961C0B.6060004@netfence.it> In-Reply-To: <46961C0B.6060004@netfence.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Thu, 12 Jul 2007 17:19:42 +0300 (EEST) X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on localhost X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: Again two ADSL lines, routing problems 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, 12 Jul 2007 14:19:45 -0000 Andrea Venturoli wrote: > Artyom Viklenko ha scritto: > >> You have to enforce simmetrical routing on your FreeBSD box. >> You can use, for example, PF firewall Using such options and features >> as labels and route-to/reply-to statemens. >> >> Also it is possible with ipfw, but I prefer PF. :) > > > Thanks, this is interesting. However I failed to understand what you > mean exactly. > Do you have any pointer to a document that explains this? > I searched in PF's and ipfw's manual, but found nothing that I could > relate to this. > > Also, I'm right now using ipfw... > > bye & Thanks > av. Very brief example (just to show main idea). Assume you have thre interfaces in router fxp0 - lan, fxp1 - adsl1, fxp2 - adsl2. fxp0 - 192.168.0.1, fxp1 - 192.168.1.2, fxp2 - 192.168.2.2 adsl1 - 192.168.1.1, adsl2 - 192.168.2.1 $server="192.168.0.2" $adsl1="192.168.1.1" $adsl2="192.168.2.1" pass in on fxp1 inet from any to $server keep state tag ADSL1 pass in on fxp2 inet from any to $server keep state tag ADSL2 pass out on fxp0 reply-to (fxp1 $adsl1) from any to $server tagged ADSL1 keep state pass out on fxp0 reply-to (fxp2 $adsl2) from any to $server tagged ADSL2 keep state This is just part of whole rulebase regarding your problem. Packets coming in via adsl1 will pass and got tagged by ADSL1 tag. Also, state will be created. Then packet will pass out to server, state will be created. and all replies from server will be frowarded back via adsl1. Same for traffic from adsl2. Also, see OpenBSD PF FAQ. Hope this helps. -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 16:08:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25D2016A46B for ; Thu, 12 Jul 2007 16:08:32 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id E75B413C48C for ; Thu, 12 Jul 2007 16:08:31 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 12 Jul 2007 09:03:41 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.13.1/8.12.11) with ESMTP id l6CG8Vqr002755; Thu, 12 Jul 2007 09:08:31 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.13.1/8.13.1/Submit) id l6CG8Sur002750; Thu, 12 Jul 2007 09:08:28 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200707121608.l6CG8Sur002750@ambrisko.com> In-Reply-To: <4695F4FD.2010102@tomjudge.com> To: Tom Judge Date: Thu, 12 Jul 2007 09:08:28 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: Josh Paetzel , freebsd-net@freebsd.org, Julian Elischer , Paul Schmehl Subject: Re: Question about bce driver 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, 12 Jul 2007 16:08:32 -0000 Tom Judge writes: | Julian Elischer wrote: | > Tom Judge wrote: | >> Josh Paetzel wrote: | >>> On Wednesday 11 July 2007, Tom Judge wrote: | >>>> Hi Paul, | >>>> | >>>> From the testing that I have been doing for the last few months | >>>> the driver in 6.2 is stable if you are not using jumbo frames and | >>>> there is a light-moderate network load. | >>>> | >>>> However if you want to use Jumbo frames the driver is very | >>>> unstable. I posted a patch against 6.2 which should fix some load | >>>> based issues in the driver with standard frame sizes. | >>>> | >>>> Tom | >>> | >>> Paul, I was never able to solve the link up/link down problems with | >>> the driver....I was using the drivers from STABLE for a while, and | >>> without jumbo frames everything worked somewhat ok most of the | >>> time....the ultimate solution was to just get the intel PCI-X card | >>> and stop using the broadcoms. | >>> | >>> | >> | >> We have basically come to the same conclusion today, unfortunately | >> this is 35 machines, but if it makes them stable at least we can use | >> them. | > | > I'm not seeing any problems on our 2950s running 6.1 plus some backpatches. | | I am very surprised at that. The driver in 6.1 was un-usable in our | environment. 6.2 makes it usable with standard frames under moderate | load. However use jumbo frames and it all falls apart, and unfortunately | the network these systems are plugged into is GigE only with a 8192 | Jumbo mtu. There are several back-ports/patches in our 6.1 image that we are running! Also we don't do jumbo packets. It wouldn't surprize me if there were jumbo packets issues. Other drivers have had issues with that at certain sizes. What Julian is really saying, is that for our work-load and version of the bce driver things are pretty darn stable. None of our patches are private and are from various versions that have been in -current etc. (ie. pre-Serdes support). There is one possibility in that our IPMI support might be ahead of what is in -current. I forget. IPMI WRT to Broadcom can be "tricky" and cause issues at the PHY level. | I have been trying to get some help with the problem for over a month | now without luck. Firstly I was asked to enable some debugging in the | driver, this just uncovered what seems to be memory management bug in | the driver. A patch was suggest for this but it did not solve the | problem. Next I noticed the NetBSD guys had we written the offending | parts of code which I then ported to FreeBSD driver. Still no luck, | although the problem was not as bad as before. Then I took a look at | the OpenBSD driver, and it seems that they just completely disabled | jumbo frames as they are just so ropey. | | If a patch was released today that fixed the problem then I may be able | to fully test the driver and not have to replace the NIC's. However I am | running out of time with deployment deadlines and I need this kit in | production by the latest mid next week. Which is reasonable unless you have the time to try to really dig in and try to isolate the problem with the firmware or the driver (ie. hack on the driver). Unfortunately you are blazing into uncharted teritory with the bce driver. David has done some great work getting it to work under FreeBSD in what looks to me as his spare time. Things are improving all of the time. Doug A. From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 16:41:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F05D16A400 for ; Thu, 12 Jul 2007 16:41:47 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog11.obsmtp.com (s200aog11.obsmtp.com [207.126.144.125]) by mx1.freebsd.org (Postfix) with SMTP id 33DF213C45B for ; Thu, 12 Jul 2007 16:41:39 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob011.postini.com ([207.126.147.11]) with SMTP; Thu, 12 Jul 2007 16:41:07 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 10D8318141B; Thu, 12 Jul 2007 17:41:07 +0100 (BST) Message-ID: <469657BD.3010204@tomjudge.com> Date: Thu, 12 Jul 2007 17:33:01 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Doug Ambrisko References: <200707121608.l6CG8Sur002750@ambrisko.com> In-Reply-To: <200707121608.l6CG8Sur002750@ambrisko.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Josh Paetzel , freebsd-net@freebsd.org, Julian Elischer , Paul Schmehl Subject: Re: Question about bce driver 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, 12 Jul 2007 16:41:47 -0000 Doug Ambrisko wrote: > Tom Judge writes: > | > | I am very surprised at that. The driver in 6.1 was un-usable in our > | environment. 6.2 makes it usable with standard frames under moderate > | load. However use jumbo frames and it all falls apart, and unfortunately > | the network these systems are plugged into is GigE only with a 8192 > | Jumbo mtu. > > There are several back-ports/patches in our 6.1 image that we are running! > Also we don't do jumbo packets. It wouldn't surprize me if there were > jumbo packets issues. Other drivers have had issues with that at > certain sizes. What Julian is really saying, is that for our work-load > and version of the bce driver things are pretty darn stable. None > of our patches are private and are from various versions that have been > in -current etc. (ie. pre-Serdes support). > > There is one possibility in that our IPMI support might be ahead of > what is in -current. I forget. IPMI WRT to Broadcom can be "tricky" > and cause issues at the PHY level. > > | I have been trying to get some help with the problem for over a month > | now without luck. Firstly I was asked to enable some debugging in the > | driver, this just uncovered what seems to be memory management bug in > | the driver. A patch was suggest for this but it did not solve the > | problem. Next I noticed the NetBSD guys had we written the offending > | parts of code which I then ported to FreeBSD driver. Still no luck, > | although the problem was not as bad as before. Then I took a look at > | the OpenBSD driver, and it seems that they just completely disabled > | jumbo frames as they are just so ropey. > | > | If a patch was released today that fixed the problem then I may be able > | to fully test the driver and not have to replace the NIC's. However I am > | running out of time with deployment deadlines and I need this kit in > | production by the latest mid next week. > > Which is reasonable unless you have the time to try to really dig in > and try to isolate the problem with the firmware or the driver (ie. hack > on the driver). Unfortunately you are blazing into uncharted teritory > with the bce driver. David has done some great work getting it to work > under FreeBSD in what looks to me as his spare time. Things are improving > all of the time. > > Doug A. Firstly I am not trying to slate David's efforts, however there are and have been some big problems with the driver. As for the IPMI integration, our management controllers are set to used the remote access controller NIC (Set as dedicated in the bios) rather than share the host nics. Unfortunately I can not justify spending the time on the driver to management when the problem can be solved by spending a relatively small amount of money on hardware to fix the problem. Tom From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 16:54:29 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B16AD16A46B for ; Thu, 12 Jul 2007 16:54:29 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (noop.in-addr.com [208.58.23.51]) by mx1.freebsd.org (Postfix) with ESMTP id 8412613C484 for ; Thu, 12 Jul 2007 16:54:29 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1I91vt-000Cxm-AF; Thu, 12 Jul 2007 12:54:25 -0400 Date: Thu, 12 Jul 2007 12:54:25 -0400 From: Gary Palmer To: Tom Judge Message-ID: <20070712165425.GC91325@in-addr.com> Mail-Followup-To: Tom Judge , Julian Elischer , Josh Paetzel , Paul Schmehl , freebsd-net@freebsd.org References: <4694940D.9050408@tomjudge.com> <200707111230.24975.josh@tcbug.org> <46956A44.3000304@tomjudge.com> <46958A55.4020704@elischer.org> <4695F4FD.2010102@tomjudge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4695F4FD.2010102@tomjudge.com> Cc: Josh Paetzel , freebsd-net@freebsd.org, Julian Elischer , Paul Schmehl Subject: Re: Question about bce driver 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, 12 Jul 2007 16:54:29 -0000 On Thu, Jul 12, 2007 at 10:31:41AM +0100, Tom Judge wrote: > Julian Elischer wrote: > >Tom Judge wrote: > >>Josh Paetzel wrote: > >>>On Wednesday 11 July 2007, Tom Judge wrote: > >>>>Hi Paul, > >>>> > >>>> From the testing that I have been doing for the last few months > >>>>the driver in 6.2 is stable if you are not using jumbo frames and > >>>>there is a light-moderate network load. > >>>> > >>>>However if you want to use Jumbo frames the driver is very > >>>>unstable. I posted a patch against 6.2 which should fix some load > >>>>based issues in the driver with standard frame sizes. > >>>> > >>>>Tom > >>> > >>>Paul, I was never able to solve the link up/link down problems with > >>>the driver....I was using the drivers from STABLE for a while, and > >>>without jumbo frames everything worked somewhat ok most of the > >>>time....the ultimate solution was to just get the intel PCI-X card > >>>and stop using the broadcoms. > >>> > >>> > >> > >>We have basically come to the same conclusion today, unfortunately > >>this is 35 machines, but if it makes them stable at least we can use > >>them. > > > >I'm not seeing any problems on our 2950s running 6.1 plus some backpatches. > I am very surprised at that. The driver in 6.1 was un-usable in our > environment. 6.2 makes it usable with standard frames under moderate > load. However use jumbo frames and it all falls apart, and unfortunately > the network these systems are plugged into is GigE only with a 8192 > Jumbo mtu. I wouldn't be surprised if you were running different rev motherboards. Although the Dell chassis/model number is the same, they frequently rev the motherboard without any externally visible changes. I'd be more surprised if you had the same mobo part number and PCI ID's for the Broadcom chips. Gary From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 18:08:53 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B370916A46E for ; Thu, 12 Jul 2007 18:08:53 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp806.mail.ird.yahoo.com (smtp806.mail.ird.yahoo.com [217.146.188.66]) by mx1.freebsd.org (Postfix) with SMTP id 2C05D13C4D0 for ; Thu, 12 Jul 2007 18:08:52 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 93191 invoked from network); 12 Jul 2007 18:08:51 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.139.149.183 with plain) by smtp806.mail.ird.yahoo.com with SMTP; 12 Jul 2007 18:08:51 -0000 X-YMail-OSG: _0_f0wUVM1lq2rk6Izqrhb5EzP4kcqBoKvP.SFCRu_tMcIUn Message-ID: <46967C68.7030904@tomjudge.com> Date: Thu, 12 Jul 2007 20:09:28 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Tom Judge , Julian Elischer , Josh Paetzel , Paul Schmehl , freebsd-net@freebsd.org References: <4694940D.9050408@tomjudge.com> <200707111230.24975.josh@tcbug.org> <46956A44.3000304@tomjudge.com> <46958A55.4020704@elischer.org> <4695F4FD.2010102@tomjudge.com> <20070712165425.GC91325@in-addr.com> In-Reply-To: <20070712165425.GC91325@in-addr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Question about bce driver 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, 12 Jul 2007 18:08:53 -0000 Gary Palmer wrote: > On Thu, Jul 12, 2007 at 10:31:41AM +0100, Tom Judge wrote: >> Julian Elischer wrote: >>> Tom Judge wrote: >>>> Josh Paetzel wrote: >>>>> On Wednesday 11 July 2007, Tom Judge wrote: >>>>>> Hi Paul, >>>>>> >>>>>> From the testing that I have been doing for the last few months >>>>>> the driver in 6.2 is stable if you are not using jumbo frames and >>>>>> there is a light-moderate network load. >>>>>> >>>>>> However if you want to use Jumbo frames the driver is very >>>>>> unstable. I posted a patch against 6.2 which should fix some load >>>>>> based issues in the driver with standard frame sizes. >>>>>> >>>>>> Tom >>>>> Paul, I was never able to solve the link up/link down problems with >>>>> the driver....I was using the drivers from STABLE for a while, and >>>>> without jumbo frames everything worked somewhat ok most of the >>>>> time....the ultimate solution was to just get the intel PCI-X card >>>>> and stop using the broadcoms. >>>>> >>>>> >>>> We have basically come to the same conclusion today, unfortunately >>>> this is 35 machines, but if it makes them stable at least we can use >>>> them. >>> I'm not seeing any problems on our 2950s running 6.1 plus some backpatches. > >> I am very surprised at that. The driver in 6.1 was un-usable in our >> environment. 6.2 makes it usable with standard frames under moderate >> load. However use jumbo frames and it all falls apart, and unfortunately >> the network these systems are plugged into is GigE only with a 8192 >> Jumbo mtu. > > I wouldn't be surprised if you were running different rev motherboards. > Although the Dell chassis/model number is the same, they frequently rev > the motherboard without any externally visible changes. I'd be more > surprised if you had the same mobo part number and PCI ID's for the > Broadcom chips. > > Gary I have systems with 2 different revisions of the broadcom chip on them, both revisions have show the same symptoms. Please see my posts in thread "Problems with BCE network adapter (Dell PE2950)" you will find full details of the chip revisions that I have tested with. Tom From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 18:34:39 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B2AD16A4EE for ; Thu, 12 Jul 2007 18:34:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outJ.internet-mail-service.net (outJ.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id 754F213C4E3 for ; Thu, 12 Jul 2007 18:34:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 12 Jul 2007 11:34:39 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 84058125AE3; Thu, 12 Jul 2007 11:34:38 -0700 (PDT) Message-ID: <4696744F.20508@elischer.org> Date: Thu, 12 Jul 2007 11:34:55 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Tom Judge References: <4694940D.9050408@tomjudge.com> <200707111230.24975.josh@tcbug.org> <46956A44.3000304@tomjudge.com> <46958A55.4020704@elischer.org> <4695F4FD.2010102@tomjudge.com> In-Reply-To: <4695F4FD.2010102@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Josh Paetzel , Paul Schmehl , freebsd-net@freebsd.org Subject: Re: Question about bce driver 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, 12 Jul 2007 18:34:39 -0000 Tom Judge wrote: > Julian Elischer wrote: >> Tom Judge wrote: >>> Josh Paetzel wrote: >>>> On Wednesday 11 July 2007, Tom Judge wrote: >>>>> Hi Paul, >>>>> >>>>> From the testing that I have been doing for the last few months >>>>> the driver in 6.2 is stable if you are not using jumbo frames and >>>>> there is a light-moderate network load. >>>>> >>>>> However if you want to use Jumbo frames the driver is very >>>>> unstable. I posted a patch against 6.2 which should fix some load >>>>> based issues in the driver with standard frame sizes. >>>>> >>>>> Tom >>>> >>>> Paul, I was never able to solve the link up/link down problems with >>>> the driver....I was using the drivers from STABLE for a while, and >>>> without jumbo frames everything worked somewhat ok most of the >>>> time....the ultimate solution was to just get the intel PCI-X card >>>> and stop using the broadcoms. >>>> >>>> >>> >>> We have basically come to the same conclusion today, unfortunately >>> this is 35 machines, but if it makes them stable at least we can use >>> them. >> >> I'm not seeing any problems on our 2950s running 6.1 plus some >> backpatches. >> > I am very surprised at that. The driver in 6.1 was un-usable in our > environment. note "plus some backpatches". Doug Ambrisko moved us up to somewhere around 6.2 > 6.2 makes it usable with standard frames under moderate > load. However use jumbo frames and it all falls apart, and unfortunately > the network these systems are plugged into is GigE only with a 8192 > Jumbo mtu. > > I have been trying to get some help with the problem for over a month > now without luck. Firstly I was asked to enable some debugging in the > driver, this just uncovered what seems to be memory management bug in > the driver. A patch was suggest for this but it did not solve the > problem. Next I noticed the NetBSD guys had we written the offending > parts of code which I then ported to FreeBSD driver. Still no luck, > although the problem was not as bad as before. Then I took a look at > the OpenBSD driver, and it seems that they just completely disabled > jumbo frames as they are just so ropey. > > If a patch was released today that fixed the problem then I may be able > to fully test the driver and not have to replace the NIC's. However I am > running out of time with deployment deadlines and I need this kit in > production by the latest mid next week. > > Tom From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 19:11:35 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9927C16A421 for ; Thu, 12 Jul 2007 19:11:35 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from smtp1.yandex.ru (smtp1.yandex.ru [213.180.223.87]) by mx1.freebsd.org (Postfix) with ESMTP id DE9ED13C483 for ; Thu, 12 Jul 2007 19:11:34 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from 248-0-5-195.pool.ukrtel.net ([195.5.0.248]:21773 "EHLO 248-0-5-195.pool.ukrtel.net" smtp-auth: "kes-kes" TLS-CIPHER: TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S8372588AbXGLSJ3 (ORCPT ); Thu, 12 Jul 2007 22:09:29 +0400 X-Comment: RFC 2476 MSA function at smtp1.yandex.ru logged sender identity as: kes-kes Date: Thu, 12 Jul 2007 21:09:29 +0300 From: KES X-Mailer: The Bat! (v3.80.06) Professional Organization: SaftTen X-Priority: 3 (Normal) Message-ID: <1235762993.20070712210929@yandex.ru> To: freebsd-net@freebsd.org In-Reply-To: <44FCD6E2.50501@dellroad.org> References: <1957744731.20060902204653@yandex.ru> <44FCD6E2.50501@dellroad.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Subject: Fwd: Re: NEW IDEAS (NETGRAPH) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KES List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 19:11:35 -0000 Çäðàâñòâóéòå, . ---------- Ïåðåñûëàåìîå ïèñüìî ---------- Îò: Archie Cobbs Ê: KES À òàêæå ê: Âðåìÿ ñîçäàíèÿ: Mon, 04 Sep 2006 20:46:10 -0500 Òåìà: NEW IDEAS (NETGRAPH) Ïðèêðåïëåííûå ôàéëû: KES wrote: > Hello, archie. > > How about 'ALTQ' node? or may be 'queue' node > for packets scheduling > > in--->|policy|--->out > > policy may be CBQ, PRIO, HFSC or HTB.... > > I want this: > > in-->HTB-->out - - - in-->PRIO-->out Sounds neat.. ask around on freebsd-net@freebsd.org as there may be others interested, etc. Cheers, -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com ---------- Êîíåö ïåðåñûëàåìîãî ïèñüìà ---------- -- Ñ óâàæåíèåì, KES mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 19:17:58 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 343F916A468 for ; Thu, 12 Jul 2007 19:17:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outA.internet-mail-service.net (outA.internet-mail-service.net [216.240.47.224]) by mx1.freebsd.org (Postfix) with ESMTP id 2155C13C4B9 for ; Thu, 12 Jul 2007 19:17:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 12 Jul 2007 12:17:57 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id A7539125ADA; Thu, 12 Jul 2007 12:17:57 -0700 (PDT) Message-ID: <46967E76.4010702@elischer.org> Date: Thu, 12 Jul 2007 12:18:14 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Andrea Venturoli References: <4695FEF4.4030708@netfence.it> In-Reply-To: <4695FEF4.4030708@netfence.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Again two ADSL lines, routing problems 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, 12 Jul 2007 19:17:58 -0000 Andrea Venturoli wrote: > Hello. > I have a setup where a FreeBSD box is connected to two ADSL routers: > default gateway is set to the first and, in case of failure, is moved to > the other one. This works perfectly for outgoing connections: in the > event of the switch, I'll have to reconnect, but that's acceptable. > > The problem is in the incoming connections: if I get one on the "backup" > router, this will reach the server, which will however answer through > its "default" router. Thus the remote client will see packets coming > back from a different host and things won't work. > Just to be clear, the packets travel as follows (with source and dest IP > in brackets): > Client (x.x.x.x) -> Backup router (y.y.y.y) > Backup router (x.x.x.x) -> Server (z.z.z.z) > Server (z.z.z.z) -> Default router (x.x.x.x) > Default router (v.v.v.v) -> Client (x.x.x.x) > > So the client (x.x.x.x) connects to y.y.y.y (the backup ADSL public IP), > but gets answers from v.v.v.v (the master ADSL public IP). > > > AFAIK there is no solution to this, but I tought I'd ask before giving > my official opinion to my customer. > Perhaps there's some sort of hack we could use, that through > ipfw/natd/other diverting daemon/whatever delivers answers based on the > MAC address of the incoming connections (if the MAC address belongs to > the backup router, use that for answers)... does anyone know? > I have done this successfully as follows: firstly, you need to have NAT on Both interfaces, This ensures that from the point of view of the two ISPs each sees packets coming from the address they assigned you, even if they originate from machines in your local network. Then you need a way to allocate each session to one or the other of the links. The plain old routing table can do this. If you want to select which route to use according to SOURCE address (client) then you can use the 'fwd' command in ipfw, together with the skipto command to achieve this.. you need to make the decision as to which link you are going to use, and skipto the correct NAT rule and then the correct 'fwd' rule. (The packet will continue in the firewall after NAT so that it can then hit the FWD, but a FWD is termainal so you can't do it the other way around.. (hmmm, unless you do the fwd on incoming packets (on the inside interface)... does that work?) When one link dies you just switch he routing table as needed. (of course sessions pre-existing on the dead link will not survive but there isn't much you can do about that unles you tunnel to a third location.. > bye & Thanks > av. > _______________________________________________ > 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" From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 19:19:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06E8D16A41F for ; Thu, 12 Jul 2007 19:19:28 +0000 (UTC) (envelope-from ml@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id 3E4D513C46C for ; Thu, 12 Jul 2007 19:19:27 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.ventu ([151.77.235.121]) (authenticated bits=128) by parrot.aev.net (8.14.1/8.13.8) with ESMTP id l6CJVJFo031024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Jul 2007 21:31:25 +0200 (CEST) (envelope-from ml@netfence.it) Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.1/8.13.8) with ESMTP id l6CJK4I5010469; Thu, 12 Jul 2007 21:20:05 +0200 (CEST) (envelope-from ml@netfence.it) Message-ID: <46967EB1.9050405@netfence.it> Date: Thu, 12 Jul 2007 21:19:13 +0200 From: Andrea Venturoli User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: Josh Paetzel References: <4695FEF4.4030708@netfence.it> <469616B2.2020803@aws-net.org.ua> <46961C0B.6060004@netfence.it> <200707120745.03102.josh@tcbug.org> In-Reply-To: <200707120745.03102.josh@tcbug.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.61 on 212.31.247.179 Cc: freebsd-net@freebsd.org Subject: Re: Again two ADSL lines, routing problems 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, 12 Jul 2007 19:19:28 -0000 Josh Paetzel ha scritto: > errrm, in pf I can give you a concrete example of how to deal with > this. Thank you very much. Please see also my reply to Artyom. > Your question seemed to imply that you don't want to load-balance or > really even do round-robin NAT and you're fine with manually cutting > over the default route in case a link fails, but the problem you are > having is that the responses to incoming connections go out the > default route, which doesn't work. Yes, this is the main problem. I might be interested in load-balance, but it's much less important. Besides, what I described is part of a larger setup, so this is already partly implemented. bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 19:35:58 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D759216A468 for ; Thu, 12 Jul 2007 19:35:58 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpauth03.prod.mesa1.secureserver.net (smtpauth03.prod.mesa1.secureserver.net [64.202.165.183]) by mx1.freebsd.org (Postfix) with SMTP id 8B52013C4C1 for ; Thu, 12 Jul 2007 19:35:58 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 468 invoked from network); 12 Jul 2007 19:09:17 -0000 Received: from unknown (24.144.77.243) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 12 Jul 2007 19:09:17 -0000 Message-ID: <46967C5C.5040505@seclark.us> Date: Thu, 12 Jul 2007 15:09:16 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 19:35:58 -0000 Hello, Did something change in 6.2? If my mtu size on rl0 is 1280 it won't accept a larger incomming packet. kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max 1294) I don't think it worked this way in the past. Won't this affect pmtud? man page for ifconfig says mtu limits size of "transmission" not reception. "mtu n Set the maximum transmission unit of the interface to n, default is interface specific." TIA, 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 Thu Jul 12 20:01:51 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5EFA16A468 for ; Thu, 12 Jul 2007 20:01:51 +0000 (UTC) (envelope-from ml@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA2813C46E for ; Thu, 12 Jul 2007 20:01:50 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.ventu ([151.77.235.121]) (authenticated bits=128) by parrot.aev.net (8.14.1/8.13.8) with ESMTP id l6CKDijA036501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Jul 2007 22:13:50 +0200 (CEST) (envelope-from ml@netfence.it) Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.1/8.13.8) with ESMTP id l6CK2TvA018315; Thu, 12 Jul 2007 22:02:30 +0200 (CEST) (envelope-from ml@netfence.it) Message-ID: <469688A2.3000708@netfence.it> Date: Thu, 12 Jul 2007 22:01:38 +0200 From: Andrea Venturoli User-Agent: Thunderbird 2.0.0.4 (X11/20070617) MIME-Version: 1.0 To: Artyom Viklenko References: <4695FEF4.4030708@netfence.it> <469616B2.2020803@aws-net.org.ua> <46961C0B.6060004@netfence.it> <4696387F.4080404@aws-net.org.ua> In-Reply-To: <4696387F.4080404@aws-net.org.ua> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.61 on 212.31.247.179 Cc: freebsd-net@freebsd.org Subject: Re: Again two ADSL lines, routing problems 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, 12 Jul 2007 20:01:52 -0000 Artyom Viklenko ha scritto: > Very brief example (just to show main idea). > Assume you have thre interfaces in router fxp0 - lan, fxp1 - adsl1, fxp2 > - adsl2. > fxp0 - 192.168.0.1, fxp1 - 192.168.1.2, fxp2 - 192.168.2.2 > adsl1 - 192.168.1.1, adsl2 - 192.168.2.1 > > > > $server="192.168.0.2" > $adsl1="192.168.1.1" > $adsl2="192.168.2.1" > > pass in on fxp1 inet from any to $server keep state tag ADSL1 > pass in on fxp2 inet from any to $server keep state tag ADSL2 > > pass out on fxp0 reply-to (fxp1 $adsl1) from any to $server tagged ADSL1 > keep state > pass out on fxp0 reply-to (fxp2 $adsl2) from any to $server tagged ADSL2 > keep state > > This is just part of whole rulebase regarding your problem. > Packets coming in via adsl1 will pass and got tagged by ADSL1 tag. Also, > state will > be created. Then packet will pass out to server, state will be created. > and all replies from server will be frowarded back via adsl1. > > Same for traffic from adsl2. Thank you very much, this might do the trick. However, in your example the two ADSL routers are on separate interfaces, while in the setup I have there's only one external interface (and a switch). Would this work the same, by tagging based on MAC address? Even if the machine is not acting as a bridge? Should I create a bridge0 interface, even if it would actually not bridge anything? Besides, I don't really understand what fxp0 has to do with this: the box which is connected to the two ADSL is running the server, so in the above example $server would be 192.168.0.1 itself. If I understand correctly I should do something on the line of: $adsl1="192.168.0.1" $adsl1mac="aa:bb:cc:dd:ee:ff" $adsl2="192.168.0.2" $adsl2mac="gg:hh:ii:jj:kk:ll" //Tag based on MAC address pass in on fxp0 reply-to (fxp0 $adsl1) inet from any to $server tagged ADSL1 keep state pass in on fxp0 reply-to (fxp0 $adsl2) inet from any to $server tagged ADSL2 keep state One last question: could I use this, while still filtering with ipfw as I do now? Can the two firewalls cooperate? Would this be too much trouble (even if I have a non trivial ruleset working)? Someone can suggest a way with ipfw? I found this: http://archive.netbsd.se/?ml=dfbsd-users&a=2005-10&t=1361976 (the last message). It would involve creating a second net on the same ethernet segment, but I can live with that (altough it is going to be slightly more compilcated since I'm also using CARP). Any opinion on this? bye & Thanks av. bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 22:10:59 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 04CFE16A46C for ; Thu, 12 Jul 2007 22:10:59 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.freebsd.org (Postfix) with ESMTP id D208813C459 for ; Thu, 12 Jul 2007 22:10:58 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 12 Jul 2007 15:10:46 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id C3B952AF; Thu, 12 Jul 2007 15:10:46 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 91D742AF; Thu, 12 Jul 2007 15:10:46 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FLT19823; Thu, 12 Jul 2007 15:10:36 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id A621569CA5; Thu, 12 Jul 2007 15:10:36 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jul 2007 15:10:31 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD9030477CD0F@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <469657BD.3010204@tomjudge.com> Thread-Topic: Question about bce driver Thread-Index: AcfEpL6Te5ll8LFxQKKVVTPbyotsmgAK79KA References: <200707121608.l6CG8Sur002750@ambrisko.com> <469657BD.3010204@tomjudge.com> From: "David Christensen" To: "Tom Judge" , "Doug Ambrisko" X-WSS-ID: 6A88796C1S84457260-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Josh Paetzel , Paul Schmehl , Julian Elischer , freebsd-net@freebsd.org Subject: RE: Question about bce driver 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, 12 Jul 2007 22:10:59 -0000 > Firstly I am not trying to slate David's efforts, however=20 > there are and=20 > have been some big problems with the driver. >=20 > As for the IPMI integration, our management controllers are=20 > set to used=20 > the remote access controller NIC (Set as dedicated in the=20 > bios) rather=20 > than share the host nics. >=20 > Unfortunately I can not justify spending the time on the driver to=20 > management when the problem can be solved by spending a=20 > relatively small=20 > amount of money on hardware to fix the problem. >=20 I'm sorry I haven't been able to get to the root of your problems Tom. My biggest challenge is trying to duplicate the a loaded system which seems to be an important component of the failure you're seeing. Simply blasting traffic with netperf hasn't been much of a challenge as it runs over the weekend at line rate without a hiccup. If anyone has an idea on how to load the system (which means regular failures by the driver to allocate mbufs) I'd definitely appreciate hearing it so that I can duplicate Tom's environment. It's certainly important to me that the driver perform well and I won't stop looking at the problem if you do decide to jump ship. Dave From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 22:42:19 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1407A16A400 for ; Thu, 12 Jul 2007 22:42:19 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from smtp3.utdallas.edu (smtp3.utdallas.edu [129.110.10.49]) by mx1.freebsd.org (Postfix) with ESMTP id DE04A13C458 for ; Thu, 12 Jul 2007 22:42:18 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from utd59514.utdallas.edu (utd59514.utdallas.edu [129.110.3.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTP id 77C66654FF; Thu, 12 Jul 2007 17:42:18 -0500 (CDT) Date: Thu, 12 Jul 2007 17:42:18 -0500 From: Paul Schmehl To: David Christensen , freebsd-net@freebsd.org Message-ID: <48951B1B7222BB1512D27F8D@utd59514.utdallas.edu> In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD9030477CD0F@NT-IRVA-0750.brcm.ad.broadcom.com> References: <200707121608.l6CG8Sur002750@ambrisko.com> <469657BD.3010204@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030477CD0F@NT-IRVA-0750.brcm.ad.broadcom.com> X-Mailer: Mulberry/4.0.6 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========A51267AC8F0E5A76FF77==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: Question about bce driver 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, 12 Jul 2007 22:42:19 -0000 --==========A51267AC8F0E5A76FF77========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Thursday, July 12, 2007 15:10:31 -0700 David Christensen=20 wrote: > > I'm sorry I haven't been able to get to the root of your problems > Tom. My biggest challenge is trying to duplicate the a loaded system > which seems to be an important component of the failure you're seeing. > Simply blasting traffic with netperf hasn't been much of a challenge > as it runs over the weekend at line rate without a hiccup. If > anyone has an idea on how to load the system (which means regular > failures by the driver to allocate mbufs) I'd definitely appreciate > hearing it so that I can duplicate Tom's environment. It's certainly > important to me that the driver perform well and I won't stop looking > at the problem if you do decide to jump ship. > Dave, perhaps you could answer my question? I'm using the 0.9.6 driver with 6.1 RELEASE. I don't use jumbo frames, so=20 the only problem I've experienced is the link state going up and down=20 occasionally. Does the more current driver solve the link state problem? If it does, can = I use it on 6.1 merely by replacing the three files included with it? Or=20 are there includes that refer to other libraries that have changed since=20 6.1? Am I better off upgrading the entire system to 6.2? (I prefer not to do=20 this, because I have to take the site down to do so. Patching files and=20 rebuilding world and kernel only takes the box out of service during the=20 reboots. --=20 Paul Schmehl (pauls@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --==========A51267AC8F0E5A76FF77==========-- From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 23:11:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DE7716A468 for ; Thu, 12 Jul 2007 23:11:23 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id 442B513C4C8 for ; Thu, 12 Jul 2007 23:11:22 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 12 Jul 2007 16:11:13 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 88AC12AF; Thu, 12 Jul 2007 16:11:13 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 73F252AE; Thu, 12 Jul 2007 16:11:13 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FLT30000; Thu, 12 Jul 2007 16:11:12 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 424FE69CAB; Thu, 12 Jul 2007 16:11:12 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jul 2007 16:11:11 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD9030477CD64@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <48951B1B7222BB1512D27F8D@utd59514.utdallas.edu> Thread-Topic: Question about bce driver Thread-Index: AcfE1e8cOExUkxH0Q0qAkmSMxf+1fgAA3/+Q References: <200707121608.l6CG8Sur002750@ambrisko.com> <469657BD.3010204@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030477CD0F@NT-IRVA-0750.brcm.ad.broadcom.com> <48951B1B7222BB1512D27F8D@utd59514.utdallas.edu> From: "David Christensen" To: "Paul Schmehl" , freebsd-net@freebsd.org X-WSS-ID: 6A886A9B3DG7380677-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: Question about bce driver 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, 12 Jul 2007 23:11:23 -0000 > Dave, perhaps you could answer my question? >=20 > I'm using the 0.9.6 driver with 6.1 RELEASE. I don't use=20 > jumbo frames, so=20 > the only problem I've experienced is the link state going up and down=20 > occasionally. >=20 > Does the more current driver solve the link state problem? =20 > If it does, can=20 > I use it on 6.1 merely by replacing the three files included=20 > with it? Or=20 > are there includes that refer to other libraries that have=20 > changed since=20 > 6.1? >=20 > Am I better off upgrading the entire system to 6.2? (I=20 > prefer not to do=20 > this, because I have to take the site down to do so. =20 > Patching files and=20 > rebuilding world and kernel only takes the box out of service=20 > during the=20 > reboots. I've never seen the link up/down problem myself, so I don't know if any changes I've made have an effect on it. You would need to change more than the bce driver since it depends upon the brgphy driver under sys/dev/mii which would also need to change. There may be other dependencies upon changes in the 6.2 kernel which would prevent a quick/easy port without some debugging. =20 Dave From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 23:24:00 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B28616A41F for ; Thu, 12 Jul 2007 23:24:00 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from smtp3.utdallas.edu (smtp3.utdallas.edu [129.110.10.49]) by mx1.freebsd.org (Postfix) with ESMTP id 0A7FD13C43E for ; Thu, 12 Jul 2007 23:24:00 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from utd59514.utdallas.edu (utd59514.utdallas.edu [129.110.3.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTP id 97585654FF; Thu, 12 Jul 2007 18:23:59 -0500 (CDT) Date: Thu, 12 Jul 2007 18:23:59 -0500 From: Paul Schmehl To: David Christensen , freebsd-net@freebsd.org Message-ID: In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD9030477CD64@NT-IRVA-0750.brcm.ad.broadcom.com> References: <200707121608.l6CG8Sur002750@ambrisko.com> <469657BD.3010204@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030477CD0F@NT-IRVA-0750.brcm.ad.broadcom.com> <48951B1B7222BB1512D27F8D@utd59514.utdallas.edu> <09BFF2FA5EAB4A45B6655E151BBDD9030477CD64@NT-IRVA-0750.brcm.ad.broadcom.com> X-Mailer: Mulberry/4.0.6 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========3ECBE2EF37E2D349828C==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: Question about bce driver 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, 12 Jul 2007 23:24:00 -0000 --==========3ECBE2EF37E2D349828C========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Thursday, July 12, 2007 16:11:11 -0700 David Christensen=20 wrote: >> Dave, perhaps you could answer my question? >> >> I'm using the 0.9.6 driver with 6.1 RELEASE. I don't use >> jumbo frames, so >> the only problem I've experienced is the link state going up and down >> occasionally. >> >> Does the more current driver solve the link state problem? >> If it does, can >> I use it on 6.1 merely by replacing the three files included >> with it? Or >> are there includes that refer to other libraries that have >> changed since >> 6.1? >> >> Am I better off upgrading the entire system to 6.2? (I >> prefer not to do >> this, because I have to take the site down to do so. >> Patching files and >> rebuilding world and kernel only takes the box out of service >> during the >> reboots. > > I've never seen the link up/down problem myself, so I don't know > if any changes I've made have an effect on it. You would need to > change more than the bce driver since it depends upon the brgphy > driver under sys/dev/mii which would also need to change. There > may be other dependencies upon changes in the 6.2 kernel which > would prevent a quick/easy port without some debugging. > > Dave > Thanks for the quick answer. --=20 Paul Schmehl (pauls@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --==========3ECBE2EF37E2D349828C==========-- From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 23:50:09 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A50A16A476; Thu, 12 Jul 2007 23:50:09 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.freebsd.org (Postfix) with ESMTP id 6E06713C459; Thu, 12 Jul 2007 23:50:09 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from 185.32.61.10.in-addr.arpa.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l6CNnpDr025898; Thu, 12 Jul 2007 16:49:51 -0700 (PDT) Date: Thu, 12 Jul 2007 16:49:37 -0700 Message-ID: From: gnn@freebsd.org To: "Peter Blok" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.95 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current@freebsd.org, net@freebsd.org Subject: Re: FAST_IPSEC is now IPSEC, please be advised... 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, 12 Jul 2007 23:50:09 -0000 At Wed, 11 Jul 2007 13:49:37 +0200, Peter Blok wrote: > > Hi George, > > Is somebody looking at ipsec-tools? As far as I can see it requires a > lot of kame definitions, although not used most of the times. I have > tried to make sense of this, but it wasn't easy. I am not right now, if you have interest and or patches I (we) would love to see them. Thanks, George From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 04:15:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93CFE16A401 for ; Fri, 13 Jul 2007 04:15:10 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id 6628013C481 for ; Fri, 13 Jul 2007 04:15:08 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [192.168.32.253]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l6D4F5Ep076760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 07:15:06 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Date: Fri, 13 Jul 2007 07:15:00 +0300 (EEST) From: Artyom Viklenko To: Andrea Venturoli In-Reply-To: <469688A2.3000708@netfence.it> Message-ID: <20070713065254.K76503@alf.aws-net.org.ua> References: <4695FEF4.4030708@netfence.it> <469616B2.2020803@aws-net.org.ua> <46961C0B.6060004@netfence.it> <4696387F.4080404@aws-net.org.ua> <469688A2.3000708@netfence.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Fri, 13 Jul 2007 07:15:06 +0300 (EEST) X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on localhost X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: Again two ADSL lines, routing problems 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, 13 Jul 2007 04:15:10 -0000 On Thu, 12 Jul 2007, Andrea Venturoli wrote: > Artyom Viklenko ha scritto: > >> Very brief example (just to show main idea). >> Assume you have thre interfaces in router fxp0 - lan, fxp1 - adsl1, fxp2 - >> adsl2. >> fxp0 - 192.168.0.1, fxp1 - 192.168.1.2, fxp2 - 192.168.2.2 >> adsl1 - 192.168.1.1, adsl2 - 192.168.2.1 >> >> >> >> $server="192.168.0.2" >> $adsl1="192.168.1.1" >> $adsl2="192.168.2.1" >> >> pass in on fxp1 inet from any to $server keep state tag ADSL1 >> pass in on fxp2 inet from any to $server keep state tag ADSL2 >> >> pass out on fxp0 reply-to (fxp1 $adsl1) from any to $server tagged ADSL1 >> keep state >> pass out on fxp0 reply-to (fxp2 $adsl2) from any to $server tagged ADSL2 >> keep state >> >> This is just part of whole rulebase regarding your problem. >> Packets coming in via adsl1 will pass and got tagged by ADSL1 tag. Also, >> state will >> be created. Then packet will pass out to server, state will be created. and >> all replies from server will be frowarded back via adsl1. >> >> Same for traffic from adsl2. > > Thank you very much, this might do the trick. > However, in your example the two ADSL routers are on separate interfaces, > while in the setup I have there's only one external interface (and a switch). > Would this work the same, by tagging based on MAC address? > Even if the machine is not acting as a bridge? > Should I create a bridge0 interface, even if it would actually not bridge > anything? > > Besides, I don't really understand what fxp0 has to do with this: the box > which is connected to the two ADSL is running the server, so in the above > example $server would be 192.168.0.1 itself. > If I understand correctly I should do something on the line of: > > > $adsl1="192.168.0.1" > $adsl1mac="aa:bb:cc:dd:ee:ff" > $adsl2="192.168.0.2" > $adsl2mac="gg:hh:ii:jj:kk:ll" > //Tag based on MAC address Unfortunately, PF does not work with layer 2 data like MAC addresses. > pass in on fxp0 reply-to (fxp0 $adsl1) inet from any to $server tagged ADSL1 > keep state > pass in on fxp0 reply-to (fxp0 $adsl2) inet from any to $server tagged ADSL2 > keep state This should work. Also, is is possible to set up two aliases on FreeBSD box for server and redurect connections from adsl routers to different addresses on it. And then route back packets from server to adsl routers based on ip. > > > > One last question: could I use this, while still filtering with ipfw as I do > now? Can the two firewalls cooperate? > Would this be too much trouble (even if I have a non trivial ruleset > working)? While it is possible to use two firewalls on the same system, I won't recommend to do so until you have some special requirements in layer 2 filtering. E.g. if you need to filter some cleints based on their MAC address. IPFW alone also can do what you want. PF way just more elegant. :) You have yo deside how would you differentiate packets going back from your server. If you have two incoming interfaces it is much simpler. If you have managed switch, you can create separate VLAN for each ADSL and two vlan interfaces on FreeBSD. You can do this even with dumb unmanaged swich. Or use two ip addresses on server. > > > > Someone can suggest a way with ipfw? > I found this: http://archive.netbsd.se/?ml=dfbsd-users&a=2005-10&t=1361976 > (the last message). > It would involve creating a second net on the same ethernet segment, but I > can live with that (altough it is going to be slightly more compilcated since > I'm also using CARP). > Any opinion on this? > -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 05:45:07 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B786416A401; Fri, 13 Jul 2007 05:45:07 +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 6E9B213C478; Fri, 13 Jul 2007 05:45:07 +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 EA3D641C5AD; Fri, 13 Jul 2007 07:45:05 +0200 (CEST) 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 BtMuXvm94yHG; Fri, 13 Jul 2007 07:45:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 7B31741C5AC; Fri, 13 Jul 2007 07:45:05 +0200 (CEST) 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 BFF21444885; Fri, 13 Jul 2007 05:41:04 +0000 (UTC) Date: Fri, 13 Jul 2007 05:41:04 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: "George V. Neville-Neil" In-Reply-To: Message-ID: <20070713053534.D31116@maildrop.int.zabbadoz.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Peter Blok , FreeBSD current mailing list , net@freebsd.org Subject: Re: FAST_IPSEC is now IPSEC, please be advised... 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, 13 Jul 2007 05:45:07 -0000 On Thu, 12 Jul 2007, gnn@freebsd.org wrote: Morning, > At Wed, 11 Jul 2007 13:49:37 +0200, > Peter Blok wrote: >> >> Hi George, >> >> Is somebody looking at ipsec-tools? As far as I can see it requires a >> lot of kame definitions, although not used most of the times. I have >> tried to make sense of this, but it wasn't easy. > > I am not right now, if you have interest and or patches I (we) would > love to see them. I have a preliminary hackish patch. The problem is that I have other patches in there as well. I'll have to disunite them. I was hoping that ipsec-tools would release earlier so that the gcc4 compile issues would have been solved already only leaving us with the directory changes for the #inlcude files... /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 07:26:59 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABD9E16A402 for ; Fri, 13 Jul 2007 07:26:59 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5F56613C4A7 for ; Fri, 13 Jul 2007 07:26:59 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 9810A3F1F; Fri, 13 Jul 2007 09:26:57 +0200 (CEST) Date: Fri, 13 Jul 2007 09:26:57 +0200 From: VANHULLEBUS Yvan To: "Bjoern A. Zeeb" Message-ID: <20070713072657.GA13945@zen.inc> References: <20070713053534.D31116@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713053534.D31116@maildrop.int.zabbadoz.net> User-Agent: All mail clients suck. This one just sucks less. Cc: "George V. Neville-Neil" , Peter Blok , FreeBSD current mailing list , net@freebsd.org Subject: Re: FAST_IPSEC is now IPSEC, please be advised... 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, 13 Jul 2007 07:26:59 -0000 On Fri, Jul 13, 2007 at 05:41:04AM +0000, Bjoern A. Zeeb wrote: > On Thu, 12 Jul 2007, gnn@freebsd.org wrote: > >At Wed, 11 Jul 2007 13:49:37 +0200, > >Peter Blok wrote: Hi all. [KAME's IPSec removal and ipsec-tools] > I have a preliminary hackish patch. The problem is that I have other > patches in there as well. I'll have to disunite them. > > I was hoping that ipsec-tools would release earlier so that the gcc4 > compile issues would have been solved already only leaving us with the > directory changes for the #inlcude files... Ipsec-tools 0.7.0 Release (which includes gcc4 fixes) should have been released this week. We did NOT release it until now for various reasons, including the fact that I hoped we could fix this include problem for 0.7.0 release. But if it is quite simple to fix for -HEAD, which now only have netipsec/ipsec.h, it is harder to solve cleanly for older versions, which have both netinet6/ipsec.h and netipsec/ipsec.h, and on which I just don't know how to guess which one we should use. I think I'll commit today a patch to detect the case where we only have netipsec/ipsec.h (so it will compile again on -HEAD), and we'll keep the netinet6/ipsec.h Vs netipsec/ipsec.h problem as an open issue until someone gives me a clean way to decide which one we should use when we found both. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 08:00:07 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 453BA16A400 for ; Fri, 13 Jul 2007 08:00:07 +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 00C6013C4A5 for ; Fri, 13 Jul 2007 08:00:06 +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 898D441C5BC; Fri, 13 Jul 2007 10:00:05 +0200 (CEST) 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 mbMwyyBUve-u; Fri, 13 Jul 2007 10:00:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 2DC3641C5B0; Fri, 13 Jul 2007 10:00:05 +0200 (CEST) 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 0A7E9444885; Fri, 13 Jul 2007 07:55:14 +0000 (UTC) Date: Fri, 13 Jul 2007 07:55:14 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: net@freebsd.org In-Reply-To: <20070713072657.GA13945@zen.inc> Message-ID: <20070713074530.A31116@maildrop.int.zabbadoz.net> References: <20070713053534.D31116@maildrop.int.zabbadoz.net> <20070713072657.GA13945@zen.inc> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: VANHULLEBUS Yvan Subject: Re: FAST_IPSEC is now IPSEC, please be advised... 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, 13 Jul 2007 08:00:07 -0000 On Fri, 13 Jul 2007, VANHULLEBUS Yvan wrote: (taking the thread to net@ only as it does not affect current@ but is more a port@ thing) > On Fri, Jul 13, 2007 at 05:41:04AM +0000, Bjoern A. Zeeb wrote: >> On Thu, 12 Jul 2007, gnn@freebsd.org wrote: >>> At Wed, 11 Jul 2007 13:49:37 +0200, >>> Peter Blok wrote: > > Hi all. > > [KAME's IPSec removal and ipsec-tools] >> I have a preliminary hackish patch. The problem is that I have other >> patches in there as well. I'll have to disunite them. >> >> I was hoping that ipsec-tools would release earlier so that the gcc4 >> compile issues would have been solved already only leaving us with the >> directory changes for the #inlcude files... > > Ipsec-tools 0.7.0 Release (which includes gcc4 fixes) should have been > released this week. > We did NOT release it until now for various reasons, including the > fact that I hoped we could fix this include problem for 0.7.0 release. > > But if it is quite simple to fix for -HEAD, which now only have > netipsec/ipsec.h, it is harder to solve cleanly for older versions, > which have both netinet6/ipsec.h and netipsec/ipsec.h, and on which I > just don't know how to guess which one we should use. > > I think I'll commit today a patch to detect the case where we only > have netipsec/ipsec.h (so it will compile again on -HEAD), and we'll > keep the netinet6/ipsec.h Vs netipsec/ipsec.h problem as an open issue > until someone gives me a clean way to decide which one we should use > when we found both. Ahh... The best way to detect this would be along these lines... (if on FreeBSD, autoconf knows that already) echo -n "checking for cleaned up IPSEC on FreeBSD 7 and later.." #include #if defined(__FreeBSD_version) && (__FreeBSD_version<700049) #error "Old FreeBSD" #endif (or having main() and return 0 and 1). I would have done that for configure but the autotools framework on FreeBSD is not really happy atm. The other and maybe simpler version would be to conditionally include an extra patch for the FreeBSD port from the port's Makefile for this release (based on the same criteria). This might also be less intrusive for ispec-tools at that stage of release. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 12:55:32 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ECF2016A408; Fri, 13 Jul 2007 12:55:32 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.freebsd.org (Postfix) with ESMTP id 9CE2D13C4A5; Fri, 13 Jul 2007 12:55:32 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 151BF1CCE9; Fri, 13 Jul 2007 14:35:52 +0200 (CEST) Date: Fri, 13 Jul 2007 14:35:52 +0200 From: Ed Schouten To: VANHULLEBUS Yvan Message-ID: <20070713123552.GW55449@hoeg.nl> References: <20070713053534.D31116@maildrop.int.zabbadoz.net> <20070713072657.GA13945@zen.inc> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O2izrSG9ltmUPm45" Content-Disposition: inline In-Reply-To: <20070713072657.GA13945@zen.inc> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: "Bjoern A. Zeeb" , net@freebsd.org, Peter Blok , FreeBSD current mailing list , "George V. Neville-Neil" Subject: Re: FAST_IPSEC is now IPSEC, please be advised... 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, 13 Jul 2007 12:55:33 -0000 --O2izrSG9ltmUPm45 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * VANHULLEBUS Yvan wrote: > But if it is quite simple to fix for -HEAD, which now only have > netipsec/ipsec.h, it is harder to solve cleanly for older versions, > which have both netinet6/ipsec.h and netipsec/ipsec.h, and on which I > just don't know how to guess which one we should use. You could use the __FreeBSD_version definition to detect what version of FreeBSD people are using. I guess it has been bumped after the IPSEC import. --=20 Ed Schouten WWW: http://g-rave.nl/ --O2izrSG9ltmUPm45 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGl3Gn52SDGA2eCwURAkLqAJ0e9ktUkyYLFc9SUFBNeYMT9MYW+ACeN66v T8KqKR+0xvw/Qxog1M6DPLc= =BM3I -----END PGP SIGNATURE----- --O2izrSG9ltmUPm45-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 12:59:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 916C816A405 for ; Fri, 13 Jul 2007 12:59:48 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpout05.prod.mesa1.secureserver.net (smtpout05-04.prod.mesa1.secureserver.net [64.202.165.221]) by mx1.freebsd.org (Postfix) with SMTP id 5A69313C4DE for ; Fri, 13 Jul 2007 12:59:48 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 22818 invoked from network); 13 Jul 2007 12:59:46 -0000 Received: from unknown (24.144.77.243) by smtpout05-04.prod.mesa1.secureserver.net (64.202.165.221) with ESMTP; 13 Jul 2007 12:59:46 -0000 Message-ID: <46977741.8090301@seclark.us> Date: Fri, 13 Jul 2007 08:59:45 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sten Daniel Soersdal References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> In-Reply-To: <469772DA.1000700@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 12:59:48 -0000 Sten Daniel Soersdal wrote: >Stephen Clark wrote: > > >>Hello, >> >>Did something change in 6.2? If my mtu size on rl0 is 1280 it won't >>accept a larger incomming packet. >> >>kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max >>1294) >> >> > >That is what to be expected. >Incoming interface must have mtu set to the same mtu as all other hosts >on the same L2 network. If mtu is set to the same as all other hosts, >then it is impossible to receive a frame that is too large (assuming >everything works). > > > >>I don't think it worked this way in the past. >> >>Won't this affect pmtud? >> >> > >Incoming interface must have its mtu set to large enough to receive the >frame. Outgoing interface, on the other hand, can be lower. > >For pmtud to work you need to be able to receive packets on an interface >with sufficiently set mtu, but the exitting interface can have a lower >mtu configured. Thus the router can accept the incoming packet but may >drop and notify on a frame that is too large to exit the outgoing >interface (assuming DF is set). > > > >>man page for ifconfig says mtu limits size of "transmission" not reception. >> >> "mtu n Set the maximum transmission unit of the interface to n, >>default >> is interface specific." >> >> > >Perhaps the man author considered reception to be implied? > >In any case, enforcing this on incoming packets is correct behavior. > > > But shouldn't an icmp be generated back to the system sending the packet that is being dropped? This is not happening. So the connection stalls. client mtu 1500 <-> |rl0 mtu 1500 FreeBSD Router rl1 mtu 1280| <-> some host on internet client sends syn saying i can do mss=1460 host sends syn saying i can do mss=1460 host tries to send packet of 1460 it get silently dropped. connection stalls. -- "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 Jul 13 13:09:29 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5AF8016A405 for ; Fri, 13 Jul 2007 13:09:29 +0000 (UTC) (envelope-from netslists@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id DEA3113C46B for ; Fri, 13 Jul 2007 13:09:28 +0000 (UTC) (envelope-from netslists@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so628996uge for ; Fri, 13 Jul 2007 06:09:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ebvl6urDlnN3ZqH5pwk1rePXD/RM/9gb/1d5472T2/476dSQeyK7A58zHA+qVC0YAd50GplC1TkjfwUw8dsGCVwHYiAYhGLkQmKeqHKF5jsQNK0kBSZJRBkR4JHZE8y0BYoEhEZgmLxGf/CN2WK6nPcAEySJ9IYc3HmGuOKkFL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=guZ1XVf1bMMALmPSGU4d3lVj8JsN+JElW7uCl/M6raMNOvb4Hq7mdR694hkONK5MNn/yOoGtXXk3gX5cYcBscFiD77i+brhz1DVAKsw8FeKFVUXdcB6TRCeTpWwvOYBl2ApXy0tZYTMhW1Cyo5ApAXsVU7ftvw/1CPnb3XboyLs= Received: by 10.86.97.7 with SMTP id u7mr1258907fgb.1184330465309; Fri, 13 Jul 2007 05:41:05 -0700 (PDT) Received: from ?192.168.9.8? ( [91.135.49.10]) by mx.google.com with ESMTP id 13sm2964369fks.2007.07.13.05.41.04 (version=SSLv3 cipher=RC4-MD5); Fri, 13 Jul 2007 05:41:04 -0700 (PDT) Message-ID: <469772DA.1000700@gmail.com> Date: Fri, 13 Jul 2007 14:40:58 +0200 From: Sten Daniel Soersdal User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephen.Clark@seclark.us References: <46967C5C.5040505@seclark.us> In-Reply-To: <46967C5C.5040505@seclark.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet 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, 13 Jul 2007 13:09:29 -0000 Stephen Clark wrote: > Hello, > > Did something change in 6.2? If my mtu size on rl0 is 1280 it won't > accept a larger incomming packet. > > kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max > 1294) That is what to be expected. Incoming interface must have mtu set to the same mtu as all other hosts on the same L2 network. If mtu is set to the same as all other hosts, then it is impossible to receive a frame that is too large (assuming everything works). > > I don't think it worked this way in the past. > > Won't this affect pmtud? Incoming interface must have its mtu set to large enough to receive the frame. Outgoing interface, on the other hand, can be lower. For pmtud to work you need to be able to receive packets on an interface with sufficiently set mtu, but the exitting interface can have a lower mtu configured. Thus the router can accept the incoming packet but may drop and notify on a frame that is too large to exit the outgoing interface (assuming DF is set). > > man page for ifconfig says mtu limits size of "transmission" not reception. > > "mtu n Set the maximum transmission unit of the interface to n, > default > is interface specific." Perhaps the man author considered reception to be implied? In any case, enforcing this on incoming packets is correct behavior. -- Sten Daniel Soersdal From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 13:34:09 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95A0516A400 for ; Fri, 13 Jul 2007 13:34:09 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 6B02213C47E for ; Fri, 13 Jul 2007 13:34:09 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pitbpa0.priv.collaborativefusion.com (vanquish.pitbpa0.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Fri, 13 Jul 2007 09:34:08 -0400 id 0005641B.46977F50.0000B150 Date: Fri, 13 Jul 2007 09:34:08 -0400 From: Bill Moran To: Stephen.Clark@seclark.us Message-Id: <20070713093408.b8a92c23.wmoran@collaborativefusion.com> In-Reply-To: <46977741.8090301@seclark.us> References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.11; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Sten Daniel Soersdal Subject: Re: 6.2 mtu now limits size of incomming packet 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, 13 Jul 2007 13:34:09 -0000 In response to Stephen Clark : > Sten Daniel Soersdal wrote: > > >Stephen Clark wrote: > > > > > >>Hello, > >> > >>Did something change in 6.2? If my mtu size on rl0 is 1280 it won't > >>accept a larger incomming packet. > >> > >>kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max > >>1294) > >> > >> > > > >That is what to be expected. > >Incoming interface must have mtu set to the same mtu as all other hosts > >on the same L2 network. If mtu is set to the same as all other hosts, > >then it is impossible to receive a frame that is too large (assuming > >everything works). > > > > > > > >>I don't think it worked this way in the past. > >> > >>Won't this affect pmtud? > >> > >> > > > >Incoming interface must have its mtu set to large enough to receive the > >frame. Outgoing interface, on the other hand, can be lower. > > > >For pmtud to work you need to be able to receive packets on an interface > >with sufficiently set mtu, but the exitting interface can have a lower > >mtu configured. Thus the router can accept the incoming packet but may > >drop and notify on a frame that is too large to exit the outgoing > >interface (assuming DF is set). > > > > > > > >>man page for ifconfig says mtu limits size of "transmission" not reception. > >> > >> "mtu n Set the maximum transmission unit of the interface to n, > >>default > >> is interface specific." > >> > >> > > > >Perhaps the man author considered reception to be implied? > > > >In any case, enforcing this on incoming packets is correct behavior. > > > > > > > But shouldn't an icmp be generated back to the system sending the packet > that is > being dropped? This is not happening. So the connection stalls. No. You're thinking of PMTU, which involves the don't fragment bit and intermediate routers. A packet that exceeds the network maximum MTU is an invalid packet, and thus should be dropped silently or it could cause a DoS. > > client mtu 1500 <-> |rl0 mtu 1500 FreeBSD Router rl1 mtu 1280| <-> some > host on internet > client sends syn saying i can do mss=1460 > host sends syn saying i can do mss=1460 > host tries to send packet of 1460 it get silently dropped. connection > stalls. > > -- > > "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) > > > > _______________________________________________ > 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" > > > > > > -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 16:19:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4860516A405 for ; Fri, 13 Jul 2007 16:19:28 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpauth01.prod.mesa1.secureserver.net (smtpauth01.prod.mesa1.secureserver.net [64.202.165.181]) by mx1.freebsd.org (Postfix) with SMTP id 1114013C4B9 for ; Fri, 13 Jul 2007 16:19:27 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 6178 invoked from network); 13 Jul 2007 16:19:25 -0000 Received: from unknown (24.144.77.243) by smtpauth01.prod.mesa1.secureserver.net (64.202.165.181) with ESMTP; 13 Jul 2007 16:19:24 -0000 Message-ID: <4697A60C.4090409@seclark.us> Date: Fri, 13 Jul 2007 12:19:24 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Moran References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.wmoran@collaborativefusion.com> In-Reply-To: <20070713093408.b8a92c23.wmoran@collaborativefusion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Sten Daniel Soersdal Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 16:19:28 -0000 Bill Moran wrote: >In response to Stephen Clark : > > > >>Sten Daniel Soersdal wrote: >> >> >> >>>Stephen Clark wrote: >>> >>> >>> >>> >>>>Hello, >>>> >>>>Did something change in 6.2? If my mtu size on rl0 is 1280 it won't >>>>accept a larger incomming packet. >>>> >>>>kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max >>>>1294) >>>> >>>> >>>> >>>> >>>That is what to be expected. >>>Incoming interface must have mtu set to the same mtu as all other hosts >>>on the same L2 network. If mtu is set to the same as all other hosts, >>>then it is impossible to receive a frame that is too large (assuming >>>everything works). >>> >>> >>> >>> >>> >>>>I don't think it worked this way in the past. >>>> >>>>Won't this affect pmtud? >>>> >>>> >>>> >>>> >>>Incoming interface must have its mtu set to large enough to receive the >>>frame. Outgoing interface, on the other hand, can be lower. >>> >>>For pmtud to work you need to be able to receive packets on an interface >>>with sufficiently set mtu, but the exitting interface can have a lower >>>mtu configured. Thus the router can accept the incoming packet but may >>>drop and notify on a frame that is too large to exit the outgoing >>>interface (assuming DF is set). >>> >>> >>> >>> >>> >>>>man page for ifconfig says mtu limits size of "transmission" not reception. >>>> >>>> "mtu n Set the maximum transmission unit of the interface to n, >>>>default >>>> is interface specific." >>>> >>>> >>>> >>>> >>>Perhaps the man author considered reception to be implied? >>> >>>In any case, enforcing this on incoming packets is correct behavior. >>> >>> >>> >>> >>> >>But shouldn't an icmp be generated back to the system sending the packet >>that is >>being dropped? This is not happening. So the connection stalls. >> >> > >No. You're thinking of PMTU, which involves the don't fragment bit and >intermediate routers. > >A packet that exceeds the network maximum MTU is an invalid packet, and >thus should be dropped silently or it could cause a DoS. > > > This is not the behavior FreeBSD 4.9 exhibits. I just tested it. I had a mtu of 1280 on the rl1 interface and it glady accepted packets of 1460. Steve >>client mtu 1500 <-> |rl0 mtu 1500 FreeBSD Router rl1 mtu 1280| <-> some >>host on internet >>client sends syn saying i can do mss=1460 >>host sends syn saying i can do mss=1460 >>host tries to send packet of 1460 it get silently dropped. connection >>stalls. >> >>-- >> >>"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) >> >> >> >>_______________________________________________ >>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 Fri Jul 13 17:04:04 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2CC9616A403 for ; Fri, 13 Jul 2007 17:04:04 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id D45C213C48D for ; Fri, 13 Jul 2007 17:04:03 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pitbpa0.priv.collaborativefusion.com (vanquish.pitbpa0.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Fri, 13 Jul 2007 13:04:03 -0400 id 00056424.4697B083.00010E0A Date: Fri, 13 Jul 2007 13:04:02 -0400 From: Bill Moran To: Stephen.Clark@seclark.us Message-Id: <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> In-Reply-To: <4697A60C.4090409@seclark.us> References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.wmoran@collaborativefusion.com> <4697A60C.4090409@seclark.us> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.11; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Sten Daniel Soersdal Subject: Re: 6.2 mtu now limits size of incomming packet 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, 13 Jul 2007 17:04:04 -0000 In response to Stephen Clark : > Bill Moran wrote: > > >In response to Stephen Clark : > > > >>Sten Daniel Soersdal wrote: > >> > >>>Stephen Clark wrote: > >>> > >>>>Hello, > >>>> > >>>>Did something change in 6.2? If my mtu size on rl0 is 1280 it won't > >>>>accept a larger incomming packet. > >>>> > >>>>kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max > >>>>1294) > >>> > >>>That is what to be expected. > >>>Incoming interface must have mtu set to the same mtu as all other hosts > >>>on the same L2 network. If mtu is set to the same as all other hosts, > >>>then it is impossible to receive a frame that is too large (assuming > >>>everything works). > >>> > >>>>I don't think it worked this way in the past. > >>>> > >>>>Won't this affect pmtud? > >>> > >>>Incoming interface must have its mtu set to large enough to receive the > >>>frame. Outgoing interface, on the other hand, can be lower. > >>> > >>>For pmtud to work you need to be able to receive packets on an interface > >>>with sufficiently set mtu, but the exitting interface can have a lower > >>>mtu configured. Thus the router can accept the incoming packet but may > >>>drop and notify on a frame that is too large to exit the outgoing > >>>interface (assuming DF is set). > >>> > >>>>man page for ifconfig says mtu limits size of "transmission" not reception. > >>>> > >>>> "mtu n Set the maximum transmission unit of the interface to n, > >>>>default > >>>> is interface specific." > >>>> > >>>Perhaps the man author considered reception to be implied? > >>> > >>>In any case, enforcing this on incoming packets is correct behavior. > >> > >>But shouldn't an icmp be generated back to the system sending the packet > >>that is > >>being dropped? This is not happening. So the connection stalls. > > > >No. You're thinking of PMTU, which involves the don't fragment bit and > >intermediate routers. > > > >A packet that exceeds the network maximum MTU is an invalid packet, and > >thus should be dropped silently or it could cause a DoS. > > This is not the behavior FreeBSD 4.9 exhibits. I just tested it. I had a > mtu of 1280 on the > rl1 interface and it glady accepted packets of 1460. I don't see that as relevant. I'm sure earlier versions of many parts of FreeBSD had bugs. Take also into account the fact that best practices are still evolving. Let's flip the question around a bit: why would you _want_ the TCP stack to accept frames larger than the stated MTU? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 17:12:40 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EEA316A402 for ; Fri, 13 Jul 2007 17:12:40 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpauth03.prod.mesa1.secureserver.net (smtpauth03.prod.mesa1.secureserver.net [64.202.165.183]) by mx1.freebsd.org (Postfix) with SMTP id 67B3013C4A6 for ; Fri, 13 Jul 2007 17:12:40 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 23832 invoked from network); 13 Jul 2007 17:12:39 -0000 Received: from unknown (24.144.77.243) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 13 Jul 2007 17:12:39 -0000 Message-ID: <4697B285.9050602@seclark.us> Date: Fri, 13 Jul 2007 13:12:37 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Moran , freebsd-net@freebsd.org References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.wmoran@collaborativefusion.com> <4697A60C.4090409@seclark.us> <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> In-Reply-To: <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 17:12:40 -0000 Bill Moran wrote: >In response to Stephen Clark : > > > >>Bill Moran wrote: >> >> >> >>>In response to Stephen Clark : >>> >>> >>> >>>>Sten Daniel Soersdal wrote: >>>> >>>> >>>> >>>>>Stephen Clark wrote: >>>>> >>>>> >>>>> >>>>>>Hello, >>>>>> >>>>>>Did something change in 6.2? If my mtu size on rl0 is 1280 it won't >>>>>>accept a larger incomming packet. >>>>>> >>>>>>kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max >>>>>>1294) >>>>>> >>>>>> >>>>>That is what to be expected. >>>>>Incoming interface must have mtu set to the same mtu as all other hosts >>>>>on the same L2 network. If mtu is set to the same as all other hosts, >>>>>then it is impossible to receive a frame that is too large (assuming >>>>>everything works). >>>>> >>>>> >>>>> >>>>>>I don't think it worked this way in the past. >>>>>> >>>>>>Won't this affect pmtud? >>>>>> >>>>>> >>>>>Incoming interface must have its mtu set to large enough to receive the >>>>>frame. Outgoing interface, on the other hand, can be lower. >>>>> >>>>>For pmtud to work you need to be able to receive packets on an interface >>>>>with sufficiently set mtu, but the exitting interface can have a lower >>>>>mtu configured. Thus the router can accept the incoming packet but may >>>>>drop and notify on a frame that is too large to exit the outgoing >>>>>interface (assuming DF is set). >>>>> >>>>> >>>>> >>>>>>man page for ifconfig says mtu limits size of "transmission" not reception. >>>>>> >>>>>> "mtu n Set the maximum transmission unit of the interface to n, >>>>>>default >>>>>> is interface specific." >>>>>> >>>>>> >>>>>> >>>>>Perhaps the man author considered reception to be implied? >>>>> >>>>>In any case, enforcing this on incoming packets is correct behavior. >>>>> >>>>> >>>>But shouldn't an icmp be generated back to the system sending the packet >>>>that is >>>>being dropped? This is not happening. So the connection stalls. >>>> >>>> >>>No. You're thinking of PMTU, which involves the don't fragment bit and >>>intermediate routers. >>> >>>A packet that exceeds the network maximum MTU is an invalid packet, and >>>thus should be dropped silently or it could cause a DoS. >>> >>> >>This is not the behavior FreeBSD 4.9 exhibits. I just tested it. I had a >>mtu of 1280 on the >>rl1 interface and it glady accepted packets of 1460. >> >> > >I don't see that as relevant. I'm sure earlier versions of many parts of >FreeBSD had bugs. Take also into account the fact that best practices are >still evolving. > >Let's flip the question around a bit: why would you _want_ the TCP stack >to accept frames larger than the stated MTU? > > > I guess because thats the way it used to work ;-) , and it caused me confusion in testing our updated security appliance that used to be based on 4.9 and now will be based on 6.x. As I am gaining a better understanding of things I don't see it as a real problem. Thanks for you input. 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 Jul 13 17:28:35 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7EEE116A4B3 for ; Fri, 13 Jul 2007 17:28:35 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outI.internet-mail-service.net (outI.internet-mail-service.net [216.240.47.232]) by mx1.freebsd.org (Postfix) with ESMTP id 8B8D913C526 for ; Fri, 13 Jul 2007 17:28:34 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 13 Jul 2007 10:28:34 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id CA9DE125B1C; Fri, 13 Jul 2007 10:28:33 -0700 (PDT) Message-ID: <4697B653.8050906@elischer.org> Date: Fri, 13 Jul 2007 10:28:51 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Bill Moran References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.wmoran@collaborativefusion.com> <4697A60C.4090409@seclark.us> <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> In-Reply-To: <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stephen.Clark@seclark.us, Sten Daniel Soersdal , freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet 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, 13 Jul 2007 17:28:35 -0000 Bill Moran wrote: ractices are > still evolving. > > Let's flip the question around a bit: why would you _want_ the TCP stack > to accept frames larger than the stated MTU? > Because mtu is mTu not mRu. The interface should theoretically always accept any packet up to the maximum practical size.. As the original BSD group always said.. (from my memories of Kirk's and Mike's talks in 1991), "Transmit strictly [according to the spec] but receive forgivingly". The ability to receive packets larger than mtu was not accidental. This should be fixed, if it is, as is suggested, a deliberate change. From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 18:08:46 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39C7B16A400 for ; Fri, 13 Jul 2007 18:08:46 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0953613C4BC for ; Fri, 13 Jul 2007 18:08:45 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 1I9PZN-00059W-7N for freebsd-net@freebsd.org; Fri, 13 Jul 2007 18:08:45 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp4.email.verio.net with esmtp id 1I9PZN-00008M-4I for freebsd-net@freebsd.org; Fri, 13 Jul 2007 18:08:45 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 86A838E296; Fri, 13 Jul 2007 13:08:41 -0500 (CDT) Date: Fri, 13 Jul 2007 13:08:41 -0500 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20070713180840.GB8392@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.wmoran@collaborativefusion.com> <4697A60C.4090409@seclark.us> <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 18:08:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Moran wrote: > > Let's flip the question around a bit: why would you _want_ the TCP > stack to accept frames larger than the stated MTU? If I receive a 64K frame and the TCP checksum checks out, and the sequence numbers match, and it passes my firewall state, why NOT receive it? It is obviously valid, even if I cannot understand how my interface could have received it. The packet is here, so do something useful with it. I agree with others that MTU means "limit what I transmit". It does not mean "limit what someone else can transmit to me." - -- David DeSimone == Network Admin == fox@verio.net "It took me fifteen years to discover that I had no talent for writing, but I couldn't give it up because by that time I was too famous. -- Robert Benchley -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGl7+oFSrKRjX5eCoRAg/IAKCjpErjfEMx33emhDqtNs327Hi1vQCfQnpC i+33Od/k39MaAF/1LZyxj4I= =xtlB -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 19:27:26 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66CC416A402 for ; Fri, 13 Jul 2007 19:27:26 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 14C5A13C441 for ; Fri, 13 Jul 2007 19:27:25 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pitbpa0.priv.collaborativefusion.com (vanquish.pitbpa0.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Fri, 13 Jul 2007 15:27:25 -0400 id 00056412.4697D21D.00012712 Date: Fri, 13 Jul 2007 15:27:25 -0400 From: Bill Moran To: David DeSimone Message-Id: <20070713152725.6ae40056.wmoran@collaborativefusion.com> In-Reply-To: <20070713180840.GB8392@verio.net> References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.wmoran@collaborativefusion.com> <4697A60C.4090409@seclark.us> <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> <20070713180840.GB8392@verio.net> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.11; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet 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, 13 Jul 2007 19:27:26 -0000 In response to David DeSimone : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Bill Moran wrote: > > > > Let's flip the question around a bit: why would you _want_ the TCP > > stack to accept frames larger than the stated MTU? > > If I receive a 64K frame and the TCP checksum checks out, and the > sequence numbers match, and it passes my firewall state, why NOT receive > it? It is obviously valid, even if I cannot understand how my interface > could have received it. The packet is here, so do something useful with > it. But it's not here yet. The problem is that it doesn't pass a basic sanity check at the media layer, so it would be dropped before it ever starts seeing checks at the TCP or IP layer. > I agree with others that MTU means "limit what I transmit". It does not > mean "limit what someone else can transmit to me." Interesting viewpoint. I disagree with it, but I can't quote any standard or otherwise to support my view. You didn't either. Does anyone know of a publicised, authoritative standard that would clear this up? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 19:54:40 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A489C16A400 for ; Fri, 13 Jul 2007 19:54:40 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 8718713C428 for ; Fri, 13 Jul 2007 19:54:40 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out3.apple.com (Postfix) with ESMTP id 74E15BA90E9; Fri, 13 Jul 2007 12:54:40 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 5F1C629C003; Fri, 13 Jul 2007 12:54:40 -0700 (PDT) X-AuditID: 11807123-a573dbb000000b34-23-4697d8808b75 Received: from [17.214.13.96] (int-si-a.apple.com [17.128.113.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay5.apple.com (Apple SCV relay) with ESMTP id 415CD30400D; Fri, 13 Jul 2007 12:54:40 -0700 (PDT) In-Reply-To: <20070713152725.6ae40056.wmoran@collaborativefusion.com> References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.wmoran@collaborativefusion.com> <4697A60C.4090409@seclark.us> <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> <20070713180840.GB8392@verio.net> <20070713152725.6ae40056.wmoran@collaborativefusion.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Fri, 13 Jul 2007 12:54:40 -0700 To: Bill Moran X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-net@freebsd.org, David DeSimone Subject: Re: 6.2 mtu now limits size of incomming packet 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, 13 Jul 2007 19:54:40 -0000 On Jul 13, 2007, at 12:27 PM, Bill Moran wrote: >> I agree with others that MTU means "limit what I transmit". It >> does not >> mean "limit what someone else can transmit to me." > > Interesting viewpoint. I disagree with it, but I can't quote any > standard > or otherwise to support my view. You didn't either. > > Does anyone know of a publicised, authoritative standard that would > clear this up? Sure. RFC-791: "Fragmentation Fragmentation of an internet datagram is necessary when it originates in a local net that allows a large packet size and must traverse a local net that limits packets to a smaller size to reach its destination. An internet datagram can be marked "don't fragment." Any internet datagram so marked is not to be internet fragmented under any circumstances. If internet datagram marked don't fragment cannot be delivered to its destination without fragmenting it, it is to be discarded instead. Fragmentation, transmission and reassembly across a local network which is invisible to the internet protocol module is called intranet fragmentation and may be used [6]." RFC-879: " HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO ACCEPT LARGER DATAGRAMS." "8. Maximum Packet Size Each network has some maximum packet size, or maximum transmission unit (MTU). Ultimately there is some limit imposed by the technology, but often the limit is an engineering choice or even an administrative choice. Different installations of the same network product do not have to use the same maximum packet size. Even within one installation not all host must use the same packet size (this way lies madness, though). Some IP implementers have assumed that all hosts on the directly attached network will be the same or at least run the same implementation. This is a dangerous assumption. It has often developed that after a small homogeneous set of host have become operational additional hosts of different types are introduced into the environment. And it has often developed that it is desired to use a copy of the implementation in a different inhomogeneous environment. Designers of gateways should be prepared for the fact that successful gateways will be copied and used in other situation and installations. Gateways must be prepared to accept datagrams as large as can be sent in the maximum packets of the directly attached networks. Gateway implementations should be easily configured for installation in different circumstances. A footnote: The MTUs of some popular networks (note that the actual limit in some installations may be set lower by administrative policy): ARPANET, MILNET = 1007 Ethernet (10Mb) = 1500 Proteon PRONET = 2046" RFC-894: " The minimum length of the data field of a packet sent over an Ethernet is 1500 octets, thus the maximum length of an IP datagram sent over an Ethernet is 1500 octets. Implementations are encouraged to support full-length packets. Gateway implementations MUST be prepared to accept full-length packets and fragment them if necessary. If a system cannot receive full-length packets, it should take steps to discourage others from sending them, such as using the TCP Maximum Segment Size option [4]. Note: Datagrams on the Ethernet may be longer than the general Internet default maximum packet size of 576 octets. Hosts connected to an Ethernet should keep this in mind when sending datagrams to hosts not on the same Ethernet. It may be appropriate to send smaller datagrams to avoid unnecessary fragmentation at intermediate gateways. Please see [4] for further information on this point." And RFCs 1122 and 1191 are also somewhat relevant. My reading of the above is that ethernet-capable gateways must be willing to accept packets as large as 1500 octets and fragment such traffic to meet the MTU settings as needed, except if DF is set. If DF is set, but the packet is addressed to the gateway itself, then it should be delivered unfragmented even if that packet exceeded the MTU set on the receiving interface. For hosts which are not network gateways, one should not assume them to be capable of receiving packets larger than 576 octets, but the TCP MSS option is almost universally available to indicate the appropriate maximum size that host is willing to receive during the 3WHS setup... -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 20:22:12 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60DA516A406; Fri, 13 Jul 2007 20:22:12 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id 4395713C4B5; Fri, 13 Jul 2007 20:22:12 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from sakai.kitchenlab.org (sakai.kitchenlab.org [64.142.31.108]) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l6DKMBbh013585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Jul 2007 13:22:11 -0700 Received: from phantom.kitchenlab.org (phantom.kitchenlab.org [64.142.31.109]) by sakai.kitchenlab.org (8.14.1/8.14.1) with ESMTP id l6DKM9lE021845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 13:22:11 -0700 (PDT) (envelope-from bmah@freebsd.org) Date: Fri, 13 Jul 2007 13:22:09 -0700 From: "Bruce A. Mah" To: freebsd-mobile@freebsd.org, freebsd-net@freebsd.org Message-ID: <20070713202015.GA1718@phantom.kitchenlab.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline X-Image-Url: http://www.kitchenlab.org/~bmah/Images/bmah-cisco-small.gif X-url: http://www.kitchenlab.org/~bmah/ User-Agent: Mutt/1.5.15 (2007-04-06) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sakai.kitchenlab.org [64.142.31.108]); Fri, 13 Jul 2007 13:22:11 -0700 (PDT) X-Virus-Scanned: ClamAV 0.90.3/3662/Fri Jul 13 10:53:47 2007 on sakai.kitchenlab.org X-Virus-Status: Clean Cc: bmah@freebsd.org Subject: ath(4), wpa_supplicant, WPA2, Netgear WG302 problem 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, 13 Jul 2007 20:22:12 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm having a problem getting a Netgear WG511T in my FreeBSD CURRENT laptop to do WPA2-PSK with a Netgear WG302 access point. I'm hoping someone here can give me a nudge in the right direction to help troubleshoot this. The laptop is an old Sony Vaio (PCG-Z505HS). The Netgear WG511T probes thusly: ath0: mem 0x88000000-0x8800ffff irq 9 at device 0.0 on cardb= us0 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:0f:b5:af:81:39 ath0: mac 7.9 phy 4.5 radio 5.6 The OS is FreeBSD HEAD as of yesterday, GENERIC kernel. Note that this has the recent HAL import, as well as wpa_supplicant v0.5.8: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) The AP is a Netgear WG302 with Firmware 4.2.17. It's configured for WPA2-PSK. Several other clients can communicate with this AP without any problems. A slightly sanitized wpa_supplicant.conf is: ----- network=3D{ ssid=3D"kitchenlab.org" scan_ssid=3D1 psk=3D"REAL_PSK_REMOVED" } ----- Some output from wpa_supplicant -dd is below: ----- Starting AP scan (specific SSID) Scan SSID - hexdump_ascii(len=3D14): 6b 69 74 63 68 65 6e 6c 61 62 2e 6f 72 67 kitchenlab.org =20 Received 0 bytes of scan results (6 BSSes) Scan results: 6 Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:14:6c:6f:2e:7d ssid=3D'kitchenlab.org' wpa_ie_len=3D0 rsn_ie_len=3D26= caps=3D0x31 selected based on RSN IE selected WPA AP 00:14:6c:6f:2e:7d ssid=3D'kitchenlab.org' Try to find non-WPA AP Trying to associate with 00:14:6c:6f:2e:7d (SSID=3D'kitchenlab.org' freq=3D= 2412 MHz) Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1 RSN: using IEEE 802.11i/D9.0 WPA: Selected cipher suites: group 8 pairwise 24 key_mgmt 2 proto 2 WPA: clearing AP WPA IE WPA: set AP RSN IE - hexdump(len=3D26): 30 18 01 00 00 0f ac 02 02 00 00 0f= ac 02 00 0f ac 04 01 00 00 0f ac 02 01 00 WPA: using GTK TKIP WPA: using PTK CCMP WPA: using KEY_MGMT WPA-PSK WPA: Set own WPA IE default - hexdump(len=3D22): 30 14 01 00 00 0f ac 02 01= 00 00 0f ac 04 01 00 00 0f ac 02 00 00 No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=3D1 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'kitchenlab.org' wpa ie len 22 pairwise 3 gr= oup 2 key mgmt 1 wpa_driver_bsd_associate: set PRIVACY 1 Setting authentication timeout: 10 sec 0 usec EAPOL: External notification - EAP success=3D0 EAPOL: External notification - EAP fail=3D0 EAPOL: External notification - portControl=3DAuto RSN: added PMKSA cache candidate 00:14:6c:6f:2e:7d prio 1000 RSN: processing PMKSA candidate list RSN: not in suitable state for new pre-authentication Authentication with 00:00:00:00:00:00 timed out. BSSID 00:14:6c:6f:2e:7d blacklist count incremented to 2 No keys have been configured - skip key clearing State: ASSOCIATING -> DISCONNECTED EAPOL: External notification - portEnabled=3D0 EAPOL: External notification - portValid=3D0 EAPOL: External notification - EAP success=3D0 Setting scan request: 0 sec 0 usec State: DISCONNECTED -> SCANNING ----- It's interesting that the WG511T can associate with this AP if both are configured for WEP, and it can do WPA2 with a Linksys WRT54G (unknown version). Also I saw superficially similar results while running 6.2-RELEASE and RELENG_6 on the same hardware. Debugging by Google hasn't helped me yet either, so I'm running out of ideas. Any thoughts? Thanks! Bruce. --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGl97x2MoxcVugUsMRAmtbAKDfSURNp1VcU+ln1PB3PnxErpvDjACfXYmA dAA3J/j5rJvh/wn3uXaqWi8= =yJUc -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 20:24:07 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2CFC16A402 for ; Fri, 13 Jul 2007 20:24:06 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by mx1.freebsd.org (Postfix) with SMTP id A8B4113C4B9 for ; Fri, 13 Jul 2007 20:24:06 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 19328 invoked from network); 13 Jul 2007 20:24:05 -0000 Received: from unknown (24.144.77.243) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 13 Jul 2007 20:24:05 -0000 Message-ID: <4697DF64.9070203@seclark.us> Date: Fri, 13 Jul 2007 16:24:04 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Swiger , freebsd-net@freebsd.org References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.wmoran@collaborativefusion.com> <4697A60C.4090409@seclark.us> <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> <20070713180840.GB8392@verio.net> <20070713152725.6ae40056.wmoran@collaborativefusion.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 20:24:07 -0000 Chuck Swiger wrote: >On Jul 13, 2007, at 12:27 PM, Bill Moran wrote: > > >>>I agree with others that MTU means "limit what I transmit". It >>>does not >>>mean "limit what someone else can transmit to me." >>> >>> >>Interesting viewpoint. I disagree with it, but I can't quote any >>standard >>or otherwise to support my view. You didn't either. >> >>Does anyone know of a publicised, authoritative standard that would >>clear this up? >> >> > >Sure. RFC-791: > >"Fragmentation > > Fragmentation of an internet datagram is necessary when it > originates in a local net that allows a large packet size and must > traverse a local net that limits packets to a smaller size to reach > its destination. > > An internet datagram can be marked "don't fragment." Any internet > datagram so marked is not to be internet fragmented under any > circumstances. If internet datagram marked don't fragment >cannot be > delivered to its destination without fragmenting it, it is to be > discarded instead. > > Fragmentation, transmission and reassembly across a local network > which is invisible to the internet protocol module is called > intranet fragmentation and may be used [6]." > >RFC-879: > >" HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY > HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO > ACCEPT LARGER DATAGRAMS." > >"8. Maximum Packet Size > > Each network has some maximum packet size, or maximum transmission > unit (MTU). Ultimately there is some limit imposed by the > technology, but often the limit is an engineering choice or even an > administrative choice. Different installations of the same network > product do not have to use the same maximum packet size. Even >within > one installation not all host must use the same packet size (this >way > lies madness, though). > > Some IP implementers have assumed that all hosts on the directly > attached network will be the same or at least run the same > implementation. This is a dangerous assumption. It has often > developed that after a small homogeneous set of host have become > operational additional hosts of different types are introduced into > the environment. And it has often developed that it is desired to > use a copy of the implementation in a different inhomogeneous > environment. > > Designers of gateways should be prepared for the fact that >successful > gateways will be copied and used in other situation and > installations. Gateways must be prepared to accept datagrams as > large as can be sent in the maximum packets of the directly attached > networks. > Doesn't this imply if a gateway has 2 interfaces, one with an mtu of 1280 and the other with an mtu of 1500 it should accept 1500 on either interface? >Gateway implementations should be easily configured for > installation in different circumstances. > > A footnote: The MTUs of some popular networks (note that the actual > limit in some installations may be set lower by administrative > policy): > > ARPANET, MILNET = 1007 > Ethernet (10Mb) = 1500 > Proteon PRONET = 2046" > >RFC-894: > >" The minimum length of the data field of a packet sent over an > Ethernet is 1500 octets, thus the maximum length of an IP datagram > sent over an Ethernet is 1500 octets. Implementations are >encouraged > to support full-length packets. Gateway implementations MUST be > prepared to accept full-length packets and fragment them if > necessary. If a system cannot receive full-length packets, it >should > take steps to discourage others from sending them, such as using the > TCP Maximum Segment Size option [4]. > > Note: Datagrams on the Ethernet may be longer than the general > Internet default maximum packet size of 576 octets. Hosts connected > to an Ethernet should keep this in mind when sending datagrams to > hosts not on the same Ethernet. It may be appropriate to send > smaller datagrams to avoid unnecessary fragmentation at intermediate > gateways. Please see [4] for further information on this point." > >And RFCs 1122 and 1191 are also somewhat relevant. My reading of the >above is that ethernet-capable gateways must be willing to accept >packets as large as 1500 octets and fragment such traffic to meet the >MTU settings as needed, except if DF is set. If DF is set, but the >packet is addressed to the gateway itself, then it should be >delivered unfragmented even if that packet exceeded the MTU set on >the receiving interface. > >For hosts which are not network gateways, one should not assume them >to be capable of receiving packets larger than 576 octets, but the >TCP MSS option is almost universally available to indicate the >appropriate maximum size that host is willing to receive during the >3WHS setup... > > > -- "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 Jul 13 20:31:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAD0016A404 for ; Fri, 13 Jul 2007 20:31:10 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id D0E3F13C48E for ; Fri, 13 Jul 2007 20:31:10 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out4.apple.com (Postfix) with ESMTP id C7628BEDA1E; Fri, 13 Jul 2007 13:31:10 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id B3F821008E; Fri, 13 Jul 2007 13:31:10 -0700 (PDT) X-AuditID: 11807124-a5fb9bb0000007f3-64-4697e10e37e3 Received: from [17.214.13.96] (int-si-a.apple.com [17.128.113.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay6.apple.com (Apple SCV relay) with ESMTP id A161E1006A; Fri, 13 Jul 2007 13:31:10 -0700 (PDT) In-Reply-To: <4697DF64.9070203@seclark.us> References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.wmoran@collaborativefusion.com> <4697A60C.4090409@seclark.us> <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> <20070713180840.GB8392@verio.net> <20070713152725.6ae40056.wmoran@collaborativefusion.com> <4697DF64.9070203@seclark.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Fri, 13 Jul 2007 13:31:10 -0700 To: Stephen.Clark@seclark.us X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet 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, 13 Jul 2007 20:31:11 -0000 On Jul 13, 2007, at 1:24 PM, Stephen Clark wrote: >> Designers of gateways should be prepared for the fact that >> successful >> gateways will be copied and used in other situation and >> installations. Gateways must be prepared to accept datagrams as >> large as can be sent in the maximum packets of the directly >> attached >> networks. > > Doesn't this imply if a gateway has 2 interfaces, one with an mtu > of 1280 and the other > with an mtu of 1500 it should accept 1500 on either interface? Agreed-- if the traffic is going towards the network on the interface with the 1280 MTU, the gateway should accept and then either fragment such traffic or drop it, depending on whether DF is set. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 20:35:49 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6ACA16A400 for ; Fri, 13 Jul 2007 20:35:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id CF04A13C442 for ; Fri, 13 Jul 2007 20:35:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 13 Jul 2007 13:35:47 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 8E8B7125B26; Fri, 13 Jul 2007 13:35:46 -0700 (PDT) Message-ID: <4697E234.1070201@elischer.org> Date: Fri, 13 Jul 2007 13:36:04 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Stephen.Clark@seclark.us References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.wmoran@collaborativefusion.com> <4697A60C.4090409@seclark.us> <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> <20070713180840.GB8392@verio.net> <20070713152725.6ae40056.wmoran@collaborativefusion.com> <4697DF64.9070203@seclark.us> In-Reply-To: <4697DF64.9070203@seclark.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet 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, 13 Jul 2007 20:35:49 -0000 Stephen Clark wrote: > Chuck Swiger wrote: > >> On Jul 13, 2007, at 12:27 PM, Bill Moran wrote: >> >> >>>> I agree with others that MTU means "limit what I transmit". It >>>> does not >>>> mean "limit what someone else can transmit to me." >>>> >>> Interesting viewpoint. I disagree with it, but I can't quote any >>> standard >>> or otherwise to support my view. You didn't either. >>> >>> Does anyone know of a publicised, authoritative standard that would >>> clear this up? >>> >> >> Sure. RFC-791: >> >> "Fragmentation >> >> Fragmentation of an internet datagram is necessary when it >> originates in a local net that allows a large packet size and must >> traverse a local net that limits packets to a smaller size to reach >> its destination. >> >> An internet datagram can be marked "don't fragment." Any internet >> datagram so marked is not to be internet fragmented under any >> circumstances. If internet datagram marked don't fragment cannot be >> delivered to its destination without fragmenting it, it is to be >> discarded instead. >> >> Fragmentation, transmission and reassembly across a local network >> which is invisible to the internet protocol module is called >> intranet fragmentation and may be used [6]." >> >> RFC-879: >> >> " HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY >> HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO >> ACCEPT LARGER DATAGRAMS." >> >> "8. Maximum Packet Size >> >> Each network has some maximum packet size, or maximum transmission >> unit (MTU). Ultimately there is some limit imposed by the >> technology, but often the limit is an engineering choice or even an >> administrative choice. Different installations of the same network >> product do not have to use the same maximum packet size. Even within >> one installation not all host must use the same packet size (this way >> lies madness, though). >> >> Some IP implementers have assumed that all hosts on the directly >> attached network will be the same or at least run the same >> implementation. This is a dangerous assumption. It has often >> developed that after a small homogeneous set of host have become >> operational additional hosts of different types are introduced into >> the environment. And it has often developed that it is desired to >> use a copy of the implementation in a different inhomogeneous >> environment. >> >> Designers of gateways should be prepared for the fact that successful >> gateways will be copied and used in other situation and >> installations. Gateways must be prepared to accept datagrams as >> large as can be sent in the maximum packets of the directly attached >> networks. > Doesn't this imply if a gateway has 2 interfaces, one with an mtu of > 1280 and the other > with an mtu of 1500 it should accept 1500 on either interface? not specifically but I would.. > >> Gateway implementations should be easily configured for >> installation in different circumstances. >> >> A footnote: The MTUs of some popular networks (note that the actual >> limit in some installations may be set lower by administrative >> policy): >> >> ARPANET, MILNET = 1007 >> Ethernet (10Mb) = 1500 >> Proteon PRONET = 2046" >> >> RFC-894: >> >> " The minimum length of the data field of a packet sent over an >> Ethernet is 1500 octets, thus the maximum length of an IP datagram >> sent over an Ethernet is 1500 octets. Implementations are encouraged >> to support full-length packets. Gateway implementations MUST be >> prepared to accept full-length packets and fragment them if >> necessary. If a system cannot receive full-length packets, it should >> take steps to discourage others from sending them, such as using the >> TCP Maximum Segment Size option [4]. >> >> Note: Datagrams on the Ethernet may be longer than the general >> Internet default maximum packet size of 576 octets. Hosts connected >> to an Ethernet should keep this in mind when sending datagrams to >> hosts not on the same Ethernet. It may be appropriate to send >> smaller datagrams to avoid unnecessary fragmentation at intermediate >> gateways. Please see [4] for further information on this point." >> >> And RFCs 1122 and 1191 are also somewhat relevant. My reading of the >> above is that ethernet-capable gateways must be willing to accept >> packets as large as 1500 octets and fragment such traffic to meet the >> MTU settings as needed, except if DF is set. If DF is set, but the >> packet is addressed to the gateway itself, then it should be >> delivered unfragmented even if that packet exceeded the MTU set on >> the receiving interface. >> >> For hosts which are not network gateways, one should not assume them >> to be capable of receiving packets larger than 576 octets, but the >> TCP MSS option is almost universally available to indicate the >> appropriate maximum size that host is willing to receive during the >> 3WHS setup... >> >> >> > > From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 01:21:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F143616A402 for ; Sat, 14 Jul 2007 01:21:10 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (redrock.karels.net [206.196.45.2]) by mx1.freebsd.org (Postfix) with ESMTP id A4A5813C491 for ; Sat, 14 Jul 2007 01:21:10 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (localhost.karels.net [127.0.0.1]) by redrock.karels.net (8.13.8/8.13.6) with ESMTP id l6E16HWi006607; Fri, 13 Jul 2007 20:06:17 -0500 (CDT) (envelope-from karels@redrock.karels.net) Message-Id: <200707140106.l6E16HWi006607@redrock.karels.net> To: Julian Elischer From: Mike Karels In-reply-to: Your message of Fri, 13 Jul 2007 10:28:51 -0700. <4697B653.8050906@elischer.org> Date: Fri, 13 Jul 2007 20:06:17 -0500 Sender: karels@karels.net Cc: Stephen.Clark@seclark.us, freebsd-net@freebsd.org, Bill Moran , Sten Daniel Soersdal Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: karels@karels.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 01:21:11 -0000 > Bill Moran wrote: > ractices are > > still evolving. > > > > Let's flip the question around a bit: why would you _want_ the TCP stack > > to accept frames larger than the stated MTU? > > > Because mtu is mTu not mRu. I must agree. There is no strong requirement that MTU == MRU, although the standard BSD interface description does not include an MRU. As a practical example, I'll note that our (Secure Computing) version of the system provides an option to receive jumbo Ethernet frames without sending them; MRU is 9K or so, MTU is 1500. If the NIC (as programmed) is willing to receive the frame, we are willing to receive the packet at the protocol level. Similarly, if someone sets the MTU on an Ethernet interface to 1280, that does not really mean that frames up to 1500 bytes are nonconformant. > As the original BSD group always said.. (from my memories of Kirk's and > Mike's talks in 1991), > "Transmit strictly [according to the spec] but receive forgivingly". >From RFC-1122, and memorialized on the working group coffee cup on my bookshelf: Be liberal in what you accept, and conservative in what you send (attributed to RFC-791, but paraphrased; also in RFC-793; for those who don't recognize them, these are the original IP and TCP specs.) > The ability to receive packets larger than mtu was not accidental. > This should be fixed, if it is, as is suggested, a deliberate change. I'd be happy to see the change undone as well. I (well, our test group) found this change in a similar way, and it didn't agree with our previous usage. Mike From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 02:30:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9773616A400 for ; Sat, 14 Jul 2007 02:30:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6E09D13C428 for ; Sat, 14 Jul 2007 02:30:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id E1A399A85; Fri, 13 Jul 2007 22:30:55 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 13 Jul 2007 22:30:55 -0400 X-Sasl-enc: N04f8KdexVRz0GK1ybBT1oOKzWySAQTnffl4aQE/WBDK 1184380255 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 188FA62D1; Fri, 13 Jul 2007 22:30:54 -0400 (EDT) Message-ID: <4698355E.2030707@FreeBSD.org> Date: Sat, 14 Jul 2007 03:30:54 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: karels@karels.net References: <200707140106.l6E16HWi006607@redrock.karels.net> In-Reply-To: <200707140106.l6E16HWi006607@redrock.karels.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stephen.Clark@seclark.us, Sten Daniel Soersdal , Julian Elischer , Bill Moran , freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet 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, 14 Jul 2007 02:30:56 -0000 Mike Karels wrote: > I'd be happy to see the change undone as well. I (well, our test > group) found this change in a similar way, and it didn't agree with > our previous usage. > In -CURRENT my changes to the ethernet input path maintain the use of ETHER_MAX_FRAME() however the check is folded under #ifdef DIAGNOSTIC. I don't recall adding this conditional or touching it so it seems to be something which was already thereo radded by someone else. Could be pilot error; its use in -CURRENT seems to apply strictly to the use of large-receive offload (LRO). regards, BMS From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 03:31:05 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED93916A405 for ; Sat, 14 Jul 2007 03:31:05 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (redrock.karels.net [206.196.45.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9EA3213C478 for ; Sat, 14 Jul 2007 03:31:05 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (localhost.karels.net [127.0.0.1]) by redrock.karels.net (8.13.8/8.13.6) with ESMTP id l6E3RqWA007006; Fri, 13 Jul 2007 22:27:52 -0500 (CDT) (envelope-from karels@redrock.karels.net) Message-Id: <200707140327.l6E3RqWA007006@redrock.karels.net> To: "Bruce M. Simpson" From: Mike Karels In-reply-to: Your message of Sat, 14 Jul 2007 03:30:54 +0100. <4698355E.2030707@FreeBSD.org> Date: Fri, 13 Jul 2007 22:27:52 -0500 Sender: karels@karels.net Cc: Stephen.Clark@seclark.us, Sten Daniel Soersdal , Julian Elischer , Bill Moran , freebsd-net@FreeBSD.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: karels@karels.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 03:31:06 -0000 > In -CURRENT my changes to the ethernet input path maintain the use of > ETHER_MAX_FRAME() however the check is folded under #ifdef DIAGNOSTIC. I > don't recall adding this conditional or touching it so it seems to be > something which was already thereo radded by someone else. It has been there at least since 6.0. The issue is that ETHER_MAX_FRAME is computed using ifp->if_mtu, as opposed to something like ETHER_MAX_LEN. This is under #ifdef DIAGNOSTIC in -current, not in -stable. > Could be pilot error; its use in -CURRENT seems to apply strictly to the > use of large-receive offload (LRO). LRO relaxes the requirement, otherwise LRO packets would never pass the check. Mike From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 13:41:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BA6716A401 for ; Sat, 14 Jul 2007 13:41:43 +0000 (UTC) (envelope-from netslists@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 85FF913C478 for ; Sat, 14 Jul 2007 13:41:42 +0000 (UTC) (envelope-from netslists@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so814681uge for ; Sat, 14 Jul 2007 06:41:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qt2mC4Rww0nXfp9lLV2ZZIaNm5XnkUXEBZXBJf2rM73SvM6trPFioWaGMkwocd+f7XtCfKqAC0M7YcBloAjhY4nH6TXFDm1cSjUoKkY3tpHuf7ikmkBsrChGfszC/Bu/MdMbJ0ub4xE7Nt4ZXBT41oWYjdvKV6X1nUgpTzs+mEc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=WCbpRrWOmKYBnsmdwo/DgFJd1s2h4zAuyLcABFvtq/SobTCKy/cCKSzsypY8oZL9sZU5LOgY4h38GOUbkseY33kTGIayNAt2yS0PnBpxYnzAzizU1RBjSdLql+mf/ID+Bgf3vwPwFd529kT1s+ZHksullaFrXwa8T8X0/YjcWtU= Received: by 10.86.68.16 with SMTP id q16mr2116506fga.1184420501301; Sat, 14 Jul 2007 06:41:41 -0700 (PDT) Received: from ?192.168.9.8? ( [91.135.49.10]) by mx.google.com with ESMTP id f19sm5702795fka.2007.07.14.06.41.39 (version=SSLv3 cipher=RC4-MD5); Sat, 14 Jul 2007 06:41:39 -0700 (PDT) Message-ID: <4698D290.5080004@gmail.com> Date: Sat, 14 Jul 2007 15:41:36 +0200 From: Sten Daniel Soersdal User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephen.Clark@seclark.us References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> In-Reply-To: <46977741.8090301@seclark.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet 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, 14 Jul 2007 13:41:43 -0000 Stephen Clark wrote: > Sten Daniel Soersdal wrote: > >> Stephen Clark wrote: >> >> >>> Hello, >>> >>> Did something change in 6.2? If my mtu size on rl0 is 1280 it won't >>> accept a larger incomming packet. >>> >>> kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 >>> > max >>> 1294) >>> >> >> That is what to be expected. >> Incoming interface must have mtu set to the same mtu as all other >> hosts on the same L2 network. If mtu is set to the same as all other >> hosts, then it is impossible to receive a frame that is too large >> (assuming everything works). >> >> >> >>> I don't think it worked this way in the past. >>> >>> Won't this affect pmtud? >>> >> >> Incoming interface must have its mtu set to large enough to receive >> the frame. Outgoing interface, on the other hand, can be lower. >> >> For pmtud to work you need to be able to receive packets on an >> interface with sufficiently set mtu, but the exitting interface can >> have a lower mtu configured. Thus the router can accept the incoming >> packet but may drop and notify on a frame that is too large to exit >> the outgoing interface (assuming DF is set). >> >> >> >>> man page for ifconfig says mtu limits size of "transmission" not >>> reception. >>> >>> "mtu n Set the maximum transmission unit of the interface to n, >>> default >>> is interface specific." >>> >> >> Perhaps the man author considered reception to be implied? >> >> In any case, enforcing this on incoming packets is correct behavior. >> >> >> > But shouldn't an icmp be generated back to the system sending the packet > that is > being dropped? This is not happening. So the connection stalls. > > client mtu 1500 <-> |rl0 mtu 1500 FreeBSD Router rl1 mtu 1280| <-> some > host on internet > client sends syn saying i can do mss=1460 > host sends syn saying i can do mss=1460 > host tries to send packet of 1460 it get silently dropped. connection > stalls. > You are trying to lower the mtu on the wrong end. As i said, all hosts on the same L2 needs to share the same mtu. The router that forwarded you that packet is obviously not using the same mtu (otherwise it would not be able to forward it to you). Either you need to lower that routers local interface mtu or you need to raise your hosts mtu to match that of the router. Because ALL hosts on the same L2 network need to have the same mtu. -- Sten Daniel Soersdal From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 18:41:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B41416A404 for ; Sat, 14 Jul 2007 18:41:43 +0000 (UTC) (envelope-from brian@Awfulhak.org) Received: from storm.uk.FreeBSD.org (storm.uk.FreeBSD.org [194.242.157.42]) by mx1.freebsd.org (Postfix) with ESMTP id E615713C442 for ; Sat, 14 Jul 2007 18:41:42 +0000 (UTC) (envelope-from brian@Awfulhak.org) Received: from store.lan.Awfulhak.org (store.lan.Awfulhak.org [172.16.0.35]) by storm.uk.FreeBSD.org (8.14.1/8.14.1) with ESMTP id l6EIfeNY019018; Sat, 14 Jul 2007 19:41:40 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id E3D1B1957C7F; Sat, 14 Jul 2007 18:42:14 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Email Security Appliance) with ESMTP id 8C2BE1957C7D; Sat, 14 Jul 2007 18:42:10 +0000 (GMT) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.14.1/8.14.1) with ESMTP id l6EIfYXm015523; Sat, 14 Jul 2007 11:41:34 -0700 (PDT) (envelope-from brian@Awfulhak.org) Date: Sat, 14 Jul 2007 11:41:32 -0700 From: Brian Somers To: Brett Glass Message-ID: <20070714114132.6b395616@dev.lan.Awfulhak.org> In-Reply-To: <200707120114.TAA28481@lariat.net> References: <200707110014.SAA02181@lariat.net> <200707120114.TAA28481@lariat.net> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.13; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: Re: Bug in userland PPP LQR? 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, 14 Jul 2007 18:41:43 -0000 On Wed, 11 Jul 2007 19:14:03 -0600 Brett Glass wrote: > At 06:23 PM 7/11/2007, Mike Tancsa wrote: > > >Did you try and use just LCP echo mode instead ? I have come across a > >number of devices (especially GPRS/EVDO cards) that seem to say yes to > >supporting LQR, but do not. Try instead lcp echo > > I will try it. (To be more specific, I am going to try > > disable lqr > allow lqr accept lqr > enable echo > echoperiod 12 set echoperiod 12 > so that the peer can get LQR if it requests it.) But since this would > just be working around the bug I think might be there, it would also > be a good idea to look at how the LQR counter is managed. From what > I can see, the problem is that the counter either is cumulative or > counts irrevocably up to 5 after one LQR packet is missed. The > reason why I'd like to see more eyes than my own on this is that > it's difficult to see how and where the LQR routines are invoked > and how they react to a pattern of missed and un-missed packets. I'd also add "set log +lqm" to your configuration. Disabling lqr should just remove the problem as there will be no calls to SendLqrReport(). Try adding the lqm logging with lqr enabled too. It'd be interesting to see what's actually being sent out. I expect unacknowledged LQR packets to be resent 5 times (exactly the same packet), and the 6th timeout to cause a line drop. The spec says that the peer may ignore an LQR request if it's under load, but that it must respond to a duplicate LQR request. My suspicion is that some implementations just ignore LQR altogether under load. These implementations should disable LQR if they can't implement it properly. Of course the *other* option is to implement an LQM strategy. I've never come up with anything that might really be useful though - except for suggesting that LQR is disabled. -- Brian Somers Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 19:01:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E22316A403 for ; Sat, 14 Jul 2007 19:01:23 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id D62DB13C4B8 for ; Sat, 14 Jul 2007 19:01:22 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id NAA27366; Sat, 14 Jul 2007 13:01:13 -0600 (MDT) Message-Id: <200707141901.NAA27366@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 14 Jul 2007 13:01:06 -0600 To: Brian Somers From: Brett Glass In-Reply-To: <20070714114132.6b395616@dev.lan.Awfulhak.org> References: <200707110014.SAA02181@lariat.net> <200707120114.TAA28481@lariat.net> <20070714114132.6b395616@dev.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: Re: Bug in userland PPP LQR? 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, 14 Jul 2007 19:01:23 -0000 At 12:41 PM 7/14/2007, Brian Somers wrote: >> disable lqr >> allow lqr > >accept lqr > >> enable echo >> echoperiod 12 > >set echoperiod 12 Yes, found and fixed both of these mistakes. >I'd also add "set log +lqm" to your configuration. Will try that. >I expect unacknowledged LQR packets to be resent >5 times (exactly the same packet), and the 6th >timeout to cause a line drop. That's what I thought too. But it seems as if a single dropped packet among plenty of successful ones can cause the session to drop. This is why I am wondering if the counter is properly reset or if one missed packet leads to a permanent loss of synchronization. >The spec says that the peer may ignore an LQR >request if it's under load, but that it must >respond to a duplicate LQR request. My suspicion >is that some implementations just ignore LQR >altogether under load. These implementations >should disable LQR if they can't implement it >properly. I'm mostly dealing with the Linux pppd or ports of it on the clients (since it seems to be the most popular open source implementation, regardless of quality). --Brett Glass From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 19:12:35 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 448F516A401 for ; Sat, 14 Jul 2007 19:12:35 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-04.prod.mesa1.secureserver.net [64.202.165.17]) by mx1.freebsd.org (Postfix) with SMTP id 0D13613C442 for ; Sat, 14 Jul 2007 19:12:34 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 31087 invoked from network); 14 Jul 2007 19:12:34 -0000 Received: from unknown (24.144.77.243) by smtpout09-04.prod.mesa1.secureserver.net (64.202.165.17) with ESMTP; 14 Jul 2007 19:12:34 -0000 Message-ID: <46992021.8090603@seclark.us> Date: Sat, 14 Jul 2007 15:12:33 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sten Daniel Soersdal References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <4698D290.5080004@gmail.com> In-Reply-To: <4698D290.5080004@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 19:12:35 -0000 Sten Daniel Soersdal wrote: >Stephen Clark wrote: > > >>Sten Daniel Soersdal wrote: >> >> >> >>>Stephen Clark wrote: >>> >>> >>> >>> >>>>Hello, >>>> >>>>Did something change in 6.2? If my mtu size on rl0 is 1280 it won't >>>>accept a larger incomming packet. >>>> >>>>kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 >>>> >>>> >>>>>max >>>>> >>>>> >>>>1294) >>>> >>>> >>>> >>>That is what to be expected. >>>Incoming interface must have mtu set to the same mtu as all other >>>hosts on the same L2 network. If mtu is set to the same as all other >>>hosts, then it is impossible to receive a frame that is too large >>>(assuming everything works). >>> >>> >>> >>> >>> >>>>I don't think it worked this way in the past. >>>> >>>>Won't this affect pmtud? >>>> >>>> >>>> >>>Incoming interface must have its mtu set to large enough to receive >>>the frame. Outgoing interface, on the other hand, can be lower. >>> >>>For pmtud to work you need to be able to receive packets on an >>>interface with sufficiently set mtu, but the exitting interface can >>>have a lower mtu configured. Thus the router can accept the incoming >>>packet but may drop and notify on a frame that is too large to exit >>>the outgoing interface (assuming DF is set). >>> >>> >>> >>> >>> >>>>man page for ifconfig says mtu limits size of "transmission" not >>>>reception. >>>> >>>> "mtu n Set the maximum transmission unit of the interface to n, >>>>default >>>> is interface specific." >>>> >>>> >>>> >>>Perhaps the man author considered reception to be implied? >>> >>>In any case, enforcing this on incoming packets is correct behavior. >>> >>> >>> >>> >>> >>But shouldn't an icmp be generated back to the system sending the packet >>that is >>being dropped? This is not happening. So the connection stalls. >> >>client mtu 1500 <-> |rl0 mtu 1500 FreeBSD Router rl1 mtu 1280| <-> some >>host on internet >>client sends syn saying i can do mss=1460 >>host sends syn saying i can do mss=1460 >>host tries to send packet of 1460 it get silently dropped. connection >>stalls. >> >> >> > >You are trying to lower the mtu on the wrong end. >As i said, all hosts on the same L2 needs to share the same mtu. >The router that forwarded you that packet is obviously not using the >same mtu (otherwise it would not be able to forward it to you). >Either you need to lower that routers local interface mtu or you need to >raise your hosts mtu to match that of the router. >Because ALL hosts on the same L2 network need to have the same mtu. > > > I don't disagree - my issue is that this is new behavior in FreeBSD 6.x that did not exist in FreeBSD 4.x. However as many have said in thread : >From RFC-1122, and memorialized on the working group coffee cup on my bookshelf: Be liberal in what you accept, and conservative in what you send (attributed to RFC-791, but paraphrased; also in RFC-793; for those who don't recognize them, these are the original IP and TCP specs.) >> The ability to receive packets larger than mtu was not accidental. >> This should be fixed, if it is, as is suggested, a deliberate change. > > I'd be happy to see the change undone as well. I (well, our test group) found this change in a similar way, and it didn't agree with our previous usage. -- "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 Sat Jul 14 19:21:41 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 938A316A402; Sat, 14 Jul 2007 19:21:41 +0000 (UTC) (envelope-from brian@Awfulhak.org) Received: from storm.uk.FreeBSD.org (storm.uk.FreeBSD.org [194.242.157.42]) by mx1.freebsd.org (Postfix) with ESMTP id 326EE13C48E; Sat, 14 Jul 2007 19:21:41 +0000 (UTC) (envelope-from brian@Awfulhak.org) Received: from store.lan.Awfulhak.org (store.lan.Awfulhak.org [172.16.0.35]) by storm.uk.FreeBSD.org (8.14.1/8.14.1) with ESMTP id l6EJLdTa020148; Sat, 14 Jul 2007 20:21:39 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 370D11957C7F; Sat, 14 Jul 2007 19:22:14 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Email Security Appliance) with ESMTP id 2160A1957C9C; Sat, 14 Jul 2007 19:22:10 +0000 (GMT) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.14.1/8.14.1) with ESMTP id l6EJLXLS015959; Sat, 14 Jul 2007 12:21:34 -0700 (PDT) (envelope-from brian@Awfulhak.org) Date: Sat, 14 Jul 2007 12:21:32 -0700 From: Brian Somers To: Stefan Ehmann Message-ID: <20070714122132.0142f559@dev.lan.Awfulhak.org> In-Reply-To: <200704221318.50042.shoesoft@gmx.net> References: <200704221318.50042.shoesoft@gmx.net> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.13; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: tun devices and vpnc in CURRENT 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, 14 Jul 2007 19:21:41 -0000 On Sun, 22 Apr 2007 13:18:49 +0200 Stefan Ehmann wrote: > On CURRENT, each time I stop/start vpnc a new tun device is created. > Since I restart vpnc every time I re-connect to the network, my ifconfig > output fills up with tun devices. > > On 6.2-RELEASE the tun0 device is reused each time I run vpnc. > > Reverting to src/sys/net/if_tun.c rev 1.162 shows the old behaviour. (It seems > I'm noticing this a bit late) > > Is this a bug in either CURRENT or vpnc? > > If I set sysctl net.link.tun.devfs_cloning=0, vpnc doesn't work at all: > # vpnc > vpnc version 0.4.0 > kldload: can't load if_tun: File exists > can't initialise tunnel interface: No such file or directory > > This is a CURRENT as of today. Please tell me if you need more info. It looks like the problem is in the vpnc-script destroy_tun_device() function, but even if I add FreeBSD to that, it creates the additional interfaces. Maybe this is because I'm passing it bogus data and the connection attempt doesn't cleanup properly either. Have you tried talking to the port writer or maintainer? -- Brian Somers Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 20:32:46 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85F4D16A406; Sat, 14 Jul 2007 20:32:46 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6E213C4A3; Sat, 14 Jul 2007 20:32:46 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l6EK3IcK049070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2007 13:03:19 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46992C9C.8040308@errno.com> Date: Sat, 14 Jul 2007 13:05:48 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.0 (X11/20070530) MIME-Version: 1.0 To: karels@karels.net References: <200707140327.l6E3RqWA007006@redrock.karels.net> In-Reply-To: <200707140327.l6E3RqWA007006@redrock.karels.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bill Moran , Stephen.Clark@seclark.us, Julian Elischer , freebsd-net@freebsd.org, "Bruce M. Simpson" , Sten Daniel Soersdal Subject: Re: 6.2 mtu now limits size of incomming packet 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, 14 Jul 2007 20:32:46 -0000 Mike Karels wrote: >> In -CURRENT my changes to the ethernet input path maintain the use of >> ETHER_MAX_FRAME() however the check is folded under #ifdef DIAGNOSTIC. I >> don't recall adding this conditional or touching it so it seems to be >> something which was already thereo radded by someone else. > > It has been there at least since 6.0. The issue is that ETHER_MAX_FRAME > is computed using ifp->if_mtu, as opposed to something like ETHER_MAX_LEN. > This is under #ifdef DIAGNOSTIC in -current, not in -stable. > >> Could be pilot error; its use in -CURRENT seems to apply strictly to the >> use of large-receive offload (LRO). > > LRO relaxes the requirement, otherwise LRO packets would never pass the > check. I can't recall if I brought the check in when I moved a lot of common logic out of 802.3 drivers' rx intr handler or if it pre-dated that. I believe the code is shared with netbsd (which I cross-checked when I did that cleanup work). I think removing it is fine. As has been said mtu was never intended to be applied to the rx path. Sam From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 21:26:00 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EDE5516A403 for ; Sat, 14 Jul 2007 21:26:00 +0000 (UTC) (envelope-from brian@Awfulhak.org) Received: from storm.uk.FreeBSD.org (storm.uk.FreeBSD.org [194.242.157.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8B04D13C4D0 for ; Sat, 14 Jul 2007 21:26:00 +0000 (UTC) (envelope-from brian@Awfulhak.org) Received: from store.lan.Awfulhak.org (store.lan.Awfulhak.org [172.16.0.35]) by storm.uk.FreeBSD.org (8.14.1/8.14.1) with ESMTP id l6ELPwPr022919; Sat, 14 Jul 2007 22:25:58 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id E44AE1957C74; Sat, 14 Jul 2007 21:26:32 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Email Security Appliance) with ESMTP id D4C4C1957C56; Sat, 14 Jul 2007 21:26:28 +0000 (GMT) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.14.1/8.14.1) with ESMTP id l6ELPqJN017207; Sat, 14 Jul 2007 14:25:53 -0700 (PDT) (envelope-from brian@Awfulhak.org) Date: Sat, 14 Jul 2007 14:25:51 -0700 From: Brian Somers To: Brett Glass Message-ID: <20070714142551.52f9a6b4@dev.lan.Awfulhak.org> In-Reply-To: <200707141901.NAA27366@lariat.net> References: <200707110014.SAA02181@lariat.net> <200707120114.TAA28481@lariat.net> <20070714114132.6b395616@dev.lan.Awfulhak.org> <200707141901.NAA27366@lariat.net> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.13; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: Re: Bug in userland PPP LQR? 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, 14 Jul 2007 21:26:01 -0000 On Sat, 14 Jul 2007 13:01:06 -0600 Brett Glass wrote: > At 12:41 PM 7/14/2007, Brian Somers wrote: > >I expect unacknowledged LQR packets to be resent > >5 times (exactly the same packet), and the 6th > >timeout to cause a line drop. > > That's what I thought too. But it seems as if a > single dropped packet among plenty of successful > ones can cause the session to drop. This is > why I am wondering if the counter is properly reset > or if one missed packet leads to a permanent loss > of synchronization. The lqm logging should prove/disprove that ppp is sending the packet 6 times. The code *looks* ok. The counter is reset at line 236 of lqr.c (on receipt of an LQR packet). -- Brian Somers Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 23:46:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1239A16A400 for ; Sat, 14 Jul 2007 23:46:28 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id CCC6B13C48D for ; Sat, 14 Jul 2007 23:46:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 677A6470C7; Sat, 14 Jul 2007 19:46:27 -0400 (EDT) Date: Sun, 15 Jul 2007 00:46:27 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Karels In-Reply-To: <200707140106.l6E16HWi006607@redrock.karels.net> Message-ID: <20070715003156.B94899@fledge.watson.org> References: <200707140106.l6E16HWi006607@redrock.karels.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Stephen.Clark@seclark.us, Sten Daniel Soersdal , Julian Elischer , Bill Moran , freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet 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, 14 Jul 2007 23:46:28 -0000 On Fri, 13 Jul 2007, Mike Karels wrote: >> The ability to receive packets larger than mtu was not accidental. This >> should be fixed, if it is, as is suggested, a deliberate change. > > I'd be happy to see the change undone as well. I (well, our test group) > found this change in a similar way, and it didn't agree with our previous > usage. A related change that should probably be discussed if we want to think more about asymmetry in maximum transmission unit is this one: ---------------------------- revision 1.98 date: 2006/06/26 17:54:53; author: andre; state: Exp; lines: +2 -0 In syncache_respond() do not reply with a MSS that is larger than what the peer announced to us but make it at least tcp_minmss in size. Sponsored by: TCP/IP Optimization Fundraise 2005 ---------------------------- In this change, we cap the advertised MSS in SYN/ACK to the received advertised MSS, which presumably avoids an extra PMTU round trip if jumbograms are enabled on the receiving endpoint. However, it also prevents use of larger packet sizes if asymmetric MTU is supported. I think I suggested after this was committed that we at least add an administrative twiddle to enable/disable this mode of operation, but don't see one in there currently. Does the Secure Computing scenario use TCP in this way, and is the potential win in avoiding a PMTU round-trip worth disallowing asymmetric MSS at the TCP layer? Robert N M Watson Computer Laboratory University of Cambridge