From owner-freebsd-net@FreeBSD.ORG Sun Nov 16 08:50:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F3B51065687 for ; Sun, 16 Nov 2008 08:50:56 +0000 (UTC) (envelope-from kayvey@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id AB2188FC18 for ; Sun, 16 Nov 2008 08:50:54 +0000 (UTC) (envelope-from kayvey@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so807590eyi.7 for ; Sun, 16 Nov 2008 00:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=+CAmEkZyqWgIqIgBVOrzPqg9giz+HtmFH4uluuRr6gE=; b=DMehu0C4RQcFEl3VACikTK4Rdk80tSQyLCzxJbr7JvJiBK30dPKzJNDm+WsAg21Kqr nB8tOJi31qd7CrxFha+omELppnpxXOLNpTfB0GgOjmiQWLomURlzXs/5gnmBS5DXlQd/ ig24G25ObiLEwd/+tATt4zzVBzOTeTmDLZpl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=gqNIIBOTgdOpysr3GID+FiTwGetMBlvxMviFXhYkrkQ6M5zKHbScXpdiQLIbRQriZB iZKt4NcC/2vyuufCss9v0c9XHhoriUd578tIrJX/rC/YxXaeEnZfsQg/6o5PJ6WFqmHL EetnhomVNndsh31lAXEPj9lyI9vm9/UJN0Y6o= Received: by 10.210.109.10 with SMTP id h10mr2782212ebc.154.1226823538002; Sun, 16 Nov 2008 00:18:58 -0800 (PST) Received: by 10.210.68.20 with HTTP; Sun, 16 Nov 2008 00:18:57 -0800 (PST) Message-ID: <28b9b4180811160018q2823d7fap90b546ba444f191d@mail.gmail.com> Date: Sun, 16 Nov 2008 00:18:57 -0800 From: "Kayven Riese" To: freebsd-net@freebsd.org, freebsd-mobile@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: driver support for Belkin F5D7050 v 5xxx ? 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, 16 Nov 2008 08:50:56 -0000 I just purchased a wireless connection device that connects to my ASUS M6800N laptop dual booting Vista and KV_BSD# uname -a FreeBSD KV_BSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 KV_BSD# via USB. While booting on Vista, connection was fine. I investigated my man pages for Belkin modles in the interfaces: V_BSD# man an | grep Belkin KV_BSD# man awi | grep Belkin KV_BSD# man ipw | grep Belkin KV_BSD# set -o vi KV_BSD# man iwi | grep Belkin KV_BSD# man ral | grep Belkin Belkin F5D7000 v3 RT2560 PCI Belkin F5D7010 v2 RT2560 CardBus KV_BSD# man rum | grep Belkin Belkin F5D7050 ver 3 USB Belkin F5D9050 ver 3 USB KV_BSD# man ural | grep Belkin Belkin F5D7050 v2000 USB KV_BSD# man wi | grep Belkin Belkin F5D6000 (a rebadged WL11000P) KV_BSD# man zyd | grep Belkin Belkin F5D7050 v.4000 KV_BSD# and found some websites that made me compare a serial number that I correlated to some information on the Belkin website and came to the conclusion that my device is a newer version than appears in the above list because of this information: K7SF5D7050E corresponds to version 5xxx That serial number is written on the device. There were no unfamiliar results of ifconfig: KV_BSD# ifconfig bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:11:d8:22:c9:91 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX ) status: active fwe0: flags=8802 metric 0 mtu 1500 options=8 ether 02:e0:18:26:4c:e9 ch 1 dma -1 fwip0: flags=8802 metric 0 mtu 1500 lladdr 0.e0.18.0.3.26.4c.e9.a.2.ff.fe.0.0.0.0 plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 KV_BSD# I attempted to use the ndisgen utility with the driver disk mounted on "/mnt/drive" KV_BSD# pwd /mnt/drive KV_BSD# ls AUTORUN.INF Belkin.ico Installer.exe UserManual Acrobat Reader InstallationFiles Installer.ini KV_BSD# cd InstallationFiles KV_BSD# ls Belkin.bmp Setup.exe VistaX64 WinXP2K data1.hdr layout.bin ISSetup.dll Setup.ini VistaX86 _Setup.dll data2.cab SETUP.ISS Setup.inx WinX64 data1.cab ikernel.ex_ KV_BSD# ls WinXP2K BLKWGU.inf BLKWGU.sys blkwgu.cat twice, once using the BLKWGU.inf and BLKWGU.sys files from the WinXP2K directory and again adding the blkwgu.cat file using the menu that ndisgen gives, and both times it terminated with success: ================================================================== ------------------ Windows(r) driver converter ------------------- ================================================================== Kernel module generation The script will now try to generate the kernel driver module. This is the last step. Once this module is generated, you should be able to load it just like any other FreeBSD driver module. Press enter to compile the stub module and generate the driver module now: Generating Makefile... done. Building kernel module... done. Cleaning up... done. The file BLKWGU_sys.ko has been successfully generated. You can kldload this module to get started. Press return to exit. When I tried to use the kldload command in both cases, the system rebooted. I messed around with /boot/loader.conf, including many of the interfaces that were noted above "man if | grep Belkin," and right now this is what it looks like: KV_BSD# cat /boot/loader.conf hint.ichss.0.disabled="1" W32DRIVER_load="YES" wlan_load="YES" firmware_load="YES" if_zyd_load="YES" wlan_scan_ap_load="YES" wlan_scan_sta_load="YES" wlan_wep_load="YES" wlan_ccmp_load="YES" wlan_tkip_load="YES" I note that the device is showing up in dmesg KV_BSD# dmesg | grep Belkin ugen0: on uhub3 ugen0: on uhub3 ugen0: on uhub3 ugen0: on uhub3 KV_BSD# some other info.. KV_BSD# pciconf -lv hostb0@pci0:0:0:0: class=0x060000 card=0x186a1043 chip=0x33408086 rev=0x21 hdr=0x00 vendor = 'Intel Cor . . none1@pci0:0:31:6: class=0x070300 card=0x18261043 chip=0x24c68086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller' class = simple comms subclass = generic modem vgapci0@pci0:1:0:0: class=0x030000 card=0x17721043 chip=0x4e501002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Mobility Radeon 9700 (M10 NP) (RV350)' class = display subclass = VGA bge0@pci0:2:0:0: class=0x020000 card=0x17351043 chip=0x169c14e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5788 Broadcom NetLink (TM) Gigabit Ethernet' class = network subclass = ethernet cbb0@pci0:2:1:0: class=0x060700 card=0x18641043 chip=0x04761180 rev=0xac hdr=0x02 vendor = 'Ricoh Company, Ltd.' device = 'unknown Ricoh R/RL/5C476(II)' class = bridge subclass = PCI-CardBus cbb1@pci0:2:1:1: class=0x060700 card=0x18641043 chip=0x04761180 rev=0xac hdr=0x02 vendor = 'Ricoh Company, Ltd.' device = 'unknown Ricoh R/RL/5C476(II)' class = bridge subclass = PCI-CardBus fwohci0@pci0:2:1:2: class=0x0c0010 card=0x18671043 chip=0x05521180 rev=0x04 hdr=0x00 vendor = 'Ricoh Company, Ltd.' device = 'RL5c552 IEEE-1394 Controller' class = serial bus subclass = FireWire none2@pci0:2:2:0: class=0x028000 card=0x10008086 chip=0x42238086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '2915ABG Intel (R) PRO/Wireless 2200BG Network Connection, (R) PRO/Wireless 2915ABG Network Connection' class = network KV_BSD# usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 addr 2: low speed, power 100 mA, config 1, USB Optical Mouse(0xc019), Logitech(0x046d), rev 43.01 port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb3: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 addr 2: high speed, power 500 mA, config 1, Belkin Wireless G USB Adapter(0x705e), vendor 0x050d(0x050d), rev 2.00 port 3 powered port 4 powered port 5 powered port 6 powered KV_BSD# exit Thanks to anyone in advance who gives me the time of day. I looked at some of the archives and felt these two lists seemed appropriate. Forgive me if I misused the lists. *----------------------------------------------------------* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *----------------------------------------------------------* From owner-freebsd-net@FreeBSD.ORG Sun Nov 16 11:58:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 919871065689 for ; Sun, 16 Nov 2008 11:58:59 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 492CC8FC1C for ; Sun, 16 Nov 2008 11:58:59 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so862459yxb.13 for ; Sun, 16 Nov 2008 03:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=8V+dCTyrAPBDNCwJVobSNth89Od3yU3sSgfeK9Hn6rI=; b=xTE7oppXU719Fl3srJM2KUxI0N+e9P2c+Ol4cqo4XZgBsg0qaxmPI588+63x7XHLRl vi0aJF8mGc2U35fbZsCC9HifZyAIrfj5SISYJzSOhQ9/YLmykbQCSzjKTpYE2hDvHCTY bci93pu+cry/0PEbk5ei2qqdo4gDkgptRVgrk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Cu5udzt+pgT5l8RcXWKTatspILu3uug2WGMLObEPfo4Fe3Rglw9Yrc4nARH0XOJFgS Q8FepoPRODP9lZrwklwvAUshpr2O6xnCWnhmoSBakZaebk2sT+ik7mgCStXL4qKhIhyO vI1+RE3v32Bqz6NkEYBX5pQJm4bQLLsN57fmY= Received: by 10.64.242.4 with SMTP id p4mr2704784qbh.84.1226835323562; Sun, 16 Nov 2008 03:35:23 -0800 (PST) Received: by 10.65.216.9 with HTTP; Sun, 16 Nov 2008 03:35:23 -0800 (PST) Message-ID: <3a142e750811160335y6867d362k93a525774bc3667@mail.gmail.com> Date: Sun, 16 Nov 2008 12:35:23 +0100 From: "Paul B. Mahol" To: "Kayven Riese" In-Reply-To: <28b9b4180811160018q2823d7fap90b546ba444f191d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <28b9b4180811160018q2823d7fap90b546ba444f191d@mail.gmail.com> Cc: freebsd-net@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: driver support for Belkin F5D7050 v 5xxx ? 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, 16 Nov 2008 11:58:59 -0000 On 11/16/08, Kayven Riese wrote: > I just purchased a wireless connection device that connects to my ASUS > M6800N laptop dual > booting Vista and > > KV_BSD# uname -a > FreeBSD KV_BSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC > 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > KV_BSD# > > via USB. > > While booting on Vista, connection was fine. I investigated my man pages > for Belkin modles in > the interfaces: > V_BSD# man an | grep Belkin > KV_BSD# man awi | grep Belkin > KV_BSD# man ipw | grep Belkin > KV_BSD# set -o vi > KV_BSD# man iwi | grep Belkin > KV_BSD# man ral | grep Belkin > Belkin F5D7000 v3 RT2560 PCI > Belkin F5D7010 v2 RT2560 CardBus > KV_BSD# man rum | grep Belkin > Belkin F5D7050 ver 3 USB > Belkin F5D9050 ver 3 USB > KV_BSD# man ural | grep Belkin > Belkin F5D7050 v2000 USB > KV_BSD# man wi | grep Belkin > Belkin F5D6000 (a rebadged WL11000P) > KV_BSD# man zyd | grep Belkin > Belkin F5D7050 v.4000 > KV_BSD# > > and found some websites that made me compare a serial number that I > correlated to some > information on the Belkin website and came to the conclusion that my device > is a newer > version than appears in the above list because of this information: > > K7SF5D7050E corresponds to version 5xxx > > That serial number is written on the device. > > There were no unfamiliar results of ifconfig: > > > > KV_BSD# ifconfig > bge0: flags=8843 metric 0 mtu 1500 > options=9b > ether 00:11:d8:22:c9:91 > inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 > media: Ethernet autoselect (100baseTX ) > status: active > fwe0: flags=8802 metric 0 mtu 1500 > options=8 > ether 02:e0:18:26:4c:e9 > ch 1 dma -1 > fwip0: flags=8802 metric 0 mtu 1500 > lladdr 0.e0.18.0.3.26.4c.e9.a.2.ff.fe.0.0.0.0 > plip0: flags=108810 metric 0 mtu > 1500 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > KV_BSD# > > I attempted to use the ndisgen utility with the driver disk mounted on > "/mnt/drive" > Currently ndis on freebsd doesnt support usb cards at all. There is patch available for CURRENT that is considered experimental and make possible to use ndis on FreeBSD with usb cards. > KV_BSD# pwd > /mnt/drive > KV_BSD# ls > AUTORUN.INF Belkin.ico Installer.exe UserManual > Acrobat Reader InstallationFiles Installer.ini > KV_BSD# cd InstallationFiles > KV_BSD# ls > Belkin.bmp Setup.exe VistaX64 WinXP2K data1.hdr > layout.bin > ISSetup.dll Setup.ini VistaX86 _Setup.dll data2.cab > SETUP.ISS Setup.inx WinX64 data1.cab ikernel.ex_ > KV_BSD# ls WinXP2K > BLKWGU.inf BLKWGU.sys blkwgu.cat > > twice, once using the BLKWGU.inf and BLKWGU.sys files from the WinXP2K > directory and again > adding the blkwgu.cat file using the menu that ndisgen gives, and both times > it terminated > with success: > > ================================================================== > ------------------ Windows(r) driver converter ------------------- > ================================================================== > > Kernel module generation > > > The script will now try to generate the kernel driver module. > This is the last step. Once this module is generated, you should > be able to load it just like any other FreeBSD driver module. > > Press enter to compile the stub module and generate the driver > module now: > > Generating Makefile... done. > Building kernel module... done. > Cleaning up... done. > > The file BLKWGU_sys.ko has been successfully generated. > You can kldload this module to get started. > > Press return to exit. > > When I tried to use the kldload command in both cases, the system rebooted. > > I messed around with /boot/loader.conf, including many of the interfaces > that were > noted above "man if | grep Belkin," and right now this is what it looks > like: > KV_BSD# cat /boot/loader.conf > hint.ichss.0.disabled="1" > W32DRIVER_load="YES" > wlan_load="YES" > firmware_load="YES" > if_zyd_load="YES" > wlan_scan_ap_load="YES" > wlan_scan_sta_load="YES" > wlan_wep_load="YES" > wlan_ccmp_load="YES" > wlan_tkip_load="YES" > > I note that the device is showing up in dmesg > > KV_BSD# dmesg | grep Belkin > ugen0: 2.00/2.00, addr 2> on uhub3 > ugen0: 2.00/2.00, addr 2> on uhub3 > ugen0: 2.00/2.00, addr 2> on uhub3 > ugen0: 2.00/2.00, addr 2> on uhub3 > KV_BSD# > > > some other info.. > > > KV_BSD# pciconf -lv > hostb0@pci0:0:0:0: class=0x060000 card=0x186a1043 chip=0x33408086 > rev=0x21 hdr=0x00 > vendor = 'Intel Cor > . > > . > > none1@pci0:0:31:6: class=0x070300 card=0x18261043 chip=0x24c68086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem > Controller' > class = simple comms > subclass = generic modem > vgapci0@pci0:1:0:0: class=0x030000 card=0x17721043 chip=0x4e501002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'Mobility Radeon 9700 (M10 NP) (RV350)' > class = display > subclass = VGA > bge0@pci0:2:0:0: class=0x020000 card=0x17351043 chip=0x169c14e4 rev=0x03 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5788 Broadcom NetLink (TM) Gigabit Ethernet' > class = network > subclass = ethernet > cbb0@pci0:2:1:0: class=0x060700 card=0x18641043 chip=0x04761180 rev=0xac > hdr=0x02 > vendor = 'Ricoh Company, Ltd.' > device = 'unknown Ricoh R/RL/5C476(II)' > class = bridge > subclass = PCI-CardBus > cbb1@pci0:2:1:1: class=0x060700 card=0x18641043 chip=0x04761180 rev=0xac > hdr=0x02 > vendor = 'Ricoh Company, Ltd.' > device = 'unknown Ricoh R/RL/5C476(II)' > class = bridge > subclass = PCI-CardBus > fwohci0@pci0:2:1:2: class=0x0c0010 card=0x18671043 chip=0x05521180 > rev=0x04 hdr=0x00 > vendor = 'Ricoh Company, Ltd.' > device = 'RL5c552 IEEE-1394 Controller' > class = serial bus > subclass = FireWire > none2@pci0:2:2:0: class=0x028000 card=0x10008086 chip=0x42238086 rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = '2915ABG Intel (R) PRO/Wireless 2200BG Network Connection, > (R) PRO/Wireless 2915ABG Network Connection' > class = network > KV_BSD# usbdevs -v > Controller /dev/usb0: > addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), > Intel(0x0000), rev 1.00 > port 1 powered > port 2 powered > Controller /dev/usb1: > addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), > Intel(0x0000), rev 1.00 > port 1 addr 2: low speed, power 100 mA, config 1, USB Optical > Mouse(0xc019), Logitech(0x046d), rev 43.01 > port 2 powered > Controller /dev/usb2: > addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), > Intel(0x0000), rev 1.00 > port 1 powered > port 2 powered > Controller /dev/usb3: > addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), > Intel(0x0000), rev 1.00 > port 1 powered > port 2 addr 2: high speed, power 500 mA, config 1, Belkin Wireless G USB > Adapter(0x705e), vendor 0x050d(0x050d), rev 2.00 > port 3 powered > port 4 powered > port 5 powered > port 6 powered > KV_BSD# exit > > Thanks to anyone in advance who gives me the time of day. I looked at some > of the archives and felt these two > lists seemed appropriate. Forgive me if I misused the lists. > > > *----------------------------------------------------------* > Kayven Riese, BSCS, > MS (Physiology and Biophysics) > (415) 902 5513 cellular > http://kayve.net > Webmaster http://ChessYoga.org > *----------------------------------------------------------* > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Nov 16 12:27:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C31801065695 for ; Sun, 16 Nov 2008 12:27:37 +0000 (UTC) (envelope-from yonyossef.lists@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.191]) by mx1.freebsd.org (Postfix) with ESMTP id 74E428FC14 for ; Sun, 16 Nov 2008 12:27:37 +0000 (UTC) (envelope-from yonyossef.lists@gmail.com) Received: by rn-out-0910.google.com with SMTP id j71so2036602rne.12 for ; Sun, 16 Nov 2008 04:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=DHsNYSSW94+rvGVu0aozJMsfu3qLmukGIRMd8DfqmdY=; b=Id964GyagyoYkdS7y7mmK8MnHn5hrvne3ujesH2kRxJnjVFMtkFOWtlKZ/D8TMVr5N NJfHQ0FTVSrOr4O4Zr4TaA8GppgPy9RYef1x5IAmCpUOfypvnRuHRdvdgC4G6f6diSEd DeR9FfQG7S++yEB0F2hBukIkFcqsqSnxkXPiU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=GIetj1LPGHCA6V3gZ2ctnu8fhZXl9u2xkBhQwYKLEOy8BQfb5r+cpEpwuypzgFvI45 oFUZuGTWuZnmJigKoNmfk5wf7tZahDUwQCii3IesQ0jh+jFp2xvqezjkq++HLOJ/1b/r QDB+wPBfPjcJAH3dDGdjDKO9TfHk9I4l8mdHE= Received: by 10.150.202.8 with SMTP id z8mr5765277ybf.37.1226838456443; Sun, 16 Nov 2008 04:27:36 -0800 (PST) Received: by 10.150.124.5 with HTTP; Sun, 16 Nov 2008 04:27:36 -0800 (PST) Message-ID: <20def4870811160427k1a718a8es9287220c03f71f26@mail.gmail.com> Date: Sun, 16 Nov 2008 14:27:36 +0200 From: "Yony Yossef" To: "Jeremy Chadwick" In-Reply-To: <20081116121345.GA952@icarus.home.lan> MIME-Version: 1.0 References: <20def4870811160403i67f9e8d6i1a52e93d1b68c5ad@mail.gmail.com> <20081116121345.GA952@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Yehonatan Yossef , freebsd-questions@freebsd.org, liranl@mellanox.co.il Subject: Re: HW VLAN Filtering on FreeBSD 6.3 + 7.0 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, 16 Nov 2008 12:27:38 -0000 > > > I would like to enable my NIC HW VLAN filtering, is there any way for > my > > driver to access the OS vlan table? (something like vlan_group_get_device > on > > linux) > > > > I understood from previous investigation that on FreeBSD 6.3 and 7.0 > there's > > no ioctl informing the driver of vlan addition/removal. Is that correct? > > Man pages to check out: vlan(4) and ifconfig(8). I'm pretty sure the > vlan tagging feature is per-driver. > Also, the vlan(4) list of supported drivers is out of date (for example, > em(4) is missing), so be sure to check the man page of your NIC driver. Sorry, i explained myself pretty bad. I'm working on an Ethernet driver for FreeBSD. The VLAN hw tagging is already working properly, but my nic is capable of holding a vlan table on hw, filtering vlans on it's own. I need to find a way to update that hw table. one way is to recieve a ioctl from the OS of it's vlan table event (add, remove). I can't find such ioctl. second is to have a direct access from the driver to the OS vlan table. I'm not familiar with the interface or if it's possible at all, and that is my actual question. Thanks Yony From owner-freebsd-net@FreeBSD.ORG Sun Nov 16 12:29:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A6F5106564A for ; Sun, 16 Nov 2008 12:29:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 202448FC0C for ; Sun, 16 Nov 2008 12:29:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id fo3D1a0020cQ2SLA4oDmh2; Sun, 16 Nov 2008 12:13:46 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id foDl1a0022P6wsM8WoDlBR; Sun, 16 Nov 2008 12:13:46 +0000 X-Authority-Analysis: v=1.0 c=1 a=6DhFfMlRuDsA:10 a=26nLF3QrrG0A:10 a=QycZ5dHgAAAA:8 a=NOCtGtdb3hBXjMRsbZ8A:9 a=7Kk88k79HDH06MiNl0kA:7 a=8qCjTKgiMswSVmAji9Pt8MgW7zQA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 309E433C36; Sun, 16 Nov 2008 04:13:45 -0800 (PST) Date: Sun, 16 Nov 2008 04:13:45 -0800 From: Jeremy Chadwick To: Yony Yossef Message-ID: <20081116121345.GA952@icarus.home.lan> References: <20def4870811160403i67f9e8d6i1a52e93d1b68c5ad@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20def4870811160403i67f9e8d6i1a52e93d1b68c5ad@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-net@freebsd.org, Yehonatan Yossef , freebsd-questions@freebsd.org, liranl@mellanox.co.il Subject: Re: HW VLAN Filtering on FreeBSD 6.3 + 7.0 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, 16 Nov 2008 12:29:46 -0000 On Sun, Nov 16, 2008 at 02:03:54PM +0200, Yony Yossef wrote: > I would like to enable my NIC HW VLAN filtering, is there any way for my > driver to access the OS vlan table? (something like vlan_group_get_device on > linux) > > I understood from previous investigation that on FreeBSD 6.3 and 7.0 there's > no ioctl informing the driver of vlan addition/removal. Is that correct? Man pages to check out: vlan(4) and ifconfig(8). I'm pretty sure the vlan tagging feature is per-driver. Also, the vlan(4) list of supported drivers is out of date (for example, em(4) is missing), so be sure to check the man page of your NIC driver. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-net@FreeBSD.ORG Sun Nov 16 12:35:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B709106564A for ; Sun, 16 Nov 2008 12:35:38 +0000 (UTC) (envelope-from yonyossef.lists@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id B48608FC08 for ; Sun, 16 Nov 2008 12:35:37 +0000 (UTC) (envelope-from yonyossef.lists@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so864988ywe.13 for ; Sun, 16 Nov 2008 04:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=qx50QlJ6LGg2QVH/Ohen3IrzRCXo2qOHZ71sJoQSkWA=; b=fBvxtEqjUouYHPL5j0KGo4mvRr6y+dnV2B0cV4azjpzDU9g9mTAgW2nYy7ipaa6QVQ PgX3wtb4Gb9KXWQUEXxO5anQVZaERIY3iYMEfiUSzuEq5A3JWCcx5X1PLfi0TywE0Amd wH6VTVIDZGqsmSi0nXIj+3A2IdXLMWDM5B8Vk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=mIZU6DR1VoPu9iq2oEFpvQep6ynUDk/ur/cx6Ckh4LSlx5hMtlLLAPrUeO3XfGQUza drCp1yFsFRIdqeX8jZHaLwuImoyAlTg0sCHQhsWs7SB24ssnnQwL90bgR4TezK2tBsjT Ukn9HyCbEg2jAgcyUK5liDpj0S/5aPsyYobdk= Received: by 10.151.108.13 with SMTP id k13mr5705839ybm.160.1226837034650; Sun, 16 Nov 2008 04:03:54 -0800 (PST) Received: by 10.150.124.5 with HTTP; Sun, 16 Nov 2008 04:03:54 -0800 (PST) Message-ID: <20def4870811160403i67f9e8d6i1a52e93d1b68c5ad@mail.gmail.com> Date: Sun, 16 Nov 2008 14:03:54 +0200 From: "Yony Yossef" To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org, liranl@mellanox.co.il, "Yehonatan Yossef" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: HW VLAN Filtering on FreeBSD 6.3 + 7.0 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, 16 Nov 2008 12:35:38 -0000 Hi All, I would like to enable my NIC HW VLAN filtering, is there any way for my driver to access the OS vlan table? (something like vlan_group_get_device on linux) I understood from previous investigation that on FreeBSD 6.3 and 7.0 there's no ioctl informing the driver of vlan addition/removal. Is that correct? Thanks, Yony From owner-freebsd-net@FreeBSD.ORG Sun Nov 16 12:49:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAB611065677 for ; Sun, 16 Nov 2008 12:49:06 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 753E58FC12 for ; Sun, 16 Nov 2008 12:49:06 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA01.westchester.pa.mail.comcast.net with comcast id fniY1a00317dt5G51obqYv; Sun, 16 Nov 2008 12:35:50 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA13.westchester.pa.mail.comcast.net with comcast id fobp1a0012P6wsM3ZobpX6; Sun, 16 Nov 2008 12:35:50 +0000 X-Authority-Analysis: v=1.0 c=1 a=6DhFfMlRuDsA:10 a=26nLF3QrrG0A:10 a=QycZ5dHgAAAA:8 a=am93mdXYGLi2k7DCcPoA:9 a=yMPGIt8WYO6JulCFK-UA:7 a=txcwMbo6XZkXGGgq-d_k3OLNy04A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id DFC9633C36; Sun, 16 Nov 2008 04:35:48 -0800 (PST) Date: Sun, 16 Nov 2008 04:35:48 -0800 From: Jeremy Chadwick To: Yony Yossef Message-ID: <20081116123548.GA1531@icarus.home.lan> References: <20def4870811160403i67f9e8d6i1a52e93d1b68c5ad@mail.gmail.com> <20081116121345.GA952@icarus.home.lan> <20def4870811160427k1a718a8es9287220c03f71f26@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20def4870811160427k1a718a8es9287220c03f71f26@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-net@freebsd.org, Yehonatan Yossef , freebsd-questions@freebsd.org, liranl@mellanox.co.il Subject: Re: HW VLAN Filtering on FreeBSD 6.3 + 7.0 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, 16 Nov 2008 12:49:06 -0000 On Sun, Nov 16, 2008 at 02:27:36PM +0200, Yony Yossef wrote: > > > I would like to enable my NIC HW VLAN filtering, is there any way for > > my > > > driver to access the OS vlan table? (something like vlan_group_get_device > > on > > > linux) > > > > > > I understood from previous investigation that on FreeBSD 6.3 and 7.0 > > there's > > > no ioctl informing the driver of vlan addition/removal. Is that correct? > > > > Man pages to check out: vlan(4) and ifconfig(8). I'm pretty sure the > > vlan tagging feature is per-driver. > > > Also, the vlan(4) list of supported drivers is out of date (for example, > > em(4) is missing), so be sure to check the man page of your NIC driver. > > Sorry, i explained myself pretty bad. I'm working on an Ethernet driver for > FreeBSD. > The VLAN hw tagging is already working properly, but my nic is capable of > holding a vlan table on hw, filtering vlans on it's own. > I need to find a way to update that hw table. > one way is to recieve a ioctl from the OS of it's vlan table event (add, > remove). I can't find such ioctl. > second is to have a direct access from the driver to the OS vlan table. I'm > not familiar with the interface or if it's possible at all, and that is my > actual question. This question should go to freebsd-hackers. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-net@FreeBSD.ORG Sun Nov 16 13:02:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 893B11065670 for ; Sun, 16 Nov 2008 13:02:26 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 275CC8FC0A for ; Sun, 16 Nov 2008 13:02:25 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.100] ([172.21.151.1]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Nov 2008 13:56:09 +0100 Message-ID: <49201859.2080605@dlr.de> Date: Sun, 16 Nov 2008 13:55:53 +0100 From: Hartmut Brandt User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Rui Paulo References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> In-Reply-To: <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2008 12:56:09.0863 (UTC) FILETIME=[B273E970:01C947EA] Cc: freebsd-net@freebsd.org Subject: Re: TCP and syncache question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2008 13:02:26 -0000 Rui Paulo wrote: > > On 15 Nov 2008, at 20:08, Hartmut Brandt wrote: > >> Hi, >> >> in tcp_syncache.c:syncache_expand() there is a test that the >> acknowledgement number and the sequence number of an incoming ACK >> segment are in the expected range. If they are not, syncache_expand() >> returns 0 and tcp_input drops the segment and sets a reset. So far so >> good. But syncache_expand() also deletes the syncache entry, and so >> destroys the connection. I cannot see why it does it. It seems to me >> that such a wrong segment should be interpreted as to be from another >> connection and as such the segment should be ignored (but a reset >> sent). When the correct ACK comes, the connection could still be >> established. As it is now, the establishment of incoming connections >> can seriously be disturbed by someone sending fake ACK packets. >> >> The same test (for the ack number, not for the sequence number) is >> also further down in tcp_input.c:tcp_do_segment() (just after the >> header prediction stuff) and here the handling is correct: the goto >> dropwithreset just sends a reset and drops the segment but leaves the >> connection in the SYN-RECEIVED state. This test is probably never >> reached now, because of syncache_expand(), though. >> >> Maybe I fail to see something obvious, though... > > > Well, if the RST is sent, why should we keep the syncache entry? Because this effectively destroys the connection in SYN-RECEIVED which is wrong according to RFC793. On page 69 the handling of incoming segments for connections in SYN-RECEIVED is described: first you check the sequence number and, if it is wrong, you send an RST (unless the RST bit is set in the incoming segment), but otherwise ignore the segment. A segment with a bad sequence number in SYN-RECEIVED is either forged or from an old connection. In both cases you don't want to destroy the embryonic connection, because the correct ACK from the correct peer may still arrive. harti From owner-freebsd-net@FreeBSD.ORG Sun Nov 16 21:50:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9B3A10656B4 for ; Sun, 16 Nov 2008 21:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AA2E18FC18 for ; Sun, 16 Nov 2008 21:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAGLo4p1045454 for ; Sun, 16 Nov 2008 21:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAGLo4UJ045453; Sun, 16 Nov 2008 21:50:04 GMT (envelope-from gnats) Date: Sun, 16 Nov 2008 21:50:04 GMT Message-Id: <200811162150.mAGLo4UJ045453@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Marius Strobl Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marius Strobl List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2008 21:50:04 -0000 The following reply was made to PR kern/128833; it has been noted by GNATS. From: Marius Strobl To: =?unknown-8bit?Q?Aur=E9lien_M=E9r=E9?= Cc: bug-followup@FreeBSD.org Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Sun, 16 Nov 2008 22:45:33 +0100 On Sat, Nov 15, 2008 at 02:01:50AM +0100, Aurlien Mr wrote: > Hi > I installed the patch there are still the same issues : > > 0x0060: 6965 2d68 656c 6c6d 616e 2d67 726f 7570 ie-hellman-group > 0x0070: 2d65 7863 6861 6e67 2c64 6966 6669 652d -exchang,diffie- > 0x0080: 2c64 6966 6669 652d 6865 6c6c 6d61 6e2d ,diffie-hellman- > 0x0090: 6772 6f75 702d 6578 6368 616e 6765 2d73 group-exchange-s > 0x00a0: 6861 312c 6469 6666 6965 2d68 656c 6c6d ha1,diffie-hellm > 0x00b0: 616e 2d67 726f 7570 3134 2d73 6861 312c an-group14-sha1, > 0x00c0: 6469 6666 6965 2d68 656c 6c6d 616e 2d67 diffie-hellman-g > > 0x0060: 6965 2d68 656c 6c6d 616e 2d67 726f 7570 ie-hellman-group > 0x0070: 2d65 7863 6861 6e67 652d 7368 6132 3536 -exchange-sha256 > 0x0080: 2c64 6966 6669 652d 6865 6c6c 6d61 6e2d ,diffie-hellman- > 0x0090: 6772 6f75 702d 6578 6368 616e 6765 2d73 group-exchange-s > 0x00a0: 6861 312c 6469 6666 6965 2d68 656c 6c6d ha1,diffie-hellm > 0x00b0: 616e 2d67 726f 7570 3134 2d73 6861 312c an-group14-sha1, > 0x00c0: 6469 6666 6965 2d68 656c 6c6d 616e 2d67 diffie-hellman-g > > I will try to add some debug, don't hesitate to tell me if you have other > ideas so i can do more tests. Ok, thanks for testing anyway. I still think that this isn't really a driver bug though but you are hitting some hardware-related problem like f.e. a silicon bug and the question is how to work around it. Looking at the bge(4) versions of the other BSDs and the corresponding Linux and OpenSolaris drivers I can't spot a such a workaround apart from the already known PCI-X issue, unfortunately. The only other thing that comes to my mind is that you might suffer from sort of the opposite of the problem worked around by ti_64bitslot_war() (the NICs driven by ti(4) are the predecessors of those supported by bge(4)). Given that this also involves the BIOS that could then explain why you're see first person to hit this problem. Could you please instrument bge(4) to print the content of the BGE_PCI_PCISTATE register and report back which values it's initialized to depending on which type of slot the card is plugged into? Marius From owner-freebsd-net@FreeBSD.ORG Sun Nov 16 23:28:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF92F1065675 for ; Sun, 16 Nov 2008 23:28:02 +0000 (UTC) (envelope-from glavoie@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id 86A658FC08 for ; Sun, 16 Nov 2008 23:28:02 +0000 (UTC) (envelope-from glavoie@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2087358rvf.43 for ; Sun, 16 Nov 2008 15:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=Xm0ZI6BzfX0IbD3U9/VJZ/1/uzCd163R51SSUGkK8ls=; b=K4Db51aEPxSIvAU4rKuK34UGValLbFR7Po3q4zU+X4sWYSmBv20EdS2V6JQpqSlvJH H8Fy1FbUZAZdqPnOrR8Z5LgjOAy2+i4lNLVNk0kkCMKPkwYFqQiwQa0hlzZLSBros+0v 30NCOqWUV+Lv96qlT0zNFrtAOpVZN+G4a2ci8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=iV+41FwHQm8Ei5cZ3RO1HcKTf9LMjw/fF/JaOT+dmx4OC9+eG7jdQIstLyFO96Y8x+ jfK5i+inANlDSEwtoFXsFdHTkNMLxjftGDgLX/HQamsWt3foPB1GiPR4YsO9zvCmxzPV Qyr9WGuh0agE2FfhXh4xe1Dw9nZ8IhCR2yJNY= Received: by 10.141.180.5 with SMTP id h5mr1878187rvp.238.1226876518870; Sun, 16 Nov 2008 15:01:58 -0800 (PST) Received: by 10.141.146.8 with HTTP; Sun, 16 Nov 2008 15:01:58 -0800 (PST) Message-ID: Date: Sun, 16 Nov 2008 18:01:58 -0500 From: "Gabriel Lavoie" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Realtek 8139 with rl(4) driver -> Poor performance 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, 16 Nov 2008 23:28:02 -0000 Hello, I recently built a new system to use as a home server. This system has an Intel Pentium Dual Core E5200, 4GB RAM and an Asus P5KPL-CM motherboard which has an Atheros L1E network adapter, not yet supported on FreeBSD. For now, I use a Realtek 8139 PCI adapter that uses the rl(4) driver, but the upload performances are really poor (under 1 MB/sec). Is there any way to improve the performance with this driver? This adapter was in a Linux system with a Pentium III processor before and I could upload/download at around 10 MB/sec in my local network with no problem at all. Thanks! -- Gabriel Lavoie glavoie@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 00:01:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50676106567B for ; Mon, 17 Nov 2008 00:01:58 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id CBE808FC19 for ; Mon, 17 Nov 2008 00:01:57 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so282884ugs.39 for ; Sun, 16 Nov 2008 16:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=0MvPiWlGGxA4ubCaD5dr7wZhRJ24IuAJbq8QIqpl6dE=; b=NcPw8MQhoFikJnJkFp7/2IBdY3h6UCLzhXrwabaxBuxvVE8E5d2DyvqP8xih89awDa Xq99jF4J1NPPT76nCJTliElSsT3rxIBD7Behl9D75XX8jcuULzBt7XUPU7kr4PPnH0g7 jRy7rzeAUZT+KkhMA2wcv/TAvG3BxzaO3WZgE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=I0rVF7Crj/nf6UI2sXhxbIYInHu4vEhugzAw1F47xYWAext834F7dDUasiOPbvrZ1K LLeA4VYtB3r1IKDvu2MrR71HZxODRbAgFT5ljRPLPeIlEenO9l8KlkfOIn2vBaP42ahx QA2dECL2oNNQHrf0g0LeZcPSN7f5YOT+c9D7M= Received: by 10.66.252.18 with SMTP id z18mr1024964ugh.30.1226880116483; Sun, 16 Nov 2008 16:01:56 -0800 (PST) Received: from epsilon.lan (bl6-146-52.dsl.telepac.pt [82.155.146.52]) by mx.google.com with ESMTPS id m38sm1788510ugd.51.2008.11.16.16.01.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Nov 2008 16:01:55 -0800 (PST) Message-Id: <27C5037E-25AB-4EA5-B4DA-445A4B4218F1@freebsd.org> From: Rui Paulo To: Hartmut Brandt In-Reply-To: <49201859.2080605@dlr.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 00:01:52 +0000 References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> X-Mailer: Apple Mail (2.929.2) Sender: Rui Paulo Cc: freebsd-net@freebsd.org Subject: Re: TCP and syncache question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 00:01:58 -0000 On 16 Nov 2008, at 12:55, Hartmut Brandt wrote: > Rui Paulo wrote: >> >> On 15 Nov 2008, at 20:08, Hartmut Brandt wrote: >> >>> Hi, >>> >>> in tcp_syncache.c:syncache_expand() there is a test that the >>> acknowledgement number and the sequence number of an incoming ACK >>> segment are in the expected range. If they are not, >>> syncache_expand() returns 0 and tcp_input drops the segment and >>> sets a reset. So far so good. But syncache_expand() also deletes >>> the syncache entry, and so destroys the connection. I cannot see >>> why it does it. It seems to me that such a wrong segment should be >>> interpreted as to be from another connection and as such the >>> segment should be ignored (but a reset sent). When the correct ACK >>> comes, the connection could still be established. As it is now, >>> the establishment of incoming connections can seriously be >>> disturbed by someone sending fake ACK packets. >>> >>> The same test (for the ack number, not for the sequence number) is >>> also further down in tcp_input.c:tcp_do_segment() (just after the >>> header prediction stuff) and here the handling is correct: the >>> goto dropwithreset just sends a reset and drops the segment but >>> leaves the connection in the SYN-RECEIVED state. This test is >>> probably never reached now, because of syncache_expand(), though. >>> >>> Maybe I fail to see something obvious, though... >> >> >> Well, if the RST is sent, why should we keep the syncache entry? > > Because this effectively destroys the connection in SYN-RECEIVED > which is wrong according to RFC793. On page 69 the handling of > incoming segments for connections in SYN-RECEIVED is described: > first you check the sequence number and, if it is wrong, you send an > RST (unless the RST bit is set in the incoming segment), but > otherwise ignore the segment. > > A segment with a bad sequence number in SYN-RECEIVED is either > forged or from an old connection. In both cases you don't want to > destroy the embryonic connection, because the correct ACK from the > correct peer may still arrive. That clarifies your initial email. You're probably right, I'll try to find out when the bug was introduced. Thanks, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 00:36:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8F89106567C for ; Mon, 17 Nov 2008 00:36:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by mx1.freebsd.org (Postfix) with ESMTP id CC24A8FC16 for ; Mon, 17 Nov 2008 00:36:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id a1so1264741tib.3 for ; Sun, 16 Nov 2008 16:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=jIDMSOrG4aDWfmq4oWwb5f6vYzU3OyISAzJKl9oeuCU=; b=Z2Uu2c9Dt3UFZT2+8gQRu/z9ApBH3kzGWqhgXLUlsaMPrpDWQxmgRagZ1wD3npDaI3 3ZIP9FvvNJrHT2ZvWxsgXv5wa9qjqJ2MPAHLTKXjlVynglWml3k7SOTEdItUyMpQn4Oi zyqLyYDPMOcSGQD77EZoeq6kbnTEihm5rTtZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=fWi0kmqsBqqVyVGhK/IULpu4nlA9wAa7XnTb/1YtCs1nH7LVtcaOmxHibotf93Ds9S nHA1hWSi6evjNumpXIbC1OKBtHgtr5UMyWaMX/FSkrZvHO9pd6NdTkJy1RSF1kA1o+NI GZPq0yQ5WiEV79zjeS/re3BVbgjLfvCy+YgNw= Received: by 10.110.60.2 with SMTP id i2mr4427532tia.28.1226882170738; Sun, 16 Nov 2008 16:36:10 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id y3sm4973646tia.6.2008.11.16.16.36.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Nov 2008 16:36:09 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mAH0Y4DX051042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 09:34:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mAH0Y2Au051041; Mon, 17 Nov 2008 09:34:02 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 17 Nov 2008 09:34:02 +0900 From: Pyun YongHyeon To: Yony Yossef Message-ID: <20081117003402.GA50872@cdnetworks.co.kr> References: <20def4870811160403i67f9e8d6i1a52e93d1b68c5ad@mail.gmail.com> <20081116121345.GA952@icarus.home.lan> <20def4870811160427k1a718a8es9287220c03f71f26@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20def4870811160427k1a718a8es9287220c03f71f26@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, Jeremy Chadwick , Yehonatan Yossef , freebsd-questions@freebsd.org, liranl@mellanox.co.il Subject: Re: HW VLAN Filtering on FreeBSD 6.3 + 7.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 00:36:13 -0000 On Sun, Nov 16, 2008 at 02:27:36PM +0200, Yony Yossef wrote: > > > > > I would like to enable my NIC HW VLAN filtering, is there any way for > > my > > > driver to access the OS vlan table? (something like vlan_group_get_device > > on > > > linux) > > > > > > I understood from previous investigation that on FreeBSD 6.3 and 7.0 > > there's > > > no ioctl informing the driver of vlan addition/removal. Is that correct? > > > > Man pages to check out: vlan(4) and ifconfig(8). I'm pretty sure the > > vlan tagging feature is per-driver. > > > > Also, the vlan(4) list of supported drivers is out of date (for example, > > em(4) is missing), so be sure to check the man page of your NIC driver. > > > Sorry, i explained myself pretty bad. I'm working on an Ethernet driver for > FreeBSD. > The VLAN hw tagging is already working properly, but my nic is capable of > holding a vlan table on hw, filtering vlans on it's own. > I need to find a way to update that hw table. > one way is to recieve a ioctl from the OS of it's vlan table event (add, > remove). I can't find such ioctl. FreeBSD doesn't use ioctl to manipulate VLAN HW table. > second is to have a direct access from the driver to the OS vlan table. I'm > not familiar with the interface or if it's possible at all, and that is my > actual question. > See EVENT_HANDLER(9) and igb(4) for working example. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 00:41:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 535381065677 for ; Mon, 17 Nov 2008 00:41:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by mx1.freebsd.org (Postfix) with ESMTP id DB5A28FC1E for ; Mon, 17 Nov 2008 00:41:02 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id a1so1265415tib.3 for ; Sun, 16 Nov 2008 16:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=wG8R2pgXFi2AfQCHa2LJOKsQ2dEw1csWL98Yruka5/8=; b=qai5Gp3eGCy3duVm98/iea05aaybILCDONuS+PeWGn00maqYmHZ/XfSwWW+cxVOvX6 I2A3gx929QRYZaeP+ZpCndnBk2ju71UYAdral/RabIbV6tGut+ABnR+OV4BabmtU7B/B zHBx9xV8mLxiEWwTlO88ZA1qi+QRJUuBrqPn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=fRz6oI21+IWUkicaEzCel4kGfDCPWh5oIEd5uJH6Pfj1jyP39Jn6+xjAlJ5GupzJLi hygqMXLGJ6z2nju2NutMHzVoEJ+a2FGLM0NUTEw4q70vw1BZnh+qt80/UK9vEpQKtypU zTgv2UepeDHUd7ENhtDb5QfpcMnRoeAAB9sJQ= Received: by 10.110.15.19 with SMTP id 19mr4366584tio.57.1226882461679; Sun, 16 Nov 2008 16:41:01 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id y5sm8636905tia.13.2008.11.16.16.40.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Nov 2008 16:41:00 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mAH0cvPu051062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 09:38:57 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mAH0cuNW051061; Mon, 17 Nov 2008 09:38:56 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 17 Nov 2008 09:38:56 +0900 From: Pyun YongHyeon To: Gabriel Lavoie Message-ID: <20081117003856.GB50872@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Realtek 8139 with rl(4) driver -> Poor performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 00:41:03 -0000 On Sun, Nov 16, 2008 at 06:01:58PM -0500, Gabriel Lavoie wrote: > Hello, > I recently built a new system to use as a home server. This system has > an Intel Pentium Dual Core E5200, 4GB RAM and an Asus P5KPL-CM motherboard > which has an Atheros L1E network adapter, not yet supported on FreeBSD. For ale(4) was committed to HEAD. If you're using lastest stable/7 see the following URL. http://people.freebsd.org/~yongari/ale/README > now, I use a Realtek 8139 PCI adapter that uses the rl(4) driver, but the > upload performances are really poor (under 1 MB/sec). Is there any way to > improve the performance with this driver? This adapter was in a Linux system > with a Pentium III processor before and I could upload/download at around 10 > MB/sec in my local network with no problem at all. > There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. How about rl(4) in HEAD? I guess it would build with minor modification. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 00:47:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3DBF106564A for ; Mon, 17 Nov 2008 00:47:34 +0000 (UTC) (envelope-from glavoie@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8695B8FC17 for ; Mon, 17 Nov 2008 00:47:34 +0000 (UTC) (envelope-from glavoie@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2106830rvf.43 for ; Sun, 16 Nov 2008 16:47:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=pdIRxBsAnc+/Wmmxdqshz5X+Uhg02SJK4ayIUr2i0+Y=; b=fu5IS0KNFN/Or+9XuB+DiE8AvZ8ngdWg3Gk9FBCpFqiSwd1EKhuMo7utQ304Zld8H+ Zcj+/sxKm99PjRmJPa2k++DMiwXllpmtMJ3sxz5zcrIbzKLGf9ve+CnxIlt307qLXpWk 6CT7wzjc25T/7UTNe69s9IKqpkptlL7dbD4EE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=Ju6ksHSBGyINSpZr8WkF6jlKneFgT3p9+Pd8G1t7cjedqMREcYzyDHGEUvp61Oe8fG hjuSR9BMle0zOXSJNRtOgMFPuFvOg8mYqNXhTpJ3quwAci/JHWin9XP3Q/7Qsk+iVh3Y FQQQ9fUpMpVatD+vQeOaCAVx2BxS/Z1JabLwE= Received: by 10.141.161.6 with SMTP id n6mr1931386rvo.55.1226882854181; Sun, 16 Nov 2008 16:47:34 -0800 (PST) Received: by 10.141.146.8 with HTTP; Sun, 16 Nov 2008 16:47:34 -0800 (PST) Message-ID: Date: Sun, 16 Nov 2008 19:47:34 -0500 From: "Gabriel Lavoie" To: pyunyh@gmail.com In-Reply-To: <20081117003856.GB50872@cdnetworks.co.kr> MIME-Version: 1.0 References: <20081117003856.GB50872@cdnetworks.co.kr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Realtek 8139 with rl(4) driver -> Poor performance 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, 17 Nov 2008 00:47:34 -0000 I guess I'll have to try both solutions! Thanks for your help. Gabriel 2008/11/16 Pyun YongHyeon > On Sun, Nov 16, 2008 at 06:01:58PM -0500, Gabriel Lavoie wrote: > > Hello, > > I recently built a new system to use as a home server. This system > has > > an Intel Pentium Dual Core E5200, 4GB RAM and an Asus P5KPL-CM > motherboard > > which has an Atheros L1E network adapter, not yet supported on FreeBSD. > For > > ale(4) was committed to HEAD. If you're using lastest stable/7 > see the following URL. > http://people.freebsd.org/~yongari/ale/README > > > now, I use a Realtek 8139 PCI adapter that uses the rl(4) driver, but > the > > upload performances are really poor (under 1 MB/sec). Is there any way > to > > improve the performance with this driver? This adapter was in a Linux > system > > with a Pentium III processor before and I could upload/download at > around 10 > > MB/sec in my local network with no problem at all. > > > > There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. > How about rl(4) in HEAD? I guess it would build with minor > modification. > > -- > Regards, > Pyun YongHyeon > -- Gabriel Lavoie glavoie@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 02:32:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 824FD1065670 for ; Mon, 17 Nov 2008 02:32:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9078FC0A for ; Mon, 17 Nov 2008 02:32:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2135396rvf.43 for ; Sun, 16 Nov 2008 18:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Q+hY+Dm9YBuW9kf/e86giN1YdpOM994GFjwYMF2wAi4=; b=r1H6Nf6X36ATxer94hlwhR/EAoU7Z4ujAPyZSNsnR6qSvqAPN3ebacaCpWt9WdVnL6 H2nf8oC18N57qjPMODgHiuXrSqqAAKZhcpb1Hw4m03wcSm4pijIdB3qmCw7Lb5ZXIa8c 55BqMlgNeeVSQ6rvpYITZNhmHVyVTQCKNX2uw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Nga4+UnWDCLlPbmr+Rp0fSkBrmQTjNK0EQlxw6MmaY0N33kOpxNaFIQIRVqpErEFNT z0PmLfKCWKc3IVn0DfIcEpoP2q14lcsEM4qUB3R0E3z3JAt7E2XAWILMx2uS64mAiA0S yzeVlz/ZITl1MF4nUXBF3iyCXNsbCvQ3Ctl/s= Received: by 10.140.165.21 with SMTP id n21mr1958772rve.240.1226889146918; Sun, 16 Nov 2008 18:32:26 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id k2sm8234099rvb.1.2008.11.16.18.32.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Nov 2008 18:32:26 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mAH2UOVE051407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 11:30:24 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mAH2UOll051406; Mon, 17 Nov 2008 11:30:24 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 17 Nov 2008 11:30:24 +0900 From: Pyun YongHyeon To: bf Message-ID: <20081117023024.GE50872@cdnetworks.co.kr> References: <957411.42240.qm@web39101.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <957411.42240.qm@web39101.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Realtek 8139 with rl(4) driver -> Poor performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 02:32:27 -0000 On Sun, Nov 16, 2008 at 06:26:34PM -0800, bf wrote: > > > There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. > > How about rl(4) in HEAD? I guess it would build with minor > > modification. > > > > -- > > Regards, > > Pyun YongHyeon > > I meant to ask about this: I think you are referring to r184240-3 committed > around Oct. 25, partly in response to PR kern/128143, right? Is there any Yes. > plan to merge these changes to RELENG_7, either before or after the > release of 7.1? > I'll MFC the change after 7.1-RELEASE. Did the change set r184240 fix your issue? -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 02:53:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CC59106564A for ; Mon, 17 Nov 2008 02:53:17 +0000 (UTC) (envelope-from bf2006a@yahoo.com) Received: from web39101.mail.mud.yahoo.com (web39101.mail.mud.yahoo.com [209.191.86.252]) by mx1.freebsd.org (Postfix) with SMTP id 1693E8FC1D for ; Mon, 17 Nov 2008 02:53:16 +0000 (UTC) (envelope-from bf2006a@yahoo.com) Received: (qmail 45141 invoked by uid 60001); 17 Nov 2008 02:26:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=YrEtLCZ4MApzUkS9KW1fH5MCxj/4YuG8H7ui6axqp3Wa2qetRqKyWWPisqka9WSqxG0GPMra3E/Ge+djCWbQ2dKVePOVja8jej4fnbxMEBJtmkxJ12MoXbqYuVJJ7a6TYtOADir37UzaaWMAxO021p7CnLKB7Wp/iqKdgAz3sCg=; X-YMail-OSG: HTuU6U4VM1lBO9M4hQL8cV1iRjAgpLBKwTB7UuGuM3VMa1dPg7jofyKS9UgidoRrxU6zOkr6C9SO78e5I2MSrHmPe0W_QQGorQMbqn.hZPJ3j_LLMQp4xrBZ6daTRKwvpZcBgH5hZoCuI6SGjMPhdW7pVfbddSS2g55E0SdPARtplbxTZ54koPBbIw-- Received: from [87.118.101.102] by web39101.mail.mud.yahoo.com via HTTP; Sun, 16 Nov 2008 18:26:34 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Sun, 16 Nov 2008 18:26:34 -0800 (PST) From: bf To: freebsd-net@freebsd.org, pyunyh@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <957411.42240.qm@web39101.mail.mud.yahoo.com> Cc: Subject: Re: Realtek 8139 with rl(4) driver -> Poor performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf2006a@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 02:53:17 -0000 > There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. > How about rl(4) in HEAD? I guess it would build with minor > modification. > > -- > Regards, > Pyun YongHyeon I meant to ask about this: I think you are referring to r184240-3 committed around Oct. 25, partly in response to PR kern/128143, right? Is there any plan to merge these changes to RELENG_7, either before or after the release of 7.1? Thanks, b. From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 03:03:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FA8E106564A for ; Mon, 17 Nov 2008 03:03:16 +0000 (UTC) (envelope-from glavoie@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id 011108FC13 for ; Mon, 17 Nov 2008 03:03:15 +0000 (UTC) (envelope-from glavoie@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2144030rvf.43 for ; Sun, 16 Nov 2008 19:03:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=188nhIhqSjSQfDAIugd78/mdE8ECnTg03FMeocMbJXI=; b=c5GJUB1QpLs1oi1N/IQW/E5fwslrmpxnNiFnv9JCXsnMSRBlVueD38mrZvY34s6XbW H57foBUUm3KRCpbVSvMJzCcHYR1g8/Ya+kQGLBnQIYc8+albEcRkxk9yN1LTyzWzsmnH zbBZUEuOC1QlokpcgrmVjQXaUTIZ60zRaLQtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=lslAaeQN+kLoMyc/AXW7v14yCTqIj6iRQn0ERMOBMXjG4ixxG2S+ftPuVcYiN1M3Ej zqhLL4ETdTC9n0C4epEX7hVFxl58zZiv5tw41x+2Zptjf8Drp8r2QPVU2hT2PRgtA8ZB fqWuk4a0tZ/yEdfJyDQJDw6g4qU97BO6rjAO0= Received: by 10.140.141.16 with SMTP id o16mr1979577rvd.138.1226890995487; Sun, 16 Nov 2008 19:03:15 -0800 (PST) Received: by 10.141.146.8 with HTTP; Sun, 16 Nov 2008 19:03:15 -0800 (PST) Message-ID: Date: Sun, 16 Nov 2008 22:03:15 -0500 From: "Gabriel Lavoie" To: pyunyh@gmail.com In-Reply-To: <20081117023024.GE50872@cdnetworks.co.kr> MIME-Version: 1.0 References: <957411.42240.qm@web39101.mail.mud.yahoo.com> <20081117023024.GE50872@cdnetworks.co.kr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bf , freebsd-net@freebsd.org Subject: Re: Realtek 8139 with rl(4) driver -> Poor performance 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, 17 Nov 2008 03:03:16 -0000 All right! rl(4) from HEAD solved my problem! I now get a solid 11.2 MB/sec file transfer, on both directions. I found about this problem because my Samba share was too slow. The Samba problem is solved. Thanks! 2008/11/16 Pyun YongHyeon > On Sun, Nov 16, 2008 at 06:26:34PM -0800, bf wrote: > > > > > There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. > > > How about rl(4) in HEAD? I guess it would build with minor > > > modification. > > > > > > -- > > > Regards, > > > Pyun YongHyeon > > > > I meant to ask about this: I think you are referring to r184240-3 > committed > > around Oct. 25, partly in response to PR kern/128143, right? Is there > any > > Yes. > > > plan to merge these changes to RELENG_7, either before or after the > > release of 7.1? > > > > I'll MFC the change after 7.1-RELEASE. > Did the change set r184240 fix your issue? > > -- > Regards, > Pyun YongHyeon > _______________________________________________ > 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" > -- Gabriel Lavoie glavoie@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 03:23:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B6141065670 for ; Mon, 17 Nov 2008 03:23:51 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.freebsd.org (Postfix) with ESMTP id 29B9E8FC18 for ; Mon, 17 Nov 2008 03:23:50 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.183]) by hub.org (Postfix) with ESMTP id 9C74611A2C9B for ; Sun, 16 Nov 2008 23:23:50 -0400 (AST) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 24760-04 for ; Sun, 16 Nov 2008 23:23:50 -0400 (AST) Received: from [192.168.1.2] (blk-224-204-104.eastlink.ca [24.224.204.104]) by hub.org (Postfix) with ESMTPA id ED38211A2C99 for ; Sun, 16 Nov 2008 23:23:49 -0400 (AST) Date: Sun, 16 Nov 2008 23:23:46 -0400 From: "Marc G. Fournier" To: freebsd-net@freebsd.org Message-ID: <4EF60FA893CC822B1EDE2FCB@ganymede.hub.org> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: bridged networking disappears ... 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, 17 Nov 2008 03:23:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm playing with bridges right now, under FreeBSD 7.x, to connect a QEMU env to the internet ... works like a charm, except periodically the network just becomes unpingable ... I've setup a cron within the QEMU environment to ping once a minute, which seems to 'fix' it, but that sounds more a bandaid then a fix ... Is this normal (I can't see how) or am I missing something with setting up the bridge? - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkg48IACgkQ4QvfyHIvDvPR8QCfWvlQzq8R0dq/Bijr25EzZdBK ULMAoI4h+yv44mFHPN6ivMcj/xLcLDl4 =tusp -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 03:46:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74FC41065673 for ; Mon, 17 Nov 2008 03:46:31 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id 3BCFA8FC1A for ; Mon, 17 Nov 2008 03:46:31 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2155670rvf.43 for ; Sun, 16 Nov 2008 19:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=zUXKAKHmhxdV2aSyZMfUwziEtI9Yio2nlmlHIT2YkF0=; b=VEIoYpKxQlqz3rHlAyXZcMJM5Y/CXVvIIxz06rxPoBA4kIaMbJoeUQ+F3oKE5B9WGX 3+lH+jeeVH0EbN7GmnSZOoJJLTCsRz7Pqbnjz7e1KRGZONYGvdGj4c5UY3UwoqdaXywb acs0jbzwPjvPLO0xEum83U2cKFXyiOn472z9Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ZKmGbWP+Hh1Y3bYhjuI7zSSXJLLbY58hrT76Ca1PCXbyFoXf6YX4FqswFlSSQMC3Po VqBenlqwhDVbvOx6Jpq6hZmJ4bvl0ZP2cm6L5hfmh8XgnRSi26VMS+3K+FnZDDX2E+AV hC4D5uTXHkQdETik39HZzjctRcwa9CcuHsj9E= Received: by 10.140.164.1 with SMTP id m1mr1990006rve.212.1226893590768; Sun, 16 Nov 2008 19:46:30 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id f42sm5615969rvb.6.2008.11.16.19.46.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Nov 2008 19:46:29 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mAH3iSkl051637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 12:44:28 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mAH3iS9f051636; Mon, 17 Nov 2008 12:44:28 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 17 Nov 2008 12:44:28 +0900 From: Pyun YongHyeon To: Gabriel Lavoie Message-ID: <20081117034428.GG50872@cdnetworks.co.kr> References: <957411.42240.qm@web39101.mail.mud.yahoo.com> <20081117023024.GE50872@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: bf , freebsd-net@freebsd.org Subject: Re: Realtek 8139 with rl(4) driver -> Poor performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 03:46:31 -0000 On Sun, Nov 16, 2008 at 10:03:15PM -0500, Gabriel Lavoie wrote: > All right! rl(4) from HEAD solved my problem! I now get a solid 11.2 MB/sec > file transfer, on both directions. I found about this problem because my > Samba share was too slow. The Samba problem is solved. > Glad to hear that. :-) > Thanks! > > 2008/11/16 Pyun YongHyeon > > > On Sun, Nov 16, 2008 at 06:26:34PM -0800, bf wrote: > > > > > > > There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. > > > > How about rl(4) in HEAD? I guess it would build with minor > > > > modification. > > > > > > > > -- > > > > Regards, > > > > Pyun YongHyeon > > > > > > I meant to ask about this: I think you are referring to r184240-3 > > committed > > > around Oct. 25, partly in response to PR kern/128143, right? Is there > > any > > > > Yes. > > > > > plan to merge these changes to RELENG_7, either before or after the > > > release of 7.1? > > > > > > > I'll MFC the change after 7.1-RELEASE. > > Did the change set r184240 fix your issue? > > > > -- -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 04:18:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEB561065670 for ; Mon, 17 Nov 2008 04:18:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 8587C8FC13 for ; Mon, 17 Nov 2008 04:18:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2164449rvf.43 for ; Sun, 16 Nov 2008 20:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=TAttYnG2yMYp6Sv3PhIHoPky5BBbqIBP/2JLJjkpTD0=; b=FCb5NKMR8IU9E70+o7vkcOPmc6jlXtRWbpS8+d7R3BWvypjFaSA9A2KajrdeFE9DIs HOEHcBVvcITqSaL+Acpas7UB3dMgCA2IW2WUhG0WuPwnrdMhhtn4evkISoWgiPoGj5yi bzwG06SsHibAhOVwUpzI0qDXeJs1m7Zs1kWm4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=YUFXBmnmOVxnVH4tri7HTaXbjNTeldSAnoEtyDJ/QicTOKycrmEYh8hGHeRLiy/78h hbCgI90UIPSLs7Yu21geyZE0laBkNMLYznS/DOt+ELzmxgXHt9ti9+3D7yrh84k3sypr mhaAcR3J/e88OuP65+Y5WuwHj49Pd3xpcjEJE= Received: by 10.141.29.21 with SMTP id g21mr2018281rvj.44.1226895517264; Sun, 16 Nov 2008 20:18:37 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id l31sm8426958rvb.2.2008.11.16.20.18.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Nov 2008 20:18:35 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mAH4GYWC051787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2008 13:16:34 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mAH4GX27051786; Mon, 17 Nov 2008 13:16:33 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 17 Nov 2008 13:16:33 +0900 From: Pyun YongHyeon To: Milan Obuch Message-ID: <20081117041633.GI50872@cdnetworks.co.kr> References: <200810300829.35980.freebsd-net@dino.sk> <200811032339.07412.freebsd-net@dino.sk> <20081104014604.GB98154@cdnetworks.co.kr> <200811150913.16407.freebsd-net@dino.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200811150913.16407.freebsd-net@dino.sk> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: re weird bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 04:18:37 -0000 On Sat, Nov 15, 2008 at 09:13:15AM +0100, Milan Obuch wrote: > On Tuesday 04 November 2008 02:46:04 Pyun YongHyeon wrote: > > On Mon, Nov 03, 2008 at 11:39:06PM +0100, Milan Obuch wrote: > > > On Monday 03 November 2008 04:59:08 Pyun YongHyeon wrote: > > > > > > [ snip ] > > > > > > > I vaguely guess hardware was not properly initialized. How about > > > > this one? > > > > http://people.freebsd.org/~yongari/re/re.phy.patch.20081103 > > > > > > This bug seems again to disappear - csup two days ago, kernel built with > > > no patches and everything works. Something like this happened already in > > > the > > > > Yeah, this is one of reason that makes it hard to fix. > > > > > past. No idea whether it has something with if_re being built as module, > > > but if it happens again, I will test this possibility, too. > > > > Ok. Please let me know your findings. > > Strange. This trouble occured again. Two days ago, fresh csup, rebuilt whole > system, re works only when with verbose boot logging. Yesterday, fresh csup, > full rebuild, re works again. There is no change in if_re.c at all - it is > dated Sep 9, 2008. This is coming from somewhere else, but I have no idea how > this could be debugged. One possibility is there is some weird issue with > code or maybe more probably buffer placement in memory, but this is just a > shot in the wild, and no idea what means could be used to trace that. > > It occurs to me from time to time, only with -current, everytime verbose boot > logging masks the trouble, at least everytime I tried. Really weird, not > predictable. And maybe only difference tracking one per one could give some If verbose boot always hide the issye how about adding a DELAY in re_attach()? You may add a DELAY line, say DELAY(2000), before any PHY access(around line number 1307 in if_re.c) Did it make difference? > clue, but this is really time consuming (apply change, rebuild kernel, > reboot, test... grrr). > > Regards, > Milan -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 04:59:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9281D1065675 for ; Mon, 17 Nov 2008 04:59:58 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 264C38FC08 for ; Mon, 17 Nov 2008 04:59:57 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by wa-out-1112.google.com with SMTP id m34so1238014wag.27 for ; Sun, 16 Nov 2008 20:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:to:cc:subject :message-id:mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent:organization :x-operation-sytem:from; bh=fQTdQ6XtZ3drKr65XBWmqDDyVZ2FqwBHRPR+GxQUHVk=; b=ROGLXNDWf8J++V6NX7lg5hGRD8DOUcIHdG6B4A6PwjX6rmgC/HX9DbKUw7zluO5aou rkMoT+H2SfkDrcKZJBb7VjGwrVRiWrlPyjc6KmB/AKZVHrhI9IRA4NOCFA/FqzOAGKBr 9vRFvPKC3oPA/aJ7ADtt19809j+VIta84ttDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem:from; b=SklKV8Pv9b+FudkY5GnarNCnRyjcdKMpSh18SHzYJo5ExBto+wn20tmLEt6nW7IEL0 qfGMNss5fnu683TROqBnxzKZA2Mu/Qf8WDTKG513pXqikughOYItMe/RiKg+2mMxLFrV dh6SgzxhGC3Tq7lWJGakH5NnwXXot7824VbrM= Received: by 10.114.176.1 with SMTP id y1mr2245877wae.49.1226896596115; Sun, 16 Nov 2008 20:36:36 -0800 (PST) Received: from freebsd.weongyo.org ([211.53.35.67]) by mx.google.com with ESMTPS id t1sm5954198poh.2.2008.11.16.20.36.33 (version=SSLv3 cipher=RC4-MD5); Sun, 16 Nov 2008 20:36:35 -0800 (PST) Received: by freebsd.weongyo.org (sSMTP sendmail emulation); Mon, 17 Nov 2008 13:36:50 +0900 Date: Mon, 17 Nov 2008 13:36:50 +0900 To: Kayven Riese Message-ID: <20081117043650.GF61939@freebsd.weongyo.org> Mail-Followup-To: Kayven Riese , "Paul B. Mahol" , freebsd-net@freebsd.org, freebsd-mobile@freebsd.org References: <28b9b4180811160018q2823d7fap90b546ba444f191d@mail.gmail.com> <3a142e750811160335y6867d362k93a525774bc3667@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a142e750811160335y6867d362k93a525774bc3667@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD From: Weongyo Jeong Cc: freebsd-net@freebsd.org, "Paul B. Mahol" , freebsd-mobile@freebsd.org Subject: Re: driver support for Belkin F5D7050 v 5xxx ? 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, 17 Nov 2008 04:59:58 -0000 On Sun, Nov 16, 2008 at 12:35:23PM +0100, Paul B. Mahol wrote: > On 11/16/08, Kayven Riese wrote: > > I just purchased a wireless connection device that connects to my ASUS > > M6800N laptop dual > > booting Vista and > > > > KV_BSD# uname -a > > FreeBSD KV_BSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC > > 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > KV_BSD# > > > > via USB. > > > > While booting on Vista, connection was fine. I investigated my man pages > > for Belkin modles in > > the interfaces: > > V_BSD# man an | grep Belkin > > KV_BSD# man awi | grep Belkin > > KV_BSD# man ipw | grep Belkin > > KV_BSD# set -o vi > > KV_BSD# man iwi | grep Belkin > > KV_BSD# man ral | grep Belkin > > Belkin F5D7000 v3 RT2560 PCI > > Belkin F5D7010 v2 RT2560 CardBus > > KV_BSD# man rum | grep Belkin > > Belkin F5D7050 ver 3 USB > > Belkin F5D9050 ver 3 USB > > KV_BSD# man ural | grep Belkin > > Belkin F5D7050 v2000 USB > > KV_BSD# man wi | grep Belkin > > Belkin F5D6000 (a rebadged WL11000P) > > KV_BSD# man zyd | grep Belkin > > Belkin F5D7050 v.4000 > > KV_BSD# > > > > and found some websites that made me compare a serial number that I > > correlated to some > > information on the Belkin website and came to the conclusion that my device > > is a newer > > version than appears in the above list because of this information: > > > > K7SF5D7050E corresponds to version 5xxx > > > > That serial number is written on the device. > > > > There were no unfamiliar results of ifconfig: > > > > > > > > KV_BSD# ifconfig > > bge0: flags=8843 metric 0 mtu 1500 > > options=9b > > ether 00:11:d8:22:c9:91 > > inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 > > media: Ethernet autoselect (100baseTX ) > > status: active > > fwe0: flags=8802 metric 0 mtu 1500 > > options=8 > > ether 02:e0:18:26:4c:e9 > > ch 1 dma -1 > > fwip0: flags=8802 metric 0 mtu 1500 > > lladdr 0.e0.18.0.3.26.4c.e9.a.2.ff.fe.0.0.0.0 > > plip0: flags=108810 metric 0 mtu > > 1500 > > lo0: flags=8049 metric 0 mtu 16384 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > > inet6 ::1 prefixlen 128 > > inet 127.0.0.1 netmask 0xff000000 > > KV_BSD# > > > > I attempted to use the ndisgen utility with the driver disk mounted on > > "/mnt/drive" > > > > Currently ndis on freebsd doesnt support usb cards at all. > There is patch available for CURRENT that is considered experimental and > make possible to use ndis on FreeBSD with usb cards. I'd try to commit NDIS USB support soon (maybe before releasing 8.0 :-)) if there are no objections but I don't know whether it should be based on USB1, USB2 or both. regards, Weongy Jeong From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 11:06:54 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F35F1065670 for ; Mon, 17 Nov 2008 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4E28B8FC1F for ; Mon, 17 Nov 2008 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAHB6sXf082601 for ; Mon, 17 Nov 2008 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAHB6rZ3082597 for freebsd-net@FreeBSD.org; Mon, 17 Nov 2008 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Nov 2008 11:06:53 GMT Message-Id: <200811171106.mAHB6rZ3082597@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 11:06:54 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o kern/128833 net [bge] Network packets corrupted when bge card is in 64 o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o kern/128181 net [fxp] panic in fxp_add_rfabuf o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126984 net [carp][patch] add carp userland notifications via devc o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 193 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 10:40:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0BF51065688 for ; Mon, 17 Nov 2008 10:40:29 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from n77.bullet.mail.sp1.yahoo.com (n77.bullet.mail.sp1.yahoo.com [98.136.44.45]) by mx1.freebsd.org (Postfix) with SMTP id B4D848FC14 for ; Mon, 17 Nov 2008 10:40:29 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from [69.147.65.173] by n77.bullet.mail.sp1.yahoo.com with NNFMP; 17 Nov 2008 10:40:29 -0000 Received: from [69.147.84.107] by t15.bullet.mail.sp1.yahoo.com with NNFMP; 17 Nov 2008 10:40:29 -0000 Received: from [127.0.0.1] by omp202.mail.sp1.yahoo.com with NNFMP; 17 Nov 2008 10:40:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 448918.70808.bm@omp202.mail.sp1.yahoo.com Received: (qmail 99828 invoked by uid 60001); 17 Nov 2008 10:40:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=P/eKVVIDUsDZjncSO03Rc+FO3tTSsh/zPQpwD7pQZjrIkO+XBLklYlt20XCwJ6i/Ofiq99Hsmr7by3pOTr80lXLXH87E7fQ2cDNv9AM1fj9U7ACI/wUFrmrmwSmVpuBihynmsuP2C+H26o8U/Bbiov16XRB8Pj8zUnl5SwL0ryU=; X-YMail-OSG: A4Xh5rAVM1mrTPW_.eS2CP83MF8axRoksYfuK798RIcYe7YQuYaZ7AW5fBRFMT16q9QtLOyHncTeQ8vuWeGcrw7uGSjVP5UX5Y4HMyMeJKSRKNwSs4j9t4vhYYH8.5r22huujeF47Y_eCZdgk741YAUw9Ac- Received: from [58.71.34.137] by web45806.mail.sp1.yahoo.com via HTTP; Mon, 17 Nov 2008 02:40:29 PST X-Mailer: YahooMailRC/1155.29 YahooMailWebService/0.7.260.1 Date: Mon, 17 Nov 2008 02:40:29 -0800 (PST) From: Won De Erick To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <351447.99591.qm@web45806.mail.sp1.yahoo.com> X-Mailman-Approved-At: Mon, 17 Nov 2008 12:28:37 +0000 Subject: Re: does freebsd support so called Scalable I/O on intel NIC ? 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, 17 Nov 2008 10:40:29 -0000 Hello, Regarding Scalable I/O on Intel NIC: Using Intel Pro NIC (82571), I've downloaded the patches found on the following link: http://people.yandex-team.ru/~wawa/ I compiled and applied w/ FreeBSD 7.1 Beta2, and made some changes on the default settings. With net.isr.direct=1, I made some changes on kthreads(default=2) for em0 and em1's rx. dev.em.0.rx_kthreads: 6 .... dev.em.1.rx_kthreads: 6 The result: last pid: 1690; load averages: 10.83, 8.92, 8.56 up 0+02:28:24 18:22:54 107 processes: 28 running, 61 sleeping, 18 waiting CPU: 0.0% user, 0.0% nice, 74.0% system, 1.7% interrupt, 24.3% idle Mem: 17M Active, 7040K Inact, 161M Wired, 76K Cache, 21M Buf, 31G Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 56 root 1 43 - 0K 16K CPU0 0 54:04 100.00% em1_rx_kthread_1 55 root 1 43 - 0K 16K CPU13 d 53:37 100.00% em1_rx_kthread_0 1280 root 1 43 - 0K 16K CPU3 3 52:23 100.00% em1_rx_kthread_3 1279 root 1 43 - 0K 16K CPU7 7 51:57 100.00% em1_rx_kthread_2 1347 root 1 43 - 0K 16K CPU2 2 45:51 100.00% em1_rx_kthread_5 1346 root 1 43 - 0K 16K CPU5 5 45:40 100.00% em1_rx_kthread_4 50 root 1 -68 - 0K 16K CPU12 c 24:17 100.00% em0_txcleaner 11 root 1 171 ki31 0K 16K RUN f 105:35 94.38% idle: cpu15 25 root 1 171 ki31 0K 16K CPU1 1 76:32 81.40% idle: cpu1 1282 root 1 43 - 0K 16K WAIT 6 92:14 76.07% em0_rx_kthread_2 51 root 1 43 - 0K 16K CPU9 9 95:00 75.59% em0_rx_kthread_0 1344 root 1 43 - 0K 16K CPU11 b 79:18 75.49% em0_rx_kthread_5 1343 root 1 43 - 0K 16K WAIT 8 79:12 75.39% em0_rx_kthread_4 52 root 1 43 - 0K 16K CPU14 e 95:00 74.37% em0_rx_kthread_1 1283 root 1 43 - 0K 16K CPU10 a 92:24 68.65% em0_rx_kthread_3 22 root 1 171 ki31 0K 16K CPU4 4 58:31 60.35% idle: cpu4 54 root 1 -68 - 0K 16K WAIT 4 88:44 39.06% em1_txcleaner 20 root 1 171 ki31 0K 16K RUN 6 88:32 32.67% idle: cpu6 16 root 1 171 ki31 0K 16K RUN a 85:10 31.49% idle: cpu10 17 root 1 171 ki31 0K 16K RUN 9 76:45 28.96% idle: cpu9 15 root 1 171 ki31 0K 16K RUN b 92:25 28.86% idle: cpu11 18 root 1 171 ki31 0K 16K RUN 8 91:58 28.66% idle: cpu8 12 root 1 171 ki31 0K 16K RUN e 104:36 28.08% idle: cpu14 28 root 1 -32 - 0K 16K WAIT 1 74:01 20.75% swi4: clock sio 23 root 1 171 ki31 0K 16K RUN 3 69:43 6.59% idle: cpu3 26 root 1 171 ki31 0K 16K RUN 0 72:57 3.37% idle: cpu0 13 root 1 171 ki31 0K 16K RUN d 86:15 0.00% idle: cpu13 24 root 1 171 ki31 0K 16K RUN 2 86:08 0.00% idle: cpu2 14 root 1 171 ki31 0K 16K RUN c 83:32 0.00% idle: cpu12 19 root 1 171 ki31 0K 16K RUN 7 80:47 0.00% idle: cpu7 21 root 1 171 ki31 0K 16K RUN 5 74:22 0.00% idle: cpu5 27 root 1 -44 - 0K 16K WAIT 2 3:04 0.00% swi1: net I am happy to see that the threads are distributed among the CPUs, but I observed that there were packets errors and drops on the LAN side (em1): # netstat -I em1 -w 1 -d input (em1) output packets errs bytes packets errs bytes colls drops 32494 483 23083087 15681 0 23719154 0 82 30547 330 23104447 16062 0 23077442 0 44 In addition to the above result. I noticed errors on the WAN side (em0), but without packet drops. # netstat -I em0 -w 1 -d input (em0) output packets errs bytes packets errs bytes colls drops 19889 640 24144754 21307 0 8719922 0 0 18071 2436 25966238 21088 0 8766995 0 0 Is there any tool that I can use to trace where the errors and drops are occurring or coming from [internally]? I should want to see the specific process/task/threads that is causing this. ----------------------------------------------------- Original Message from Robert Watson Date: Sun, 26 Oct 2008 13:43:01 +0000 (GMT) ________________________________ > On Fri, 24 Oct 2008, Kip Macy wrote: > > It is simply a knob to adjust on all new server network cards. You could benefit from it on a predominantly UDP workload. I believe that tcp_input is still sufficiently serialized that it would not make sense for TCP workloads. > > In principle we can benefit on the basis that we drop the global lock fairly quickly for steady-state workloads (i.e., few SYN/FIN/RST packets), but there should be lots of contention on tcbinfo. > > If anyone is interested in doing some benchmarks, I have some patches that should apply fairly easily againts 8.x or 7.x as of 7.1 to move to optimistic read-locking of the global lock for steady state packets, but once in a while we have to upgrade or drop and re-acquire to get an exclusive lock when it turns out something that looked like a steady state packet did require the global lock exclusively, such as the ACK to transitioning to or from established. > I am interested to conduct a benchmark. Currently I am using FreebSD 7.1 Beta2 running on HPDL 585 w/ 16 CPUs. I am happy if you can send me the patch to do some benchmarks. > I've not had a chance to do much benchmarking on them, and theorize that they probably help quite a lot for lots of steady-state connections, but as connection length gets shorter the optimistic assumption becomes less true and begins to hurt performance. > > The long-term plan is to move to some more agressive decomposition of the tcbinfo lock, but I've not started on that yet as I'm waiting for the rwlock changes to settle, and need to evaluate the above tcbinfo rwlock patch. > > Robert N M Watson > Computer Laboratory > University of Cambridge Thanks, Won From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 14:11:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FE291065672; Mon, 17 Nov 2008 14:11:27 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by mx1.freebsd.org (Postfix) with ESMTP id B5ABB8FC0A; Mon, 17 Nov 2008 14:11:26 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=K/IjisuhXC0bPy20V76/JWEImHDJR6hkjHd8USrT91/8Bslsh48/GgLABnKlr7IU; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L24p3-0008Hg-T3; Mon, 17 Nov 2008 09:11:26 -0500 Message-ID: <49217B8C.4020701@earthlink.net> Date: Mon, 17 Nov 2008 09:11:24 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> <20081115102746.K61259@maildrop.int.zabbadoz.net> In-Reply-To: <20081115102746.K61259@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec794af18fb7ee433dbef49ceb3c5a4d093f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Cc: FreeBSD Stable Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 14:11:27 -0000 Bjoern A. Zeeb wrote: > On Fri, 14 Nov 2008, Robert Noland wrote: > > Hi, > >>>>> Also just using gre's without the >>>>> underlying ipsec tunnels seems to >>>>> work properly. > > The reason for this to my knowledge is: > http://www.kame.net/dev/cvsweb2.cgi/kame/freebsd2/sys/netinet/ip_icmp.c#rev1.4 > > > or looking at recent freebsd code: > http://fxr.watson.org/fxr/source/netinet/ip_icmp.c#L164 > Look for M_DECRYPTED. > > Now what happens in your case: > > you receive an IPSec ESP packet, which gets decryped, that sets > M_DECRYPTED on the mbuf passes through various parts, gets up to gre, > gets decapsulated is an IP packet (again) gets to ip_input, TTL > expired, icmp_error and it's still the same mbuf that originally got > the M_DECRYPTED set. Thus the packets is just freed and you never see > anything. > > So thinking about this has nothing to do with gre (or gif for example > as well) in first place. It's arguably that passing it on to another > decapsulation the flag should be cleared when entering gre() for > example. > > The other question of course is why we do not send the icmp error back > even on plain ipsec? Is it because we could possibly leak information > as it's not caught by the policy sending it back? > > /bz > Hi Bjoern, Thanks for you insight. I see in the ip_icmp.c code what you are talking about. Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 18:37:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A13241065678 for ; Mon, 17 Nov 2008 18:37:57 +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 0F97F8FC1B for ; Mon, 17 Nov 2008 18:37:56 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 1324 invoked from network); 17 Nov 2008 16:36:49 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Nov 2008 16:36:49 -0000 Message-ID: <4921B3C6.5020002@freebsd.org> Date: Mon, 17 Nov 2008 19:11:18 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Hartmut Brandt References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> In-Reply-To: <49201859.2080605@dlr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Rui Paulo Subject: Re: TCP and syncache question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 18:37:57 -0000 Hartmut Brandt wrote: > Rui Paulo wrote: >> >> On 15 Nov 2008, at 20:08, Hartmut Brandt wrote: >> >>> Hi, >>> >>> in tcp_syncache.c:syncache_expand() there is a test that the >>> acknowledgement number and the sequence number of an incoming ACK >>> segment are in the expected range. If they are not, syncache_expand() >>> returns 0 and tcp_input drops the segment and sets a reset. So far so >>> good. But syncache_expand() also deletes the syncache entry, and so >>> destroys the connection. I cannot see why it does it. It seems to me >>> that such a wrong segment should be interpreted as to be from another >>> connection and as such the segment should be ignored (but a reset >>> sent). When the correct ACK comes, the connection could still be >>> established. As it is now, the establishment of incoming connections >>> can seriously be disturbed by someone sending fake ACK packets. >>> >>> The same test (for the ack number, not for the sequence number) is >>> also further down in tcp_input.c:tcp_do_segment() (just after the >>> header prediction stuff) and here the handling is correct: the goto >>> dropwithreset just sends a reset and drops the segment but leaves the >>> connection in the SYN-RECEIVED state. This test is probably never >>> reached now, because of syncache_expand(), though. Correct. >>> Maybe I fail to see something obvious, though... >> >> >> Well, if the RST is sent, why should we keep the syncache entry? > > Because this effectively destroys the connection in SYN-RECEIVED which > is wrong according to RFC793. On page 69 the handling of incoming > segments for connections in SYN-RECEIVED is described: first you check > the sequence number and, if it is wrong, you send an RST (unless the RST > bit is set in the incoming segment), but otherwise ignore the segment. > > A segment with a bad sequence number in SYN-RECEIVED is either forged or > from an old connection. In both cases you don't want to destroy the > embryonic connection, because the correct ACK from the correct peer may > still arrive. I see your problem. Syncookies mitigate this problem (if not disabled) as the correct ACK will pass that test later even if the syncache entry went away before (which can also happen due to a generally high SYN load). RFC793 wants us to do the following: Page 69: Send back a challenge ACK with the correct parameters to help to re-synchronize the connection when !(RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND). Page 72: Send back a RST when !(SND.UNA =< SEG.ACK =< SND.NXT). At the moment we send the RST and delete the syncache entry for both cases. However we should send the ACK in the former, the RST in the latter, and and keep the syncache entry in either case. Fixing this requires some re-shuffling of the syncache_expand(). I'll post a version later today. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 19:49:48 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CE3E1065674 for ; Mon, 17 Nov 2008 19:49:48 +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 D01008FC1C for ; Mon, 17 Nov 2008 19:49:47 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.11.16.99] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 17 Nov 2008 11:35:33 -0800 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 584FE2B1; Mon, 17 Nov 2008 11:35:33 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.11.18.52]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 443812B0; Mon, 17 Nov 2008 11:35:33 -0800 (PST) Received: from mail-irva-13.broadcom.com (mail-irva-13.broadcom.com [10.11.16.103]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id HHQ19480; Mon, 17 Nov 2008 11:35:31 -0800 (PST) Received: from NT-IRVA-0751.brcm.ad.broadcom.com (nt-irva-0751 [10.8.194.65]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id BAE2E74CFE; Mon, 17 Nov 2008 11:35:31 -0800 (PST) Received: from IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) by NT-IRVA-0751.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Nov 2008 11:35:31 -0800 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 17 Nov 2008 11:35:31 -0800 From: "David Christensen" To: "Marius Strobl" , "freebsd-net@FreeBSD.org" Date: Mon, 17 Nov 2008 11:37:19 -0800 Thread-Topic: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Thread-Index: AclINW0XjPLftGbyQNuZzNsj3cZKGgAsUNMA Message-ID: <5D267A3F22FD854F8F48B3D2B523819339408D91A4@IRVEXCHCCR01.corp.ad.broadcom.com> References: <200811162150.mAGLo4UJ045453@freefall.freebsd.org> In-Reply-To: <200811162150.mAGLo4UJ045453@freefall.freebsd.org> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 17 Nov 2008 19:35:31.0669 (UTC) FILETIME=[A7371850:01C948EB] X-WSS-ID: 653F180F3FC18132755-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 19:49:48 -0000 > Ok, thanks for testing anyway. > I still think that this isn't really a driver bug though but > you are hitting some hardware-related problem like f.e. a > silicon bug and the question is how to work around it. There is a documented errata for the 5701 A3 where a 64bit DMA read can be terminated early by the bridge and then completed=20 later as a 32bit access, causing corruption on the 5701. The=20 errata states this type of behavior is rare in bridges and that the workaround is to force 32bit operation (set bit 15 of register 0x6800). It's not clear whether this errata is occurring without seeing a but trace but it certainly sounds right. The only=20 question would be knowing "when" to force 32bit operation. Should it be done in all cases or only for this bridge? > Looking at the bge(4) versions of the other BSDs and the > corresponding Linux and OpenSolaris drivers I can't spot > a such a workaround apart from the already known PCI-X > issue, unfortunately. The only other thing that comes to > my mind is that you might suffer from sort of the opposite > of the problem worked around by ti_64bitslot_war() (the NICs > driven by ti(4) are the predecessors of those supported by > bge(4)). Given that this also involves the BIOS that could > then explain why you're see first person to hit this problem. > Could you please instrument bge(4) to print the content > of the BGE_PCI_PCISTATE register and report back which > values it's initialized to depending on which type of slot > the card is plugged into? Dave From owner-freebsd-net@FreeBSD.ORG Mon Nov 17 21:01:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86731106564A; Mon, 17 Nov 2008 21:01:42 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by mx1.freebsd.org (Postfix) with ESMTP id 36D808FC16; Mon, 17 Nov 2008 21:01:42 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=FNJ5vk4XIVeNYvYpQUUPqV46qfDtBhnzzipdntxDLwsrxiwWsWPpZ4xf4iYXgfNw; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L2BE5-0007Kp-GD; Mon, 17 Nov 2008 16:01:41 -0500 Message-ID: <4921DBB4.4060505@earthlink.net> Date: Mon, 17 Nov 2008 16:01:40 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> <20081115102746.K61259@maildrop.int.zabbadoz.net> In-Reply-To: <20081115102746.K61259@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec797040dbfe5ded6009d701fad992715179350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Cc: FreeBSD Stable Subject: Re: FreeBSD 6.3 gre and traceroute X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 21:01:42 -0000 Bjoern A. Zeeb wrote: > On Fri, 14 Nov 2008, Robert Noland wrote: > > Hi, > >>>>> Also just using gre's without the >>>>> underlying ipsec tunnels seems to >>>>> work properly. > > The reason for this to my knowledge is: > http://www.kame.net/dev/cvsweb2.cgi/kame/freebsd2/sys/netinet/ip_icmp.c#rev1.4 > > > or looking at recent freebsd code: > http://fxr.watson.org/fxr/source/netinet/ip_icmp.c#L164 > Look for M_DECRYPTED. > > Now what happens in your case: > > you receive an IPSec ESP packet, which gets decryped, that sets > M_DECRYPTED on the mbuf passes through various parts, gets up to gre, > gets decapsulated is an IP packet (again) gets to ip_input, TTL > expired, icmp_error and it's still the same mbuf that originally got > the M_DECRYPTED set. Thus the packets is just freed and you never see > anything. > > So thinking about this has nothing to do with gre (or gif for example > as well) in first place. It's arguably that passing it on to another > decapsulation the flag should be cleared when entering gre() for > example. > > The other question of course is why we do not send the icmp error back > even on plain ipsec? Is it because we could possibly leak information > as it's not caught by the policy sending it back? > > /bz > Update: Adding this code in ip_icmp.c makes the traceroute work. case IPPROTO_GRE: hlen += sizeof(struct gre_h); + m->m_flags &= ~(M_DECRYPTED); 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 Mon Nov 17 22:40:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7380410656AE for ; Mon, 17 Nov 2008 22:40:12 +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 BDCCB8FC18 for ; Mon, 17 Nov 2008 22:40:11 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 2547 invoked from network); 17 Nov 2008 21:05:42 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Nov 2008 21:05:42 -0000 Message-ID: <4921F2CD.503@freebsd.org> Date: Mon, 17 Nov 2008 23:40:13 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Hartmut Brandt References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> <4921B3C6.5020002@freebsd.org> In-Reply-To: <4921B3C6.5020002@freebsd.org> Content-Type: multipart/mixed; boundary="------------010706030207060604050302" Cc: freebsd-net@freebsd.org, bz@freebsd.org, Rui Paulo Subject: Re: TCP and syncache question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2008 22:40:12 -0000 This is a multi-part message in MIME format. --------------010706030207060604050302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andre Oppermann wrote: > Hartmut Brandt wrote: >> Rui Paulo wrote: >>> >>> On 15 Nov 2008, at 20:08, Hartmut Brandt wrote: >>> >>>> Hi, >>>> >>>> in tcp_syncache.c:syncache_expand() there is a test that the >>>> acknowledgement number and the sequence number of an incoming ACK >>>> segment are in the expected range. If they are not, >>>> syncache_expand() returns 0 and tcp_input drops the segment and sets >>>> a reset. So far so good. But syncache_expand() also deletes the >>>> syncache entry, and so destroys the connection. I cannot see why it >>>> does it. It seems to me that such a wrong segment should be >>>> interpreted as to be from another connection and as such the segment >>>> should be ignored (but a reset sent). When the correct ACK comes, >>>> the connection could still be established. As it is now, the >>>> establishment of incoming connections can seriously be disturbed by >>>> someone sending fake ACK packets. >>>> >>>> The same test (for the ack number, not for the sequence number) is >>>> also further down in tcp_input.c:tcp_do_segment() (just after the >>>> header prediction stuff) and here the handling is correct: the goto >>>> dropwithreset just sends a reset and drops the segment but leaves >>>> the connection in the SYN-RECEIVED state. This test is probably >>>> never reached now, because of syncache_expand(), though. > > Correct. > >>>> Maybe I fail to see something obvious, though... >>> >>> >>> Well, if the RST is sent, why should we keep the syncache entry? >> >> Because this effectively destroys the connection in SYN-RECEIVED which >> is wrong according to RFC793. On page 69 the handling of incoming >> segments for connections in SYN-RECEIVED is described: first you check >> the sequence number and, if it is wrong, you send an RST (unless the >> RST bit is set in the incoming segment), but otherwise ignore the >> segment. > > >> A segment with a bad sequence number in SYN-RECEIVED is either forged >> or from an old connection. In both cases you don't want to destroy the >> embryonic connection, because the correct ACK from the correct peer >> may still arrive. > > I see your problem. Syncookies mitigate this problem (if not disabled) as > the correct ACK will pass that test later even if the syncache entry went > away before (which can also happen due to a generally high SYN load). > > RFC793 wants us to do the following: > > Page 69: Send back a challenge ACK with the correct parameters to help > to re-synchronize the connection when > !(RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND). > > Page 72: Send back a RST when !(SND.UNA =< SEG.ACK =< SND.NXT). > > At the moment we send the RST and delete the syncache entry for both cases. > However we should send the ACK in the former, the RST in the latter, and > and keep the syncache entry in either case. > > Fixing this requires some re-shuffling of the syncache_expand(). I'll > post a version later today. This is a bit more complicated because of interactions with tcp_input() where syncache_expand() is called from. The old code (as of December 2002) behaved slightly different. It would not remove the syncache entry when (SND.UNA == SEG.ACK) but send a RST. The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't done at all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) succeeded. This gave way to the "LAND" DoS attack which was mostly fixed with a test for (RCV.IRS < SEG.SEQ). See the attached patch for fixed version of syncache_expand(). This patch is untested though. My development machine is currently down. Harti, Rui and Bjoern, please have a look at the patch and review it. -- Andre --------------010706030207060604050302 Content-Type: text/plain; name="syncache_expand_fix-20081117.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="syncache_expand_fix-20081117.diff" --- tcp_input.c.1.390 Mon Nov 17 21:33:25 2008 +++ tcp_input.c.1.390.mod Mon Nov 17 21:35:22 2008 @@ -642,10 +642,13 @@ findpcb: if (!syncache_expand(&inc, &to, th, &so, m)) { /* * No syncache entry or ACK was not - * for our SYN/ACK. Send a RST. + * for our SYN/ACK. Send a RST or + * an ACK for re-synchronization. * NB: syncache did its own logging * of the failure cause. */ + if (so == 1) + goto dropunlock; rstreason = BANDLIM_RST_OPENPORT; goto dropwithreset; } --- tcp_syncache.c.1.160 Mon Nov 17 16:49:01 2008 +++ tcp_syncache.c.1.160.mod Mon Nov 17 23:35:39 2008 @@ -817,59 +817,47 @@ syncache_expand(struct in_conninfo *inc, INP_INFO_WLOCK_ASSERT(&V_tcbinfo); KASSERT((th->th_flags & (TH_RST|TH_ACK|TH_SYN)) == TH_ACK, ("%s: can handle only ACK", __func__)); + *lsop = NULL; sc = syncache_lookup(inc, &sch); /* returns locked sch */ SCH_LOCK_ASSERT(sch); if (sc == NULL) { /* * There is no syncache entry, so see if this ACK is - * a returning syncookie. To do this, first: - * A. See if this socket has had a syncache entry dropped in - * the past. We don't want to accept a bogus syncookie - * if we've never received a SYN. - * B. check that the syncookie is valid. If it is, then - * cobble up a fake syncache entry, and return. + * a returning syncookie. If the syncookie is valid, + * cobble up a fake syncache entry and create a socket. + * + * NB: Syncache head is locked for the syncookie access. */ if (!tcp_syncookies) { - SCH_UNLOCK(sch); if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: Spurious ACK, " "segment rejected (syncookies disabled)\n", s, __func__); - goto failed; + goto sendrst; } bzero(&scs, sizeof(scs)); sc = syncookie_lookup(inc, sch, &scs, to, th, *lsop); - SCH_UNLOCK(sch); if (sc == NULL) { if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: Segment failed " "SYNCOOKIE authentication, segment rejected " "(probably spoofed)\n", s, __func__); - goto failed; + goto sendrst; } - } else { - /* Pull out the entry to unlock the bucket row. */ - TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); - sch->sch_length--; - V_tcp_syncache.cache_count--; - SCH_UNLOCK(sch); + goto expand; /* fully validated through syncookie */ } + SCH_LOCK_ASSERT(sch); /* * Segment validation: - * ACK must match our initial sequence number + 1 (the SYN|ACK). - */ - if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { - if ((s = tcp_log_addrs(inc, th, NULL, NULL))) - log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " - "rejected\n", s, __func__, th->th_ack, sc->sc_iss); - goto failed; - } - - /* + * * The SEQ must fall in the window starting at the received * initial receive sequence number + 1 (the SYN). + * If not the segment may be from an earlier connection. We send + * an ACK to re-synchronize the connection and keep the syncache + * entry without ajusting its timers. + * See RFC793 page 69, first check sequence number [SYN_RECEIVED]. */ if ((SEQ_LEQ(th->th_seq, sc->sc_irs) || SEQ_GT(th->th_seq, sc->sc_irs + sc->sc_wnd)) && @@ -877,14 +865,41 @@ syncache_expand(struct in_conninfo *inc, if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: SEQ %u != IRS+1 %u, segment " "rejected\n", s, __func__, th->th_seq, sc->sc_irs); - goto failed; + (void) syncache_respond(sc); + *lsop = 1; /* prevent RST */ + goto sendrstkeep; } + /* + * ACK must match our initial sequence number + 1 (the SYN|ACK). + * If not the segment may be from an earlier connection. We send + * a RST but keep the syncache entry without ajusting its timers. + * See RFC793 page 72, fifth check the ACK field, [SYN_RECEIVED]. + */ + if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) + log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " + "rejected\n", s, __func__, th->th_ack, sc->sc_iss); + goto sendrstkeep; + } + + /* + * Remove the entry to unlock the bucket row. + * Tests from now on are fatal and remove the syncache entry. + */ + TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); + sch->sch_length--; + V_tcp_syncache.cache_count--; + + /* + * If timestamps were not negotiated they must not show up later. + * See RFC1312bis, section 1.3, second paragraph + */ if (!(sc->sc_flags & SCF_TIMESTAMP) && (to->to_flags & TOF_TS)) { if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: Timestamp not expected, " "segment rejected\n", s, __func__); - goto failed; + goto sendrst; } /* * If timestamps were negotiated the reflected timestamp @@ -896,9 +911,11 @@ syncache_expand(struct in_conninfo *inc, log(LOG_DEBUG, "%s; %s: TSECR %u != TS %u, " "segment rejected\n", s, __func__, to->to_tsecr, sc->sc_ts); - goto failed; + goto sendrst; } +expand: + SCH_UNLOCK(sch); *lsop = syncache_socket(sc, *lsop, m); if (*lsop == NULL) @@ -906,16 +923,18 @@ syncache_expand(struct in_conninfo *inc, else V_tcpstat.tcps_sc_completed++; -/* how do we find the inp for the new socket? */ if (sc != &scs) syncache_free(sc); return (1); -failed: - if (sc != NULL && sc != &scs) + +sendrst: + if (sc != &scs) syncache_free(sc); +sendrstkeep: + SCH_LOCK_ASSERT(sch); + SCH_UNLOCK(sch); if (s != NULL) free(s, M_TCPLOG); - *lsop = NULL; return (0); } @@ -1322,6 +1341,8 @@ syncache_respond(struct syncache *sc) * * 1) path_mtu_discovery is disabled * 2) the SCF_UNREACH flag has been set + * + * XXXAO: The route lookup comment doesn't make sense. */ if (V_path_mtu_discovery && ((sc->sc_flags & SCF_UNREACH) == 0)) ip->ip_off |= IP_DF; --------------010706030207060604050302-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 02:56:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D9C51065670 for ; Tue, 18 Nov 2008 02:56:06 +0000 (UTC) (envelope-from glavoie@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id 2C18E8FC0A for ; Tue, 18 Nov 2008 02:56:06 +0000 (UTC) (envelope-from glavoie@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2603779rvf.43 for ; Mon, 17 Nov 2008 18:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=qGklXM3Ot9VAx65FffOGtGRAoiHOTJ7l4gEBCsF7E1Q=; b=VDMrVozk1qI1w+ctbBklIp5iFMsuHlFWtjATob2qyEHWbVYOzg8W1QncriZIHhrehu 2YR5De0quF8RyU+VgQnJLOeUlejN145oMT2x9CsvcGzizmVihnbeP1tLy8Gx125zPojV yltAeHfEwU+VkdySkO1o9cxcb8mwSTM5Tdf0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=ZLtfGQlkPRgPpRx3X8E/FYXib1BAV9gfkztFJ+/32qgN5DcmLsQjLQl7nwSuz+qZp0 Y3fLWkfF6P353T0hE5MPOK0vfUOs+4PoU5Oagkw+neLTYnnHs0mgfsh7AfakHrUF93Dn 0G425NTaFAPYUSKgYxRiZFxhga6U5Ba/wjUmI= Received: by 10.141.48.6 with SMTP id a6mr2632228rvk.161.1226976965916; Mon, 17 Nov 2008 18:56:05 -0800 (PST) Received: by 10.141.146.8 with HTTP; Mon, 17 Nov 2008 18:56:05 -0800 (PST) Message-ID: Date: Mon, 17 Nov 2008 21:56:05 -0500 From: "Gabriel Lavoie" To: pyunyh@gmail.com In-Reply-To: <20081117034428.GG50872@cdnetworks.co.kr> MIME-Version: 1.0 References: <957411.42240.qm@web39101.mail.mud.yahoo.com> <20081117023024.GE50872@cdnetworks.co.kr> <20081117034428.GG50872@cdnetworks.co.kr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bf , freebsd-net@freebsd.org Subject: Re: Realtek 8139 with rl(4) driver -> Poor performance 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, 18 Nov 2008 02:56:06 -0000 Hum. I tried transfering a lot of data tonight via Samba (30GB). It seems that after some time the driver becomes again unstable and the networking performance drops really low. I could hardly SSH to this box after it happened. Gabriel 2008/11/16 Pyun YongHyeon > On Sun, Nov 16, 2008 at 10:03:15PM -0500, Gabriel Lavoie wrote: > > All right! rl(4) from HEAD solved my problem! I now get a solid 11.2 > MB/sec > > file transfer, on both directions. I found about this problem because my > > Samba share was too slow. The Samba problem is solved. > > > > Glad to hear that. :-) > > > Thanks! > > > > 2008/11/16 Pyun YongHyeon > > > > > On Sun, Nov 16, 2008 at 06:26:34PM -0800, bf wrote: > > > > > > > > > There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. > > > > > How about rl(4) in HEAD? I guess it would build with minor > > > > > modification. > > > > > > > > > > -- > > > > > Regards, > > > > > Pyun YongHyeon > > > > > > > > I meant to ask about this: I think you are referring to r184240-3 > > > committed > > > > around Oct. 25, partly in response to PR kern/128143, right? Is > there > > > any > > > > > > Yes. > > > > > > > plan to merge these changes to RELENG_7, either before or after the > > > > release of 7.1? > > > > > > > > > > I'll MFC the change after 7.1-RELEASE. > > > Did the change set r184240 fix your issue? > > > > > > -- > > -- > Regards, > Pyun YongHyeon > -- Gabriel Lavoie glavoie@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 04:39:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C110106564A for ; Tue, 18 Nov 2008 04:39:35 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id E4CBB8FC1A for ; Tue, 18 Nov 2008 04:39:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2635881rvf.43 for ; Mon, 17 Nov 2008 20:39:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=hFC9vbY0ssAfEW/XOdsqWqd86UpcoeNdWos287wqy0M=; b=Zn+5z3kOaUf5shFu8TDOQsR7DthqAwgwr9QS7d/oOWOXJxEqlo/ZDB7z0nQDoEPWi4 oaLrimUavUealMhK8ocBT8aVY89aI2hj/4XIqnLXdn7+UmAqY5eNLaGl2KXE/4vFyPnu eugQIuY1AKchqcVywlCWbLScNvix5E9czOhAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=BnsthmMKPJcBEo6Y5J6DZHsR8TvY8viQrHDkzk0+LK1S5hDH2d9MM2KguDtq8yuCA3 0CMBF3RcV5C6bWCWP/+VzUTBoCfMJfYzS9TzysGUa1XLvBjfeac5jRDzYtORt903TMQq 0nEBc+cRiePAag9pkFfBFJH630vrT4acAYIGY= Received: by 10.141.198.9 with SMTP id a9mr2688319rvq.62.1226983174654; Mon, 17 Nov 2008 20:39:34 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id f21sm11562055rvb.5.2008.11.17.20.39.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Nov 2008 20:39:33 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mAI4bWIG055882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 13:37:32 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mAI4bVqa055881; Tue, 18 Nov 2008 13:37:31 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 18 Nov 2008 13:37:31 +0900 From: Pyun YongHyeon To: Gabriel Lavoie Message-ID: <20081118043731.GD55015@cdnetworks.co.kr> References: <957411.42240.qm@web39101.mail.mud.yahoo.com> <20081117023024.GE50872@cdnetworks.co.kr> <20081117034428.GG50872@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: bf , freebsd-net@freebsd.org Subject: Re: Realtek 8139 with rl(4) driver -> Poor performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2008 04:39:35 -0000 On Mon, Nov 17, 2008 at 09:56:05PM -0500, Gabriel Lavoie wrote: > Hum. I tried transfering a lot of data tonight via Samba (30GB). It seems > that after some time the driver becomes again unstable and the networking > performance drops really low. I could hardly SSH to this box after it > happened. Would you show me the output of "sysctl hw.busdma" and "netstat -nd -I rl0"? Did rl(4) show some messages on your console? > > Gabriel -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 11:45:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D6411065674 for ; Tue, 18 Nov 2008 11:45:09 +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 440DC8FC26 for ; Tue, 18 Nov 2008 11:45:09 +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 57C1B41C65F; Tue, 18 Nov 2008 12:45:07 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 9rBR6sorcQfF; Tue, 18 Nov 2008 12:45:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 9D1A241C64C; Tue, 18 Nov 2008 12:45:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 71325444888; Tue, 18 Nov 2008 11:41:10 +0000 (UTC) Date: Tue, 18 Nov 2008 11:41:10 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Stephen Clark In-Reply-To: <4921DBB4.4060505@earthlink.net> Message-ID: <20081118113823.T61259@maildrop.int.zabbadoz.net> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> <20081115102746.K61259@maildrop.int.zabbadoz.net> <4921DBB4.4060505@earthlink.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 6.3 gre and tracerouteo 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, 18 Nov 2008 11:45:09 -0000 On Mon, 17 Nov 2008, Stephen Clark wrote: Hi, > Bjoern A. Zeeb wrote: >> On Fri, 14 Nov 2008, Robert Noland wrote: >> >> Hi, >> >>>>>> Also just using gre's without the >>>>>> underlying ipsec tunnels seems to >>>>>> work properly. >> >> The reason for this to my knowledge is: >> http://www.kame.net/dev/cvsweb2.cgi/kame/freebsd2/sys/netinet/ip_icmp.c#rev1.4 >> >> or looking at recent freebsd code: >> http://fxr.watson.org/fxr/source/netinet/ip_icmp.c#L164 >> Look for M_DECRYPTED. >> >> Now what happens in your case: >> >> you receive an IPSec ESP packet, which gets decryped, that sets >> M_DECRYPTED on the mbuf passes through various parts, gets up to gre, >> gets decapsulated is an IP packet (again) gets to ip_input, TTL >> expired, icmp_error and it's still the same mbuf that originally got >> the M_DECRYPTED set. Thus the packets is just freed and you never see >> anything. >> >> So thinking about this has nothing to do with gre (or gif for example >> as well) in first place. It's arguably that passing it on to another >> decapsulation the flag should be cleared when entering gre() for >> example. >> >> The other question of course is why we do not send the icmp error back >> even on plain ipsec? Is it because we could possibly leak information >> as it's not caught by the policy sending it back? >> >> /bz >> > Update: > > Adding this code in ip_icmp.c makes the traceroute work. > case IPPROTO_GRE: > hlen += sizeof(struct gre_h); > > + m->m_flags &= ~(M_DECRYPTED); I have two problems with this: 1) my ip_icmp.c doesn't know anything about GRE (in HEAD or on my 6.x box) unless I need more coffee. 2) This obviously doesn't solve the problem for gif(4), ... Can you tell me which brnach you are working against (I guess it's 6.3?) and generate a proper diff? /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 11:56:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E7B21065670 for ; Tue, 18 Nov 2008 11:56:04 +0000 (UTC) (envelope-from glavoie@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id 648BA8FC0A for ; Tue, 18 Nov 2008 11:56:04 +0000 (UTC) (envelope-from glavoie@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2765375rvf.43 for ; Tue, 18 Nov 2008 03:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=VLuFqNHdC0Fp/SpGXEAH1QzTS/JHeWvUmGIx+MeGRNo=; b=bk/e5rA77AOXw50dPyQ/QrqMNwyAic7nXKxgd2g6P9LlbJc9pCGVW349eKjitLXx0k DopprKqdrGbZmABHSMVs2JsJllryUCp3Z860Mz/o7h5d9WKYJFXmzNMlLmQsjkslaQ50 o7oPUlYsVV4LIDE0eGLToaq0MAwAvSUuaM87c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=Vrp0xPtFjtm0ljTHN89z977K49BReTdF4cxTGPzp2OUHT/NrGnGcN2L1Bw8xDIiQKu jdXYQQEUTsvl2DrjtTc+tMUTyR/I45SB9ihl3bZKiAHnqV87AV0tiSYS9pfcJeeZUVbr V64RCHjRCxYN4Pt8R7d0d0Sd/RR5BnUfYhhdk= Received: by 10.140.132.4 with SMTP id f4mr2865549rvd.201.1227009363897; Tue, 18 Nov 2008 03:56:03 -0800 (PST) Received: by 10.141.146.8 with HTTP; Tue, 18 Nov 2008 03:56:03 -0800 (PST) Message-ID: Date: Tue, 18 Nov 2008 06:56:03 -0500 From: "Gabriel Lavoie" To: pyunyh@gmail.com In-Reply-To: <20081118043731.GD55015@cdnetworks.co.kr> MIME-Version: 1.0 References: <957411.42240.qm@web39101.mail.mud.yahoo.com> <20081117023024.GE50872@cdnetworks.co.kr> <20081117034428.GG50872@cdnetworks.co.kr> <20081118043731.GD55015@cdnetworks.co.kr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bf , freebsd-net@freebsd.org Subject: Re: Realtek 8139 with rl(4) driver -> Poor performance 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, 18 Nov 2008 11:56:04 -0000 I'll come back to you tonight with the output of sysctl and netstat but there was no message with dmesg. Not sure about the console because no screen is plugged in this computer. My client computer's Samba started to output a lot of timeout and read/write error with dmesg. 2008/11/17 Pyun YongHyeon > On Mon, Nov 17, 2008 at 09:56:05PM -0500, Gabriel Lavoie wrote: > > Hum. I tried transfering a lot of data tonight via Samba (30GB). It > seems > > that after some time the driver becomes again unstable and the > networking > > performance drops really low. I could hardly SSH to this box after it > > happened. > > Would you show me the output of "sysctl hw.busdma" and > "netstat -nd -I rl0"? > Did rl(4) show some messages on your console? > > > > > Gabriel > -- > Regards, > Pyun YongHyeon > -- Gabriel Lavoie glavoie@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 13:13:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D20FF106564A for ; Tue, 18 Nov 2008 13:13:16 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by mx1.freebsd.org (Postfix) with ESMTP id 8E72C8FC1F for ; Tue, 18 Nov 2008 13:13:16 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=h5XWmaOHyY7zwwndNn5IjMYPwptDk0tTxlEDlGi5I4kzns1OKOetAQn9Z/TZXAFT; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L2QOJ-0006FX-GN; Tue, 18 Nov 2008 08:13:15 -0500 Message-ID: <4922BF6A.1000108@earthlink.net> Date: Tue, 18 Nov 2008 08:13:14 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> <20081115102746.K61259@maildrop.int.zabbadoz.net> <4921DBB4.4060505@earthlink.net> <20081118113823.T61259@maildrop.int.zabbadoz.net> In-Reply-To: <20081118113823.T61259@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec799bd063f300eb3963a1bdbc934972a69d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 6.3 gre and tracerouteo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2008 13:13:16 -0000 Bjoern A. Zeeb wrote: > On Mon, 17 Nov 2008, Stephen Clark wrote: > > Hi, > >> Bjoern A. Zeeb wrote: >>> On Fri, 14 Nov 2008, Robert Noland wrote: >>> >>> Hi, >>> >>>>>>> Also just using gre's without the >>>>>>> underlying ipsec tunnels seems to >>>>>>> work properly. >>> >>> The reason for this to my knowledge is: >>> http://www.kame.net/dev/cvsweb2.cgi/kame/freebsd2/sys/netinet/ip_icmp.c#rev1.4 >>> >>> or looking at recent freebsd code: >>> http://fxr.watson.org/fxr/source/netinet/ip_icmp.c#L164 >>> Look for M_DECRYPTED. >>> >>> Now what happens in your case: >>> >>> you receive an IPSec ESP packet, which gets decryped, that sets >>> M_DECRYPTED on the mbuf passes through various parts, gets up to gre, >>> gets decapsulated is an IP packet (again) gets to ip_input, TTL >>> expired, icmp_error and it's still the same mbuf that originally got >>> the M_DECRYPTED set. Thus the packets is just freed and you never see >>> anything. >>> >>> So thinking about this has nothing to do with gre (or gif for example >>> as well) in first place. It's arguably that passing it on to another >>> decapsulation the flag should be cleared when entering gre() for >>> example. >>> >>> The other question of course is why we do not send the icmp error back >>> even on plain ipsec? Is it because we could possibly leak information >>> as it's not caught by the policy sending it back? >>> >>> /bz >>> >> Update: >> >> Adding this code in ip_icmp.c makes the traceroute work. >> case IPPROTO_GRE: >> hlen += sizeof(struct gre_h); >> >> + m->m_flags &= ~(M_DECRYPTED); > > I have two problems with this: > > 1) my ip_icmp.c doesn't know anything about GRE (in HEAD or on my 6.x > box) unless I need more coffee. > > 2) This obviously doesn't solve the problem for gif(4), ... > > > Can you tell me which brnach you are working against (I guess it's > 6.3?) and generate a proper diff? > > > /bz > Duh sorry - should have said ip_gre.c and it is 6.3-p5 *** ip_gre.c.ori Tue Nov 18 08:09:16 2008 --- ip_gre.c Tue Nov 18 08:10:27 2008 *************** *** 153,158 **** --- 153,161 ---- switch (proto) { case IPPROTO_GRE: hlen += sizeof(struct gre_h); + + m->m_flags &= ~(M_DECRYPTED); + /* process GRE flags as packet can be of variable len */ flags = ntohs(gip->gi_flags); Your right about gif(4) - probably something similar is needed. 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 Tue Nov 18 17:33:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44AD5106564A for ; Tue, 18 Nov 2008 17:33:09 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 0B1BA8FC13 for ; Tue, 18 Nov 2008 17:33:09 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id 1898FB0380EF for ; Tue, 18 Nov 2008 12:33:08 -0500 (EST) Thread-Index: AclJo7hD10BgsMvjSNWGjG4A8ugquw== Received: from limbo.int.dllstx01.us.it.verio.net ([10.10.10.11]) by iad-wprd-xchw01.corp.verio.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 12:33:07 -0500 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 9FD4E1E6B3; Tue, 18 Nov 2008 11:33:37 -0600 (CST) Date: Tue, 18 Nov 2008 11:33:37 -0600 From: "David DeSimone" To: Content-Transfer-Encoding: 7bit Message-ID: <20081118173337.GA19402@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> <20081115102746.K61259@maildrop.int.zabbadoz.net> <4921DBB4.4060505@earthlink.net> <20081118113823.T61259@maildrop.int.zabbadoz.net> <4922BF6A.1000108@earthlink.net> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Importance: normal Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4922BF6A.1000108@earthlink.net> Precedence: bulk User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-OriginalArrivalTime: 18 Nov 2008 17:33:07.0604 (UTC) FILETIME=[B8397540:01C949A3] Subject: Re: FreeBSD 6.3 gre and tracerouteo 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: Tue, 18 Nov 2008 17:33:09 -0000 Stephen Clark wrote: > > switch (proto) { > case IPPROTO_GRE: > hlen += sizeof(struct gre_h); > + > + m->m_flags &= ~(M_DECRYPTED); > + Are there security implications from removing this flag? -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 17:49:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EF001065672 for ; Tue, 18 Nov 2008 17:49:18 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by mx1.freebsd.org (Postfix) with ESMTP id 69FF68FC1E for ; Tue, 18 Nov 2008 17:49:18 +0000 (UTC) (envelope-from sclark46@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=qec8sezB6qcL/s3G7QECUB1txnmTVfmesrE9Sb63ujfIDNAtr4EpK2IK2F5eOoAm; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [208.118.36.229] (helo=joker.seclark.com) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L2UhR-0007dm-Td for freebsd-net@freebsd.org; Tue, 18 Nov 2008 12:49:18 -0500 Message-ID: <49230017.3050409@earthlink.net> Date: Tue, 18 Nov 2008 12:49:11 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> <20081115102746.K61259@maildrop.int.zabbadoz.net> <4921DBB4.4060505@earthlink.net> <20081118113823.T61259@maildrop.int.zabbadoz.net> <4922BF6A.1000108@earthlink.net> <20081118173337.GA19402@verio.net> In-Reply-To: <20081118173337.GA19402@verio.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79f1c406e031efcd1e93c747cb7e6693a9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 208.118.36.229 Subject: Re: FreeBSD 6.3 gre and tracerouteo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2008 17:49:18 -0000 David DeSimone wrote: > Stephen Clark wrote: >> switch (proto) { >> case IPPROTO_GRE: >> hlen += sizeof(struct gre_h); >> + >> + m->m_flags &= ~(M_DECRYPTED); >> + > > Are there security implications from removing this flag? > That is a very good question. I was wondering the same thing myself. Hopefully someone with a better understanding will comment on it. 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 Tue Nov 18 18:27:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90106106564A for ; Tue, 18 Nov 2008 18:27:51 +0000 (UTC) (envelope-from security@jim-liesl.org) Received: from smtp2.mc.surewest.net (qsmtp.mc.surewest.net [66.60.130.145]) by mx1.freebsd.org (Postfix) with SMTP id 76F5E8FC16 for ; Tue, 18 Nov 2008 18:27:51 +0000 (UTC) (envelope-from security@jim-liesl.org) Received: (qmail 28016 invoked from network); 18 Nov 2008 10:01:05 -0800 Received: by simscan 1.1.0 ppid: 28013, pid: 28014, t: 0.0768s scanners: regex: 1.1.0 attach: 1.1.0 Received: from unknown (HELO smtp.jim-liesl.org) (66.60.173.44) by smtp2 with SMTP; 18 Nov 2008 10:01:04 -0800 Received: from smtp.jim-liesl.org (localhost.static.surewest.net [127.0.0.1]) by smtp.jim-liesl.org (Postfix) with ESMTP id 2B8085DBB for ; Tue, 18 Nov 2008 10:01:08 -0800 (PST) Received: from [IPv6:::1] (daemon.static.surewest.net [192.168.1.15]) by smtp.jim-liesl.org (Postfix) with ESMTP id C572C5DB8 for ; Tue, 18 Nov 2008 10:01:07 -0800 (PST) Message-ID: <492302E2.4040907@jim-liesl.org> Date: Tue, 18 Nov 2008 10:01:06 -0800 From: security User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: bce discard frame w/o leading ethernet header and polling (broken?) 7.1-beta2 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, 18 Nov 2008 18:27:51 -0000 I'm building a WAN emulation box based on 7.1-beta2-ipfw and dummynet. The config is basically a router-on-a-stick. The server (FBSD rtr) has two nics which connect to two different switches, but both switch ports are in the same untagged interconnected vlan. All the other test boxes in the network are also in the same vlan, but broken into different nets. The different nets are spread across the two nics as primary and alias ip address in different nets. I've been getting "bursts" (maybe 8-20 at a time) of the discard frame messages. Mostly on bce1 but I've seen them on bce0 also. bce1 is probably the busier of the 2 currently. As a shot in the dark, I disabled polling system wide and the messages seemed to have stopped. thanks jim kernel: bce1: discard frame w/o leading ethernet header (len 4294967292 pkt len 4294967292) ipfw/dummynet/pipes are being used to rate limit traffic by src/dst ip address. The FreeBSD box uses the broadcom bcm5706s gigE interfaces. class=0x020000 card=0x310c103c chip=0x16aa14e4 rev=0x02 hdr=0x00. Based on some readings, I've got the following mods in place: i386 sources running on a 2 x dual core athalon64 cpus, 4 cores active. 8gig of mem available, but only 4 in use kernel i486 and i586 commented out nfs options commented out fbsd 4 and 5 commented out hz=1000 ipfirewall ipfirewall_default_to accept dummynet eisa commented out as well as the older nics sysctl settings kern.polling.enable=1 (setting this to 0 seems to fix the problem, but leaves the cpu's busier) kern.ipc.maxsockbuf=16777216 (not sure this helps much in the case of a rtr) net.inet.ip.forwarding=1 net.inet..tcp.sendbuf_auto=1 net.inet..tcp.sendbuf_max=16777216 net.inet..tcp.recvbuf_auto=1 net.inet..tcp.recvbuf_max=16777216 net.inet.tcp.rfc1323=1 net.link.ether.inet.log_arp_wrong_iface=0 (to suppress the arp messages) From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 18:44:29 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 6108F1065678; Tue, 18 Nov 2008 18:44:28 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-net@FreeBSD.org Date: Tue, 18 Nov 2008 13:44:11 -0500 User-Agent: KMail/1.6.2 References: <492302E2.4040907@jim-liesl.org> In-Reply-To: <492302E2.4040907@jim-liesl.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200811181344.20092.jkim@FreeBSD.org> Cc: security Subject: Re: bce discard frame w/o leading ethernet header and polling (broken?) 7.1-beta2 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, 18 Nov 2008 18:44:29 -0000 On Tuesday 18 November 2008 01:01 pm, security wrote: > I'm building a WAN emulation box based on 7.1-beta2-ipfw and > dummynet. The config is basically a router-on-a-stick. The server > (FBSD rtr) has two nics which connect to two different switches, > but both switch ports are in the same untagged interconnected vlan. > All the other test boxes in the network are also in the same vlan, > but broken into different nets. The different nets are spread > across the two nics as primary and alias ip address in different > nets. I've been getting "bursts" (maybe 8-20 at a time) of the > discard frame messages. Mostly on bce1 but I've seen them on bce0 > also. bce1 is probably the busier of the 2 currently. As a shot in > the dark, I disabled polling system wide and the messages seemed to > have stopped. Please try the latest driver from RELENG_7. The following commit seems interesting: http://svn.freebsd.org/viewvc/base?view=revision&revision=184826 Jung-uk Kim > thanks > jim > > > kernel: bce1: discard frame w/o leading ethernet header (len > 4294967292 pkt len 4294967292) > > ipfw/dummynet/pipes are being used to rate limit traffic by src/dst > ip address. > > The FreeBSD box uses the broadcom bcm5706s gigE interfaces. > class=0x020000 card=0x310c103c chip=0x16aa14e4 rev=0x02 hdr=0x00. > Based on some readings, I've got the following mods in place: > i386 sources running on a 2 x dual core athalon64 cpus, 4 cores > active. 8gig of mem available, but only 4 in use > kernel > i486 and i586 commented out > nfs options commented out > fbsd 4 and 5 commented out > hz=1000 > ipfirewall > ipfirewall_default_to accept > dummynet > eisa commented out as well as the older nics > > sysctl settings > kern.polling.enable=1 (setting this to 0 seems to fix the problem, > but leaves the cpu's busier) > kern.ipc.maxsockbuf=16777216 (not sure this helps much in the case > of a rtr) net.inet.ip.forwarding=1 > net.inet..tcp.sendbuf_auto=1 > net.inet..tcp.sendbuf_max=16777216 > net.inet..tcp.recvbuf_auto=1 > net.inet..tcp.recvbuf_max=16777216 > net.inet.tcp.rfc1323=1 > net.link.ether.inet.log_arp_wrong_iface=0 (to suppress the arp > messages) > > > > > _______________________________________________ > 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 Nov 18 21:15:48 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5809B1065719 for ; Tue, 18 Nov 2008 21:15:48 +0000 (UTC) (envelope-from security@jim-liesl.org) Received: from smtp1.mc.surewest.net (qsmtp.mc.surewest.net [66.60.130.145]) by mx1.freebsd.org (Postfix) with SMTP id 399518FC19 for ; Tue, 18 Nov 2008 21:15:48 +0000 (UTC) (envelope-from security@jim-liesl.org) Received: (qmail 6251 invoked from network); 18 Nov 2008 12:58:40 -0800 Received: by simscan 1.1.0 ppid: 6248, pid: 6249, t: 0.0744s scanners: regex: 1.1.0 attach: 1.1.0 Received: from unknown (HELO smtp.jim-liesl.org) (66.60.173.44) by smtp1 with SMTP; 18 Nov 2008 12:58:40 -0800 Received: from smtp.jim-liesl.org (localhost.static.surewest.net [127.0.0.1]) by smtp.jim-liesl.org (Postfix) with ESMTP id B267B5DBB; Tue, 18 Nov 2008 13:15:46 -0800 (PST) Received: from [IPv6:::1] (daemon.static.surewest.net [192.168.1.15]) by smtp.jim-liesl.org (Postfix) with ESMTP id 36C715DB8; Tue, 18 Nov 2008 13:15:45 -0800 (PST) Message-ID: <49233081.9000900@jim-liesl.org> Date: Tue, 18 Nov 2008 13:15:45 -0800 From: security User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Jung-uk Kim References: <492302E2.4040907@jim-liesl.org> <200811181344.20092.jkim@FreeBSD.org> In-Reply-To: <200811181344.20092.jkim@FreeBSD.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@FreeBSD.org Subject: Re: bce discard frame w/o leading ethernet header and polling (broken?) 7.1-beta2 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, 18 Nov 2008 21:15:48 -0000 Jung-uk Kim wrote: > On Tuesday 18 November 2008 01:01 pm, security wrote: > >> I'm building a WAN emulation box based on 7.1-beta2-ipfw and >> dummynet. The config is basically a router-on-a-stick. The server >> (FBSD rtr) has two nics which connect to two different switches, >> but both switch ports are in the same untagged interconnected vlan. >> All the other test boxes in the network are also in the same vlan, >> but broken into different nets. The different nets are spread >> across the two nics as primary and alias ip address in different >> nets. I've been getting "bursts" (maybe 8-20 at a time) of the >> discard frame messages. Mostly on bce1 but I've seen them on bce0 >> also. bce1 is probably the busier of the 2 currently. As a shot in >> the dark, I disabled polling system wide and the messages seemed to >> have stopped. >> > > Please try the latest driver from RELENG_7. The following commit > seems interesting: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=184826 > > Jung-uk Kim > Thanks, you're right it does. I noticed he disabled polling as I had done. There are enough other interesting bits that i'll try the driver. jim From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 22:22:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3456106564A for ; Tue, 18 Nov 2008 22:22:38 +0000 (UTC) (envelope-from prvs=julian=2012abc29@ironport.com) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id AA1EA8FC13 for ; Tue, 18 Nov 2008 22:22:38 +0000 (UTC) (envelope-from prvs=julian=2012abc29@ironport.com) DomainKey-Signature: s=key512; d=ironport.com; c=nofws; q=dns; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To: Subject:Content-Type; b=cMn9DdtBghLmQ/KZMk4M7bmpC6qGA2Town9IWIJcteEPUwU28wOwvPo3 6T6t3QyDIDltjCiEZPJbvKvEUc01tw==; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ironport.com; i=julian@ironport.com; q=dns/txt; s=ironport-dkim; t=1227046959; x=1258582959; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Julian=20Elischer=20 |Subject:=20tokenring=20users?|Date:=20Tue,=2018=20Nov=20 2008=2013:53:29=20-0800|Message-ID:=20<49233959.9040903@i ronport.com>|To:=20FreeBSD=20Net=20|MIME-Version:=201.0; bh=GoKqct2lRHpwYfxyKfAm8RSZCCfnz9JJ9rGWm1dC0I4=; b=SeFYg7Q8gsy5jfjTJ5DFyIMev1cSFH4YdKqmJhG2gi6evXTD0nn476F8 BZGwzLTIWRp2sG0PGewdhfNOdqvMBA==; Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.93]) by smtp-outbound.ironport.com with ESMTP; 18 Nov 2008 13:53:30 -0800 Message-ID: <49233959.9040903@ironport.com> Date: Tue, 18 Nov 2008 13:53:29 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: FreeBSD Net Content-Type: multipart/mixed; boundary="------------090307010706070108000809" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: tokenring users? 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, 18 Nov 2008 22:22:38 -0000 This is a multi-part message in MIME format. --------------090307010706070108000809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One of the things that are making things hard for network testing is the question "what to do about tokenring support?" We seem to have a dearth of tokenring users so we are completely unable test how changes affect tokenring. If anyone here knows anyone whoul could: 1/ help support tokenring 2/ help test tokenring, could they get in touch? thanks Julian and the rest of the network cabal in the dev-summit. --------------090307010706070108000809-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 22:28:15 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A2621065673 for ; Tue, 18 Nov 2008 22:28:15 +0000 (UTC) (envelope-from glavoie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 9EF1B8FC08 for ; Tue, 18 Nov 2008 22:28:14 +0000 (UTC) (envelope-from glavoie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2471852fgb.35 for ; Tue, 18 Nov 2008 14:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=8nzC+EG3dDbEVb07IQ+Mm2LaTOnvPRkEiiVZ+p4ktQE=; b=KLmYlV/uPakCRM2BzVhe6YnTs9hZ5OgbHmvUJBHYNJQdlayAaJEGuT65s/malQGgqD UIlj57egZDaHpfZrDBllucBbCwWlhNAc46Sic9pjrTfh5TEE7zDQkYjnWESjEMPl+4ob uk1bofpbKa9PhAeCgSrNqDitlfR9f2rQiSmcw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=UNtPd1v6uZHl8xtEKttQGp5MIoSIMQdYjARkGPupHRuaJfM+lIxa3WLJTE8DlngzGI NgTzZcTA2jDCECxC0jEYNFgWsIpL59FzYTRgrWbrFnqrEoz8pzwijxfvJUlMFdeR2++b /cUtM5A07/yRWOZaUEKfPRejvWn8C7ElAjDII= Received: by 10.181.153.12 with SMTP id f12mr103878bko.132.1227047293200; Tue, 18 Nov 2008 14:28:13 -0800 (PST) Received: by 10.181.16.18 with HTTP; Tue, 18 Nov 2008 14:28:13 -0800 (PST) Message-ID: Date: Tue, 18 Nov 2008 17:28:13 -0500 From: "Gabriel Lavoie" To: pyunyh@gmail.com In-Reply-To: <20081118043731.GD55015@cdnetworks.co.kr> MIME-Version: 1.0 References: <957411.42240.qm@web39101.mail.mud.yahoo.com> <20081117023024.GE50872@cdnetworks.co.kr> <20081117034428.GG50872@cdnetworks.co.kr> <20081118043731.GD55015@cdnetworks.co.kr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bf , freebsd-net@freebsd.org Subject: Re: Realtek 8139 with rl(4) driver -> Poor performance 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, 18 Nov 2008 22:28:15 -0000 Requested commands: Before a problem happens: [root@headless ~]# sysctl hw.busdma hw.busdma.total_bpages: 8260 hw.busdma.zone0.total_bpages: 8196 hw.busdma.zone0.free_bpages: 8196 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.alignment: 1 hw.busdma.zone0.boundary: 0 hw.busdma.zone1.total_bpages: 64 hw.busdma.zone1.free_bpages: 64 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.active_bpages: 0 hw.busdma.zone1.total_bounced: 8200 hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.lowaddr: 0xffffffff hw.busdma.zone1.alignment: 2 hw.busdma.zone1.boundary: 65536 [root@headless ~]# netstat -nd -I rl0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll Drop rl0 1500 00:50:fc:c6:c8:d2 64336 0 60706 0 0 0 rl0 1500 192.168.69.0/ 192.168.69.87 63398 - 59820 - - - I got a Samba copy error at this point: [root@headless /home/wildchild]# sysctl hw.busdma hw.busdma.total_bpages: 8260 hw.busdma.zone0.total_bpages: 8196 hw.busdma.zone0.free_bpages: 8196 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.alignment: 1 hw.busdma.zone0.boundary: 0 hw.busdma.zone1.total_bpages: 64 hw.busdma.zone1.free_bpages: 64 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.active_bpages: 0 hw.busdma.zone1.total_bounced: 144539 hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.lowaddr: 0xffffffff hw.busdma.zone1.alignment: 2 hw.busdma.zone1.boundary: 65536 [root@headless /home/wildchild]# netstat -nd -I rl0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll Drop rl0 1500 00:50:fc:c6:c8:d2 6718354 0 4023956 0 0 0 rl0 1500 192.168.69.0/ 192.168.69.87 6717392 - 4023051 - - - Now the networking is really erratic. I have a huge slowdown with SSH and I'm unable to copy files on the computer anymore via Samba. I must reboot to get back the full performance. Gabriel 2008/11/17 Pyun YongHyeon > On Mon, Nov 17, 2008 at 09:56:05PM -0500, Gabriel Lavoie wrote: > > Hum. I tried transfering a lot of data tonight via Samba (30GB). It > seems > > that after some time the driver becomes again unstable and the > networking > > performance drops really low. I could hardly SSH to this box after it > > happened. > > Would you show me the output of "sysctl hw.busdma" and > "netstat -nd -I rl0"? > Did rl(4) show some messages on your console? > > > > > Gabriel > -- > Regards, > Pyun YongHyeon > -- Gabriel Lavoie glavoie@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 22:50:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C06BC1065670 for ; Tue, 18 Nov 2008 22:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AB9378FC19 for ; Tue, 18 Nov 2008 22:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAIMo4rO028172 for ; Tue, 18 Nov 2008 22:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAIMo4gb028171; Tue, 18 Nov 2008 22:50:04 GMT (envelope-from gnats) Date: Tue, 18 Nov 2008 22:50:04 GMT Message-Id: <200811182250.mAIMo4gb028171@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Marius Strobl Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marius Strobl List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2008 22:50:04 -0000 The following reply was made to PR kern/128833; it has been noted by GNATS. From: Marius Strobl To: =?unknown-8bit?Q?Aur=E9lien_M=E9r=E9?= Cc: bug-followup@FreeBSD.org Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Tue, 18 Nov 2008 23:46:21 +0100 On Mon, Nov 17, 2008 at 02:37:51AM +0100, Aurlien Mr wrote: > Hi > As first check, when device is being attached, here are the values reported > and the diff : > > in 32 bit slot : > BGE_PCI_PCISTATE = 0x96 (0x86 | BGE_PCISTATE_32BIT_BUS) > bge_flags = 0x120E (0x100E | BGE_FLAG_PCIX) > > in 64 bit slot : > BGE_PCI_PCISTATE = 0x8E (0x86 | BGE_PCISTATE_PCI_BUSSPEED) > bge_flags = 0x1A0E (0x100E | BGE_FLAG_PCIX | BGE_FLAG_64BIT) > > Seems logical so far, I'll try to look further. Apart from the problem described by davidch@ (I'm not sure you actually have a BCM5701 A3 though, at least bge(4) doesn't seem to be aware of that revision) the BGE_PCI_PCISTATE and bge_flags pairs you reported don't match though; according to BGE_PCI_PCISTATE the card isn't in a PCI-X slot in either case (BGE_PCISTATE_PCI_BUSMODE is always set, which means PCI) and AFAICT your motherboard chipset also doesn't support PCI-X. However, as you noted BGE_FLAG_PCIX is set for whatever reason in both cases, which leads to some inappropriate initialization of the controller. As a quick test could you please check whether replacing the "#if __FreeBSD_version > 602101" in the driver with an "#if 0" makes any difference to your problem? Marius From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 23:01:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DB6A106564A for ; Tue, 18 Nov 2008 23:01:38 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from mail.comstyle.com (unknown [IPv6:2001:470:1d:8c::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0B8878FC0A for ; Tue, 18 Nov 2008 23:01:38 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from [192.168.3.33] (toronto-hs-216-138-195-228.s-ip.magma.ca [216.138.195.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: brad) by mail.comstyle.com (Postfix) with ESMTPSA id 7CACF9840B; Tue, 18 Nov 2008 18:01:14 -0500 (EST) From: Brad To: freebsd-net@freebsd.org, Marius Strobl Date: Tue, 18 Nov 2008 18:01:10 -0500 User-Agent: KMail/1.9.10 References: <200811182250.mAIMo4gb028171@freefall.freebsd.org> In-Reply-To: <200811182250.mAIMo4gb028171@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811181801.10997.brad@comstyle.com> X-comstyle-MailScanner-Information: Please contact the ISP for more information X-comstyle-MailScanner-ID: 7CACF9840B.6F6DF X-comstyle-MailScanner: Found to be clean X-comstyle-MailScanner-From: brad@comstyle.com X-Spam-Status: No Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2008 23:01:38 -0000 On Tuesday 18 November 2008 17:50:04 Marius Strobl wrote: > The following reply was made to PR kern/128833; it has been noted by GNATS. > > From: Marius Strobl > To: =?unknown-8bit?Q?Aur=E9lien_M=E9r=E9?= > Cc: bug-followup@FreeBSD.org > Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is > in 64-bit PCI slot Date: Tue, 18 Nov 2008 23:46:21 +0100 > > On Mon, Nov 17, 2008 at 02:37:51AM +0100, Aurlien Mr wrote: > > Hi > > As first check, when device is being attached, here are the values > > reported and the diff : > > > > in 32 bit slot : > > BGE_PCI_PCISTATE = 0x96 (0x86 | BGE_PCISTATE_32BIT_BUS) > > bge_flags = 0x120E (0x100E | BGE_FLAG_PCIX) > > > > in 64 bit slot : > > BGE_PCI_PCISTATE = 0x8E (0x86 | BGE_PCISTATE_PCI_BUSSPEED) > > bge_flags = 0x1A0E (0x100E | BGE_FLAG_PCIX | BGE_FLAG_64BIT) > > > > Seems logical so far, I'll try to look further. > > Apart from the problem described by davidch@ (I'm not sure > you actually have a BCM5701 A3 though, at least bge(4) doesn't > seem to be aware of that revision) the BGE_PCI_PCISTATE and > bge_flags pairs you reported don't match though; according > to BGE_PCI_PCISTATE the card isn't in a PCI-X slot in either > case (BGE_PCISTATE_PCI_BUSMODE is always set, which means > PCI) and AFAICT your motherboard chipset also doesn't > support PCI-X. However, as you noted BGE_FLAG_PCIX is set > for whatever reason in both cases, which leads to some > inappropriate initialization of the controller. As a quick > test could you please check whether replacing the "#if > __FreeBSD_version > 602101" in the driver with an "#if 0" > makes any difference to your problem? The PCI-X check which is used for I'm guessing FreeBSD 7 and newer is wrong. Older versions get it right. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 00:16:28 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D3581065672 for ; Wed, 19 Nov 2008 00:16:28 +0000 (UTC) (envelope-from security@jim-liesl.org) Received: from smtp1.mc.surewest.net (qsmtp.mc.surewest.net [66.60.130.145]) by mx1.freebsd.org (Postfix) with SMTP id 47A058FC25 for ; Wed, 19 Nov 2008 00:16:28 +0000 (UTC) (envelope-from security@jim-liesl.org) Received: (qmail 2250 invoked from network); 18 Nov 2008 15:59:18 -0800 Received: by simscan 1.1.0 ppid: 2247, pid: 2248, t: 0.0663s scanners: regex: 1.1.0 attach: 1.1.0 Received: from unknown (HELO smtp.jim-liesl.org) (66.60.173.44) by smtp1 with SMTP; 18 Nov 2008 15:59:18 -0800 Received: from smtp.jim-liesl.org (localhost.static.surewest.net [127.0.0.1]) by smtp.jim-liesl.org (Postfix) with ESMTP id 423E55DBB; Tue, 18 Nov 2008 16:16:25 -0800 (PST) Received: from [IPv6:::1] (daemon.static.surewest.net [192.168.1.15]) by smtp.jim-liesl.org (Postfix) with ESMTP id A296F5DB8; Tue, 18 Nov 2008 16:16:19 -0800 (PST) Message-ID: <49235AD3.1090702@jim-liesl.org> Date: Tue, 18 Nov 2008 16:16:19 -0800 From: security User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Jung-uk Kim References: <492302E2.4040907@jim-liesl.org> <200811181344.20092.jkim@FreeBSD.org> In-Reply-To: <200811181344.20092.jkim@FreeBSD.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@FreeBSD.org Subject: Re: bce discard frame w/o leading ethernet header and polling (broken?) 7.1-beta2 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, 19 Nov 2008 00:16:28 -0000 Jung-uk Kim wrote: > On Tuesday 18 November 2008 01:01 pm, security wrote: > >> I'm building a WAN emulation box based on 7.1-beta2-ipfw and >> dummynet. The config is basically a router-on-a-stick. The server >> (FBSD rtr) has two nics which connect to two different switches, >> but both switch ports are in the same untagged interconnected vlan. >> All the other test boxes in the network are also in the same vlan, >> but broken into different nets. The different nets are spread >> across the two nics as primary and alias ip address in different >> nets. I've been getting "bursts" (maybe 8-20 at a time) of the >> discard frame messages. Mostly on bce1 but I've seen them on bce0 >> also. bce1 is probably the busier of the 2 currently. As a shot in >> the dark, I disabled polling system wide and the messages seemed to >> have stopped. >> > > Please try the latest driver from RELENG_7. The following commit > seems interesting: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=184826 > > Jung-uk Kim > > >> thanks >> jim >> >> >> kernel: bce1: discard frame w/o leading ethernet header (len >> 4294967292 pkt len 4294967292) >> >> ipfw/dummynet/pipes are being used to rate limit traffic by src/dst >> ip address. >> >> The FreeBSD box uses the broadcom bcm5706s gigE interfaces. >> class=0x020000 card=0x310c103c chip=0x16aa14e4 rev=0x02 hdr=0x00. >> Based on some readings, I've got the following mods in place: >> i386 sources running on a 2 x dual core athalon64 cpus, 4 cores >> active. 8gig of mem available, but only 4 in use >> kernel >> i486 and i586 commented out >> nfs options commented out >> fbsd 4 and 5 commented out >> hz=1000 >> ipfirewall >> ipfirewall_default_to accept >> dummynet >> eisa commented out as well as the older nics >> >> sysctl settings >> kern.polling.enable=1 (setting this to 0 seems to fix the problem, >> but leaves the cpu's busier) >> kern.ipc.maxsockbuf=16777216 (not sure this helps much in the case >> of a rtr) net.inet.ip.forwarding=1 >> net.inet..tcp.sendbuf_auto=1 >> net.inet..tcp.sendbuf_max=16777216 >> net.inet..tcp.recvbuf_auto=1 >> net.inet..tcp.recvbuf_max=16777216 >> net.inet.tcp.rfc1323=1 >> net.link.ether.inet.log_arp_wrong_iface=0 (to suppress the arp >> messages) >> I'm running the new driver now. It's logging Ierrs on the of "netstat -I bcen -a" @ about 1-2 per second. I don't *think* it was doing that under the original driver, but I couldn't swear to it, and it would be difficult to revert right now to check. The errors seem unrelated to traffic generated by ping repeat count or payload size. Might these be the ARP on the wrong iface errors I'm suppressing ? Ping isn't complaining about any dropped packets and I'm not seeing any drops or collision stats. jim From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 01:30:05 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 308E11065670 for ; Wed, 19 Nov 2008 01:30:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1897B8FC0C for ; Wed, 19 Nov 2008 01:30:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAJ1U4Lt047443 for ; Wed, 19 Nov 2008 01:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAJ1U4Wr047440; Wed, 19 Nov 2008 01:30:04 GMT (envelope-from gnats) Date: Wed, 19 Nov 2008 01:30:04 GMT Message-Id: <200811190130.mAJ1U4Wr047440@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: =?iso-8859-1?B?QXVy6WxpZW4gTely6Q==?= Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?iso-8859-1?B?QXVy6WxpZW4gTely6Q==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 01:30:05 -0000 The following reply was made to PR kern/128833; it has been noted by GNATS. From: =?iso-8859-1?B?QXVy6WxpZW4gTely6Q==?= To: "Marius Strobl" Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Wed, 19 Nov 2008 02:27:43 +0100 Concerning the problem described by davidch@ , my chip is reported as a B5 revision (01050000), so it might not be the case here. You're right, the M/B doesn't support PCI-X at all. As detailed on the manual, the NB chipset (AMD762) provides support for 2x66 MHz 64-bit PCI 2.2 masters, and the SB chipset (AMD768) provides a secondary PCI 2.2 bridge 33MHz. I tried the patch but it didn't solve the problem, whilst the BGE_FLAG_PCIX was no longer in the flags, which seems much more correct anyway. At the end of the initialization values are these, as planned : bge_flags = 0x0010180F (0x10100F | BGE_FLAG_64BIT) . BGE_PCI_PCISTATE is unchanged Note I forgot to mention the BGE_FLAG_RXALIGN_BUG (100000) and BGE_FLAG_TBI (1) last time, as I tested before reset of the chip where these flags are set. ----- Original Message ----- From: "Marius Strobl" To: "Aurélien Méré" Cc: Sent: Tuesday, November 18, 2008 11:46 PM Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot > On Mon, Nov 17, 2008 at 02:37:51AM +0100, Aurlien Mr wrote: >> Hi >> As first check, when device is being attached, here are the values >> reported >> and the diff : >> >> in 32 bit slot : >> BGE_PCI_PCISTATE = 0x96 (0x86 | BGE_PCISTATE_32BIT_BUS) >> bge_flags = 0x120E (0x100E | BGE_FLAG_PCIX) >> >> in 64 bit slot : >> BGE_PCI_PCISTATE = 0x8E (0x86 | BGE_PCISTATE_PCI_BUSSPEED) >> bge_flags = 0x1A0E (0x100E | BGE_FLAG_PCIX | BGE_FLAG_64BIT) >> >> Seems logical so far, I'll try to look further. > > Apart from the problem described by davidch@ (I'm not sure > you actually have a BCM5701 A3 though, at least bge(4) doesn't > seem to be aware of that revision) the BGE_PCI_PCISTATE and > bge_flags pairs you reported don't match though; according > to BGE_PCI_PCISTATE the card isn't in a PCI-X slot in either > case (BGE_PCISTATE_PCI_BUSMODE is always set, which means > PCI) and AFAICT your motherboard chipset also doesn't > support PCI-X. However, as you noted BGE_FLAG_PCIX is set > for whatever reason in both cases, which leads to some > inappropriate initialization of the controller. As a quick > test could you please check whether replacing the "#if > __FreeBSD_version > 602101" in the driver with an "#if 0" > makes any difference to your problem? > > Marius > From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 01:39:21 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 614D0106564A for ; Wed, 19 Nov 2008 01:39:21 +0000 (UTC) (envelope-from security@jim-liesl.org) Received: from smtp2.mc.surewest.net (qsmtp.mc.surewest.net [66.60.130.145]) by mx1.freebsd.org (Postfix) with SMTP id 3CA728FC13 for ; Wed, 19 Nov 2008 01:39:21 +0000 (UTC) (envelope-from security@jim-liesl.org) Received: (qmail 7788 invoked from network); 18 Nov 2008 17:39:15 -0800 Received: by simscan 1.1.0 ppid: 7782, pid: 7784, t: 0.1588s scanners: regex: 1.1.0 attach: 1.1.0 Received: from unknown (HELO smtp.jim-liesl.org) (66.60.173.44) by smtp2 with SMTP; 18 Nov 2008 17:39:15 -0800 Received: from smtp.jim-liesl.org (localhost.static.surewest.net [127.0.0.1]) by smtp.jim-liesl.org (Postfix) with ESMTP id 26C7A5DBB; Tue, 18 Nov 2008 17:39:20 -0800 (PST) Received: from [IPv6:::1] (daemon.static.surewest.net [192.168.1.15]) by smtp.jim-liesl.org (Postfix) with ESMTP id 8CCA25DB8; Tue, 18 Nov 2008 17:39:18 -0800 (PST) Message-ID: <49236E46.7090207@jim-liesl.org> Date: Tue, 18 Nov 2008 17:39:18 -0800 From: security User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Jung-uk Kim References: <492302E2.4040907@jim-liesl.org> <200811181344.20092.jkim@FreeBSD.org> <49235AD3.1090702@jim-liesl.org> In-Reply-To: <49235AD3.1090702@jim-liesl.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@FreeBSD.org Subject: Re: bce discard frame w/o leading ethernet header and polling (broken?) 7.1-beta2 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, 19 Nov 2008 01:39:21 -0000 security wrote: > Jung-uk Kim wrote: > >> On Tuesday 18 November 2008 01:01 pm, security wrote: >> >> >>> I'm building a WAN emulation box based on 7.1-beta2-ipfw and >>> dummynet. The config is basically a router-on-a-stick. The server >>> (FBSD rtr) has two nics which connect to two different switches, >>> but both switch ports are in the same untagged interconnected vlan. >>> All the other test boxes in the network are also in the same vlan, >>> but broken into different nets. The different nets are spread >>> across the two nics as primary and alias ip address in different >>> nets. I've been getting "bursts" (maybe 8-20 at a time) of the >>> discard frame messages. Mostly on bce1 but I've seen them on bce0 >>> also. bce1 is probably the busier of the 2 currently. As a shot in >>> the dark, I disabled polling system wide and the messages seemed to >>> have stopped. >>> >>> >> Please try the latest driver from RELENG_7. The following commit >> seems interesting: >> >> http://svn.freebsd.org/viewvc/base?view=revision&revision=184826 >> >> Jung-uk Kim >> >> >> >>> thanks >>> jim >>> >>> >>> kernel: bce1: discard frame w/o leading ethernet header (len >>> 4294967292 pkt len 4294967292) >>> >>> ipfw/dummynet/pipes are being used to rate limit traffic by src/dst >>> ip address. >>> >>> The FreeBSD box uses the broadcom bcm5706s gigE interfaces. >>> class=0x020000 card=0x310c103c chip=0x16aa14e4 rev=0x02 hdr=0x00. >>> Based on some readings, I've got the following mods in place: >>> i386 sources running on a 2 x dual core athalon64 cpus, 4 cores >>> active. 8gig of mem available, but only 4 in use >>> kernel >>> i486 and i586 commented out >>> nfs options commented out >>> fbsd 4 and 5 commented out >>> hz=1000 >>> ipfirewall >>> ipfirewall_default_to accept >>> dummynet >>> eisa commented out as well as the older nics >>> >>> sysctl settings >>> kern.polling.enable=1 (setting this to 0 seems to fix the problem, >>> but leaves the cpu's busier) >>> kern.ipc.maxsockbuf=16777216 (not sure this helps much in the case >>> of a rtr) net.inet.ip.forwarding=1 >>> net.inet..tcp.sendbuf_auto=1 >>> net.inet..tcp.sendbuf_max=16777216 >>> net.inet..tcp.recvbuf_auto=1 >>> net.inet..tcp.recvbuf_max=16777216 >>> net.inet.tcp.rfc1323=1 >>> net.link.ether.inet.log_arp_wrong_iface=0 (to suppress the arp >>> messages) >>> >>> > I'm running the new driver now. It's logging Ierrs on the of > "netstat -I bcen -a" @ about 1-2 per second. I don't *think* it was > doing that under the original driver, but I couldn't swear to it, and it > would be difficult to revert right now to check. The errors seem > unrelated to traffic generated by ping repeat count or payload size. > Might these be the ARP on the wrong iface errors I'm suppressing ? Ping > isn't complaining about any dropped packets and I'm not seeing any drops > or collision stats. > to reply to my own post, I dumped the sysctl values for the bce devices. These errors are L2Filter drops and I suspect they're from oversize >1500 ethernet frames. Not sure whats generating them yet. jim From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 02:09:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B876106564A for ; Wed, 19 Nov 2008 02:09:45 +0000 (UTC) (envelope-from glavoie@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id E9BB98FC0A for ; Wed, 19 Nov 2008 02:09:44 +0000 (UTC) (envelope-from glavoie@gmail.com) Received: by rv-out-0506.google.com with SMTP id f9so405491rvb.1 for ; Tue, 18 Nov 2008 18:09:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=Hr3N689FT+nvwKWoK/7QvCGS+eWuvIJQw9CAeXHw+Hs=; b=OxQ0DxyoDJ8uud7wyNN/uag8lkwdBK087+WD5zBNcw/ro1eCmfbgt5FapQN6xF3v0n ibevulXhIMxk3MLS/MCFOxKEC3VO9h2Wka/JFRK86Umrujkifp4QIOUFyAw6rUSTIQ0d 3TkIwGKhcGg8Dabg/jI82mB+RdUtEIzz8uHJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=SiBybECFDKI6N5MuO+Ml8gaM1Ud5WDJ4xc/726GT5YdE55Dah3FvwzlsgeSmeSAaTL r4XUNYjHXcEWCOAQttGpHg5Lktj5nJFK+YXshEZ3FZsSyYLwSMKY2FtKm8ygXXA46Mzg 6o3o4Y5OMp7Qpo6PkDGMdOEx46iGRhHtISORY= Received: by 10.140.177.15 with SMTP id z15mr286179rve.114.1227060584631; Tue, 18 Nov 2008 18:09:44 -0800 (PST) Received: by 10.141.146.8 with HTTP; Tue, 18 Nov 2008 18:09:44 -0800 (PST) Message-ID: Date: Tue, 18 Nov 2008 21:09:44 -0500 From: "Gabriel Lavoie" To: pyunyh@gmail.com In-Reply-To: MIME-Version: 1.0 References: <20081117003856.GB50872@cdnetworks.co.kr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Realtek 8139 with rl(4) driver -> Poor performance 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, 19 Nov 2008 02:09:45 -0000 Hum when I do my Samba transfer, there is a lot of small files (> 50 000) and it seems at some point Samba tops at 100% CPU usage on one core. Is it possible the rl(4) driver could be influenced by high CPU load? With the ale(4) driver, there's no problem but the Samba transfer becomes really slow because of the amount of files. Gabriel 2008/11/18 Gabriel Lavoie > By the way, I'm currently trying the ale(4) driver under FreeBSD 7.0 (my > current installation). It seems to works flawlesly with excellent > performances. I'm currently doing the 30 GB transfer I'm unable to do with > the Realtek card. I'll see what happens. > > Gabriel > > 2008/11/16 Pyun YongHyeon > > On Sun, Nov 16, 2008 at 06:01:58PM -0500, Gabriel Lavoie wrote: >> > Hello, >> > I recently built a new system to use as a home server. This system >> has >> > an Intel Pentium Dual Core E5200, 4GB RAM and an Asus P5KPL-CM >> motherboard >> > which has an Atheros L1E network adapter, not yet supported on FreeBSD. >> For >> >> ale(4) was committed to HEAD. If you're using lastest stable/7 >> see the following URL. >> http://people.freebsd.org/~yongari/ale/README >> >> > now, I use a Realtek 8139 PCI adapter that uses the rl(4) driver, but >> the >> > upload performances are really poor (under 1 MB/sec). Is there any way >> to >> > improve the performance with this driver? This adapter was in a Linux >> system >> > with a Pentium III processor before and I could upload/download at >> around 10 >> > MB/sec in my local network with no problem at all. >> > >> >> There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. >> How about rl(4) in HEAD? I guess it would build with minor >> modification. >> >> -- >> Regards, >> Pyun YongHyeon >> > > > > -- > Gabriel Lavoie > glavoie@gmail.com > -- Gabriel Lavoie glavoie@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 09:09:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BB1B1065670 for ; Wed, 19 Nov 2008 09:09:18 +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 3665C8FC08 for ; Wed, 19 Nov 2008 09:09:18 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 21445 invoked from network); 19 Nov 2008 07:34:33 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Nov 2008 07:34:33 -0000 Message-ID: <4923D7C0.7050301@freebsd.org> Date: Wed, 19 Nov 2008 10:09:20 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Julian Elischer References: <49233959.9040903@ironport.com> In-Reply-To: <49233959.9040903@ironport.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: tokenring users? 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, 19 Nov 2008 09:09:18 -0000 Julian Elischer wrote: > One of the things that are making things hard for network testing is the > question > "what to do about tokenring support?" > > We seem to have a dearth of tokenring users so we are completely unable > test how changes affect tokenring. > > If anyone here knows anyone whoul could: > 1/ help support tokenring > 2/ help test tokenring, > > could they get in touch? I guess Token Ring is as dead as it gets. The last I time ran across someone using it was in 1996 or 1997. I asked our engineers here (on a customer base of about 1k SME) and got only blank stares. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 09:52:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A72D91065677; Wed, 19 Nov 2008 09:52:45 +0000 (UTC) (envelope-from prvs=julian=2029692e7@ironport.com) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 769418FC20; Wed, 19 Nov 2008 09:52:45 +0000 (UTC) (envelope-from prvs=julian=2029692e7@ironport.com) DomainKey-Signature: s=key512; d=ironport.com; c=nofws; q=dns; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To: CC:Subject:References:In-Reply-To:Content-Type; b=Gep/+KnN+c5hQw+GIu+ePmvFuc9kkPACeGw6GiatSN8DGCdlY96QtrgY mOJLLmEr1Y5BLS+IM2X1E9aiU2YTGQ==; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ironport.com; i=julian@ironport.com; q=dns/txt; s=ironport-dkim; t=1227088366; x=1258624366; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Julian=20Elischer=20 |Subject:=20Re:=20tokenring=20users?|Date:=20Wed,=2019=20 Nov=202008=2001:23:57=20-0800|Message-ID:=20<4923DB2D.208 0702@ironport.com>|To:=20Andre=20Oppermann=20|CC:=20FreeBSD=20Net=20 |MIME-Version:=201.0|In-Reply-To:=20<4923D7C0.7050301@fre ebsd.org>|References:=20<49233959.9040903@ironport.com> =20<4923D7C0.7050301@freebsd.org>; bh=1kFd4u3bq5aSm2GKebz3u+sd17ssmjL9rky5BiUHFkI=; b=AMnVlXHX0i2R4aqYdoJxnK4eFkqd+gSBu6fSEPTET9Rcv1YJu7jibtB5 exC1zbTfxO/5/dIvObhZCQ1mgsaNDQ==; Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.177]) by smtp-outbound.ironport.com with ESMTP; 19 Nov 2008 01:23:58 -0800 Message-ID: <4923DB2D.2080702@ironport.com> Date: Wed, 19 Nov 2008 01:23:57 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Andre Oppermann References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> In-Reply-To: <4923D7C0.7050301@freebsd.org> Content-Type: multipart/mixed; boundary="------------040300070207030502060100" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net Subject: Re: tokenring users? 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, 19 Nov 2008 09:52:45 -0000 This is a multi-part message in MIME format. --------------040300070207030502060100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andre Oppermann wrote: > Julian Elischer wrote: >> One of the things that are making things hard for network testing is >> the question >> "what to do about tokenring support?" >> >> We seem to have a dearth of tokenring users so we are completely unable >> test how changes affect tokenring. >> >> If anyone here knows anyone whoul could: >> 1/ help support tokenring >> 2/ help test tokenring, >> >> could they get in touch? > > I guess Token Ring is as dead as it gets. The last I time ran across > someone using it was in 1996 or 1997. I asked our engineers here (on > a customer base of about 1k SME) and got only blank stares. > yes I think that may be the case but I saw a bug report about it a few years ago.. --------------040300070207030502060100-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 10:30:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ABC61065692 for ; Wed, 19 Nov 2008 10:30:08 +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 320A88FC20 for ; Wed, 19 Nov 2008 10:30:08 +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 B54D641C69F; Wed, 19 Nov 2008 11:30:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id c+CtIF89Fpoc; Wed, 19 Nov 2008 11:30:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 69B9F41C6BB; Wed, 19 Nov 2008 11:30:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 48BB6444888; Wed, 19 Nov 2008 10:28:19 +0000 (UTC) Date: Wed, 19 Nov 2008 10:28:19 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Julian Elischer In-Reply-To: <4923DB2D.2080702@ironport.com> Message-ID: <20081119102301.R61259@maildrop.int.zabbadoz.net> References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> <4923DB2D.2080702@ironport.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net Subject: Re: tokenring users? 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, 19 Nov 2008 10:30:08 -0000 On Wed, 19 Nov 2008, Julian Elischer wrote: Hi, > Andre Oppermann wrote: >> Julian Elischer wrote: >>> One of the things that are making things hard for network testing is the >>> question >>> "what to do about tokenring support?" >>> >>> We seem to have a dearth of tokenring users so we are completely unable >>> test how changes affect tokenring. >>> >>> If anyone here knows anyone whoul could: >>> 1/ help support tokenring >>> 2/ help test tokenring, >>> >>> could they get in touch? >> >> I guess Token Ring is as dead as it gets. The last I time ran across >> someone using it was in 1996 or 1997. I asked our engineers here (on >> a customer base of about 1k SME) and got only blank stares. >> > > yes I think that may be the case but I saw a bug report > about it a few years ago.. I have given away all my TR equipment a few years back, but I know people still running TR though with Cisco and non-FreeBSD-OSes though they got rid of all TR they could get rid off. So what exactly is your question in supporting and testing FreeBSD TR support? And let me ask why you are asking for TR, not FDDI or some of the other things lingering in sys/net**? /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 11:06:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DA731065670; Wed, 19 Nov 2008 11:06:05 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by mx1.freebsd.org (Postfix) with ESMTP id DC5918FC0C; Wed, 19 Nov 2008 11:06:04 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTP id <0KAK007NRTG3ZEF0@mta-2.ms.rz.RWTH-Aachen.de>; Wed, 19 Nov 2008 11:36:03 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.33,630,1220220000"; d="scan'208";a="90915363" Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 19 Nov 2008 11:36:02 +0100 Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id mAJAa3Rc008248; Wed, 19 Nov 2008 11:36:03 +0100 (CET) Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1L2kPj-0008JH-5l; Wed, 19 Nov 2008 11:36:03 +0100 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 07C283F41B; Wed, 19 Nov 2008 11:36:03 +0100 (CET) Date: Wed, 19 Nov 2008 11:36:02 +0100 From: Christian Brueffer To: Julian Elischer Message-id: <20081119103602.GA2339@haakonia.hitnet.RWTH-Aachen.DE> References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> <4923DB2D.2080702@ironport.com> Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=ZPt4rx8FFjLCG7dd Content-disposition: inline In-reply-to: <4923DB2D.2080702@ironport.com> X-Operating-System: FreeBSD 6.4-PRERELEASE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D User-Agent: Mutt/1.5.11 Cc: FreeBSD Net , Andre Oppermann Subject: Re: tokenring users? 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, 19 Nov 2008 11:06:05 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 19, 2008 at 01:23:57AM -0800, Julian Elischer wrote: > Andre Oppermann wrote: > >Julian Elischer wrote: > >>One of the things that are making things hard for network testing is=20 > >>the question > >>"what to do about tokenring support?" > >> > >>We seem to have a dearth of tokenring users so we are completely unable > >>test how changes affect tokenring. > >> > >>If anyone here knows anyone whoul could: > >>1/ help support tokenring > >>2/ help test tokenring, > >> > >>could they get in touch? > > > >I guess Token Ring is as dead as it gets. The last I time ran across > >someone using it was in 1996 or 1997. I asked our engineers here (on > >a customer base of about 1k SME) and got only blank stares. > > >=20 > yes I think that may be the case but I saw a bug report > about it a few years ago.. >=20 The last (afaik) in-tree token-ring driver we had was oltr(4) which has been removed from HEAD not too long ago. So the questions is whether there are companies with custom drivers. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFJI+wSbHYXjKDtmC0RAqpkAKDJ/wcmUGRV5aHIbr6aKQMoPEZYkgCg6wR+ BRM2/2jNwQo4dVyL50w/eYY= =x8OM -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 15:00:30 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6B931065678 for ; Wed, 19 Nov 2008 15:00:30 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id 80EB98FC16 for ; Wed, 19 Nov 2008 15:00:30 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [130.129.95.183] ([130.129.95.183]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mAJF0SkH016780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 19 Nov 2008 10:00:29 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1227106829; h=Message-Id:From:To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:X-Mailer; b=tkb BoOU7EVyax3LPoN0c8DUGptP4H2CqCnV7SlpVjAS1djMQZfg2tPuc5i35F8SJ7YgW2u SMAJ8QQNHtM1IRIQ== Message-Id: From: Randall Stewart To: freebsd-net Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 10:00:27 -0500 X-Mailer: Apple Mail (2.929.2) Cc: Subject: Thinking about UDP and tunneling 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, 19 Nov 2008 15:00:30 -0000 Dear All: I have been contemplating UDP and tunneling. One of the things that is a nice feature in MacOS is the ability of a kernel module/extension to open a kernel level socket and have the mbuf chain that arrives for that port be passed in via a function. We use this in our MacOS version of the SCTP stack to do the UDP de-tunneling of SCTP packets. This is becoming a more and more common thing i.e. having transport protocols like SCTP and DCCP be tunneled over UDP to get by NAT's.... this actually sucks that this is necessary .. but it is what it is.... So, I am contemplating adding a similar sort of feature... basically provide an interface in UDP that a consumer (such as SCTP or DCCP) could use to "bind" a port and get UDP packets directly. What do you all think of the idea? That also reminds me.. who owns the ipfw code.. we actually have SCTP nat support that Jason But has done that we need to get in... I would be more than glad to shepherd this in if the owner of the code does not have the time... R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 15:45:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 202D01065670 for ; Wed, 19 Nov 2008 15:45:29 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id A1DF58FC0C for ; Wed, 19 Nov 2008 15:45:28 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-067-228-082.pools.arcor-ip.net [88.67.228.82]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1L2pF921hG-0004C4; Wed, 19 Nov 2008 16:45:27 +0100 Received: (qmail 80386 invoked from network); 19 Nov 2008 15:45:27 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 19 Nov 2008 15:45:27 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Wed, 19 Nov 2008 16:45:26 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811191645.26701.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/lL7HFkv211nPMuGR8NIibLJ9M/RTSYowxu5U CZ1ENglA4I6T4BaVs0tnsdWPVIrSfaNxrzo5Z9g1fbqbZmyWOQ j+yVi4alQPcbGI4axnNZg== Cc: Randall Stewart Subject: Re: Thinking about UDP and tunneling 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, 19 Nov 2008 15:45:29 -0000 On Wednesday 19 November 2008 16:00:27 Randall Stewart wrote: > Dear All: > > I have been contemplating UDP and tunneling. One of the > things that is a nice feature in MacOS is the ability of > a kernel module/extension to open a kernel level socket > and have the mbuf chain that arrives for that port be passed > in via a function. > > We use this in our MacOS version of the SCTP stack to do the > UDP de-tunneling of SCTP packets. This is becoming a more and > more common thing i.e. having transport protocols like SCTP and DCCP > be tunneled over UDP to get by NAT's.... this actually sucks that > this is necessary .. but it is what it is.... > > So, I am contemplating adding a similar sort of feature... basically > provide an interface in UDP that a consumer (such as SCTP or DCCP) could > use to "bind" a port and get UDP packets directly. > > What do you all think of the idea? What is wrong with the existing socket(9) API? > That also reminds me.. who owns the ipfw code.. we actually > have SCTP nat support that Jason But has done that we need to > get in... > > I would be more than glad to shepherd this in if the owner > of the code does not have the time... "Depends ..." ... for ipfw2 core you might be looking for luigi@, for the libalias stuff: piso@ did the kernel inclusion more or less recently ... other than that: svn log -qr HEAD:\{2006-01-01\} | grep ^r | cut -d"|" -f2 | sort | \ uniq -c | sort in sys/netinet/libalias gives a list of people who touched that code recently (for some definition of recently). I'd be happy to take a look, too ... though I might need some time for a proper review. In general, you touch it you bought it! -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 15:50:23 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B4021065670 for ; Wed, 19 Nov 2008 15:50:23 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA6E8FC0C for ; Wed, 19 Nov 2008 15:50:23 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 1BA8F7309E; Wed, 19 Nov 2008 16:35:32 +0100 (CET) Date: Wed, 19 Nov 2008 16:35:32 +0100 From: Luigi Rizzo To: Randall Stewart Message-ID: <20081119153532.GB2910@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net Subject: Re: Thinking about UDP and tunneling 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, 19 Nov 2008 15:50:23 -0000 On Wed, Nov 19, 2008 at 10:00:27AM -0500, Randall Stewart wrote: > Dear All: > > I have been contemplating UDP and tunneling. One of the > things that is a nice feature in MacOS is the ability of > a kernel module/extension to open a kernel level socket > and have the mbuf chain that arrives for that port be passed > in via a function. > > We use this in our MacOS version of the SCTP stack to do the > UDP de-tunneling of SCTP packets. This is becoming a more and > more common thing i.e. having transport protocols like SCTP and DCCP > be tunneled over UDP to get by NAT's.... this actually sucks that > this is necessary .. but it is what it is.... > > So, I am contemplating adding a similar sort of feature... basically > provide an interface in UDP that a consumer (such as SCTP or DCCP) could > use to "bind" a port and get UDP packets directly. > > What do you all think of the idea? the way (not the only one, but one way) this kind of things can be done now is have ipfw select the traffic, and pass it to one in-kernel natd instance, and after the work that Paolo Pisati did for SoC 2005 (it think) the mechanism is extensible in a relatively easy way to provide specific functions to do the mmbuf manipulation. > That also reminds me.. who owns the ipfw code.. we actually > have SCTP nat support that Jason But has done that we need to > get in... > > I would be more than glad to shepherd this in if the owner > of the code does not have the time... there isn't really a owner, over time different people including myself have worked on various aspects of the code -- if your changes affect only natd extensions then Paolo Pisati (piso@) is probably a good starting contact. You may want to have a look at the recent and not-so-recent commit history to see who did other relevant pieces of work such as dealing with locking, improving performance in SMP and so on. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 18:08:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1831D106567B for ; Wed, 19 Nov 2008 18:08:16 +0000 (UTC) (envelope-from prvs=julian=2029692e7@ironport.com) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id DC57D8FC08 for ; Wed, 19 Nov 2008 18:08:15 +0000 (UTC) (envelope-from prvs=julian=2029692e7@ironport.com) DomainKey-Signature: s=key512; d=ironport.com; c=nofws; q=dns; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To: CC:Subject:References:In-Reply-To:Content-Type; b=Ko5uGsO6UmwJ5fCXVszP5wTB1m21HRkDkUamTXAKdi+lh3d1sbeM6U2U CfpuClIx8Q1OBj755rs0ZwKh48KPDA==; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ironport.com; i=julian@ironport.com; q=dns/txt; s=ironport-dkim; t=1227118096; x=1258654096; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Julian=20Elischer=20 |Subject:=20Re:=20tokenring=20users?|Date:=20Wed,=2019=20 Nov=202008=2010:08:13=20-0800|Message-ID:=20<4924560D.800 0101@ironport.com>|To:=20"Bjoern=20A.=20Zeeb"=20|CC:=20FreeBSD=20Net=20|MIME-Version:=201.0|In-Reply-To:=20<200811 19102301.R61259@maildrop.int.zabbadoz.net>|References:=20 <49233959.9040903@ironport.com>=20<4923D7C0.7050301@freeb sd.org>=20<4923DB2D.2080702@ironport.com>=20<200811191023 01.R61259@maildrop.int.zabbadoz.net>; bh=KCXuKvY0VVG3IMVKLPE9amai/mbkYspRpwi4Tj0b04w=; b=I5QcSoJXRursV5m6lNoyeiOJU/yN5bq1Vz4hRng7jHs/sSfD4dy1JWIa XM4voXBYpdDihZNsT57rOiW7Dl2RSA==; Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.177]) by smtp-outbound.ironport.com with ESMTP; 19 Nov 2008 10:08:14 -0800 Message-ID: <4924560D.8000101@ironport.com> Date: Wed, 19 Nov 2008 10:08:13 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> <4923DB2D.2080702@ironport.com> <20081119102301.R61259@maildrop.int.zabbadoz.net> In-Reply-To: <20081119102301.R61259@maildrop.int.zabbadoz.net> Content-Type: multipart/mixed; boundary="------------000507090404070107050204" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net Subject: Re: tokenring users? 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, 19 Nov 2008 18:08:16 -0000 This is a multi-part message in MIME format. --------------000507090404070107050204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bjoern A. Zeeb wrote: > On Wed, 19 Nov 2008, Julian Elischer wrote: > > Hi, > >> Andre Oppermann wrote: >>> Julian Elischer wrote: >>>> One of the things that are making things hard for network testing >>>> is the question >>>> "what to do about tokenring support?" >>>> >>>> We seem to have a dearth of tokenring users so we are completely >>>> unable >>>> test how changes affect tokenring. >>>> >>>> If anyone here knows anyone whoul could: >>>> 1/ help support tokenring >>>> 2/ help test tokenring, >>>> >>>> could they get in touch? >>> >>> I guess Token Ring is as dead as it gets. The last I time ran across >>> someone using it was in 1996 or 1997. I asked our engineers here (on >>> a customer base of about 1k SME) and got only blank stares. >>> >> >> yes I think that may be the case but I saw a bug report >> about it a few years ago.. > > I have given away all my TR equipment a few years back, but I know people > still running TR though with Cisco and non-FreeBSD-OSes though they > got rid > of all TR they could get rid off. > > So what exactly is your question in supporting and testing FreeBSD TR > support? > > And let me ask why you are asking for TR, not FDDI or some of the > other things lingering in sys/net**? > > /bz > There are some vestiges of tokenring support in the system but since htey can't really be tested, people have been making "guessing" changes to them as things go forward. We don't know if they really work. If there are no tokenring users we might as well remove the clutter. I don't really know about FDDI support.. do we have it? --------------000507090404070107050204-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 18:09:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42F8E1065673; Wed, 19 Nov 2008 18:09:52 +0000 (UTC) (envelope-from prvs=julian=2029692e7@ironport.com) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 0E7748FC1C; Wed, 19 Nov 2008 18:09:51 +0000 (UTC) (envelope-from prvs=julian=2029692e7@ironport.com) DomainKey-Signature: s=key512; d=ironport.com; c=nofws; q=dns; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To: CC:Subject:References:In-Reply-To:Content-Type; b=SefGTMgfwTbonkN/npHPCjOt6X0EoaG971KqFOi6THDqhzBBzgo97xjb NvV0qgIMrcZumVmAAugk9/yvjEcqPA==; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ironport.com; i=julian@ironport.com; q=dns/txt; s=ironport-dkim; t=1227118192; x=1258654192; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Julian=20Elischer=20 |Subject:=20Re:=20tokenring=20users?|Date:=20Wed,=2019=20 Nov=202008=2010:09:50=20-0800|Message-ID:=20<4924566E.506 0403@ironport.com>|To:=20Christian=20Brueffer=20|CC:=20Andre=20Oppermann=20,=20=0D=0A=20FreeBSD=20Net=20 |MIME-Version:=201.0|In-Reply-To:=20<20081119103602.GA233 9@haakonia.hitnet.RWTH-Aachen.DE>|References:=20<49233959 .9040903@ironport.com>=20<4923D7C0.7050301@freebsd.org> =20<4923DB2D.2080702@ironport.com>=20<20081119103602.GA23 39@haakonia.hitnet.RWTH-Aachen.DE>; bh=fTnHMlF+JuVoFgwjkFhOEiNATdEuZiFKSAfW3+L9tFY=; b=IrO2RBJYQe8qA+XULg44O95ZBikgLlyITiQPq+mh0LxWGHCF2IHHYNZX cpeZj7I2MzF+l+C8VW+8qpDFGVQmkA==; Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.177]) by smtp-outbound.ironport.com with ESMTP; 19 Nov 2008 10:09:51 -0800 Message-ID: <4924566E.5060403@ironport.com> Date: Wed, 19 Nov 2008 10:09:50 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Brueffer References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> <4923DB2D.2080702@ironport.com> <20081119103602.GA2339@haakonia.hitnet.RWTH-Aachen.DE> In-Reply-To: <20081119103602.GA2339@haakonia.hitnet.RWTH-Aachen.DE> Content-Type: multipart/mixed; boundary="------------060609050101090003090804" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , Andre Oppermann Subject: Re: tokenring users? 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, 19 Nov 2008 18:09:52 -0000 This is a multi-part message in MIME format. --------------060609050101090003090804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Christian Brueffer wrote: > On Wed, Nov 19, 2008 at 01:23:57AM -0800, Julian Elischer wrote: > >> Andre Oppermann wrote: >> >>> Julian Elischer wrote: >>> >>>> One of the things that are making things hard for network testing is >>>> the question >>>> "what to do about tokenring support?" >>>> >>>> We seem to have a dearth of tokenring users so we are completely unable >>>> test how changes affect tokenring. >>>> >>>> If anyone here knows anyone whoul could: >>>> 1/ help support tokenring >>>> 2/ help test tokenring, >>>> >>>> could they get in touch? >>>> >>> I guess Token Ring is as dead as it gets. The last I time ran across >>> someone using it was in 1996 or 1997. I asked our engineers here (on >>> a customer base of about 1k SME) and got only blank stares. >>> >>> >> yes I think that may be the case but I saw a bug report >> about it a few years ago.. >> >> > > The last (afaik) in-tree token-ring driver we had was oltr(4) which has > been removed from HEAD not too long ago. So the questions is whether > there are companies with custom drivers. > exactly.. but there could be people using (or planning to use it) in on 7.x. > - Christian > > --------------060609050101090003090804-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 19:13:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE4571065674 for ; Wed, 19 Nov 2008 19:13:55 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 3F69A8FC1E for ; Wed, 19 Nov 2008 19:13:55 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-067-236-069.pools.arcor-ip.net [88.67.236.69]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1L2sUs0KPq-0003U6; Wed, 19 Nov 2008 20:13:54 +0100 Received: (qmail 82712 invoked from network); 19 Nov 2008 19:13:53 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by laiers.local with SMTP; 19 Nov 2008 19:13:53 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Wed, 19 Nov 2008 20:13:52 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> In-Reply-To: <4923D7C0.7050301@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200811192013.53405.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18peJRdiyf5gGEB3B5wIVeXbxaBzcpMegBkc38 Nc6LUQoaLAtlS50VyTRnYnuwM1I8QKw3Z7OiQtJ2+xcTaYHcLg w0JuUnd5eAAcY4lgbVhpA== Cc: Julian Elischer , Andre Oppermann Subject: Re: tokenring users? 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, 19 Nov 2008 19:13:55 -0000 On Wednesday 19 November 2008 10:09:20 Andre Oppermann wrote: > Julian Elischer wrote: > > One of the things that are making things hard for network testing is the > > question > > "what to do about tokenring support?" > > > > We seem to have a dearth of tokenring users so we are completely unable > > test how changes affect tokenring. > > > > If anyone here knows anyone whoul could: > > 1/ help support tokenring > > 2/ help test tokenring, > > > > could they get in touch? > > I guess Token Ring is as dead as it gets. The last I time ran across > someone using it was in 1996 or 1997. I asked our engineers here (on > a customer base of about 1k SME) and got only blank stares. =46rom the experience of replacing ~200 IBM token-ring terminals with ether= net=20 PCs & terminal emulators in a hospital back in 2001 ... yeah, it's dead. B= ack=20 then the rational was that it was already cheaper to buy a PC, ethernet car= d=20 and do the wiring than it was to get a replacement for a broken token ring= =20 card - let alone the hub that decided to die in the midst of the end-of-yea= r=20 tax report season. While TR was nice back in the days of 10Mbit ethernet hub days, there is no= =20 longer a market for it, except for the aforementioned IBM terminal - where= =20 =46reeBSD really doesn't play. =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 From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 19:14:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B26E11065677 for ; Wed, 19 Nov 2008 19:14:45 +0000 (UTC) (envelope-from prvs=julian=202b42db1@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id A04038FC27 for ; Wed, 19 Nov 2008 19:14:45 +0000 (UTC) (envelope-from prvs=julian=202b42db1@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.177]) by smtp-outbound.ironport.com with ESMTP; 19 Nov 2008 10:45:57 -0800 Message-ID: <49245EE3.2000700@elischer.org> Date: Wed, 19 Nov 2008 10:45:55 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Randall Stewart References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: Thinking about UDP and tunneling 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, 19 Nov 2008 19:14:45 -0000 Randall Stewart wrote: > Dear All: > > I have been contemplating UDP and tunneling. One of the > things that is a nice feature in MacOS is the ability of > a kernel module/extension to open a kernel level socket > and have the mbuf chain that arrives for that port be passed > in via a function. define "kernel level" and "mbuf chain that arrives [...] passed in via a function" > > We use this in our MacOS version of the SCTP stack to do the > UDP de-tunneling of SCTP packets. This is becoming a more and > more common thing i.e. having transport protocols like SCTP and DCCP > be tunneled over UDP to get by NAT's.... this actually sucks that > this is necessary .. but it is what it is.... I do that using netgraph.. set a point ot point ng_iface and hook the other end to a netgraph ksocket which is bound/connaected where you want. "just works" > > So, I am contemplating adding a similar sort of feature... basically > provide an interface in UDP that a consumer (such as SCTP or DCCP) could > use to "bind" a port and get UDP packets directly. > > What do you all think of the idea? Well netgraph allows you to do it already > > > That also reminds me.. who owns the ipfw code.. we actually > have SCTP nat support that Jason But has done that we need to > get in... > > I would be more than glad to shepherd this in if the owner > of the code does not have the time... > > > R > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > 803-345-0391(direct) > > _______________________________________________ > 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 Wed Nov 19 19:42:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AE1B106564A; Wed, 19 Nov 2008 19:42:12 +0000 (UTC) (envelope-from prvs=julian=2029692e7@ironport.com) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 6A1668FC0C; Wed, 19 Nov 2008 19:42:12 +0000 (UTC) (envelope-from prvs=julian=2029692e7@ironport.com) DomainKey-Signature: s=key512; d=ironport.com; c=nofws; q=dns; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To: CC:Subject:References:In-Reply-To:Content-Type; b=gG0ivRDrlip6YW5tjsqHwPk8AMxjY3eyaeJZ+j3nl4lCSpZkfSknOCH+ pB4b8EQgSWNe6VuC+mTIsasQSRSkfg==; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ironport.com; i=julian@ironport.com; q=dns/txt; s=ironport-dkim; t=1227123733; x=1258659733; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Julian=20Elischer=20 |Subject:=20Re:=20tokenring=20users?|Date:=20Wed,=2019=20 Nov=202008=2011:42:10=20-0800|Message-ID:=20<49246C12.808 0201@ironport.com>|To:=20Mike=20Holling=20|CC:=20Andre=20Oppermann=20,=20=0D =0A=20FreeBSD=20Net=20 |MIME-Version:=201.0|In-Reply-To:=20<20081119123600.E3075 5@claw.omgcats.com>|References:=20<49233959.9040903@ironp ort.com>=20<4923D7C0.7050301@freebsd.org>=20<4923DB2D.208 0702@ironport.com>=20<20081119123600.E30755@claw.omgcats. com>; bh=W0ma9pORnQzYn2Ln3rkkplHCeRnsBhDEa7pedooEx+A=; b=kX6Sfu4KLDUXrQFPBkXcC1bI3VvATiGkirKhSfms+mzy+GZx7VEnAW/Y qYBjtG/cvqxcAmkhtuRF0XDHH9rcNQ==; Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.75]) by smtp-outbound.ironport.com with ESMTP; 19 Nov 2008 11:42:12 -0800 Message-ID: <49246C12.8080201@ironport.com> Date: Wed, 19 Nov 2008 11:42:10 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Mike Holling References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> <4923DB2D.2080702@ironport.com> <20081119123600.E30755@claw.omgcats.com> In-Reply-To: <20081119123600.E30755@claw.omgcats.com> Content-Type: multipart/mixed; boundary="------------050609010909030804010109" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , Andre Oppermann Subject: Re: tokenring users? 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, 19 Nov 2008 19:42:12 -0000 This is a multi-part message in MIME format. --------------050609010909030804010109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike Holling wrote: >> yes I think that may be the case but I saw a bug report >> about it a few years ago.. >> > > in 2004? i was using tokenring for a project and had problems with some > cards that should have been supported (triple port card with a supported > chipset). don't need it any more though. > > - Mike > > (yay) (makes official requisition for Danish axe.) my only worry is FDDI support... 1/ do we have any 2/ if so, does it use any of the tokenring support? I don;t really know much about FDDI. Wouldn't want to remove anything still in use by something else. --------------050609010909030804010109-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 20:01:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADC33106564A for ; Wed, 19 Nov 2008 20:01:11 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 30AF28FC1C for ; Wed, 19 Nov 2008 20:01:11 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so77319ugs.39 for ; Wed, 19 Nov 2008 12:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=3hWv5l3mzSeYrRpdt2iLIuLxd4S4ICUe6ThMUSr7Uv8=; b=eYDJSjeNmAb+PeynfU2DXnEuSR9sBnChZuX44lKVw0obUFUjLs/XZqi7acz71yzKa2 xuifV2itqtQBFK5wnQggh5rE8Sp+AkHz5YbiSUOMwhwZVShylYCrncWO2XiwVkRINmBm KfOL2lmy1BRPLuYE3J1G9nPqJOyV4nY90df7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=Sq7ol0yfOq8TGmmM/Fzn4+a1SZfUDLXGQ+cYvqF03KDcT5sfkFf9634gGdS83Ya2rH IkREck/0FyuWl4Xysu1p/2+EBSSoSAL3JoMBABqtqjhYkmjH/ptFZCW3zUfbFZISFboo xJrve9hyBVfEN2IjAi3pH/P38hsBKGv64XZVs= Received: by 10.67.119.8 with SMTP id w8mr3256066ugm.3.1227124870169; Wed, 19 Nov 2008 12:01:10 -0800 (PST) Received: from epsilon.lan (bl6-157-129.dsl.telepac.pt [82.155.157.129]) by mx.google.com with ESMTPS id 31sm31848ugg.34.2008.11.19.12.01.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Nov 2008 12:01:09 -0800 (PST) Message-Id: <403932D0-8B62-4C95-8076-A185AC1C69E7@freebsd.org> From: Rui Paulo To: Andre Oppermann In-Reply-To: <4921F2CD.503@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 20:01:06 +0000 References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> <4921B3C6.5020002@freebsd.org> <4921F2CD.503@freebsd.org> X-Mailer: Apple Mail (2.929.2) Sender: Rui Paulo Cc: freebsd-net@freebsd.org, Hartmut Brandt , bz@freebsd.org Subject: Re: TCP and syncache question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 20:01:11 -0000 On 17 Nov 2008, at 22:40, Andre Oppermann wrote: > This is a bit more complicated because of interactions with > tcp_input() > where syncache_expand() is called from. > > The old code (as of December 2002) behaved slightly different. It > would > not remove the syncache entry when (SND.UNA == SEG.ACK) but send a > RST. > The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't > done at > all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) > succeeded. > This gave way to the "LAND" DoS attack which was mostly fixed with a > test > for (RCV.IRS < SEG.SEQ). > > See the attached patch for fixed version of syncache_expand(). This > patch > is untested though. My development machine is currently down. > Harti, Rui > and Bjoern, please have a look at the patch and review it. > > -- > Andre > > --- tcp_input.c.1.390 Mon Nov 17 21:33:25 2008 > +++ tcp_input.c.1.390.mod Mon Nov 17 21:35:22 2008 > @@ -642,10 +642,13 @@ findpcb: > if (!syncache_expand(&inc, &to, th, &so, m)) { > /* > * No syncache entry or ACK was not > - * for our SYN/ACK. Send a RST. > + * for our SYN/ACK. Send a RST or > + * an ACK for re-synchronization. > * NB: syncache did its own logging > * of the failure cause. > */ > + if (so == 1) > + goto dropunlock; > rstreason = BANDLIM_RST_OPENPORT; > goto dropwithreset; > } > --- tcp_syncache.c.1.160 Mon Nov 17 16:49:01 2008 > +++ tcp_syncache.c.1.160.mod Mon Nov 17 23:35:39 2008 > @@ -817,59 +817,47 @@ syncache_expand(struct in_conninfo *inc, > INP_INFO_WLOCK_ASSERT(&V_tcbinfo); > KASSERT((th->th_flags & (TH_RST|TH_ACK|TH_SYN)) == TH_ACK, > ("%s: can handle only ACK", __func__)); > + *lsop = NULL; > > sc = syncache_lookup(inc, &sch); /* returns locked sch */ > SCH_LOCK_ASSERT(sch); > if (sc == NULL) { > /* > * There is no syncache entry, so see if this ACK is > - * a returning syncookie. To do this, first: > - * A. See if this socket has had a syncache entry dropped in > - * the past. We don't want to accept a bogus syncookie > - * if we've never received a SYN. > - * B. check that the syncookie is valid. If it is, then > - * cobble up a fake syncache entry, and return. > + * a returning syncookie. If the syncookie is valid, > + * cobble up a fake syncache entry and create a socket. > + * > + * NB: Syncache head is locked for the syncookie access. > */ > if (!tcp_syncookies) { > - SCH_UNLOCK(sch); > if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > log(LOG_DEBUG, "%s; %s: Spurious ACK, " > "segment rejected (syncookies disabled)\n", > s, __func__); > - goto failed; > + goto sendrst; > } > bzero(&scs, sizeof(scs)); > sc = syncookie_lookup(inc, sch, &scs, to, th, *lsop); > - SCH_UNLOCK(sch); > if (sc == NULL) { > if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > log(LOG_DEBUG, "%s; %s: Segment failed " > "SYNCOOKIE authentication, segment rejected " > "(probably spoofed)\n", s, __func__); > - goto failed; > + goto sendrst; > } > - } else { > - /* Pull out the entry to unlock the bucket row. */ > - TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); > - sch->sch_length--; > - V_tcp_syncache.cache_count--; > - SCH_UNLOCK(sch); > + goto expand; /* fully validated through syncookie */ > } > + SCH_LOCK_ASSERT(sch); Why do you need this assert? > > > /* > * Segment validation: > - * ACK must match our initial sequence number + 1 (the SYN|ACK). > - */ > - if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { > - if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > - log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " > - "rejected\n", s, __func__, th->th_ack, sc->sc_iss); > - goto failed; > - } > - > - /* > + * > * The SEQ must fall in the window starting at the received > * initial receive sequence number + 1 (the SYN). > + * If not the segment may be from an earlier connection. We send > + * an ACK to re-synchronize the connection and keep the syncache > + * entry without ajusting its timers. > + * See RFC793 page 69, first check sequence number [SYN_RECEIVED]. > */ > if ((SEQ_LEQ(th->th_seq, sc->sc_irs) || > SEQ_GT(th->th_seq, sc->sc_irs + sc->sc_wnd)) && > @@ -877,14 +865,41 @@ syncache_expand(struct in_conninfo *inc, > if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > log(LOG_DEBUG, "%s; %s: SEQ %u != IRS+1 %u, segment " > "rejected\n", s, __func__, th->th_seq, sc->sc_irs); > - goto failed; > + (void) syncache_respond(sc); > + *lsop = 1; /* prevent RST */ > + goto sendrstkeep; > } > > + /* > + * ACK must match our initial sequence number + 1 (the SYN|ACK). > + * If not the segment may be from an earlier connection. We send > + * a RST but keep the syncache entry without ajusting its timers. > + * See RFC793 page 72, fifth check the ACK field, [SYN_RECEIVED]. > + */ > + if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { > + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > + log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " > + "rejected\n", s, __func__, th->th_ack, sc->sc_iss); > + goto sendrstkeep; > + } > + > + /* > + * Remove the entry to unlock the bucket row. > + * Tests from now on are fatal and remove the syncache entry. > + */ > + TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); > + sch->sch_length--; > + V_tcp_syncache.cache_count--; > + > + /* > + * If timestamps were not negotiated they must not show up later. > + * See RFC1312bis, section 1.3, second paragraph > + */ > if (!(sc->sc_flags & SCF_TIMESTAMP) && (to->to_flags & TOF_TS)) { > if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > log(LOG_DEBUG, "%s; %s: Timestamp not expected, " > "segment rejected\n", s, __func__); > - goto failed; > + goto sendrst; > } > /* > * If timestamps were negotiated the reflected timestamp > @@ -896,9 +911,11 @@ syncache_expand(struct in_conninfo *inc, > log(LOG_DEBUG, "%s; %s: TSECR %u != TS %u, " > "segment rejected\n", > s, __func__, to->to_tsecr, sc->sc_ts); > - goto failed; > + goto sendrst; > } > > +expand: > + SCH_UNLOCK(sch); > *lsop = syncache_socket(sc, *lsop, m); > > if (*lsop == NULL) > @@ -906,16 +923,18 @@ syncache_expand(struct in_conninfo *inc, > else > V_tcpstat.tcps_sc_completed++; > > -/* how do we find the inp for the new socket? */ > if (sc != &scs) > syncache_free(sc); > return (1); > -failed: > - if (sc != NULL && sc != &scs) > + > +sendrst: > + if (sc != &scs) > syncache_free(sc); > +sendrstkeep: > + SCH_LOCK_ASSERT(sch); > + SCH_UNLOCK(sch); Why do we need an assert before an unlock? > > if (s != NULL) > free(s, M_TCPLOG); > - *lsop = NULL; > return (0); > } > This was probably out of scope: > @@ -1322,6 +1341,8 @@ syncache_respond(struct syncache *sc) > * > * 1) path_mtu_discovery is disabled > * 2) the SCF_UNREACH flag has been set > + * > + * XXXAO: The route lookup comment doesn't make sense. > */ > if (V_path_mtu_discovery && ((sc->sc_flags & SCF_UNREACH) == 0)) > ip->ip_off |= IP_DF; I won't be able to test this any time soon, so I can't really comment on the rest, but it *looks* okay. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 20:06:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B30BD106567A; Wed, 19 Nov 2008 20:06:00 +0000 (UTC) (envelope-from myke@omgcats.com) Received: from claw.omgcats.com (block-66.135.80.250.montanasat.net [66.135.80.250]) by mx1.freebsd.org (Postfix) with ESMTP id 220D68FC1E; Wed, 19 Nov 2008 20:06:00 +0000 (UTC) (envelope-from myke@omgcats.com) Received: from localhost (myke@localhost) by claw.omgcats.com (8.11.6/8.11.6) with ESMTP id mAJJafA95168; Wed, 19 Nov 2008 12:36:41 -0700 (MST) (envelope-from myke@omgcats.com) Date: Wed, 19 Nov 2008 12:36:41 -0700 (MST) From: Mike Holling To: Julian Elischer In-Reply-To: <4923DB2D.2080702@ironport.com> Message-ID: <20081119123600.E30755@claw.omgcats.com> References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> <4923DB2D.2080702@ironport.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD Net , Andre Oppermann Subject: Re: tokenring users? 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, 19 Nov 2008 20:06:00 -0000 > yes I think that may be the case but I saw a bug report > about it a few years ago.. in 2004? i was using tokenring for a project and had problems with some cards that should have been supported (triple port card with a supported chipset). don't need it any more though. - Mike From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 20:22:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1129D1065673 for ; Wed, 19 Nov 2008 20:22:40 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id A1C1C8FC1D for ; Wed, 19 Nov 2008 20:22:39 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [130.129.95.183] ([130.129.95.183]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mAJKMaFe020944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Nov 2008 15:22:38 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1227126158; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=OMVFk0+yFpQ5UlVWPEAioJ1PkybntntZ437KSywAI2C7sHNm2FQWE42 fsnCBEV/TEcIeXqjPSpB+4BSikRh+eA== Message-Id: <9E86085F-ECAC-4C2E-ABE4-10AFB28480B3@lakerest.net> From: Randall Stewart To: Max Laier In-Reply-To: <200811191645.26701.max@love2party.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 15:22:36 -0500 References: <200811191645.26701.max@love2party.net> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-net@freebsd.org Subject: Re: Thinking about UDP and tunneling 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, 19 Nov 2008 20:22:40 -0000 On Nov 19, 2008, at 10:45 AM, Max Laier wrote: > On Wednesday 19 November 2008 16:00:27 Randall Stewart wrote: >> Dear All: >> >> I have been contemplating UDP and tunneling. One of the >> things that is a nice feature in MacOS is the ability of >> a kernel module/extension to open a kernel level socket >> and have the mbuf chain that arrives for that port be passed >> in via a function. >> >> We use this in our MacOS version of the SCTP stack to do the >> UDP de-tunneling of SCTP packets. This is becoming a more and >> more common thing i.e. having transport protocols like SCTP and DCCP >> be tunneled over UDP to get by NAT's.... this actually sucks that >> this is necessary .. but it is what it is.... >> >> So, I am contemplating adding a similar sort of feature... basically >> provide an interface in UDP that a consumer (such as SCTP or DCCP) >> could >> use to "bind" a port and get UDP packets directly. >> >> What do you all think of the idea? > > What is wrong with the existing socket(9) API? The problem with this is many fold.. 1) This works nicely for NFS and other FS based things that it was designed for I think. 2) A transport DCCP/SCTP/Next-Tunneled-Transport would need to have a thread reading, and would then need to enable the options to get the to addresses as well.. then reconstruct an IP header. Rather ugly when all you want is the mbuf chain passed in to the transport so that it can m_adj out the udp header and then its got the full IP plus the transport.... same as if it has arrived on the wire. What a transport being tunneled really wants is an easy way to have normal ip_input call it.. but also have a way to get the mbuf chain, supply a minor routine that strips udp, and then call the same routine as ip_input... giving the same look/and/feel as if it had come in off the wire.. > > >> That also reminds me.. who owns the ipfw code.. we actually >> have SCTP nat support that Jason But has done that we need to >> get in... >> >> I would be more than glad to shepherd this in if the owner >> of the code does not have the time... > > "Depends ..." ... for ipfw2 core you might be looking for luigi@, > for the > libalias stuff: piso@ did the kernel inclusion more or less > recently ... other > than that: > > svn log -qr HEAD:\{2006-01-01\} | grep ^r | cut -d"|" -f2 | sort | \ > uniq -c | sort > > in sys/netinet/libalias gives a list of people who touched that code > recently > (for some definition of recently). > > I'd be happy to take a look, too ... though I might need some time > for a > proper review. > > In general, you touch it you bought it! I have not reviewed the code myself.. and I will download it shortly and do so.. I think this is a ipfw (not 2) thing.. but I will have to check... more eyes is a good thing though.. R > > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 20:24:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 403AF1065670 for ; Wed, 19 Nov 2008 20:24:09 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id 6FF998FC1B for ; Wed, 19 Nov 2008 20:24:08 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [130.129.95.183] ([130.129.95.183]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mAJKO3s8020952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Nov 2008 15:24:05 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1227126246; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=c0oDlap3q0saWEjUrdi1W7LQKmZBrkrkQ59ECMGnaJLs+EsRBkVAk5E kC1S6ryUryTYdNi2hI4osjaKsqJkAkQ== Message-Id: From: Randall Stewart To: Luigi Rizzo In-Reply-To: <20081119153532.GB2910@onelab2.iet.unipi.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 15:24:02 -0500 References: <20081119153532.GB2910@onelab2.iet.unipi.it> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-net Subject: Re: Thinking about UDP and tunneling 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, 19 Nov 2008 20:24:09 -0000 On Nov 19, 2008, at 10:35 AM, Luigi Rizzo wrote: > On Wed, Nov 19, 2008 at 10:00:27AM -0500, Randall Stewart wrote: >> Dear All: >> >> I have been contemplating UDP and tunneling. One of the >> things that is a nice feature in MacOS is the ability of >> a kernel module/extension to open a kernel level socket >> and have the mbuf chain that arrives for that port be passed >> in via a function. >> >> We use this in our MacOS version of the SCTP stack to do the >> UDP de-tunneling of SCTP packets. This is becoming a more and >> more common thing i.e. having transport protocols like SCTP and DCCP >> be tunneled over UDP to get by NAT's.... this actually sucks that >> this is necessary .. but it is what it is.... >> >> So, I am contemplating adding a similar sort of feature... basically >> provide an interface in UDP that a consumer (such as SCTP or DCCP) >> could >> use to "bind" a port and get UDP packets directly. >> >> What do you all think of the idea? > > the way (not the only one, but one way) this kind of things > can be done now is have ipfw select the traffic, and pass it > to one in-kernel natd instance, and after the work that Paolo Pisati > did for SoC 2005 (it think) the mechanism is extensible in > a relatively easy way to provide specific functions to do > the mmbuf manipulation. Interesting idea, but the destination of the packets MAY NOT be the same box the fw/nat is on. So this means I now have to enable ipfw/nat on all boxes that want to have tunneling.. Not exactly very friendly... > > >> That also reminds me.. who owns the ipfw code.. we actually >> have SCTP nat support that Jason But has done that we need to >> get in... >> >> I would be more than glad to shepherd this in if the owner >> of the code does not have the time... > > there isn't really a owner, over time different people including > myself have worked > on various aspects of the code -- if your changes affect only > natd extensions then Paolo Pisati (piso@) is probably a good > starting contact. You may want to have a look at the recent > and not-so-recent commit history to see who did other relevant > pieces of work such as dealing with locking, improving performance > in SMP and so on. I think it must be Paolo.. I will give him a ping R > > > cheers > luigi > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 20:30:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB9B5106567A for ; Wed, 19 Nov 2008 20:30:34 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id 68A328FC1D for ; Wed, 19 Nov 2008 20:30:34 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [130.129.95.183] ([130.129.95.183]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mAJKUUPH021030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Nov 2008 15:30:31 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1227126632; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=bvj6VjytAxLlRh80//zxvN8PdZ3j/15o++wXxjDzH8CGH2LNqLWTWI6 DXoJFu8v7fOjXGYlxLU/AFpDyVrwwQA== Message-Id: From: Randall Stewart To: Julian Elischer In-Reply-To: <49245EE3.2000700@elischer.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 15:30:29 -0500 References: <49245EE3.2000700@elischer.org> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-net Subject: Re: Thinking about UDP and tunneling 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, 19 Nov 2008 20:30:34 -0000 On Nov 19, 2008, at 1:45 PM, Julian Elischer wrote: > Randall Stewart wrote: >> Dear All: >> I have been contemplating UDP and tunneling. One of the >> things that is a nice feature in MacOS is the ability of >> a kernel module/extension to open a kernel level socket >> and have the mbuf chain that arrives for that port be passed >> in via a function. > > define "kernel level" and "mbuf chain that arrives [...] passed in > via a function" > > > >> We use this in our MacOS version of the SCTP stack to do the >> UDP de-tunneling of SCTP packets. This is becoming a more and >> more common thing i.e. having transport protocols like SCTP and DCCP >> be tunneled over UDP to get by NAT's.... this actually sucks that >> this is necessary .. but it is what it is.... > > I do that using netgraph.. > set a point ot point ng_iface and hook the other end to > a netgraph ksocket which is bound/connaected where you want. > > "just works" > >> So, I am contemplating adding a similar sort of feature... basically >> provide an interface in UDP that a consumer (such as SCTP or DCCP) >> could >> use to "bind" a port and get UDP packets directly. >> What do you all think of the idea? > > Well netgraph allows you to do it already Not sure what netgraph does... what is wanted is this in comes +-----+ | IP | +-----+ | UDP | +-----+ | Oth | | tra | | por | | t h | | ead | | er | | and | | dat | | a. | +-----+ Ideally it runs into UDP via ip_input() and comes down to where it would append() to the socket. What you want in this case is the whole mbuf chain to be sent to the transport_udp_input(m, offset) function This changes the above to +-----+ | IP | +-----+ | Oth | | tra | | por | | t h | | ead | | er | | and | | dat | | a. | +-----+ And sends it into the transport_input() (same one called by ip_input). This then makes a clean and easy way to have "tunneled UDP" transport protocols work in kernel. The input side looks the same. Output is pretty easy.. easy to drop a UDP header in out output... Netgraph would have to be watching every UDP packet always.. seems to me easier to bind a kernel level socket with some option to call an input function.... R > > >> That also reminds me.. who owns the ipfw code.. we actually >> have SCTP nat support that Jason But has done that we need to >> get in... >> I would be more than glad to shepherd this in if the owner >> of the code does not have the time... >> R >> ------------------------------ >> Randall Stewart >> 803-317-4952 (cell) >> 803-345-0391(direct) >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net- >> unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-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 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 20:50:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BF2110656F2 for ; Wed, 19 Nov 2008 20:50:14 +0000 (UTC) (envelope-from prvs=julian=202b42db1@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 219668FC17 for ; Wed, 19 Nov 2008 20:50:13 +0000 (UTC) (envelope-from prvs=julian=202b42db1@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.75]) by smtp-outbound.ironport.com with ESMTP; 19 Nov 2008 12:49:52 -0800 Message-ID: <49247BEE.4040201@elischer.org> Date: Wed, 19 Nov 2008 12:49:50 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Randall Stewart References: <49245EE3.2000700@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: Thinking about UDP and tunneling 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, 19 Nov 2008 20:50:14 -0000 Randall Stewart wrote: > > On Nov 19, 2008, at 1:45 PM, Julian Elischer wrote: > >> Randall Stewart wrote: >>> Dear All: >>> I have been contemplating UDP and tunneling. One of the >>> things that is a nice feature in MacOS is the ability of >>> a kernel module/extension to open a kernel level socket >>> and have the mbuf chain that arrives for that port be passed >>> in via a function. >> >> define "kernel level" and "mbuf chain that arrives [...] passed in via >> a function" >> >> >> >>> We use this in our MacOS version of the SCTP stack to do the >>> UDP de-tunneling of SCTP packets. This is becoming a more and >>> more common thing i.e. having transport protocols like SCTP and DCCP >>> be tunneled over UDP to get by NAT's.... this actually sucks that >>> this is necessary .. but it is what it is.... >> >> I do that using netgraph.. >> set a point ot point ng_iface and hook the other end to >> a netgraph ksocket which is bound/connaected where you want. >> >> "just works" >> >>> So, I am contemplating adding a similar sort of feature... basically >>> provide an interface in UDP that a consumer (such as SCTP or DCCP) could >>> use to "bind" a port and get UDP packets directly. >>> What do you all think of the idea? >> >> Well netgraph allows you to do it already > > > Not sure what netgraph does... what is wanted is this in comes > > > +-----+ > | IP | > +-----+ > | UDP | > +-----+ > | Oth | > | tra | > | por | > | t h | > | ead | > | er | > | and | > | dat | > | a. | > +-----+ Othtra port header and data.? > > > Ideally it runs into UDP via ip_input() > and comes down to where it would append() to the socket. At this point, netgraph grabs it and passes the mbufs wherever you tell it to pass them. > > What you want in this case is the whole mbuf chain to be sent > to the transport_udp_input(m, offset) function cd /sys root@trafmon1:grep transport_udp_input net*/* root@trafmon1:grep transport_udp_input net*/*/* > > This changes the above to > +-----+ > | IP | > +-----+ > | Oth | > | tra | > | por | > | t h | > | ead | > | er | > | and | > | dat | > | a. | > +-----+ where does the new IP header information come from? > > And sends it into the transport_input() (same one called by ip_input). > > This then makes a clean and easy way to have "tunneled UDP" transport > protocols > work in kernel. The input side looks the same. Output is pretty easy.. > easy to > drop a UDP header in out output... > > > Netgraph would have to be watching every UDP packet always.. just those that go to that ksocket. we hook on at the socketbuf point. > > seems to me easier to bind a kernel level socket with some option > to call an input function.... > > R > > > >> >> >>> That also reminds me.. who owns the ipfw code.. we actually >>> have SCTP nat support that Jason But has done that we need to >>> get in... >>> I would be more than glad to shepherd this in if the owner >>> of the code does not have the time... >>> R >>> ------------------------------ >>> Randall Stewart >>> 803-317-4952 (cell) >>> 803-345-0391(direct) >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-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 > 803-317-4952 (cell) > 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 21:30:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAD65106564A for ; Wed, 19 Nov 2008 21:30:31 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6158FC0C for ; Wed, 19 Nov 2008 21:30:31 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [130.129.95.183] ([130.129.95.183]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mAJLURpi021724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Nov 2008 16:30:28 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1227130229; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=jDZKu3GytrAoWkm2yyJ+z390VXe5CeBw6q92QHbjYFEkNRaScna/kWC Ha8qrjFcah4T6UL6vV9fu7SPvqoM68w== Message-Id: <905A5B58-54D2-4B79-A1B4-44C6D5136691@lakerest.net> From: Randall Stewart To: Julian Elischer In-Reply-To: <49247BEE.4040201@elischer.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 16:30:27 -0500 References: <49245EE3.2000700@elischer.org> <49247BEE.4040201@elischer.org> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-net Subject: Re: Thinking about UDP and tunneling 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, 19 Nov 2008 21:30:31 -0000 On Nov 19, 2008, at 3:49 PM, Julian Elischer wrote: > Randall Stewart wrote: >> On Nov 19, 2008, at 1:45 PM, Julian Elischer wrote: >>> Randall Stewart wrote: >>>> Dear All: >>>> I have been contemplating UDP and tunneling. One of the >>>> things that is a nice feature in MacOS is the ability of >>>> a kernel module/extension to open a kernel level socket >>>> and have the mbuf chain that arrives for that port be passed >>>> in via a function. >>> >>> define "kernel level" and "mbuf chain that arrives [...] passed in >>> via a function" >>> >>> >>> >>>> We use this in our MacOS version of the SCTP stack to do the >>>> UDP de-tunneling of SCTP packets. This is becoming a more and >>>> more common thing i.e. having transport protocols like SCTP and >>>> DCCP >>>> be tunneled over UDP to get by NAT's.... this actually sucks that >>>> this is necessary .. but it is what it is.... >>> >>> I do that using netgraph.. >>> set a point ot point ng_iface and hook the other end to >>> a netgraph ksocket which is bound/connaected where you want. >>> >>> "just works" >>> >>>> So, I am contemplating adding a similar sort of feature... >>>> basically >>>> provide an interface in UDP that a consumer (such as SCTP or >>>> DCCP) could >>>> use to "bind" a port and get UDP packets directly. >>>> What do you all think of the idea? >>> >>> Well netgraph allows you to do it already >> Not sure what netgraph does... what is wanted is this in comes >> +-----+ >> | IP | >> +-----+ >> | UDP | >> +-----+ >> | Oth | >> | tra | >> | por | >> | t h | >> | ead | >> | er | >> | and | >> | dat | >> | a. | >> +-----+ > > > Othtra port header and data.? Of course... full transport layer header.. for sctp its port port vtag checksum first-chunk header etc.. > > > >> Ideally it runs into UDP via ip_input() >> and comes down to where it would append() to the socket. > > At this point, netgraph grabs it and passes the mbufs wherever you > tell it to pass them. Sounds interesting... two questions: 1) And how do we configure netgraph to do this? (pointers to doco's is fine) 2) Is netgraph in the GENERIC... I would like to see this work out of the box.. > > >> What you want in this case is the whole mbuf chain to be sent >> to the transport_udp_input(m, offset) function > > cd /sys > root@trafmon1:grep transport_udp_input net*/* > root@trafmon1:grep transport_udp_input net*/*/* > > > >> This changes the above to >> +-----+ >> | IP | >> +-----+ >> | Oth | >> | tra | >> | por | >> | t h | >> | ead | >> | er | >> | and | >> | dat | >> | a. | >> +-----+ > > > where does the new IP header information come from? Its not new, its the same ip header.. Its just you go into the mbuf chain and take out the udp header... > > >> And sends it into the transport_input() (same one called by >> ip_input). >> This then makes a clean and easy way to have "tunneled UDP" >> transport protocols >> work in kernel. The input side looks the same. Output is pretty >> easy.. easy to >> drop a UDP header in out output... >> Netgraph would have to be watching every UDP packet always.. > > just those that go to that ksocket. we hook on at the socketbuf > point. Hmm sounds plausible.. R > > >> seems to me easier to bind a kernel level socket with some option >> to call an input function.... >> R >>> >>> >>>> That also reminds me.. who owns the ipfw code.. we actually >>>> have SCTP nat support that Jason But has done that we need to >>>> get in... >>>> I would be more than glad to shepherd this in if the owner >>>> of the code does not have the time... >>>> R >>>> ------------------------------ >>>> Randall Stewart >>>> 803-317-4952 (cell) >>>> 803-345-0391(direct) >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org >>>> " >>> >>> _______________________________________________ >>> freebsd-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 >> 803-317-4952 (cell) >> 803-345-0391(direct) > > _______________________________________________ > 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 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 21:33:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C42711065677 for ; Wed, 19 Nov 2008 21:33:18 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id 715CC8FC13 for ; Wed, 19 Nov 2008 21:33:18 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [130.129.95.183] ([130.129.95.183]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mAJLXEGx021760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Nov 2008 16:33:15 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1227130396; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=M2VBkn/ZRoORT3s51mEtfY05bEnjsnDGIof+z8WGg6uF0Rpcc4uh/Fo vpbsZUWVYtSGPUD5Qq38bOw2ZFqB5hQ== Message-Id: <0252A647-464E-46A7-94E9-A0639083B5AE@lakerest.net> From: Randall Stewart To: Maksim Yevmenkin In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 16:33:14 -0500 References: <49245EE3.2000700@elischer.org> <49247BEE.4040201@elischer.org> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-net , Julian Elischer Subject: Re: Thinking about UDP and tunneling 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, 19 Nov 2008 21:33:18 -0000 On Nov 19, 2008, at 4:20 PM, Maksim Yevmenkin wrote: > On 11/19/08, Julian Elischer wrote: >> Randall Stewart wrote: >> >>> >>> On Nov 19, 2008, at 1:45 PM, Julian Elischer wrote: >>> >>> >>>> Randall Stewart wrote: >>>> >>>>> Dear All: >>>>> I have been contemplating UDP and tunneling. One of the >>>>> things that is a nice feature in MacOS is the ability of >>>>> a kernel module/extension to open a kernel level socket >>>>> and have the mbuf chain that arrives for that port be passed >>>>> in via a function. >>>>> >>>> >>>> define "kernel level" and "mbuf chain that arrives [...] passed >>>> in via a >> function" >>>> >>>> >>>> >>>> >>>>> We use this in our MacOS version of the SCTP stack to do the >>>>> UDP de-tunneling of SCTP packets. This is becoming a more and >>>>> more common thing i.e. having transport protocols like SCTP and >>>>> DCCP >>>>> be tunneled over UDP to get by NAT's.... this actually sucks that >>>>> this is necessary .. but it is what it is.... >>>>> >>>> >>>> I do that using netgraph.. >>>> set a point ot point ng_iface and hook the other end to >>>> a netgraph ksocket which is bound/connaected where you want. >>>> >>>> "just works" >>>> >>>> >>>>> So, I am contemplating adding a similar sort of feature... >>>>> basically >>>>> provide an interface in UDP that a consumer (such as SCTP or DCCP) >> could >>>>> use to "bind" a port and get UDP packets directly. >>>>> What do you all think of the idea? >>>>> >>>> >>>> Well netgraph allows you to do it already >>>> >>> >>> >>> Not sure what netgraph does... what is wanted is this in comes >>> >>> >>> +-----+ >>> | IP | >>> +-----+ >>> | UDP | >>> +-----+ >>> | Oth | >>> | tra | >>> | por | >>> | t h | >>> | ead | >>> | er | >>> | and | >>> | dat | >>> | a. | >>> +-----+ >>> >> >> >> Othtra port header and data.? > > i think it means: "other transport port header and data", that is take > a complete sctp/etc. datagram and stuff in inside udp datagram as > payload. > >> >>> >>> >>> Ideally it runs into UDP via ip_input() >>> and comes down to where it would append() to the socket. >>> >> >> At this point, netgraph grabs it and passes the mbufs wherever you >> tell it >> to pass them. >> >> >>> >>> What you want in this case is the whole mbuf chain to be sent >>> to the transport_udp_input(m, offset) function >>> >> >> cd /sys >> root@trafmon1:grep transport_udp_input net*/* >> root@trafmon1:grep transport_udp_input net*/*/* >> >> >> >> >>> >>> This changes the above to >>> +-----+ >>> | IP | >>> +-----+ >>> | Oth | >>> | tra | >>> | por | >>> | t h | >>> | ead | >>> | er | >>> | and | >>> | dat | >>> | a. | >>> +-----+ >>> >> >> >> where does the new IP header information come from? >> >> >>> >>> And sends it into the transport_input() (same one called by >>> ip_input). >>> >>> This then makes a clean and easy way to have "tunneled UDP" >>> transport >> protocols >>> work in kernel. The input side looks the same. Output is pretty >>> easy.. >> easy to >>> drop a UDP header in out output... >>> >>> >>> Netgraph would have to be watching every UDP packet always.. >>> >> >> just those that go to that ksocket. we hook on at the socketbuf >> point. > > that's right. basically, use ng_ksocket(4). that would be your tunnel > (outer) endpoint which you would bind to udp protocol, given address > and port. now everything that remote tunnel (outer) endpoint will send > via udp (payload) will end up in ng_ksocket(4) node and will be sent > out to ksocket's hook. you can connect whatever you want to that > hook. either move payload back into userspace, or use another ng node, > or just inject the data directly into sctp/etc. input routine. reverse > path is the same. playload comes from the hook and gets sent out via > udp Ok, let me go read the ng_ man.. I would not use the reverse path.. the ability to send encap'd udp packets is already in sctp.. after all all you are doing is dropping an extra header on it.. SCTP (and other transports) will want to control the way the IP header looks.. at least if they are multi-homed... so I don't think one would want to do output via ng.. just getting the data in is all thats missing in FreeBSD.. As long as netgraph is in generic this may work.. R > > >>> >>> seems to me easier to bind a kernel level socket with some option >>> to call an input function.... >>> >>> R >>> >>> >>> >>> >>>> >>>> >>>> >>>>> That also reminds me.. who owns the ipfw code.. we actually >>>>> have SCTP nat support that Jason But has done that we need to >>>>> get in... >>>>> I would be more than glad to shepherd this in if the owner >>>>> of the code does not have the time... >>>>> R > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 21:40:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 679CA1065675 for ; Wed, 19 Nov 2008 21:40:39 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id 36A058FC1A for ; Wed, 19 Nov 2008 21:40:39 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so129775rvf.43 for ; Wed, 19 Nov 2008 13:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=7GrqorTzU98aItaVTVSKHcjePZHZkHs45iodo20aLTU=; b=IufsdnPO9zCi5yGxUFhNYRKVbPAM01Tg8IdtXUjy72Mf8HcMJCTJ68HlEamr8CPGU9 d1KRwtG8KiEbn7HzvCtSnZiF52j/n3RbGGPfROhHgypJzYZF/9NlL90nZmW5n4C5Qznu IZ19857ioLFA2wIvrisHcmxEKrsZagN7N9YHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=IqyLswr/Ppmn1kMVRNQGoYeJW2hn0aXa1b5r5Lo1/BOb0fd8yBfSKoCiH3911DuTx9 OP0XOK1QHwZuFcW09xZU9Ayo98QFAjaSN1HlQs/+5XkV9f+8JoPnsHiOJOrzTtNfZERQ SIOO9t7ZxB3ocTa4odOBjpY596xJEzI134NNM= Received: by 10.140.170.21 with SMTP id s21mr807037rve.205.1227129616403; Wed, 19 Nov 2008 13:20:16 -0800 (PST) Received: by 10.140.199.20 with HTTP; Wed, 19 Nov 2008 13:20:16 -0800 (PST) Message-ID: Date: Wed, 19 Nov 2008 13:20:16 -0800 From: "Maksim Yevmenkin" To: "Randall Stewart" , "Julian Elischer" In-Reply-To: <49247BEE.4040201@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49245EE3.2000700@elischer.org> <49247BEE.4040201@elischer.org> Cc: freebsd-net Subject: Re: Thinking about UDP and tunneling 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, 19 Nov 2008 21:40:39 -0000 On 11/19/08, Julian Elischer wrote: > Randall Stewart wrote: > > > > > On Nov 19, 2008, at 1:45 PM, Julian Elischer wrote: > > > > > > > Randall Stewart wrote: > > > > > > > Dear All: > > > > I have been contemplating UDP and tunneling. One of the > > > > things that is a nice feature in MacOS is the ability of > > > > a kernel module/extension to open a kernel level socket > > > > and have the mbuf chain that arrives for that port be passed > > > > in via a function. > > > > > > > > > > define "kernel level" and "mbuf chain that arrives [...] passed in via a > function" > > > > > > > > > > > > > > > > We use this in our MacOS version of the SCTP stack to do the > > > > UDP de-tunneling of SCTP packets. This is becoming a more and > > > > more common thing i.e. having transport protocols like SCTP and DCCP > > > > be tunneled over UDP to get by NAT's.... this actually sucks that > > > > this is necessary .. but it is what it is.... > > > > > > > > > > I do that using netgraph.. > > > set a point ot point ng_iface and hook the other end to > > > a netgraph ksocket which is bound/connaected where you want. > > > > > > "just works" > > > > > > > > > > So, I am contemplating adding a similar sort of feature... basically > > > > provide an interface in UDP that a consumer (such as SCTP or DCCP) > could > > > > use to "bind" a port and get UDP packets directly. > > > > What do you all think of the idea? > > > > > > > > > > Well netgraph allows you to do it already > > > > > > > > > Not sure what netgraph does... what is wanted is this in comes > > > > > > +-----+ > > | IP | > > +-----+ > > | UDP | > > +-----+ > > | Oth | > > | tra | > > | por | > > | t h | > > | ead | > > | er | > > | and | > > | dat | > > | a. | > > +-----+ > > > > > Othtra port header and data.? i think it means: "other transport port header and data", that is take a complete sctp/etc. datagram and stuff in inside udp datagram as payload. > > > > > > > Ideally it runs into UDP via ip_input() > > and comes down to where it would append() to the socket. > > > > At this point, netgraph grabs it and passes the mbufs wherever you tell it > to pass them. > > > > > > What you want in this case is the whole mbuf chain to be sent > > to the transport_udp_input(m, offset) function > > > > cd /sys > root@trafmon1:grep transport_udp_input net*/* > root@trafmon1:grep transport_udp_input net*/*/* > > > > > > > > This changes the above to > > +-----+ > > | IP | > > +-----+ > > | Oth | > > | tra | > > | por | > > | t h | > > | ead | > > | er | > > | and | > > | dat | > > | a. | > > +-----+ > > > > > where does the new IP header information come from? > > > > > > And sends it into the transport_input() (same one called by ip_input). > > > > This then makes a clean and easy way to have "tunneled UDP" transport > protocols > > work in kernel. The input side looks the same. Output is pretty easy.. > easy to > > drop a UDP header in out output... > > > > > > Netgraph would have to be watching every UDP packet always.. > > > > just those that go to that ksocket. we hook on at the socketbuf point. that's right. basically, use ng_ksocket(4). that would be your tunnel (outer) endpoint which you would bind to udp protocol, given address and port. now everything that remote tunnel (outer) endpoint will send via udp (payload) will end up in ng_ksocket(4) node and will be sent out to ksocket's hook. you can connect whatever you want to that hook. either move payload back into userspace, or use another ng node, or just inject the data directly into sctp/etc. input routine. reverse path is the same. playload comes from the hook and gets sent out via udp > > > > seems to me easier to bind a kernel level socket with some option > > to call an input function.... > > > > R > > > > > > > > > > > > > > > > > > > > > That also reminds me.. who owns the ipfw code.. we actually > > > > have SCTP nat support that Jason But has done that we need to > > > > get in... > > > > I would be more than glad to shepherd this in if the owner > > > > of the code does not have the time... > > > > R From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 21:50:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D1BB1065670 for ; Wed, 19 Nov 2008 21:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2CF108FC0A for ; Wed, 19 Nov 2008 21:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAJLo37L000511 for ; Wed, 19 Nov 2008 21:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAJLo30P000510; Wed, 19 Nov 2008 21:50:03 GMT (envelope-from gnats) Date: Wed, 19 Nov 2008 21:50:03 GMT Message-Id: <200811192150.mAJLo30P000510@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Marius Strobl Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marius Strobl List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 21:50:04 -0000 The following reply was made to PR kern/128833; it has been noted by GNATS. From: Marius Strobl To: =?unknown-8bit?Q?Aur=E9lien_M=E9r=E9?= Cc: bug-followup@FreeBSD.org Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Wed, 19 Nov 2008 22:42:31 +0100 On Wed, Nov 19, 2008 at 02:27:43AM +0100, Aurlien Mr wrote: > Concerning the problem described by davidch@ , my chip is reported as a B5 > revision (01050000), so it might not be the case here. > You're right, the M/B doesn't support PCI-X at all. As detailed on the > manual, the NB chipset (AMD762) provides support for 2x66 MHz 64-bit PCI > 2.2 masters, and the SB chipset (AMD768) provides a secondary PCI 2.2 > bridge 33MHz. > I tried the patch but it didn't solve the problem, whilst the BGE_FLAG_PCIX > was no longer in the flags, which seems much more correct anyway. At the > end of the initialization values are these, as planned : > > bge_flags = 0x0010180F (0x10100F | BGE_FLAG_64BIT) . > BGE_PCI_PCISTATE is unchanged > > Note I forgot to mention the BGE_FLAG_RXALIGN_BUG (100000) and BGE_FLAG_TBI > (1) last time, as I tested before reset of the chip where these flags are > set. Okay. Have you tried the workaround described by davidch@ anyway? If that also doesn't make a difference I'm unfortunately out of ideas regarding your corruption problmem. Marius From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 21:51:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A78511065679 for ; Wed, 19 Nov 2008 21:51:25 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 77D638FC18 for ; Wed, 19 Nov 2008 21:51:25 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so141256rvb.1 for ; Wed, 19 Nov 2008 13:51:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=BOFYqXV/QEphEpolRPkaiqqpkt5KAN+UcMJ/aq0pwJk=; b=qExo3mg120fDIjeklRdttYCkyfzKciRAHeLVAUXifJe7QC9byLVl2JEoFQ0Gl/Ptpi eotOQsvszmQwe/kvCMerlamd7TZfix2OGYraN0xTYS9r/t4nizGgtEwbMaKyAXkrZYoW Hb20Q+UK3VsxpVgCjBvi+BXF8k70+LQ8HkQGk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=SF8R4kp7UEqW1ip5Oki1PiZQCVJ9L/xz00siLjUfxJO7eNa7YJLR7P5g9EHZyP5MjO BGgIgPWOLfpyEMLWNz/MoWtIYkrs/p340TnXZ8WXjQDp/P2zCAyYfg/3TZOqLv9PrnzI H9BRimWDh4oJ/G7DpFAhvPS40oZWA4HD1wb+w= Received: by 10.141.5.17 with SMTP id h17mr826449rvi.165.1227131485244; Wed, 19 Nov 2008 13:51:25 -0800 (PST) Received: by 10.140.199.20 with HTTP; Wed, 19 Nov 2008 13:51:25 -0800 (PST) Message-ID: Date: Wed, 19 Nov 2008 13:51:25 -0800 From: "Maksim Yevmenkin" To: "Randall Stewart" In-Reply-To: <0252A647-464E-46A7-94E9-A0639083B5AE@lakerest.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49245EE3.2000700@elischer.org> <49247BEE.4040201@elischer.org> <0252A647-464E-46A7-94E9-A0639083B5AE@lakerest.net> Cc: freebsd-net , Julian Elischer Subject: Re: Thinking about UDP and tunneling 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, 19 Nov 2008 21:51:25 -0000 [...] > > > just those that go to that ksocket. we hook on at the socketbuf point. > > > > > > > that's right. basically, use ng_ksocket(4). that would be your tunnel > > (outer) endpoint which you would bind to udp protocol, given address > > and port. now everything that remote tunnel (outer) endpoint will send > > via udp (payload) will end up in ng_ksocket(4) node and will be sent > > out to ksocket's hook. you can connect whatever you want to that > > hook. either move payload back into userspace, or use another ng node, > > or just inject the data directly into sctp/etc. input routine. reverse > > path is the same. playload comes from the hook and gets sent out via > > udp > > > > > Ok, let me go read the ng_ man.. > > I would not use the reverse path.. the ability to send > encap'd udp packets is already in sctp.. after all all you > are doing is dropping an extra header on it.. SCTP (and other > transports) will want to control the way the IP header looks.. at > least if they are multi-homed... so I don't think one would > want to do output via ng.. just getting the data in is all > thats missing in FreeBSD.. in this case its even easier. if you do not need reverse path, then all you need to do is to write a very small ng_ node that would 1) connect to the ng_ksocket(4) node's hook; and 2) inject received data into sctp/etc. input path so, you graph would look like [ng_ksocket] <- inet/dgram/udp -> [ng_sctp_injector] you might need an injector node do decouple netgraph from the rest of the sctp/etc. stack. alternatively, you may wish to provide netgraph hooks into sctp/etc. stack. > As long as netgraph is in generic this may work.. it is generic to some degree. if inner protocol (i.e. sctp etc.) is not aware of netgraph, then you will need to write an injector node specific to each inner protocol (basically that knows how to inject data into the stack). since injector node is simple, you could teach it to deal with multiple inner transports. for example, you could have an injector node that have multiple input hooks, one for each supported inner transport, named "sctp", etc. the idea would be that everything received from "sctp" hook will be injected into sctp stack, etc. then you could have only one injector node that could deal with multiple ng_ksockets for different inner transports. thanks, max From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 22:33:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B1B41065672 for ; Wed, 19 Nov 2008 22:33:41 +0000 (UTC) (envelope-from prvs=julian=202b42db1@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 159BB8FC1E for ; Wed, 19 Nov 2008 22:33:41 +0000 (UTC) (envelope-from prvs=julian=202b42db1@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.94]) by smtp-outbound.ironport.com with ESMTP; 19 Nov 2008 14:33:41 -0800 Message-ID: <49249443.8050707@elischer.org> Date: Wed, 19 Nov 2008 14:33:39 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Randall Stewart References: <49245EE3.2000700@elischer.org> <49247BEE.4040201@elischer.org> <905A5B58-54D2-4B79-A1B4-44C6D5136691@lakerest.net> In-Reply-To: <905A5B58-54D2-4B79-A1B4-44C6D5136691@lakerest.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: Thinking about UDP and tunneling 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, 19 Nov 2008 22:33:41 -0000 Randall Stewart wrote: > > On Nov 19, 2008, at 3:49 PM, Julian Elischer wrote: > >> Randall Stewart wrote: >>> On Nov 19, 2008, at 1:45 PM, Julian Elischer wrote: >>>> Randall Stewart wrote: >>>>> Dear All: >>>>> I have been contemplating UDP and tunneling. One of the >>>>> things that is a nice feature in MacOS is the ability of >>>>> a kernel module/extension to open a kernel level socket >>>>> and have the mbuf chain that arrives for that port be passed >>>>> in via a function. >>>> >>>> define "kernel level" and "mbuf chain that arrives [...] passed in >>>> via a function" >>>> >>>> >>>> >>>>> We use this in our MacOS version of the SCTP stack to do the >>>>> UDP de-tunneling of SCTP packets. This is becoming a more and >>>>> more common thing i.e. having transport protocols like SCTP and DCCP >>>>> be tunneled over UDP to get by NAT's.... this actually sucks that >>>>> this is necessary .. but it is what it is.... >>>> >>>> I do that using netgraph.. >>>> set a point ot point ng_iface and hook the other end to >>>> a netgraph ksocket which is bound/connaected where you want. >>>> >>>> "just works" >>>> >>>>> So, I am contemplating adding a similar sort of feature... basically >>>>> provide an interface in UDP that a consumer (such as SCTP or DCCP) >>>>> could >>>>> use to "bind" a port and get UDP packets directly. >>>>> What do you all think of the idea? >>>> >>>> Well netgraph allows you to do it already >>> Not sure what netgraph does... what is wanted is this in comes >>> +-----+ >>> | IP | >>> +-----+ >>> | UDP | >>> +-----+ >>> | Oth | >>> | tra | >>> | por | >>> | t h | >>> | ead | >>> | er | >>> | and | >>> | dat | >>> | a. | >>> +-----+ >> >> >> Othtra port header and data.? > > Of course... full transport layer header.. for sctp > its > > port port > vtag > checksum > first-chunk header > > etc.. > > >> >> >> >>> Ideally it runs into UDP via ip_input() >>> and comes down to where it would append() to the socket. >> >> At this point, netgraph grabs it and passes the mbufs wherever you >> tell it to pass them. > > Sounds interesting... two questions: > > 1) And how do we configure netgraph to do this? (pointers to doco's is > fine) > 2) Is netgraph in the GENERIC... I would like to see this work out of > the box.. yes, well I don't know what is loaded by default. > >> >> >>> What you want in this case is the whole mbuf chain to be sent >>> to the transport_udp_input(m, offset) function >> >> cd /sys >> root@trafmon1:grep transport_udp_input net*/* >> root@trafmon1:grep transport_udp_input net*/*/* >> >> >> >>> This changes the above to >>> +-----+ >>> | IP | >>> +-----+ >>> | Oth | >>> | tra | >>> | por | >>> | t h | >>> | ead | >>> | er | >>> | and | >>> | dat | >>> | a. | >>> +-----+ >> >> >> where does the new IP header information come from? > > Its not new, its the same ip header.. > > Its just you go into the mbuf chain and take out > the udp header... well you can't do that at the socket buffer becasue you've discarded the IP header. It may not even be in the mbufs you have. (though it's unlikely). After you've processed the UDP part the IP part is gone so you'd need to intercept the packet way earlier and then do your own UDP processing, (or maybe attach the IP header onto it with a tag). > > > >> >> >>> And sends it into the transport_input() (same one called by ip_input). >>> This then makes a clean and easy way to have "tunneled UDP" transport >>> protocols >>> work in kernel. The input side looks the same. Output is pretty >>> easy.. easy to >>> drop a UDP header in out output... >>> Netgraph would have to be watching every UDP packet always.. >> >> just those that go to that ksocket. we hook on at the socketbuf point. > > Hmm sounds plausible.. what you are suggesting is UDP header injection, between the existing IP header and existing SCTP header, then on reception, stripping it out. We'd have to do a bit of hacking to do that.. it's kind of 'unusual' in-kernel UDP encapsulation is easy but we don't have header injection.. I can see how one would do it but I was wrong before, you'd need to do some work. > > R > >> From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 22:39:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8073C1065678 for ; Wed, 19 Nov 2008 22:39:25 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (email.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 4025A8FC12 for ; Wed, 19 Nov 2008 22:39:25 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id A5D75172FF; Thu, 20 Nov 2008 09:39:22 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.3 required=10.0 tests=ALL_TRUSTED, DNS_FROM_SECURITYSAGE autolearn=no version=3.2.3 Received: from [10.1.50.60] (ppp121-44-7-122.lns10.syd7.internode.on.net [121.44.7.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 8017B171BF; Thu, 20 Nov 2008 09:39:18 +1100 (EST) Message-ID: <49249506.2050706@modulus.org> Date: Thu, 20 Nov 2008 09:36:54 +1100 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: Randall Stewart References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Thinking about UDP and tunneling 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, 19 Nov 2008 22:39:25 -0000 The openvpn port tunnels IP over UDP very efficiently and with optional compression and encryption. - Andrew From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 22:55:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 580F31065672 for ; Wed, 19 Nov 2008 22:55:08 +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 1306C8FC14 for ; Wed, 19 Nov 2008 22:55:08 +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 5D88841C670; Wed, 19 Nov 2008 23:55:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id BcSXH-ouIL0w; Wed, 19 Nov 2008 23:55:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 6446941C667; Wed, 19 Nov 2008 23:55:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 0379A444888; Wed, 19 Nov 2008 22:50:48 +0000 (UTC) Date: Wed, 19 Nov 2008 22:50:48 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Randall Stewart In-Reply-To: Message-ID: <20081119224027.U61259@maildrop.int.zabbadoz.net> References: <49245EE3.2000700@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net Subject: Re: Thinking about UDP and tunneling 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, 19 Nov 2008 22:55:08 -0000 On Wed, 19 Nov 2008, Randall Stewart wrote: Hi, [UDP tunneling of "foo"] I am not following this thread at all but the transport_udp_input(mbuf, offset) jumped into my eyes. > Not sure what netgraph does... what is wanted is this in comes > > +-----+ > | IP | > +-----+ > | UDP | > +-----+ ... > +-----+ > > Ideally it runs into UDP via ip_input() > and comes down to where it would append() to the socket. > > What you want in this case is the whole mbuf chain to be sent > to the transport_udp_input(m, offset) function > > This changes the above to > +-----+ > | IP | > +-----+ ... > +-----+ > > And sends it into the transport_input() (same one called by ip_input). > > This then makes a clean and easy way to have "tunneled UDP" transport > protocols > work in kernel. The input side looks the same. Output is pretty easy.. easy > to > drop a UDP header in out output... So I see things like this spring here and there and people start introducing more hacks on top of hacks on top of hacks these days to cicumvent dumb NAT setups. Right. No. So why the heck not use one of the dozend possibilities that you can find on rfc-editor.org to encapsulate whatever you want into UDP in a well defined protocol way rather than introducing yet another UDP-encap for yet another protocol? Stuffing X into UDP means having a policy to identify the next ULP possibly by port combinations, identify out of sequence data, identify randomly forged pakets insert into your stream, fragemation, \ldots \ldots \ldots possibly handshake all this first by the means of the ULP, \ldots \ldots \ldots reinventing the wheel over and over again. Ignore my 0.02CAD. /bz -- Bjoern A. Zeeb If you have a hammer, everything looks like a nail. From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 23:05:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9B481065670; Wed, 19 Nov 2008 23:05:00 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 7D61D8FC18; Wed, 19 Nov 2008 23:05:00 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.178.136]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 00:04:58 +0100 Date: Thu, 20 Nov 2008 00:04:54 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Andre Oppermann In-Reply-To: <4921F2CD.503@freebsd.org> Message-ID: <20081119234543.A90462@beagle.kn.op.dlr.de> References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> <4921B3C6.5020002@freebsd.org> <4921F2CD.503@freebsd.org> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 19 Nov 2008 23:04:58.0119 (UTC) FILETIME=[3E3AB170:01C94A9B] Cc: freebsd-net@freebsd.org, bz@freebsd.org, Rui Paulo Subject: Re: TCP and syncache question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 23:05:01 -0000 Hi Andre, On Mon, 17 Nov 2008, Andre Oppermann wrote: AO>This is a bit more complicated because of interactions with tcp_input() AO>where syncache_expand() is called from. AO> AO>The old code (as of December 2002) behaved slightly different. It would AO>not remove the syncache entry when (SND.UNA == SEG.ACK) but send a RST. AO>The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't done at AO>all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) succeeded. AO>This gave way to the "LAND" DoS attack which was mostly fixed with a test AO>for (RCV.IRS < SEG.SEQ). AO> AO>See the attached patch for fixed version of syncache_expand(). This patch AO>is untested though. My development machine is currently down. Harti, Rui AO>and Bjoern, please have a look at the patch and review it. Some small problems: AO>--- tcp_input.c.1.390 Mon Nov 17 21:33:25 2008 AO>+++ tcp_input.c.1.390.mod Mon Nov 17 21:35:22 2008 AO>@@ -642,10 +642,13 @@ findpcb: AO> if (!syncache_expand(&inc, &to, th, &so, m)) { AO> /* AO> * No syncache entry or ACK was not AO>- * for our SYN/ACK. Send a RST. AO>+ * for our SYN/ACK. Send a RST or AO>+ * an ACK for re-synchronization. AO> * NB: syncache did its own logging AO> * of the failure cause. AO> */ AO>+ if (so == 1) Need a cast here: if (so == (struct socket *)1) AO>+ goto dropunlock; AO> rstreason = BANDLIM_RST_OPENPORT; AO> goto dropwithreset; AO> } AO>--- tcp_syncache.c.1.160 Mon Nov 17 16:49:01 2008 AO>+++ tcp_syncache.c.1.160.mod Mon Nov 17 23:35:39 2008 AO>@@ -817,59 +817,47 @@ syncache_expand(struct in_conninfo *inc, AO> INP_INFO_WLOCK_ASSERT(&V_tcbinfo); AO> KASSERT((th->th_flags & (TH_RST|TH_ACK|TH_SYN)) == TH_ACK, AO> ("%s: can handle only ACK", __func__)); AO>+ *lsop = NULL; This leads to a panic on sonewconn. *lsop points to the listening socket when the function is entered and this socket is needed below in syncache_socket(). I just removed this line. AO> AO> sc = syncache_lookup(inc, &sch); /* returns locked sch */ AO> SCH_LOCK_ASSERT(sch); AO> if (sc == NULL) { AO> /* AO> * There is no syncache entry, so see if this ACK is AO>- * a returning syncookie. To do this, first: AO>- * A. See if this socket has had a syncache entry dropped in AO>- * the past. We don't want to accept a bogus syncookie AO>- * if we've never received a SYN. AO>- * B. check that the syncookie is valid. If it is, then AO>- * cobble up a fake syncache entry, and return. AO>+ * a returning syncookie. If the syncookie is valid, AO>+ * cobble up a fake syncache entry and create a socket. AO>+ * AO>+ * NB: Syncache head is locked for the syncookie access. AO> */ AO> if (!tcp_syncookies) { AO>- SCH_UNLOCK(sch); AO> if ((s = tcp_log_addrs(inc, th, NULL, NULL))) AO> log(LOG_DEBUG, "%s; %s: Spurious ACK, " AO> "segment rejected (syncookies disabled)\n", AO> s, __func__); AO>- goto failed; AO>+ goto sendrst; AO> } AO> bzero(&scs, sizeof(scs)); AO> sc = syncookie_lookup(inc, sch, &scs, to, th, *lsop); AO>- SCH_UNLOCK(sch); AO> if (sc == NULL) { AO> if ((s = tcp_log_addrs(inc, th, NULL, NULL))) AO> log(LOG_DEBUG, "%s; %s: Segment failed " AO> "SYNCOOKIE authentication, segment rejected " AO> "(probably spoofed)\n", s, __func__); AO>- goto failed; AO>+ goto sendrst; AO> } AO>- } else { AO>- /* Pull out the entry to unlock the bucket row. */ AO>- TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); AO>- sch->sch_length--; AO>- V_tcp_syncache.cache_count--; AO>- SCH_UNLOCK(sch); AO>+ goto expand; /* fully validated through syncookie */ AO> } AO>+ SCH_LOCK_ASSERT(sch); AO> AO> /* AO> * Segment validation: AO>- * ACK must match our initial sequence number + 1 (the SYN|ACK). AO>- */ AO>- if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { AO>- if ((s = tcp_log_addrs(inc, th, NULL, NULL))) AO>- log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " AO>- "rejected\n", s, __func__, th->th_ack, sc->sc_iss); AO>- goto failed; AO>- } AO>- AO>- /* AO>+ * AO> * The SEQ must fall in the window starting at the received AO> * initial receive sequence number + 1 (the SYN). AO>+ * If not the segment may be from an earlier connection. We send AO>+ * an ACK to re-synchronize the connection and keep the syncache AO>+ * entry without ajusting its timers. AO>+ * See RFC793 page 69, first check sequence number [SYN_RECEIVED]. AO> */ AO> if ((SEQ_LEQ(th->th_seq, sc->sc_irs) || AO> SEQ_GT(th->th_seq, sc->sc_irs + sc->sc_wnd)) && AO>@@ -877,14 +865,41 @@ syncache_expand(struct in_conninfo *inc, AO> if ((s = tcp_log_addrs(inc, th, NULL, NULL))) AO> log(LOG_DEBUG, "%s; %s: SEQ %u != IRS+1 %u, segment " AO> "rejected\n", s, __func__, th->th_seq, sc->sc_irs); AO>- goto failed; AO>+ (void) syncache_respond(sc); AO>+ *lsop = 1; /* prevent RST */ Need another cast here: *lsop = (struct socket *)1. [snip] I've re-run my test scripts and they seem to indicate, that the socket is now kept in the correct state when the incoming segment had an incorrect ack. I could no yet run the tests for an incorrect seqno, though. This is because there is an interesting problem in RFC793 (and MIL-STD-1778): the RFC states on page 36 a general rule that a 'reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection.' I would say, that a segment carrying a sequence number at irs (when without SYN) and below irs (in any case) cannot belong to the current connection - those sequence numbers just don't exist for the connection. On the other hand p.69 says that we must send an ACK. If this were an ITU-T standard, things would be clear, because the prosa description would be normative, not the algorithm. I've tried to follow the classical BSD code in Stevens and it seems that before syncaches and stuff, an ACK was sent for a bad sequence number. So I'll change my tests (probably tomorrow in the evening) and check that the patch is correct for this case too. At a first glance a nice SYN+ACK came out... harti From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 23:56:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D9A91065670 for ; Wed, 19 Nov 2008 23:56:45 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 221278FC13 for ; Wed, 19 Nov 2008 23:56:44 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 5EBA61BC368; Wed, 19 Nov 2008 18:56:43 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 19 Nov 2008 18:56:43 -0500 X-Sasl-enc: P8CLT6TsUVTkRQYHrNIbhrz15lGt3pDI4kWLs+P2dTaV 1227139003 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 ESMTPSA id A8F991D74C; Wed, 19 Nov 2008 18:56:42 -0500 (EST) Message-ID: <4924A7B6.9080507@incunabulum.net> Date: Wed, 19 Nov 2008 23:56:38 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: Julian Elischer References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> <4923DB2D.2080702@ironport.com> <20081119123600.E30755@claw.omgcats.com> <49246C12.8080201@ironport.com> In-Reply-To: <49246C12.8080201@ironport.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Andre Oppermann , Mike Holling Subject: Re: tokenring users? 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, 19 Nov 2008 23:56:45 -0000 Julian Elischer wrote: > my only worry is FDDI support... > 1/ do we have any There's like one driver left, and I don't think it even builds. > 2/ if so, does it use any of the tokenring support? I don;t really > know much > about FDDI. Wouldn't want to remove anything still in use by something > else. > It doesn't use "canonical MAC address format", if that's what you mean. Let's just kill it and get on with our lives... From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 10:25:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96A1F106564A for ; Thu, 20 Nov 2008 10:25:56 +0000 (UTC) (envelope-from cole@opteqint.net) Received: from elektra.opteqint.net (elektra.opteqint.net [209.25.178.105]) by mx1.freebsd.org (Postfix) with ESMTP id 7379B8FC0C for ; Thu, 20 Nov 2008 10:25:56 +0000 (UTC) (envelope-from cole@opteqint.net) Received: from [196.210.36.132] (helo=Jiraiya) by elektra.opteqint.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.66 (FreeBSD)) (envelope-from ) id 1L367f-00041w-3I for freebsd-net@freebsd.org; Thu, 20 Nov 2008 01:47:00 -0800 From: "Cole" To: Date: Thu, 20 Nov 2008 11:46:42 +0200 Message-ID: <002f01c94af4$ecbced90$c636c8b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclK9OQ08c9xF4lCRPuOrPwtLptYDQ== Content-Language: en-za X-Spam-Score: -113.0 (---------------------------------------------------) X-Spam-Report: Spam detection software, running on the system "elektra.opteqint.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hi. I have been playing with FreeBSD bridging in 7.0-Release. And was just testing some things to see exactly how it worked and try a few things out. I know that this isn't how the bridge is meant to be setup, but now im just curious as to why the following is happening. [...] Content analysis details: (-113.0 points, 4.3 required) pts rule name description ---- ---------------------- -------------------------------------------------- -100 USER_IN_WHITELIST From: address is in the user's white-list -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -12 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.8 AWL AWL: From: address is in the auto white-list Subject: FreeBSD Bridge and ARP question/strangeness 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, 20 Nov 2008 10:25:56 -0000 Hi. I have been playing with FreeBSD bridging in 7.0-Release. And was just testing some things to see exactly how it worked and try a few things out. I know that this isn't how the bridge is meant to be setup, but now im just curious as to why the following is happening. I have a box with a few interfaces, and i had setup rl0 with an ip address and it could communicate/ping everything on the network fine, all the rest of the other interfaces are unplugged and have no ip's assigned. Now if i go ahead and create a bridge interface and then just add that single interface with the ip assigned to it to the bridge, without assigning a new ip to the bridge, i get some strange things happening. Every box on the network not running FreeBSD is still able to ping and receive a reply from the box on the ip it was using on the interface. However, no FreeBSD box is now able to ping the box at all. In the arp listing, it shows any of the FreeBSD boxes that are trying to ping it as "(incomplete)". But for every other box that isn't FreeBSD it gets a full arp listing and all those boxes are still able to communicate with the box fine. So i was just wondering if theres a reason for this, or if anyone has any idea or clues why this might be happening. If you want i can provide whatever dumps you would need or anything like that. Regards /Cole From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 10:59:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87A4D106564A for ; Thu, 20 Nov 2008 10:59:22 +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 641BD8FC19 for ; Thu, 20 Nov 2008 10:59:20 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 45163 invoked from network); 20 Nov 2008 09:24:22 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 20 Nov 2008 09:24:22 -0000 Message-ID: <4925430A.9050602@freebsd.org> Date: Thu, 20 Nov 2008 11:59:22 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Rui Paulo References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> <4921B3C6.5020002@freebsd.org> <4921F2CD.503@freebsd.org> <403932D0-8B62-4C95-8076-A185AC1C69E7@freebsd.org> In-Reply-To: <403932D0-8B62-4C95-8076-A185AC1C69E7@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Hartmut Brandt , bz@freebsd.org Subject: Re: TCP and syncache question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2008 10:59:22 -0000 Rui Paulo wrote: > On 17 Nov 2008, at 22:40, Andre Oppermann wrote: >> This is a bit more complicated because of interactions with tcp_input() >> where syncache_expand() is called from. >> >> The old code (as of December 2002) behaved slightly different. It would >> not remove the syncache entry when (SND.UNA == SEG.ACK) but send a RST. >> The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't done at >> all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) >> succeeded. >> This gave way to the "LAND" DoS attack which was mostly fixed with a test >> for (RCV.IRS < SEG.SEQ). >> >> See the attached patch for fixed version of syncache_expand(). This >> patch >> is untested though. My development machine is currently down. Harti, >> Rui >> and Bjoern, please have a look at the patch and review it. >> >> --Andre >> >> --- tcp_input.c.1.390 Mon Nov 17 21:33:25 2008 >> +++ tcp_input.c.1.390.mod Mon Nov 17 21:35:22 2008 >> @@ -642,10 +642,13 @@ findpcb: >> if (!syncache_expand(&inc, &to, th, &so, m)) { >> /* >> * No syncache entry or ACK was not >> - * for our SYN/ACK. Send a RST. >> + * for our SYN/ACK. Send a RST or >> + * an ACK for re-synchronization. >> * NB: syncache did its own logging >> * of the failure cause. >> */ >> + if (so == 1) >> + goto dropunlock; >> rstreason = BANDLIM_RST_OPENPORT; >> goto dropwithreset; >> } >> --- tcp_syncache.c.1.160 Mon Nov 17 16:49:01 2008 >> +++ tcp_syncache.c.1.160.mod Mon Nov 17 23:35:39 2008 >> @@ -817,59 +817,47 @@ syncache_expand(struct in_conninfo *inc, >> INP_INFO_WLOCK_ASSERT(&V_tcbinfo); >> KASSERT((th->th_flags & (TH_RST|TH_ACK|TH_SYN)) == TH_ACK, >> ("%s: can handle only ACK", __func__)); >> + *lsop = NULL; >> >> sc = syncache_lookup(inc, &sch); /* returns locked sch */ >> SCH_LOCK_ASSERT(sch); >> if (sc == NULL) { >> /* >> * There is no syncache entry, so see if this ACK is >> - * a returning syncookie. To do this, first: >> - * A. See if this socket has had a syncache entry dropped in >> - * the past. We don't want to accept a bogus syncookie >> - * if we've never received a SYN. >> - * B. check that the syncookie is valid. If it is, then >> - * cobble up a fake syncache entry, and return. >> + * a returning syncookie. If the syncookie is valid, >> + * cobble up a fake syncache entry and create a socket. >> + * >> + * NB: Syncache head is locked for the syncookie access. >> */ >> if (!tcp_syncookies) { >> - SCH_UNLOCK(sch); >> if ((s = tcp_log_addrs(inc, th, NULL, NULL))) >> log(LOG_DEBUG, "%s; %s: Spurious ACK, " >> "segment rejected (syncookies disabled)\n", >> s, __func__); >> - goto failed; >> + goto sendrst; >> } >> bzero(&scs, sizeof(scs)); >> sc = syncookie_lookup(inc, sch, &scs, to, th, *lsop); >> - SCH_UNLOCK(sch); >> if (sc == NULL) { >> if ((s = tcp_log_addrs(inc, th, NULL, NULL))) >> log(LOG_DEBUG, "%s; %s: Segment failed " >> "SYNCOOKIE authentication, segment rejected " >> "(probably spoofed)\n", s, __func__); >> - goto failed; >> + goto sendrst; >> } >> - } else { >> - /* Pull out the entry to unlock the bucket row. */ >> - TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); >> - sch->sch_length--; >> - V_tcp_syncache.cache_count--; >> - SCH_UNLOCK(sch); >> + goto expand; /* fully validated through syncookie */ >> } >> + SCH_LOCK_ASSERT(sch); > > Why do you need this assert? Removed. Was from an earlier iteration with different locking and gotos. >> /* >> * Segment validation: >> - * ACK must match our initial sequence number + 1 (the SYN|ACK). >> - */ >> - if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { >> - if ((s = tcp_log_addrs(inc, th, NULL, NULL))) >> - log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " >> - "rejected\n", s, __func__, th->th_ack, sc->sc_iss); >> - goto failed; >> - } >> - >> - /* >> + * >> * The SEQ must fall in the window starting at the received >> * initial receive sequence number + 1 (the SYN). >> + * If not the segment may be from an earlier connection. We send >> + * an ACK to re-synchronize the connection and keep the syncache >> + * entry without ajusting its timers. >> + * See RFC793 page 69, first check sequence number [SYN_RECEIVED]. >> */ >> if ((SEQ_LEQ(th->th_seq, sc->sc_irs) || >> SEQ_GT(th->th_seq, sc->sc_irs + sc->sc_wnd)) && >> @@ -877,14 +865,41 @@ syncache_expand(struct in_conninfo *inc, >> if ((s = tcp_log_addrs(inc, th, NULL, NULL))) >> log(LOG_DEBUG, "%s; %s: SEQ %u != IRS+1 %u, segment " >> "rejected\n", s, __func__, th->th_seq, sc->sc_irs); >> - goto failed; >> + (void) syncache_respond(sc); >> + *lsop = 1; /* prevent RST */ >> + goto sendrstkeep; >> } >> >> + /* >> + * ACK must match our initial sequence number + 1 (the SYN|ACK). >> + * If not the segment may be from an earlier connection. We send >> + * a RST but keep the syncache entry without ajusting its timers. >> + * See RFC793 page 72, fifth check the ACK field, [SYN_RECEIVED]. >> + */ >> + if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { >> + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) >> + log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " >> + "rejected\n", s, __func__, th->th_ack, sc->sc_iss); >> + goto sendrstkeep; >> + } >> + >> + /* >> + * Remove the entry to unlock the bucket row. >> + * Tests from now on are fatal and remove the syncache entry. >> + */ >> + TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); >> + sch->sch_length--; >> + V_tcp_syncache.cache_count--; >> + >> + /* >> + * If timestamps were not negotiated they must not show up later. >> + * See RFC1312bis, section 1.3, second paragraph >> + */ >> if (!(sc->sc_flags & SCF_TIMESTAMP) && (to->to_flags & TOF_TS)) { >> if ((s = tcp_log_addrs(inc, th, NULL, NULL))) >> log(LOG_DEBUG, "%s; %s: Timestamp not expected, " >> "segment rejected\n", s, __func__); >> - goto failed; >> + goto sendrst; >> } >> /* >> * If timestamps were negotiated the reflected timestamp >> @@ -896,9 +911,11 @@ syncache_expand(struct in_conninfo *inc, >> log(LOG_DEBUG, "%s; %s: TSECR %u != TS %u, " >> "segment rejected\n", >> s, __func__, to->to_tsecr, sc->sc_ts); >> - goto failed; >> + goto sendrst; >> } >> >> +expand: >> + SCH_UNLOCK(sch); >> *lsop = syncache_socket(sc, *lsop, m); >> >> if (*lsop == NULL) >> @@ -906,16 +923,18 @@ syncache_expand(struct in_conninfo *inc, >> else >> V_tcpstat.tcps_sc_completed++; >> >> -/* how do we find the inp for the new socket? */ >> if (sc != &scs) >> syncache_free(sc); >> return (1); >> -failed: >> - if (sc != NULL && sc != &scs) >> + >> +sendrst: >> + if (sc != &scs) >> syncache_free(sc); >> +sendrstkeep: >> + SCH_LOCK_ASSERT(sch); >> + SCH_UNLOCK(sch); > > Why do we need an assert before an unlock? This is customary in at least the TCP code. A failed assert provides more and better diagnostics than a crash-and-burn failed unlock. >> if (s != NULL) >> free(s, M_TCPLOG); >> - *lsop = NULL; >> return (0); >> } >> > > This was probably out of scope: yep. Put it in while reading the code. >> @@ -1322,6 +1341,8 @@ syncache_respond(struct syncache *sc) >> * >> * 1) path_mtu_discovery is disabled >> * 2) the SCF_UNREACH flag has been set >> + * >> + * XXXAO: The route lookup comment doesn't make sense. >> */ >> if (V_path_mtu_discovery && ((sc->sc_flags & SCF_UNREACH) == 0)) >> ip->ip_off |= IP_DF; > > > > I won't be able to test this any time soon, so I can't really comment on > the rest, but it *looks* okay. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 11:52:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75FAF106564A for ; Thu, 20 Nov 2008 11:52:41 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id EEF2F8FC19 for ; Thu, 20 Nov 2008 11:52:40 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L385M-0006QZ-Q4 for freebsd-net@freebsd.org; Thu, 20 Nov 2008 11:52:36 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Nov 2008 11:52:36 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Nov 2008 11:52:36 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Thu, 20 Nov 2008 12:53:28 +0100 Lines: 64 Message-ID: References: <002f01c94af4$ecbced90$c636c8b0$@net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig857B30409D1AE3D619B3685F" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.17 (X11/20080925) In-Reply-To: <002f01c94af4$ecbced90$c636c8b0$@net> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: FreeBSD Bridge and ARP question/strangeness 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, 20 Nov 2008 11:52:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig857B30409D1AE3D619B3685F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cole wrote: > Hi. >=20 > I have been playing with FreeBSD bridging in 7.0-Release. And was just > testing some things to see exactly how it worked and try a few things o= ut. I > know that this isn't how the bridge is meant to be setup, but now im ju= st > curious as to why the following is happening. >=20 > I have a box with a few interfaces, and i had setup rl0 with an ip addr= ess > and it could communicate/ping everything on the network fine, all the r= est > of the other interfaces are unplugged and have no ip's assigned. Now if= i go > ahead and create a bridge interface and then just add that single inter= face > with the ip assigned to it to the bridge, without assigning a new ip to= the > bridge, i get some strange things happening. Every box on the network n= ot > running FreeBSD is still able to ping and receive a reply from the box = on > the ip it was using on the interface. However, no FreeBSD box is now ab= le to > ping the box at all. In the arp listing, it shows any of the FreeBSD bo= xes > that are trying to ping it as "(incomplete)". But for every other box t= hat > isn't FreeBSD it gets a full arp listing and all those boxes are still = able > to communicate with the box fine. >=20 > So i was just wondering if theres a reason for this, or if anyone has a= ny > idea or clues why this might be happening. If you want i can provide > whatever dumps you would need or anything like that. Can you rule out ARP timeouts? E.g. maybe other boxes have longer ARP TTLs than FreeBSD boxes. It's happened to me once (it was a bug in the em driver). --------------enig857B30409D1AE3D619B3685F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJJU+4ldnAQVacBcgRAhirAJ0QRL+yKuDp5nkxL4kJlIQo+YIzuACg5Mjv vBwoVGLH4UtXn+052NT35hw= =FKt4 -----END PGP SIGNATURE----- --------------enig857B30409D1AE3D619B3685F-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 11:52:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 743911065673 for ; Thu, 20 Nov 2008 11:52:52 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 239D08FC0C for ; Thu, 20 Nov 2008 11:52:52 +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:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=oHmo/SjL+VlS3xbRW9dXogHSa8CbmSwxnjHwEWB3WgMDg6w2ZPOAmai/wgk8GYBkDbOTwTUFO2+ZaayofyGa2xGc1ZMFAgQf4NkNmUfkAFDnhFED+t3U2r+5cOf0QUsy5oGCYvIp5KW8Yii/0CljHSnNvfy/lL76rsoM2vf7xVw=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1L385a-0003oD-BD; Thu, 20 Nov 2008 14:52:50 +0300 Date: Thu, 20 Nov 2008 14:52:49 +0300 From: Eygene Ryabinkin To: Cole Message-ID: References: <002f01c94af4$ecbced90$c636c8b0$@net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Epv4kl9IRBfg3rk" Content-Disposition: inline In-Reply-To: <002f01c94af4$ecbced90$c636c8b0$@net> Sender: rea-fbsd@codelabs.ru Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD Bridge and ARP question/strangeness 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, 20 Nov 2008 11:52:52 -0000 --4Epv4kl9IRBfg3rk Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cole, good day. Thu, Nov 20, 2008 at 11:46:42AM +0200, Cole wrote: > I have a box with a few interfaces, and i had setup rl0 with an ip address > and it could communicate/ping everything on the network fine, all the rest > of the other interfaces are unplugged and have no ip's assigned. Now if i= go > ahead and create a bridge interface and then just add that single interfa= ce > with the ip assigned to it to the bridge, without assigning a new ip to t= he > bridge, i get some strange things happening. Every box on the network not > running FreeBSD is still able to ping and receive a reply from the box on > the ip it was using on the interface. However, no FreeBSD box is now able= to > ping the box at all. In the arp listing, it shows any of the FreeBSD boxes > that are trying to ping it as "(incomplete)". But for every other box that > isn't FreeBSD it gets a full arp listing and all those boxes are still ab= le > to communicate with the box fine. I think that the first thing to look at will be the tcpdump of the ARP traffic -- if your peers are seeing '(incomplete)' as the bridging host MAC, then it is good to check if ARP requests are received and are they replied to. 'tcpdump -lvvnetti rl0 arp' should produce the fine listing. And the output of 'ifconfig' and 'sysctl net.link.bridge' will be helpful too. --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --4Epv4kl9IRBfg3rk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkklT5EACgkQthUKNsbL7YgN1QCgnG5QJFD4SNQErkQ5Qmrt3Lz5 VYUAninFoYS+WBgKIhaIj/LY6BcNB0je =sQ2+ -----END PGP SIGNATURE----- --4Epv4kl9IRBfg3rk-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 12:51:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 125AC1065677 for ; Thu, 20 Nov 2008 12:51:38 +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 421B78FC12 for ; Thu, 20 Nov 2008 12:51:37 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 47985 invoked from network); 20 Nov 2008 11:16:38 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 20 Nov 2008 11:16:38 -0000 Message-ID: <49255D5B.5040303@freebsd.org> Date: Thu, 20 Nov 2008 13:51:39 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Harti Brandt References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> <4921B3C6.5020002@freebsd.org> <4921F2CD.503@freebsd.org> <20081119234543.A90462@beagle.kn.op.dlr.de> In-Reply-To: <20081119234543.A90462@beagle.kn.op.dlr.de> Content-Type: multipart/mixed; boundary="------------040901000405020901010901" Cc: freebsd-net@freebsd.org, bz@freebsd.org, Rui Paulo Subject: Re: TCP and syncache question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2008 12:51:38 -0000 This is a multi-part message in MIME format. --------------040901000405020901010901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Harti Brandt wrote: > Hi Andre, > > On Mon, 17 Nov 2008, Andre Oppermann wrote: > > AO>This is a bit more complicated because of interactions with tcp_input() > AO>where syncache_expand() is called from. > AO> > AO>The old code (as of December 2002) behaved slightly different. It would > AO>not remove the syncache entry when (SND.UNA == SEG.ACK) but send a RST. > AO>The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't done at > AO>all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) succeeded. > AO>This gave way to the "LAND" DoS attack which was mostly fixed with a test > AO>for (RCV.IRS < SEG.SEQ). > AO> > AO>See the attached patch for fixed version of syncache_expand(). This patch > AO>is untested though. My development machine is currently down. Harti, Rui > AO>and Bjoern, please have a look at the patch and review it. > > Some small problems: ... > Need another cast here: *lsop = (struct socket *)1. Changed the logic to use a NULL *lsop to differentiate in tcp_input(). Much simpler. > [snip] > > I've re-run my test scripts and they seem to indicate, that the socket is > now kept in the correct state when the incoming segment had an incorrect > ack. I could no yet run the tests for an incorrect seqno, though. This is > because there is an interesting problem in RFC793 (and MIL-STD-1778): the RFC > states on page 36 a general rule that a 'reset (RST) must be sent whenever > a segment arrives which apparently is not intended for the current connection.' The full quote from page 36 is: "As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case." > I would say, that a segment carrying a sequence number at irs (when without SYN) > and below irs (in any case) cannot belong to the current connection - those > sequence numbers just don't exist for the connection. On the other hand p.69 > says that we must send an ACK. If this were an ITU-T standard, things > would be clear, because the prosa description would be normative, not the > algorithm. The more specific rule wins. Sending the "challenge" ACK is done under the assumption that the remote end will send a reset to our "challenge" ACK if such an connection doesn't exist there. > I've tried to follow the classical BSD code in Stevens and > it seems that before syncaches and stuff, an ACK was sent for a bad > sequence number. So I'll change my tests (probably tomorrow in the evening) > and check that the patch is correct for this case too. At a first glance > a nice SYN+ACK came out... An updated patch is attached. -- Andre --------------040901000405020901010901 Content-Type: text/plain; name="syncache_expand_fix-20081120.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="syncache_expand_fix-20081120.diff" --- tcp_input.c.1.390 Mon Nov 17 21:33:25 2008 +++ tcp_input.c.1.390.mod Thu Nov 20 08:25:36 2008 @@ -642,10 +642,13 @@ findpcb: if (!syncache_expand(&inc, &to, th, &so, m)) { /* * No syncache entry or ACK was not - * for our SYN/ACK. Send a RST. + * for our SYN/ACK. Send a RST or + * an ACK for re-synchronization. * NB: syncache did its own logging * of the failure cause. */ + if (so == NULL) + goto dropunlock; rstreason = BANDLIM_RST_OPENPORT; goto dropwithreset; } --- tcp_syncache.c.1.160 Mon Nov 17 16:49:01 2008 +++ tcp_syncache.c.1.160.mod Thu Nov 20 12:13:26 2008 @@ -823,53 +823,39 @@ syncache_expand(struct in_conninfo *inc, if (sc == NULL) { /* * There is no syncache entry, so see if this ACK is - * a returning syncookie. To do this, first: - * A. See if this socket has had a syncache entry dropped in - * the past. We don't want to accept a bogus syncookie - * if we've never received a SYN. - * B. check that the syncookie is valid. If it is, then - * cobble up a fake syncache entry, and return. + * a returning syncookie. If the syncookie is valid, + * cobble up a fake syncache entry and create a socket. + * + * NB: Syncache head is locked for the syncookie access. */ if (!tcp_syncookies) { - SCH_UNLOCK(sch); if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: Spurious ACK, " "segment rejected (syncookies disabled)\n", s, __func__); - goto failed; + goto sendrst; } bzero(&scs, sizeof(scs)); sc = syncookie_lookup(inc, sch, &scs, to, th, *lsop); - SCH_UNLOCK(sch); if (sc == NULL) { if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: Segment failed " "SYNCOOKIE authentication, segment rejected " "(probably spoofed)\n", s, __func__); - goto failed; + goto sendrst; } - } else { - /* Pull out the entry to unlock the bucket row. */ - TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); - sch->sch_length--; - V_tcp_syncache.cache_count--; - SCH_UNLOCK(sch); + goto expand; /* fully validated through syncookie */ } /* * Segment validation: - * ACK must match our initial sequence number + 1 (the SYN|ACK). - */ - if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { - if ((s = tcp_log_addrs(inc, th, NULL, NULL))) - log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " - "rejected\n", s, __func__, th->th_ack, sc->sc_iss); - goto failed; - } - - /* + * * The SEQ must fall in the window starting at the received * initial receive sequence number + 1 (the SYN). + * If not the segment may be from an earlier connection. + * We send an ACK to re-synchronize the connection and keep + * the syncache entry without ajusting its timers. + * See RFC793 page 69, first check sequence number [SYN_RECEIVED]. */ if ((SEQ_LEQ(th->th_seq, sc->sc_irs) || SEQ_GT(th->th_seq, sc->sc_irs + sc->sc_wnd)) && @@ -877,14 +863,41 @@ syncache_expand(struct in_conninfo *inc, if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: SEQ %u != IRS+1 %u, segment " "rejected\n", s, __func__, th->th_seq, sc->sc_irs); - goto failed; + (void) syncache_respond(sc); + *lsop = NULL; /* prevent RST */ + goto sendrstkeep; + } + + /* + * ACK must match our initial sequence number + 1 (the SYN|ACK). + * If not the segment may be from an earlier connection. We send + * a RST but keep the syncache entry without ajusting its timers. + * See RFC793 page 72, fifth check the ACK field, [SYN_RECEIVED]. + */ + if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) + log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " + "rejected\n", s, __func__, th->th_ack, sc->sc_iss); + goto sendrstkeep; } + /* + * Remove the entry to unlock the bucket row. + * Tests from now on are fatal and remove the syncache entry. + */ + TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); + sch->sch_length--; + V_tcp_syncache.cache_count--; + + /* + * If timestamps were not negotiated they must not show up later. + * See RFC1312bis, section 1.3, second paragraph + */ if (!(sc->sc_flags & SCF_TIMESTAMP) && (to->to_flags & TOF_TS)) { if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: Timestamp not expected, " "segment rejected\n", s, __func__); - goto failed; + goto sendrst; } /* * If timestamps were negotiated the reflected timestamp @@ -896,9 +909,11 @@ syncache_expand(struct in_conninfo *inc, log(LOG_DEBUG, "%s; %s: TSECR %u != TS %u, " "segment rejected\n", s, __func__, to->to_tsecr, sc->sc_ts); - goto failed; + goto sendrst; } +expand: + SCH_UNLOCK(sch); *lsop = syncache_socket(sc, *lsop, m); if (*lsop == NULL) @@ -906,16 +921,18 @@ syncache_expand(struct in_conninfo *inc, else V_tcpstat.tcps_sc_completed++; -/* how do we find the inp for the new socket? */ if (sc != &scs) syncache_free(sc); return (1); -failed: - if (sc != NULL && sc != &scs) + +sendrst: + if (sc != &scs) syncache_free(sc); +sendrstkeep: + SCH_LOCK_ASSERT(sch); + SCH_UNLOCK(sch); if (s != NULL) free(s, M_TCPLOG); - *lsop = NULL; return (0); } --------------040901000405020901010901-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 12:56:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBEEA1065675 for ; Thu, 20 Nov 2008 12:56:29 +0000 (UTC) (envelope-from dikshie@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 66EEF8FC0C for ; Thu, 20 Nov 2008 12:56:29 +0000 (UTC) (envelope-from dikshie@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so195236ywe.13 for ; Thu, 20 Nov 2008 04:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=6/rL6wxT0TJFXwXOndH8oqnkohI9erwuten5Gfdp8kM=; b=qFWJYpppQSRtCOGAJbO2JvGoK3to2vln8r/AN3et1HN8aoqJsTV0mnqQ9xuE/oOwI0 52w9NCEqTE9f5A4lm1DqiUGrKTB8pOjLK08ANA8/Djc7t2HnUBFs6K48yG4XrCdR9SEL C1/O8WVbE+ybfTRbmy795I9slvPEDp+gsom9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=RrlazORE7tIVrLXLh8IGOj1kSfT3Oh5KnWQYU7GItAxV/PmpTZfgLJZSsdVGdkgvlG jMAj+mB8K3BsAHU5woZ0niwMQWeLbqk+ljbO9gQ4B0xZ04Ndtd6U80pAaYkYL0AlOAel zOl6QDmTfGG8FezL4wRqC7r3oURnFDKNor+/8= Received: by 10.150.227.14 with SMTP id z14mr2164140ybg.106.1227184128001; Thu, 20 Nov 2008 04:28:48 -0800 (PST) Received: by 10.150.121.2 with HTTP; Thu, 20 Nov 2008 04:28:47 -0800 (PST) Message-ID: <910e60e80811200428u41eef8d6sa78582889b620efb@mail.gmail.com> Date: Thu, 20 Nov 2008 21:28:47 +0900 From: dikshie To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: asm multicast ping 6.3 vs 7.1 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, 20 Nov 2008 12:56:29 -0000 hi, i have strange situation here. in my 6.3 box: ------------------------------------- $ asmping ff38:20:2001:d30:: soi-mirror.unibraw.ai3.net asmping joined (S,G) = (*,ff38:20:2001:d30::4321:1234) pinging 2001:d30:111:2::4 from 2001:d30:101:1::10 unicast from 2001:d30:111:2::4, seq=1 dist=2 time=329.990 ms multicast from 2001:d30:111:2::4, seq=1 dist=2 time=334.344 ms unicast from 2001:d30:111:2::4, seq=2 dist=2 time=340.283 ms multicast from 2001:d30:111:2::4, seq=2 dist=2 time=341.357 ms unicast from 2001:d30:111:2::4, seq=3 dist=2 time=347.617 ms multicast from 2001:d30:111:2::4, seq=3 dist=2 time=347.627 ms ^C --- 2001:d30:111:2::4 statistics --- 3 packets transmitted, time 2726 ms unicast: 3 packets received, 0% packet loss rtt min/avg/max/std-dev = 329.990/339.296/347.617/7.261 ms multicast: 3 packets received, 0% packet loss since first mc packet (seq 1) recvd rtt min/avg/max/std-dev = 334.344/341.109/347.627/5.446 ms -------------------------------------- in my 7.1 box: -------------------------------------- $ asmping ff38:20:2001:d30:: soi-mirror.unibraw.ai3.net Failed to join multicast group: Protocol not available errno=42 -------------------------------------- both boxes has same ipv4 subnet and same ipv6 link. 7.1 box has options MROUTING 6.3 box does not has options MROUTING do i miss something here? best regards, -- -dikshie- From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 13:00:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C9CE1065674 for ; Thu, 20 Nov 2008 13:00:17 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id B7F5B8FC08 for ; Thu, 20 Nov 2008 13:00:16 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [130.129.75.226] ([130.129.75.226]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mAKD0CxL029537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 20 Nov 2008 08:00:13 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1227186014; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=BmjWpPKXd1LH30c93SQv2as7xcgH/9iHW3L4476HFc2wA185LzDcwL9 je6E/pZMtiNdg1wUZaG+ac+FNyT0UVA== Message-Id: <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> From: Randall Stewart To: Julian Elischer In-Reply-To: <49249443.8050707@elischer.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 08:00:11 -0500 References: <49245EE3.2000700@elischer.org> <49247BEE.4040201@elischer.org> <905A5B58-54D2-4B79-A1B4-44C6D5136691@lakerest.net> <49249443.8050707@elischer.org> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-net Subject: Re: Thinking about UDP and tunneling 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, 20 Nov 2008 13:00:17 -0000 On Nov 19, 2008, at 5:33 PM, Julian Elischer wrote: >>> >> Its not new, its the same ip header.. >> Its just you go into the mbuf chain and take out >> the udp header... > > well you can't do that at the socket buffer becasue you've discarded > the IP header. It may not even be in the mbufs you have. (though it's > unlikely). After you've processed the UDP part the IP part is gone so > you'd need to intercept the packet way earlier and then do your > own UDP processing, (or maybe attach the IP header onto it with a > tag). > > One would definitely have to do some work in udp_input() not a lot from what I can tell... but it would take some work. Maybe good course is to use the socket(9) stuff, but add an option that can set a "by-pass function" if the socket is udp... right after you establish the INP the packet goes to, if the function is set, you engage the bypass... >>> >>> >>>> And sends it into the transport_input() (same one called by >>>> ip_input). >>>> This then makes a clean and easy way to have "tunneled UDP" >>>> transport protocols >>>> work in kernel. The input side looks the same. Output is pretty >>>> easy.. easy to >>>> drop a UDP header in out output... >>>> Netgraph would have to be watching every UDP packet always.. >>> >>> just those that go to that ksocket. we hook on at the socketbuf >>> point. >> Hmm sounds plausible.. > > what you are suggesting is UDP header injection, between the > existing IP header and existing SCTP header, then on reception, > stripping it out. > > > We'd have to do a bit of hacking to do that.. it's kind of 'unusual' You need to take a look at some of the activities in tsvwg and the transport area open area meeting in the IETF. Not counting Jonathan's Rosenburgs IAB presentation an IETF or two ago claiming that "all new transports must tunnel via UDP". This seems to be a more and more common theme in the IETF. Now I personally do not agree that new transports cannot be deployed without UDP tunneling.. however there will always be the need for this IMO.. since you will often have NAT's that don't know about the new transport "yet"... Jonathan (and others claims is that the "yet" is really a "never".. here I disagree). Having infrastructure so we can do UDP tunneling of a new transport easily is IMO a good idea. Netgraph, looks interesting.. but I am afraid is not in GENERIC.. so you end up with a solution that only sometimes works. What I am thinking is a clean way to have kernel sockets(9) extended a bit so that we can better support tunneling input... Let me chew on this a while and come up with a working solution ... using socket(9) as much as possible... I think a couple of tweaks will be needed.. but I think its quite feasible and will be a benefit for not just SCTP but also DCCP and some of the other transports on the horizon... R > > > in-kernel UDP encapsulation is easy but we don't have header > injection.. > > I can see how one would do it > but I was wrong before, you'd need to do some work. > >> R >>> > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 13:06:47 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 493B9106564A for ; Thu, 20 Nov 2008 13:06:47 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id D43A68FC12 for ; Thu, 20 Nov 2008 13:06:46 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [130.129.75.226] ([130.129.75.226]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mAKD6g5F029577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 20 Nov 2008 08:06:43 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1227186405; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=NeyWyDBWzfFa2mPRuSYmBywfOalrKLAd+oaZ5UPHPPZkWbR1ukMt9/1 oQdY9Y3MstqJvfIDczLxH6VjmAgL0hw== Message-Id: <52CB7D7E-60BC-4F40-AE31-E1353B435409@lakerest.net> From: Randall Stewart To: "Bjoern A. Zeeb" In-Reply-To: <20081119224027.U61259@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 08:06:42 -0500 References: <49245EE3.2000700@elischer.org> <20081119224027.U61259@maildrop.int.zabbadoz.net> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-net Subject: Re: Thinking about UDP and tunneling 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, 20 Nov 2008 13:06:47 -0000 Bjoern: I am writing this email FROM the IETF. There are MANY drafts right now in the IETF that will SOON become RFC's on how to run transport foo over UDP. this seems to be a predominate thing now. IPv6 was not ready early thus we suffer nats.. and always will (see my previous response a few minutes ago to Julian)... If you would like I can go dig around in the drafts db and find a list for you of all the transports proposed UDP tunneling. All are pretty much the same, they reg a port.. and then just have the UDP header stripped off... I think this will become a common thing wanted I know its needed for both DCCP and SCTP now.. there are other transports coming behind that I am sure :-) R On Nov 19, 2008, at 5:50 PM, Bjoern A. Zeeb wrote: > On Wed, 19 Nov 2008, Randall Stewart wrote: > > Hi, > > [UDP tunneling of "foo"] > > I am not following this thread at all but the > transport_udp_input(mbuf, offset) > jumped into my eyes. > >> Not sure what netgraph does... what is wanted is this in comes >> >> +-----+ >> | IP | >> +-----+ >> | UDP | >> +-----+ > ... >> +-----+ >> >> Ideally it runs into UDP via ip_input() >> and comes down to where it would append() to the socket. >> >> What you want in this case is the whole mbuf chain to be sent >> to the transport_udp_input(m, offset) function >> >> This changes the above to >> +-----+ >> | IP | >> +-----+ > ... >> +-----+ >> >> And sends it into the transport_input() (same one called by >> ip_input). >> >> This then makes a clean and easy way to have "tunneled UDP" >> transport protocols >> work in kernel. The input side looks the same. Output is pretty >> easy.. easy to >> drop a UDP header in out output... > > > So I see things like this spring here and there and people start > introducing more hacks on top of hacks on top of hacks these days to > cicumvent dumb NAT setups. Right. No. > > So why the heck not use one of the dozend possibilities that you can > find on rfc-editor.org to encapsulate whatever you want into UDP in a > well defined protocol way rather than introducing yet another > UDP-encap for yet another protocol? > > Stuffing X into UDP means having a policy to identify the next ULP > possibly by port combinations, identify out of sequence data, identify > randomly forged pakets insert into your stream, fragemation, \ldots > \ldots \ldots possibly handshake all this first by the means of the > ULP, > \ldots \ldots \ldots reinventing the wheel over and over again. > > Ignore my 0.02CAD. > > /bz > > -- > Bjoern A. Zeeb > If you have a hammer, everything looks like a nail. > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 13:50:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B14C81065678 for ; Thu, 20 Nov 2008 13:50:33 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9368FC0C for ; Thu, 20 Nov 2008 13:50:32 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-067-236-069.pools.arcor-ip.net [88.67.236.69]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1L39vS31yv-0000Ic; Thu, 20 Nov 2008 14:50:31 +0100 Received: (qmail 86177 invoked from network); 20 Nov 2008 13:50:30 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by laiers.local with SMTP; 20 Nov 2008 13:50:30 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Thu, 20 Nov 2008 14:50:29 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> In-Reply-To: <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811201450.30016.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/pa2s+q3F8auTq4PnG5wTXZm9AMqm7nEVCfey mjtM7GzeyHOdvb1ye5hfPOJXze4mu7sInQYTdmemj8wo9Bp1Xp m9kCAiAKsP3EHjkg15Rzg== Cc: Randall Stewart , Julian Elischer Subject: Re: Thinking about UDP and tunneling 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, 20 Nov 2008 13:50:33 -0000 On Thursday 20 November 2008 14:00:11 Randall Stewart wrote: > On Nov 19, 2008, at 5:33 PM, Julian Elischer wrote: > >> Its not new, its the same ip header.. > >> Its just you go into the mbuf chain and take out > >> the udp header... > > > > well you can't do that at the socket buffer becasue you've discarded > > the IP header. It may not even be in the mbufs you have. (though it's > > unlikely). After you've processed the UDP part the IP part is gone so > > you'd need to intercept the packet way earlier and then do your > > own UDP processing, (or maybe attach the IP header onto it with a > > tag). > > One would definitely have to do some work in udp_input() not a lot from > what I can tell... but it would take some work. > > Maybe good course is to use the socket(9) stuff, but add an option > that can set a "by-pass function" if the socket is udp... right > after you establish the INP the packet goes to, if the function is > set, you engage the bypass... This sounds reasonable. One would only have to replace calls to udp_append in udp_input with the by-pass function et voila. Should be clean enough. There might be some problems with holding the socket lock, though. For the record, I don't like all the UDP-tunneling madness either, but it seems that we are stuck with it ... so we should at least try to come up with a somewhat reasonable implementation for this hackery. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 13:54:23 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51BB61065672 for ; Thu, 20 Nov 2008 13:54:23 +0000 (UTC) (envelope-from cole@opteqint.net) Received: from elektra.opteqint.net (elektra.opteqint.net [209.25.178.105]) by mx1.freebsd.org (Postfix) with ESMTP id 27E618FC08 for ; Thu, 20 Nov 2008 13:54:23 +0000 (UTC) (envelope-from cole@opteqint.net) Received: from [196.210.36.132] (helo=Jiraiya) by elektra.opteqint.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.66 (FreeBSD)) (envelope-from ) id 1L39zA-0005TM-4F for freebsd-net@freebsd.org; Thu, 20 Nov 2008 05:54:23 -0800 From: "Cole" To: References: <002f01c94af4$ecbced90$c636c8b0$@net> In-Reply-To: Date: Thu, 20 Nov 2008 15:54:12 +0200 Message-ID: <00a901c94b17$7c81eb70$7585c250$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLBpBSE5WPqc31TKKyKn/PgZwV0AAEAjvw Content-Language: en-za X-Spam-Score: -113.0 (---------------------------------------------------) X-Spam-Report: Spam detection software, running on the system "elektra.opteqint.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hi. The 10.10.7.1 is the FreeBSD box with the rl0 interface that gets added to a bridge. The 10.0.0.6 box is the other FreeBSD box. If you would like the same tcpdumps for any other OS pinging this box i would be glad to supply. [...] Content analysis details: (-113.0 points, 4.3 required) pts rule name description ---- ---------------------- -------------------------------------------------- -100 USER_IN_WHITELIST From: address is in the user's white-list -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -12 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.8 AWL AWL: From: address is in the auto white-list Subject: RE: FreeBSD Bridge and ARP question/strangeness 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, 20 Nov 2008 13:54:23 -0000 Hi. The 10.10.7.1 is the FreeBSD box with the rl0 interface that gets added to a bridge. The 10.0.0.6 box is the other FreeBSD box. If you would like the same tcpdumps for any other OS pinging this box i would be glad to supply. Heres the output from the tcpdump, this carries on as long as the ping from the freebsd box happens: 1227217832.867492 00:03:2d:0e:5b:69 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.0.0.6 tell 10.10.7.1 1227217832.867700 00:0c:f1:b6:ab:ca > 00:03:2d:0e:5b:69, ethertype ARP (0x0806), length 60: arp reply 10.0.0.6 is-at 00:0c:f1:b6:ab:ca 1227217833.868686 00:03:2d:0e:5b:69 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.0.0.6 tell 10.10.7.1 1227217833.868890 00:0c:f1:b6:ab:ca > 00:03:2d:0e:5b:69, ethertype ARP (0x0806), length 60: arp reply 10.0.0.6 is-at 00:0c:f1:b6:ab:ca 1227217834.869814 00:03:2d:0e:5b:69 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.0.0.6 tell 10.10.7.1 1227217834.869954 00:0c:f1:b6:ab:ca > 00:03:2d:0e:5b:69, ethertype ARP (0x0806), length 60: arp reply 10.0.0.6 is-at 00:0c:f1:b6:ab:ca 1227217835.871002 00:03:2d:0e:5b:69 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.0.0.6 tell 10.10.7.1 Heres the ifconfig for the box: rl0: flags=8943 metric 0 mtu 1500 options=8 ether 00:03:2d:0e:5b:69 inet 10.10.7.1 netmask 0xff000000 broadcast 10.255.255.255 media: Ethernet autoselect (100baseTX ) status: active rl1: flags=8802 metric 0 mtu 1500 options=8 ether 00:03:2d:0e:5b:68 media: Ethernet autoselect status: no carrier rl2: flags=8802 metric 0 mtu 1500 options=8 ether 00:03:2d:0e:5b:67 media: Ethernet autoselect status: no carrier rl3: flags=8843 metric 0 mtu 1500 options=8 ether 00:03:2d:0e:5b:66 media: Ethernet autoselect (none) status: no carrier pfsync0: flags=0<> metric 0 mtu 1460 syncpeer: 224.0.0.240 maxupd: 128 pflog0: flags=0<> metric 0 mtu 33204 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 bridge0: flags=8843 metric 0 mtu 1500 ether 00:03:2d:0e:5b:69 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: rl0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 200000 and the sysctl: net.link.bridge.ipfw: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 1 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_onlyip: 1 and heres the output from arp -na: ? (10.0.0.6) at (incomplete) on rl0 [ethernet] Regards /Cole -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Eygene Ryabinkin Sent: 20 November 2008 01:53 PM To: Cole Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD Bridge and ARP question/strangeness Cole, good day. Thu, Nov 20, 2008 at 11:46:42AM +0200, Cole wrote: > I have a box with a few interfaces, and i had setup rl0 with an ip > address and it could communicate/ping everything on the network fine, > all the rest of the other interfaces are unplugged and have no ip's > assigned. Now if i go ahead and create a bridge interface and then > just add that single interface with the ip assigned to it to the > bridge, without assigning a new ip to the bridge, i get some strange > things happening. Every box on the network not running FreeBSD is > still able to ping and receive a reply from the box on the ip it was > using on the interface. However, no FreeBSD box is now able to ping > the box at all. In the arp listing, it shows any of the FreeBSD boxes > that are trying to ping it as "(incomplete)". But for every other box > that isn't FreeBSD it gets a full arp listing and all those boxes are still able to communicate with the box fine. I think that the first thing to look at will be the tcpdump of the ARP traffic -- if your peers are seeing '(incomplete)' as the bridging host MAC, then it is good to check if ARP requests are received and are they replied to. 'tcpdump -lvvnetti rl0 arp' should produce the fine listing. And the output of 'ifconfig' and 'sysctl net.link.bridge' will be helpful too. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 15:50:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AFD81065673 for ; Thu, 20 Nov 2008 15:50:12 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0F0A88FC14 for ; Thu, 20 Nov 2008 15:50:11 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 274821C64A6; Thu, 20 Nov 2008 10:50:11 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 20 Nov 2008 10:50:11 -0500 X-Sasl-enc: YzT1+dOr1fI6blZk6NVa+lvhmqscc4QC/XC4EFxx+UOT 1227196210 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 ESMTPSA id A16A53021; Thu, 20 Nov 2008 10:50:10 -0500 (EST) Message-ID: <4925872E.1060401@incunabulum.net> Date: Thu, 20 Nov 2008 15:50:06 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: dikshie References: <910e60e80811200428u41eef8d6sa78582889b620efb@mail.gmail.com> In-Reply-To: <910e60e80811200428u41eef8d6sa78582889b620efb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: asm multicast ping 6.3 vs 7.1 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, 20 Nov 2008 15:50:12 -0000 dikshie wrote: > ... > both boxes has same ipv4 subnet and same ipv6 link. > 7.1 box has options MROUTING > 6.3 box does not has options MROUTING > Post ktrace output? Can you try building MROUTING as a module instead, load it in and see if you have the same result? From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 16:47:56 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77CDE106564A for ; Thu, 20 Nov 2008 16:47:56 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (grosbein.pp.ru [89.189.172.146]) by mx1.freebsd.org (Postfix) with ESMTP id D17788FC1D for ; Thu, 20 Nov 2008 16:47:54 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.3/8.14.3) with ESMTP id mAKGEfBN003595 for ; Thu, 20 Nov 2008 23:14:41 +0700 (KRAT) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.14.3/8.14.3/Submit) id mAKGEe7Z003594 for net@freebsd.org; Thu, 20 Nov 2008 23:14:40 +0700 (KRAT) (envelope-from eugen) Date: Thu, 20 Nov 2008 23:14:40 +0700 From: Eugene Grosbein To: net@freebsd.org Message-ID: <20081120161440.GA3537@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: jail translates destination IP? 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, 20 Nov 2008 16:47:56 -0000 Hi! For some strange reason, RAW sockets (when allowed) and TCP beheave very differently in jail (7.1-PRERELEASE). In host's rc.conf: jail_enable="YES" jail_list="test" jail_devfs_enable="YES" jail_test_rootdir="/mnt/big/jail/test" jail_test_hostname="myname.ru" jail_test_ip="192.168.0.1" jail_test_interface="lo0" "/etc/rc.d/jail start" does all right and I may rlogin into jail. In host environment I run tcpdump -np -i lo0. Inside jail I ping 127.0.0.1, it succeedes and tcpdump shows that requests go from 192.168.0.1 to 127.0.0.1 really. But when I try to telnet 127.0.0.1 25 from jail, tcpdump shows that TCP SYN are sent to 192.168.0.1, so telnet fails. There is no NAT here. It it a bug? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 17:37:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 781DF1065670 for ; Thu, 20 Nov 2008 17:37:53 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id ECD988FC0C for ; Thu, 20 Nov 2008 17:37:52 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [130.129.95.183] ([130.129.95.183]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mAKHbmwO034414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 20 Nov 2008 12:37:49 -0500 (EST) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1227202670; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=j136b1+oqHDDSLEWKb4+deq8PxQiNpwm5MWYXdIcLnymbboNG+L1IVO 1yuwj9BOprSO200Y4LC0cJ/TPyMFr6g== Message-Id: From: Randall Stewart To: Max Laier In-Reply-To: <200811201450.30016.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 12:37:47 -0500 References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: Thinking about UDP and tunneling 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, 20 Nov 2008 17:37:53 -0000 On Nov 20, 2008, at 8:50 AM, Max Laier wrote: > On Thursday 20 November 2008 14:00:11 Randall Stewart wrote: >> On Nov 19, 2008, at 5:33 PM, Julian Elischer wrote: >>>> Its not new, its the same ip header.. >>>> Its just you go into the mbuf chain and take out >>>> the udp header... >>> >>> well you can't do that at the socket buffer becasue you've discarded >>> the IP header. It may not even be in the mbufs you have. (though =20 >>> it's >>> unlikely). After you've processed the UDP part the IP part is gone =20= >>> so >>> you'd need to intercept the packet way earlier and then do your >>> own UDP processing, (or maybe attach the IP header onto it with a >>> tag). >> >> One would definitely have to do some work in udp_input() not a lot =20= >> from >> what I can tell... but it would take some work. >> >> Maybe good course is to use the socket(9) stuff, but add an option >> that can set a "by-pass function" if the socket is udp... right >> after you establish the INP the packet goes to, if the function is >> set, you engage the bypass... > > This sounds reasonable. One would only have to replace calls to =20 > udp_append in > udp_input with the by-pass function et voila. Should be clean =20 > enough. There > might be some problems with holding the socket lock, though. > > For the record, I don't like all the UDP-tunneling madness either, =20 > but it > seems that we are stuck with it ... so we should at least try to =20 > come up with > a somewhat reasonable implementation for this hackery. Max: This was along the lines of what I was thinking exactly.. one side note. I am told by my colleague in SCTP crime (Michael T=FCxen) that = Apple has this functional by-pass interface. He has already got the UDP =20 tunneling code working in the MAC version of our stack :-) I will start working on this when I get back from the IETF. I need to =20= finish up the NAT support stuff (almost done) and then I will start looking at the locking issues that this may bring... R > > > --=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 > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 18:42:02 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A9351065673 for ; Thu, 20 Nov 2008 18:42:02 +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 E52608FC0A for ; Thu, 20 Nov 2008 18:42:01 +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 CF7BC41C65F; Thu, 20 Nov 2008 19:25:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id x4y4zJSOYNPy; Thu, 20 Nov 2008 19:25:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 71FED41C65E; Thu, 20 Nov 2008 19:25:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7E0844448DD; Thu, 20 Nov 2008 18:23:57 +0000 (UTC) Date: Thu, 20 Nov 2008 18:23:56 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Eugene Grosbein In-Reply-To: <20081120161440.GA3537@grosbein.pp.ru> Message-ID: <20081120182035.H61259@maildrop.int.zabbadoz.net> References: <20081120161440.GA3537@grosbein.pp.ru> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-jail@freebsd.org, net@freebsd.org Subject: Re: jail translates destination IP? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-jail@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2008 18:42:02 -0000 On Thu, 20 Nov 2008, Eugene Grosbein wrote: Hi, freebsd-jail@ is a good place to ask jail questiosn as well. > For some strange reason, RAW sockets (when allowed) and TCP beheave > very differently in jail (7.1-PRERELEASE). In host's rc.conf: > > jail_enable="YES" > jail_list="test" > jail_devfs_enable="YES" > jail_test_rootdir="/mnt/big/jail/test" > jail_test_hostname="myname.ru" > jail_test_ip="192.168.0.1" > jail_test_interface="lo0" > > "/etc/rc.d/jail start" does all right and I may rlogin into jail. > > In host environment I run tcpdump -np -i lo0. > Inside jail I ping 127.0.0.1, it succeedes and tcpdump shows that requests > go from 192.168.0.1 to 127.0.0.1 really. But when I try to telnet 127.0.0.1 25 > from jail, tcpdump shows that TCP SYN are sent to 192.168.0.1, so telnet fails. > > There is no NAT here. It it a bug? What happens with TCP is the expected behaviour. I wonder more about the raw socket case and am not sure this is correct. jails try to "simulate" the non-existing loopback by re-writing the IPs to the jail-IP, which obviously has other implications. You should never be able to connect from inside the jail to the base systems 127.0.0.1 loopback IP. This is a known "feature" (limitation) of jails. Full network stack virtualization will no longer have that problem. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 22:42:06 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E84371065697; Thu, 20 Nov 2008 22:42:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BBC988FC0C; Thu, 20 Nov 2008 22:42:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAKMg6I9064668; Thu, 20 Nov 2008 22:42:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAKMg6o9064664; Thu, 20 Nov 2008 22:42:06 GMT (envelope-from linimon) Date: Thu, 20 Nov 2008 22:42:06 GMT Message-Id: <200811202242.mAKMg6o9064664@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/129022: [ath] ath cannot connect using WEP 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, 20 Nov 2008 22:42:07 -0000 Old Synopsis: ath cannot connect using WEP New Synopsis: [ath] ath cannot connect using WEP Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 20 22:41:44 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129022 From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 03:58:18 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FCE41065670 for ; Fri, 21 Nov 2008 03:58:18 +0000 (UTC) (envelope-from security@jim-liesl.org) Received: from smtp2.mc.surewest.net (qsmtp.mc.surewest.net [66.60.130.145]) by mx1.freebsd.org (Postfix) with SMTP id 4F9298FC1A for ; Fri, 21 Nov 2008 03:58:18 +0000 (UTC) (envelope-from security@jim-liesl.org) Received: (qmail 25602 invoked from network); 20 Nov 2008 19:58:02 -0800 Received: by simscan 1.1.0 ppid: 25599, pid: 25600, t: 0.0795s scanners: regex: 1.1.0 attach: 1.1.0 Received: from unknown (HELO smtp.jim-liesl.org) (66.60.173.44) by smtp2 with SMTP; 20 Nov 2008 19:58:02 -0800 Received: from smtp.jim-liesl.org (localhost.static.surewest.net [127.0.0.1]) by smtp.jim-liesl.org (Postfix) with ESMTP id 465AE5DBB; Thu, 20 Nov 2008 19:58:17 -0800 (PST) Received: from [IPv6:::1] (daemon.static.surewest.net [192.168.1.15]) by smtp.jim-liesl.org (Postfix) with ESMTP id BDD0B5DB8; Thu, 20 Nov 2008 19:58:16 -0800 (PST) Message-ID: <492631D7.30909@jim-liesl.org> Date: Thu, 20 Nov 2008 19:58:15 -0800 From: security User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, freebsd-ipfw@FreeBSD.ORG X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Subject: ipfw/dummynet question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2008 03:58:18 -0000 context is 7.1-beta2 I'm using a FreeBSD box as a router and IPFW/dummynet to simulate 3 WAN connections. The three networks are actually on the same lan, but have aliased ip's on the router's NIC (router on a stick). I've set up bi-directional pipes for each "net" that enforce various impairments. What I'm trying to do is have all traffic to or from "net-a" simulate a 30Mbit link, "net-b" a 20Mbit, and "net-c" a 10Mbit one. Traffic coming from elsewhere would not be touched until it was outbound for one of the 3 nets, and like wise, traffic coming from the 3 nets and going elsewhere would only be touched coming in. Traffic who's src and dst don't match at all would fall through. An example would be traffic from "net-a" going to "net-c" gets passed into the router like it's on a 30Mbit link, but heads out (after routing) like it's on a 10 Mbit link Question: Am I on the right path or have I made some stupid assumption(s)? I realize I have a few extra rules that could be optimized out, but this is probably good for the sake of readability. Another question, is each ip flow treated like it has it's own dedicated bw, or do all flows that match a pipe share the b/w ? thx jim (assume one_pass is set) ${fwcmd} add 10 skipto 100 ip from any to any in ${fwcmd} add 20 skipto 500 ip from any to any out ${fwcmd} add 100 pipe 1 ip from net-a to any ${fwcmd} add 200 pipe 2 ip from net-b to any ${fwcmd} add 300 pipe 3 ip from net-c to any ${fwcmd} add 400 skipto 65535 ip from any to any ${fwcmd} pipe 1 config bw 30Mbit/s ${fwcmd} pipe 2 config bw 20Mbit/s ${fwcmd} pipe 3 config bw 10Mbit/s ${fwcmd} add 500 pipe 4 ip from any to net-a ${fwcmd} add 600 pipe 5 ip from any to net-b ${fwcmd} add 700 pipe 6 ip from any to net-c ${fwcmd} pipe 4 config bw 30Mbit/s ${fwcmd} pipe 5 config bw 20Mbit/s ${fwcmd} pipe 6 config bw 10Mbit/s ${fwcmd} add 1000 skipto 65535 ip from any to any From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 12:10:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7A391065687; Fri, 21 Nov 2008 12:10:28 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 4A7388FC2A; Fri, 21 Nov 2008 12:10:28 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.100] ([172.21.151.2]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 13:10:25 +0100 Message-ID: <4926A520.9050400@dlr.de> Date: Fri, 21 Nov 2008 13:10:08 +0100 From: Hartmut Brandt User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Andre Oppermann References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> <4921B3C6.5020002@freebsd.org> <4921F2CD.503@freebsd.org> <20081119234543.A90462@beagle.kn.op.dlr.de> <49255D5B.5040303@freebsd.org> In-Reply-To: <49255D5B.5040303@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2008 12:10:25.0743 (UTC) FILETIME=[22E52DF0:01C94BD2] Cc: freebsd-net@freebsd.org, bz@freebsd.org, Harti Brandt , Rui Paulo Subject: Re: TCP and syncache question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2008 12:10:28 -0000 Andre Oppermann wrote: > Harti Brandt wrote: >> Hi Andre, >> >> On Mon, 17 Nov 2008, Andre Oppermann wrote: >> >> AO>This is a bit more complicated because of interactions with >> tcp_input() >> AO>where syncache_expand() is called from. >> AO> >> AO>The old code (as of December 2002) behaved slightly different. It >> would >> AO>not remove the syncache entry when (SND.UNA == SEG.ACK) but send a >> RST. >> AO>The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't >> done at >> AO>all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) >> succeeded. >> AO>This gave way to the "LAND" DoS attack which was mostly fixed with >> a test >> AO>for (RCV.IRS < SEG.SEQ). >> AO> >> AO>See the attached patch for fixed version of syncache_expand(). >> This patch >> AO>is untested though. My development machine is currently down. >> Harti, Rui >> AO>and Bjoern, please have a look at the patch and review it. >> >> Some small problems: > ... >> Need another cast here: *lsop = (struct socket *)1. > > Changed the logic to use a NULL *lsop to differentiate in tcp_input(). > Much simpler Indeed. But now the code sends a SYN+ACK with seqno == iss which is contrary to p.69 which requires ACK only and seqno == snd_nxt == iss + 1 (in our case). On the other hand one could point to the example on p. 33 (fig. 9), although it is not entirely clear from the figure whether the SYN in line 2 actually moves TCP B to SYN-RECEIVED. In any case I checked both our pre-syncache code and OpenSolaris and both of them seem to send only the ACK (I did not try it, just read the code). > . > >> [snip] >> >> I've re-run my test scripts and they seem to indicate, that the >> socket is >> now kept in the correct state when the incoming segment had an incorrect >> ack. I could no yet run the tests for an incorrect seqno, though. >> This is >> because there is an interesting problem in RFC793 (and MIL-STD-1778): >> the RFC >> states on page 36 a general rule that a 'reset (RST) must be sent >> whenever >> a segment arrives which apparently is not intended for the current >> connection.' > > The full quote from page 36 is: "As a general rule, reset (RST) must > be sent > whenever a segment arrives which apparently is not intended for the > current > connection. A reset must not be sent if it is not clear that this is > the case." > >> I would say, that a segment carrying a sequence number at irs (when >> without SYN) >> and below irs (in any case) cannot belong to the current connection - >> those >> sequence numbers just don't exist for the connection. On the other >> hand p.69 >> says that we must send an ACK. If this were an ITU-T standard, things >> would be clear, because the prosa description would be normative, not >> the >> algorithm. > > The more specific rule wins. Sending the "challenge" ACK is done > under the > assumption that the remote end will send a reset to our "challenge" > ACK if > such an connection doesn't exist there. Well, at least in the last pre-syncache revision (tcp_input.c rev. 1.142) there is the sequence number check on line 1580, that was introduced in rev. 1.81 to prevent the "land" attack, that sends an RST when th_seq <= irs. Confusingly enough that test is still there (now at line 1610) but, as far as I can see never reached (because of syncache). It also is th_seq < irs now for some reasons. harti From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 18:56:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25B8A1065675; Fri, 21 Nov 2008 18:56:46 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id AAAC98FC28; Fri, 21 Nov 2008 18:56:45 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.100] ([172.21.151.1]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 19:56:43 +0100 Message-ID: <4927045A.8020805@dlr.de> Date: Fri, 21 Nov 2008 19:56:26 +0100 From: Hartmut Brandt User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Andre Oppermann References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> <4921B3C6.5020002@freebsd.org> <4921F2CD.503@freebsd.org> <20081119234543.A90462@beagle.kn.op.dlr.de> <49255D5B.5040303@freebsd.org> In-Reply-To: <49255D5B.5040303@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2008 18:56:43.0642 (UTC) FILETIME=[E5415DA0:01C94C0A] Cc: freebsd-net@freebsd.org, bz@freebsd.org, Harti Brandt , Rui Paulo Subject: Re: TCP and syncache question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2008 18:56:46 -0000 Andre Oppermann wrote: > Harti Brandt wrote: >> Hi Andre, >> >> On Mon, 17 Nov 2008, Andre Oppermann wrote: >> >> AO>This is a bit more complicated because of interactions with >> tcp_input() >> AO>where syncache_expand() is called from. >> AO> >> AO>The old code (as of December 2002) behaved slightly different. It >> would >> AO>not remove the syncache entry when (SND.UNA == SEG.ACK) but send a >> RST. >> AO>The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't >> done at >> AO>all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) >> succeeded. >> AO>This gave way to the "LAND" DoS attack which was mostly fixed with >> a test >> AO>for (RCV.IRS < SEG.SEQ). >> AO> >> AO>See the attached patch for fixed version of syncache_expand(). >> This patch >> AO>is untested though. My development machine is currently down. >> Harti, Rui >> AO>and Bjoern, please have a look at the patch and review it. >> >> Some small problems: > ... >> Need another cast here: *lsop = (struct socket *)1. > > Changed the logic to use a NULL *lsop to differentiate in tcp_input(). > Much simpler. Turns out there is a bug in the patch: after the call to syncache_lookup() at test sc == NULL is made and if sc == NULL and may goto sendrst: sendrst: if (sc != &scs) syncache_free(sc); Here syncache_free panics because of the NULL passed to it. I suppose both gotos under the if() should go to sendrstkeep instead. harti From owner-freebsd-net@FreeBSD.ORG Sat Nov 22 13:31:31 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B56B1065677; Sat, 22 Nov 2008 13:31:31 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 591508FC28; Sat, 22 Nov 2008 13:31:31 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAMDVV0X081291; Sat, 22 Nov 2008 13:31:31 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAMDVVtU081287; Sat, 22 Nov 2008 13:31:31 GMT (envelope-from remko) Date: Sat, 22 Nov 2008 13:31:31 GMT Message-Id: <200811221331.mAMDVVtU081287@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: i386/128917: if_wpi and wpa+tkip causing kernel panic 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, 22 Nov 2008 13:31:31 -0000 Synopsis: if_wpi and wpa+tkip causing kernel panic Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sat Nov 22 13:31:30 UTC 2008 Responsible-Changed-Why: This is a networking item http://www.freebsd.org/cgi/query-pr.cgi?pr=128917 From owner-freebsd-net@FreeBSD.ORG Sat Nov 22 22:42:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83DBD1065674 for ; Sat, 22 Nov 2008 22:42:22 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 0CE3C8FC1B for ; Sat, 22 Nov 2008 22:42:21 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id mAMMUo61005091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Nov 2008 23:30:50 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id mAMMUlC3080190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Nov 2008 23:30:47 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id mAMMUlKJ040972; Sat, 22 Nov 2008 23:30:47 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id mAMMUkLD040971; Sat, 22 Nov 2008 23:30:46 +0100 (CET) (envelope-from ticso) Date: Sat, 22 Nov 2008 23:30:46 +0100 From: Bernd Walter To: Bruce M Simpson Message-ID: <20081122223046.GE40650@cicely7.cicely.de> References: <48EBB3D6.600@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48EBB3D6.600@incunabulum.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.064, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-net@freebsd.org Subject: Re: How to support an Ethernet PHY without ID registers? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2008 22:42:22 -0000 On Tue, Oct 07, 2008 at 08:09:10PM +0100, Bruce M Simpson wrote: > Hi, > > I have been trying to get FreeBSD onto the Freecom FSG3 Storage Gateway. > It is an xScale based ARM system. > > Whilst the npe(4) driver appears to attach, the PHY does not. It is a > Realtel RTL8305SB switch chip in dual miibus mode. Unfortunately the > RTL8305SB does not have ID registers. The RTL8305SC does, but it's a > totally different chip. > > We do have a driver in the tree for the RTL8305SC, however these chips > are different enough for this to cause problems. > > Is there any way I could for example force ukphy(4) to attach? A late response... rlswitch is there for two reasons: forcing speed independed of port0 autoselect and setting VLAN (using hardcoded values though). I never worked with the SB, but read the datasheet a while back before I ordered the SC for my project. IIRC the SB has no VLAN support. Not sure about registers - maybe it really hasn't any or MDIO isn't connected with your hardware. I would suggest that you localy patch the rlswitch driver to always attach and be done with it. ukphy would try to read link parameters, which will fail and report wrong speed - MII speed of course is always 100/FDX. > Note: Because there are no ID registers, mii_phy_probe_gen() WILL NOT > work. It looks like I'd have to override this by hacking if_npe.c > itself. Can anyone clarify? This is possible as well, you can patch if_npe.c to return faked phy register values. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.