From owner-freebsd-net Sun Feb 4 1:52: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 2524B37B401 for ; Sun, 4 Feb 2001 01:51:44 -0800 (PST) Received: (qmail 16129 invoked by uid 666); 4 Feb 2001 09:59:33 -0000 Received: from reggae-18-28.nv.iinet.net.au (HELO elischer.org) (203.59.80.28) by mail.m.iinet.net.au with SMTP; 4 Feb 2001 09:59:33 -0000 Message-ID: <3A7D2610.E2CD1AD0@elischer.org> Date: Sun, 04 Feb 2001 01:51:12 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Rich Wales Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: BRIDGE breaks ARP? (more info) References: <20010204062837.94849.richw@wyattearp.stanford.edu> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Rich Wales wrote: > > Earlier, I reported an ARP problem on a 4.2-STABLE bridge system. > > A few people wrote me privately, advising me to include a firewall > rule passing UDP packets on port 2054 to/from the IP address 0.0.0.0. > > I've tried this, but it doesn't help any. I should mention, though, > that I don't think this firewall rule is relevant in any case. > > First, the "port 2054" kludge doesn't appear to be in the networking > code any more. I grep'ed the entire -STABLE base source for any > references to UDP port 2054, and I found nothing at all except for > the commented-out line in the etc/rc.firewall file. As far as I'm > aware, bridging of non-IP packets is now controlled by the kernel's > default "ipfw" rule -- and, yes, I do have the options IPFIREWALL > and IPFIREWALL_DEFAULT_TO_ACCEPT in my configuration. > > Second, I'm not talking about bridging of ARP packets anyway. I'm > trying to connect directly to the bridge machine -- but the bridge > is failing to respond to requests for its own hardware address on > its "rl0" interface. try using netgraph bridging instead. > > Rich Wales richw@webcom.com http://www.webcom.com/richw/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 6:43:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id 2292B37B401; Sun, 4 Feb 2001 06:43:16 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id GAA03077; Sun, 4 Feb 2001 06:42:37 -0800 (PST) (envelope-from richw) Date: Sun, 4 Feb 2001 06:42:37 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Julian Elischer Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: BRIDGE breaks ARP? (more info) In-Reply-To: <3A7D2610.E2CD1AD0@elischer.org> Message-ID: <20010204143346.02926.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer wrote: > try using netgraph bridging instead. Can't do this until the netgraph code supports ipfirewall or ipfilter. Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 7:29:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from hera.drwilco.net (10dyn26.dh.casema.net [212.64.31.26]) by hub.freebsd.org (Postfix) with ESMTP id 3905637B401; Sun, 4 Feb 2001 07:29:22 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f14Fpbb69208; Sun, 4 Feb 2001 16:51:41 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010204160340.00afe240@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 04 Feb 2001 16:12:17 +0100 To: Rich Wales , freebsd-net@FreeBSD.ORG From: "Rogier R. Mulhuijzen" Subject: Re: BRIDGE breaks ARP? Cc: freebsd-stable@FreeBSD.ORG In-Reply-To: <20010203220223.86591.richw@wyattearp.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 14:26 3-2-01 -0800, Rich Wales wrote: >I'm running -STABLE (cvsup'ed on 26jan2001) on a machine with the >BRIDGE option, bridging between two PCI NICs (rl0 and xl0). > >I'm having ARP problems. Machines on the "rl0" card are unable to >get a hardware address for the bridge. (For whatever reason, I have >no problems talking via the "xl0" interface.) > >I've done "tcpdump" on the bridge, and it's receiving ARP queries on >the "rl0" interface, but it doesn't appear to be sending replies. I >did a "tcpdump" on the "xl0" interface too, just in case ARP replies >were going out over the wrong interface, but no such luck. Are you using different IP addresses on both NICs? and If so can machines on rl0 get the MAC for xl0? and can machines on xl0 get the MAC for rl0? Can you include the output of 'tcpdump arp' for both interfaces while doing these cross tests? >If I turn off bridging (sysctl -w net.link.ether.bridge=0), the ARP >problem quickly resolves itself. So the problem would seem to be >related somehow to the bridge code. > >I can sidestep the problem by using "arp -s" commands on the other >machines to tell them the bridge's hardware address -- but I really >shouldn't have to do this. You got that right >Any ideas? Been digging in that code the past week, so when I'm done with some stuff for work I can try and track it down. Can you include a kernel config and dmesg output. Greets, DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 7:55:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0C1C737B4EC; Sun, 4 Feb 2001 07:54:56 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f14Fsdh70888; Sun, 4 Feb 2001 10:54:39 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 4 Feb 2001 10:54:39 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: cjclark@alum.mit.edu Cc: Rich Wales , freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? In-Reply-To: <20010203153917.I91447@rfx-216-196-73-168.users.reflex> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 3 Feb 2001, Crist J. Clark wrote: > Not all cards support bridging. The bridge(4) manpage _used to_ have a > list of cards that work. Now all it says is, > > "Interfaces that cannot be put into promiscuous mode or that don't support > sending packets with arbitrary Ethernet source addresses are not compati- > ble with bridging." > > And I have not been able to figure out if the rl(4) device satisfies > those conditions. I should note that rl(4) was not on the list of > working cards prior to the change in the manpage. > > Maybe someone who knows more about the rl(4) driver can elaborate? I may be wrong here, but my understanding was that Archie's work a few months ago to abstract the BPF and BRIDGE behavior into ether_input() rather than in device-specific code was intended to make both BPF and BRIDGE work for all interfaces without special work. It appears that those changes are present in the RELENG_4 branch. This prompted the removal of the per-interface "works and doesn't work" comment in the man page. The replacement comment, I think, specifically refers to the wavelan cards from Lucent, as those apparently don't like sending out packets with a MAC address other than the one shipped with the card (or at least, in the form expected by BRIDGE. I would guess that most ISA and PCI ethernet cards on the market due permit the sending of packets with other MAC addresses than shipped with. Therefore, I would assume (and possibly incorrectly) that BRIDGE would work in the rl cards. This, mind you, is without practical experience with the rl cards. Recently a number of changes (labeled as fixes) were committed to the BRIDGE code. It may be that you want to slide back to before the changes if you're using the code after them, or vice versa. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 7:59:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0B2B737B4EC; Sun, 4 Feb 2001 07:59:31 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f14FxTh70923; Sun, 4 Feb 2001 10:59:29 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 4 Feb 2001 10:59:29 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Rich Wales Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: BRIDGE breaks ARP? (more info) In-Reply-To: <20010204062837.94849.richw@wyattearp.stanford.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 3 Feb 2001, Rich Wales wrote: > Earlier, I reported an ARP problem on a 4.2-STABLE bridge system. > > A few people wrote me privately, advising me to include a firewall rule > passing UDP packets on port 2054 to/from the IP address 0.0.0.0. > > I've tried this, but it doesn't help any. I should mention, though, > that I don't think this firewall rule is relevant in any case. > > First, the "port 2054" kludge doesn't appear to be in the networking > code any more. I grep'ed the entire -STABLE base source for any > references to UDP port 2054, and I found nothing at all except for the > commented-out line in the etc/rc.firewall file. As far as I'm aware, > bridging of non-IP packets is now controlled by the kernel's default > "ipfw" rule -- and, yes, I do have the options IPFIREWALL and > IPFIREWALL_DEFAULT_TO_ACCEPT in my configuration. There used to be a kludge that mapped the ether_header.ether_type field of non-IP packets into the UDP port number for the purposes of certain IPFW rules when bridging. This was pretty awful. :-) That kludge was removed, and the BRIDGE code now simply forwards all non-IP packets, including ARP, and does not pass them through IPFW when IPFW is enabled, making them follow the equivilent of a default pass rule. This is a kludge that I am glad to see go: I can certainly imagine the desire to support non-IP filtering in a bridge, but IPFW was not the right vehicle for that. I believe the removal of the kludge occurred along with Archie's other fixups around Jun 21, 2000, which was certainly prior to 4.2-RELEASE. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 8:28: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id AFD1F37B4EC; Sun, 4 Feb 2001 08:27:20 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id IAA05293; Sun, 4 Feb 2001 08:26:52 -0800 (PST) (envelope-from richw) Date: Sun, 4 Feb 2001 08:26:52 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: "Rogier R. Mulhuijzen" Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? In-Reply-To: <4.3.2.7.0.20010204160340.00afe240@mail.bsdchicks.com> Message-ID: <20010204161742.04832.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Rogier R. Mulhuijzen wrote: > Are you using different IP addresses on both NICs? And if so, > can machines on rl0 get the MAC for xl0? And can machines on > xl0 get the MAC for rl0? No, I'm using only one IP address for the bridged pair of NICs. (The IP address is assigned via "ifconfig rl0".) > Can you include the output of 'tcpdump arp' for both interfaces > while doing these cross tests? I'll have to redo my earlier tests and send the results sometime later. From what I remember, though, the bridge machine saw lots of queries ("arp who-has"), but it didn't send out a reply right away. Sometimes, after several minutes, a reply did get sent out, but I have no idea why this happened or what provoked the machine to finally get around to sending an ARP reply. > Been digging in that code the past week, so when I'm done with > some stuff for work I can try and track it down. Can you include > a kernel config and dmesg output? OK. See below. Rich Wales richw@webcom.com http://www.webcom.com/richw/ ======================================================================== # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.20 2000/10/31 23:16:07 n_hibma Exp $ machine i386 #cpu I386_CPU #cpu I486_CPU cpu I586_CPU cpu I686_CPU ident GATEWAY maxusers 32 makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking #options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=10000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM #Rate limit bad replies options KBD_INSTALL_CDEV # install a CDEV entry in /dev # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O device isa device eisa device pci # Floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 # ATA and ATAPI devices device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering options ATA_ENABLE_ATAPI_DMA #Enable DMA on ATAPI devices # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices device amd # AMD 53C974 (Teckram DC-390(T)) device isp # Qlogic family device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets) options SYM_SETUP_LP_PROBE_MAP=0x40 # Allow ncr to attach legacy NCR devices when # both sym and ncr are configured device adv0 at isa? device adw device bt0 at isa? device aha0 at isa? device aic0 at isa? device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) # RAID controllers interfaced to the SCSI subsystem device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device dpt # DPT Smartcache - See LINT for options! device mly # Mylex AcceleRAID/eXtremeRAID # RAID controllers device ida # Compaq Smart RAID device amr # AMI MegaRAID device mlx # Mylex DAC960 family device twe # 3ware Escalade # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0 at atkbdc? irq 12 device vga0 at isa? # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? flags 0x100 # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 # Power management support (see LINT for more options) #device apm0 at nexus? disable flags 0x20 # Advanced Power Management # PCCARD (PCMCIA) support #device card #device pcic0 at isa? irq 0 port 0x3e0 iomem 0xd0000 #device pcic1 at isa? irq 0 port 0x3e2 iomem 0xd4000 disable # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 #device sio2 at isa? disable port IO_COM3 irq 5 #device sio3 at isa? disable port IO_COM4 irq 9 # Parallel port device ppc0 at isa? irq 7 device ppbus # Parallel port bus (required) device lpt # Printer #device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device fxp # Intel EtherExpress PRO/100B (82557, 82558) device tx # SMC 9432TX (83c170 ``EPIC'') device vx # 3Com 3c590, 3c595 (``Vortex'') device wx # Intel Gigabit Ethernet Card (``Wiseman'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device dc # DEC/Intel 21143 and various workalikes device pcn # AMD Am79C79x PCI 10/100 NICs device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device ste # Sundance ST201 (D-Link DFE-550TX) device tl # Texas Instruments ThunderLAN device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. device ed0 at isa? port 0x280 irq 10 iomem 0xd8000 #device ex #device ep #device fe0 at isa? port 0x300 # WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really # exists only as a PCMCIA device, so there is no ISA attatement needed # and resources will always be dynamically assigned by the pccard code. #device wi # Aironet 4500/4800 802.11 wireless NICs. Note: the declaration below will # work for PCMCIA and PCI cards, as well as ISA cards set to ISA PnP # mode (the factory default). If you set the switches on your ISA # card for a manually chosen I/O address and IRQ, you must specify # those paremeters here. #device an # Xircom Ethernet #device xe # The probe order of these is presently determined by i386/isa/isa_compat.c. device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 #device le0 at isa? port 0x300 irq 5 iomem 0xd0000 #device lnc0 at isa? port 0x280 irq 10 drq 0 #device cs0 at isa? port 0x300 #device sn0 at isa? port 0x300 irq 10 # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support #pseudo-device sl 1 # Kernel SLIP #pseudo-device ppp 1 # Kernel PPP pseudo-device tun # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device md # Memory "disks" #pseudo-device gif 4 # IPv6 and IPv4 tunneling #pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf 16 #Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device usb # USB Bus (required) #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device uscanner # Scanners # USB Ethernet, requires mii #device aue # ADMtek USB ethernet #device cue # CATC USB ethernet #device kue # Kawasaki LSI USB ethernet options INCLUDE_CONFIG_FILE # Include this file in kernel #device pcm #device sbc0 at isa? port 0x220 irq 5 drq 1 flags 0x15 device snd device pas0 at isa? port 0x388 irq 10 drq 6 device sb0 at isa? port 0x220 irq 5 drq 1 #device sbxvi0 at isa? drq 5 #device sbmidi0 at isa? port 0x330 options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about # dropped packets options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPDIVERT #divert sockets #options IPFILTER #ipfilter support #options IPFILTER_LOG #ipfilter logging options IPSTEALTH #support for stealth forwarding options SC_HISTORY_SIZE=600 # number of history buffer lines options CONSPEED=115200 #default speed for serial console #options DUMMYNET options BRIDGE #options DDB_UNATTENDED options DDB options KTRACE options INVARIANTS options INVARIANT_SUPPORT options DIAGNOSTIC options COMPAT_LINUX options DEBUG_LINUX ======================================================================== Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.2-STABLE #0: Fri Feb 2 13:20:42 PST 2001 richw@gateway.richw.org:/big/4.2/usr/obj/big/4.2/usr/STABLE/src/sys/GATEWAY Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 233864518 Hz CPU: Pentium/P55C (233.86-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bf real memory = 25165824 (24576K bytes) avail memory = 20529152 (20048K bytes) Preloaded elf kernel "kernel" at 0xc03f6000. Intel Pentium detected, installing workaround for F00F bug md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0xe000-0xe00f at device 1.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 1.2 chip1: port 0xe800-0xe80f at device 1.3 on pci0 ed0: port 0xd400-0xd41f irq 9 at device 9.0 on pci0 ed0: address 00:80:48:c6:1d:ec, type NE2000 (16 bit) pcn0: port 0xd000-0xd01f mem 0xe7000000-0xe700001f irq 9 at device 10.0 on pci0 pcn0: Ethernet address: 00:20:78:b1:74:4a miibus0: on pcn0 pnaphy0: on miibus0 pnaphy0: HomePNA xl0: <3Com 3c900-TPO Etherlink XL> port 0xb800-0xb83f irq 12 at device 11.0 on pci0 xl0: Ethernet address: 00:60:97:05:32:cd xl0: selecting 10baseT transceiver, half duplex rl0: port 0xb400-0xb4ff mem 0xe6800000-0xe68000ff irq 11 at device 12.0 on pci0 rl0: Ethernet address: 00:e0:29:68:64:3e miibus1: on rl0 rlphy0: on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: MLC,PCL,PML lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pas0 at port 0x388 irq 10 drq 6 on isa0 snd0: pas0: driver is using old-style compatability shims sb0 at port 0x220 irq 5 drq 1 on isa0 snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] sb0: driver is using old-style compatability shims IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, unlimited logging BRIDGE 990810, have 5 interfaces -- index 1 type 6 phy 0 addrl 6 addr 00.80.48.c6.1d.ec -- index 2 type 6 phy 0 addrl 6 addr 00.20.78.b1.74.4a -- index 3 type 6 phy 0 addrl 6 addr 00.60.97.05.32.cd -- index 4 type 6 phy 0 addrl 6 addr 00.e0.29.68.64.3e ad0: 17418MB [35390/16/63] at ata0-master UDMA33 acd0: CDROM at ata1-master using UDMA33 Mounting root from ufs:/dev/ad0s2a -- match beg(3) p <1,xl0:1,pcn0:2,ed0:2,> --++ found rl0:1 -- match beg(3) p <1,pcn0:2,ed0:2,> --++ found xl0:1 -- match beg(4) p <2,ed0:2,> --++ found pcn0:2 -- match beg(3) p <2,> --++ found ed0:2 >> now ed0 promisc ON if_flags 0xffff8943 bdg_flags 0x5 >> now pcn0 promisc ON if_flags 0xffff8943 bdg_flags 0x5 >> now xl0 promisc ON if_flags 0xffff8943 bdg_flags 0x5 >> now rl0 promisc ON if_flags 0xffff8943 bdg_flags 0x5 ======================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 8:35:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id 6DD0637B401; Sun, 4 Feb 2001 08:35:10 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id IAA05523; Sun, 4 Feb 2001 08:35:00 -0800 (PST) (envelope-from richw) Date: Sun, 4 Feb 2001 08:35:00 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Robert Watson Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: BRIDGE breaks ARP? (more info) In-Reply-To: Message-ID: <20010204162724.04832.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson wrote: > There used to be a kludge that mapped the ether_header.ether_type > field of non-IP packets into the UDP port number for the purposes > of certain IPFW rules when bridging. This was pretty awful. :-) I should add something else. My bridge =does= pass ARP info between the two bridged NIC's. Thus, for example, a machine on the "rl0" side of the bridge can successfully use a default Internet gateway which is on the "xl0" side of the bridge (and "arp -a" on the rl0-side machine shows the hardware address of the xl0-side gateway). So the problem doesn't seem to have anything to do with ARP bridging. Even though ARP packets are being passed through the bridge, the bridge itself doesn't reply to ARP requests asking it for its own MAC address. (Or, to be more precise, it sometimes does send out ARP replies, but only sporadically and unpredictably.) Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 8:47:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3B05937B401; Sun, 4 Feb 2001 08:47:25 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f14GlLh71256; Sun, 4 Feb 2001 11:47:22 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 4 Feb 2001 11:47:21 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Rich Wales Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: BRIDGE breaks ARP? In-Reply-To: <20010203220223.86591.richw@wyattearp.stanford.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 3 Feb 2001, Rich Wales wrote: > I'm running -STABLE (cvsup'ed on 26jan2001) on a machine with the BRIDGE > option, bridging between two PCI NICs (rl0 and xl0). > > I'm having ARP problems. Machines on the "rl0" card are unable to get a > hardware address for the bridge. (For whatever reason, I have no > problems talking via the "xl0" interface.) > > I've done "tcpdump" on the bridge, and it's receiving ARP queries on the > "rl0" interface, but it doesn't appear to be sending replies. I did a > "tcpdump" on the "xl0" interface too, just in case ARP replies were > going out over the wrong interface, but no such luck. > > If I turn off bridging (sysctl -w net.link.ether.bridge=0), the ARP > problem quickly resolves itself. So the problem would seem to be > related somehow to the bridge code. > > I can sidestep the problem by using "arp -s" commands on the other > machines to tell them the bridge's hardware address -- but I really > shouldn't have to do this. So at one point I was experimenting with userland bridging software based on BPF, and supported that through an additional option I added to BPF, BIOCSSEESENT. Normally, BPF will provide access to both ethernet packets that come off the wire, and those that are locally sourced. Toggling off BIOCSSEESENT causes BPF to not push looped back ethernet packets into the BPF device -- this is determined by looking at the ifnet (interface) pointer in the mbuf for the packet. This allowed the userland software to simply open a BPF device for each interface desired, and then to propagate any packets received on any BPF device to all other bridged BPF devices, optionally with filtering (which was the real goal of the exercise, I wanted to work with bridged filtering without hacking up the kernel). An interesting side effect of this was that locally sourced packets that came out of the IP stack would not be bridged, as they would have a NULL source interface (this is because most ethernet cards do not deliver locally sourced packets back in the interface, so we rely on a software loopback to provide this service, which in turn doesn't set the interface pointer, I believe -- both convenient and inconvenient). So when the bridge was in operation, nodes on either side of the bridge could talk to each other just fine, but not to the bridge *unless* they were talking to the bridge on an IP address configured on the interface on their side of the bridge. Due to limitations in our IP stack and routing code, it's not possible to bind two identical subnet address/masks to two different interfaces, meaning that in effect, unless I used different subnets for both interfaces in the bridge, only one set of hosts could communicate with the bridge. So my question for you is, does this behavior sound like something you're experiencing: if you have the bridge ping the broadcast address on the side of the bridge where the IP address is configured on the interface, does packet sniffing on the other side see the bridged packets? If you configure the IP address on the other interface, does ARPing the bridge host from that side work? I.e., do you see behavior where the bridge is only IP-reachable from one side of the bridge, and not the other? This might suggest a problem with bridging of software-looped back packets, possibly specific to the interfaces you're using. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 9:44:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts6-srv.bellnexxia.net (tomts6.bellnexxia.net [209.226.175.26]) by hub.freebsd.org (Postfix) with ESMTP id 9338F37B4EC; Sun, 4 Feb 2001 09:44:20 -0800 (PST) Received: from johnny2k ([64.229.39.50]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010204174419.KTYP21723.tomts6-srv.bellnexxia.net@johnny2k>; Sun, 4 Feb 2001 12:44:19 -0500 Message-ID: <000501c08ed2$2e1c5920$3227e540@johnny2k> From: "John Telford" To: Cc: Subject: Firewalling a PPPoE, any easy workaround to MTU on lan stations ? Date: Sun, 4 Feb 2001 12:44:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm putting a 4.2 R firewall in for a ppoe connection. (sympatico) Is there any workaround I can use so I don't have to reduce the MTU on all the internal stations ? It's a mix of Windows 9x and Macs. And I've found only one utility capable of adjusting MTU on Macs. Can anything be done on the freebsd box as the traffic goes through it ? Thanks in advance, John. P.S. the pppoe setup went fine thanks to a page at www.sympaticousers.org and some further notes at www.freebsddiary.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 10:16:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from hera.drwilco.net (10dyn100.dh.casema.net [212.64.31.100]) by hub.freebsd.org (Postfix) with ESMTP id D379337B69D; Sun, 4 Feb 2001 10:15:53 -0800 (PST) Received: from ceres.drwilco.net (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.2/8.11.1) with ESMTP id f14Icco00219; Sun, 4 Feb 2001 19:38:41 +0100 (CET) (envelope-from drwilco@drwilco.net) Message-Id: <4.3.2.7.0.20010204182315.00ce8100@mail.drwilco.net> X-Sender: drwilco@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 04 Feb 2001 18:30:36 +0100 To: Rich Wales From: "Rogier R. Mulhuijzen" Subject: Re: BRIDGE breaks ARP? Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG In-Reply-To: <20010204161742.04832.richw@wyattearp.stanford.edu> References: <4.3.2.7.0.20010204160340.00afe240@mail.bsdchicks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >ed0: port 0xd400-0xd41f irq 9 at device 9.0 >on pci0 >ed0: address 00:80:48:c6:1d:ec, type NE2000 (16 bit) >pcn0: port 0xd000-0xd01f mem >0xe7000000-0xe700001f irq 9 at device 10.0 on pci0 >pcn0: Ethernet address: 00:20:78:b1:74:4a >xl0: <3Com 3c900-TPO Etherlink XL> port 0xb800-0xb83f irq 12 at device >11.0 on pci0 >xl0: Ethernet address: 00:60:97:05:32:cd >xl0: selecting 10baseT transceiver, half duplex >rl0: port 0xb400-0xb4ff mem >0xe6800000-0xe68000ff irq 11 at device 12.0 on pci0 >rl0: Ethernet address: 00:e0:29:68:64:3e >BRIDGE 990810, have 5 interfaces >-- index 1 type 6 phy 0 addrl 6 addr 00.80.48.c6.1d.ec >-- index 2 type 6 phy 0 addrl 6 addr 00.20.78.b1.74.4a >-- index 3 type 6 phy 0 addrl 6 addr 00.60.97.05.32.cd >-- index 4 type 6 phy 0 addrl 6 addr 00.e0.29.68.64.3e >-- match beg(3) p <1,xl0:1,pcn0:2,ed0:2,> >--++ found rl0:1 >-- match beg(3) p <1,pcn0:2,ed0:2,> >--++ found xl0:1 >-- match beg(4) p <2,ed0:2,> >--++ found pcn0:2 >-- match beg(3) p <2,> >--++ found ed0:2 > >> now ed0 promisc ON if_flags 0xffff8943 bdg_flags 0x5 > >> now pcn0 promisc ON if_flags 0xffff8943 bdg_flags 0x5 > >> now xl0 promisc ON if_flags 0xffff8943 bdg_flags 0x5 > >> now rl0 promisc ON if_flags 0xffff8943 bdg_flags 0x5 Interesting. 4 interfaces in 2 clusters. Do you have the same problem in the 2nd cluster? Do you have the same problem without clustering? I.E. make the bridge do all 4 interfaces at once. What happens when you assign the IP to xl0 instead of rl0? Just some things you can try that might give us some more info. DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 11:23:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 5DA1D37B4EC for ; Sun, 4 Feb 2001 11:23:00 -0800 (PST) Received: (qmail 11875 invoked by uid 666); 4 Feb 2001 19:30:47 -0000 Received: from reggae-02-40.nv.iinet.net.au (HELO elischer.org) (203.59.91.40) by mail.m.iinet.net.au with SMTP; 4 Feb 2001 19:30:47 -0000 Message-ID: <3A7D9DE0.CE10C046@elischer.org> Date: Sun, 04 Feb 2001 10:22:24 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: John Telford Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Firewalling a PPPoE, any easy workaround to MTU on lan stations ? References: <000501c08ed2$2e1c5920$3227e540@johnny2k> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Telford wrote: > > I'm putting a 4.2 R firewall in for a ppoe connection. (sympatico) > Is there any workaround I can use so I don't have to reduce the MTU on all > the internal stations ? > It's a mix of Windows 9x and Macs. And I've found only one utility capable > of adjusting MTU on Macs. > Can anything be done on the freebsd box as the traffic goes through it ? > Thanks in advance, John. > P.S. the pppoe setup went fine thanks to a page at www.sympaticousers.org > and some further notes at www.freebsddiary.org ppp now has an option where it will force the negotiated packet size of new tcp sessions going through it down. (i.e it fiddles with the packets) check the man page.. I THINK it may be in 4.2, if not it's in -Stable > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 12:14:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from hera.drwilco.net (10dyn100.dh.casema.net [212.64.31.100]) by hub.freebsd.org (Postfix) with ESMTP id C064537B4EC; Sun, 4 Feb 2001 12:14:31 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.2/8.11.1) with ESMTP id f14Kamo00473; Sun, 4 Feb 2001 21:36:55 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010204201824.00bd33c0@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 04 Feb 2001 20:20:37 +0100 To: Julian Elischer , John Telford From: "Rogier R. Mulhuijzen" Subject: Re: Firewalling a PPPoE, any easy workaround to MTU on lan stations ? Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG In-Reply-To: <3A7D9DE0.CE10C046@elischer.org> References: <000501c08ed2$2e1c5920$3227e540@johnny2k> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:22 4-2-01 -0800, Julian Elischer wrote: >John Telford wrote: > > > > I'm putting a 4.2 R firewall in for a ppoe connection. (sympatico) > > Is there any workaround I can use so I don't have to reduce the MTU on all > > the internal stations ? > > It's a mix of Windows 9x and Macs. And I've found only one utility capable > > of adjusting MTU on Macs. > > Can anything be done on the freebsd box as the traffic goes through it ? > > Thanks in advance, John. > > P.S. the pppoe setup went fine thanks to a page at www.sympaticousers.org > > and some further notes at www.freebsddiary.org > > >ppp now has an option where it will force the negotiated packet size >of new tcp sessions going through it down. (i.e it fiddles with the packets) >check the man page.. I THINK it may be in 4.2, if not it's in -Stable Actually, I have just been playing with this. Userland ppp has the 'set mtu' command which will make ppp try and set that MTU at negotiation time. That's on a 4.2-STABLE box. DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 14:26:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from gecko.eric.net.au (gecko.eric.net.au [203.102.228.3]) by hub.freebsd.org (Postfix) with ESMTP id 5B95837B491 for ; Sun, 4 Feb 2001 14:26:27 -0800 (PST) Received: (from ghcrompton@localhost) by gecko.eric.net.au (8.9.3/8.8.7) id JAA26878; Mon, 5 Feb 2001 09:30:55 +1100 Date: Mon, 5 Feb 2001 09:30:54 +1100 From: "Geoffrey Crompton (RMIT Guest)" To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: pseudo interface and ioctls Message-ID: <20010205093054.A26854@gecko.eric.net.au> References: <20010201103716.A23667@gecko.eric.net.au> <3A791528.BC4593E2@elischer.org> <20010202092233.A986@gecko.eric.net.au> <3A7A8AA5.625ADA@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <3A7A8AA5.625ADA@elischer.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Feb 02, 2001 at 02:23:34AM -0800, Julian Elischer wrote: > "Geoffrey Crompton (RMIT Guest)" wrote: > > > > On Wed, Jan 31, 2001 at 11:50:01PM -0800, Julian Elischer wrote: > > > "Geoffrey Crompton (RMIT Guest)" wrote: > > > why are you doing this? > > > there are already 4 pseudo interfaces in the system of varying types.. > > > netgraph(2 types), divert, tap, tun. > > > what do you need to do? > > > > I need to do packet translation between different AF_ types. I haven't seen > > any interfaces that do that. (I haven't got too much experience though) > > can you be more specific? > Playing with rfc2765, converting IPv4 packets to IPv6 packets and vice versa. I know that this rfc doesn't work in isolation. I can't really explain about what I'm using it in though. Geoff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 14:48:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id A1F8037B401; Sun, 4 Feb 2001 14:48:17 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.2/8.11.2) with ESMTP id f14MmN207012; Sun, 4 Feb 2001 22:48:23 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.2/8.11.1) with ESMTP id f14Mo7M07132; Sun, 4 Feb 2001 22:50:07 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200102042250.f14Mo7M07132@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Julian Elischer Cc: John Telford , freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Firewalling a PPPoE, any easy workaround to MTU on lan stations ? In-Reply-To: Message from Julian Elischer of "Sun, 04 Feb 2001 10:22:24 PST." <3A7D9DE0.CE10C046@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Feb 2001 22:50:07 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > John Telford wrote: > > > > I'm putting a 4.2 R firewall in for a ppoe connection. (sympatico) > > Is there any workaround I can use so I don't have to reduce the MTU on all > > the internal stations ? > > It's a mix of Windows 9x and Macs. And I've found only one utility capable > > of adjusting MTU on Macs. > > Can anything be done on the freebsd box as the traffic goes through it ? > > Thanks in advance, John. > > P.S. the pppoe setup went fine thanks to a page at www.sympaticousers.org > > and some further notes at www.freebsddiary.org > > > ppp now has an option where it will force the negotiated packet size > of new tcp sessions going through it down. (i.e it fiddles with the packets) > check the man page.. I THINK it may be in 4.2, if not it's in -Stable It didn't make 4.2 - it was MFC'd on December 18 :-( > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000-2001 > ---> X_.---._/ > v -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 16:11:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from hera.drwilco.net (10dyn237.dh.casema.net [212.64.31.237]) by hub.freebsd.org (Postfix) with ESMTP id AD93F37B491; Sun, 4 Feb 2001 16:10:38 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.2/8.11.1) with ESMTP id f150XEo00957; Mon, 5 Feb 2001 01:33:15 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010205000202.00c47f00@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Feb 2001 00:04:20 +0100 To: Brian Somers , Julian Elischer From: "Rogier R. Mulhuijzen" Subject: Re: Firewalling a PPPoE, any easy workaround to MTU on lan stations ? Cc: John Telford , freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG In-Reply-To: <200102042250.f14Mo7M07132@hak.lan.Awfulhak.org> References: <3A7D9DE0.CE10C046@elischer.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_162724927==_.ALT" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --=====================_162724927==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 22:50 4-2-01 +0000, Brian Somers wrote: > > John Telford wrote: > > > > > > I'm putting a 4.2 R firewall in for a ppoe connection. (sympatico) > > > Is there any workaround I can use so I don't have to reduce the MTU > on all > > > the internal stations ? > > > It's a mix of Windows 9x and Macs. And I've found only one utility > capable > > > of adjusting MTU on Macs. > > > Can anything be done on the freebsd box as the traffic goes through it ? > > > Thanks in advance, John. > > > P.S. the pppoe setup went fine thanks to a page at www.sympaticousers.org > > > and some further notes at www.freebsddiary.org > > > > > > ppp now has an option where it will force the negotiated packet size > > of new tcp sessions going through it down. (i.e it fiddles with the > packets) > > check the man page.. I THINK it may be in 4.2, if not it's in -Stable > >It didn't make 4.2 - it was MFC'd on December 18 :-( Brian, may I quote you from a different thread? =) "I think I've figured out the problem though... can you try the latest version of ppp - should be available via http://www.Awfulhak.org/ppp.html RSN (the 010204 archive) if you don't get -current. " John might not need that version, but shouldn't he be able to run a newer ppp on his 4.2-R without hitches? DocWilco --=====================_162724927==_.ALT Content-Type: text/html; charset="us-ascii" At 22:50 4-2-01 +0000, Brian Somers wrote:
> John Telford wrote:
> >
> > I'm putting  a 4.2 R firewall in for a ppoe connection. (sympatico)
> > Is there any workaround I can use so I don't have to reduce the MTU on all
> > the internal stations ?
> > It's a mix of Windows 9x and Macs. And I've found only one utility capable
> > of adjusting MTU on Macs.
> > Can anything be done on the freebsd box as the traffic goes through it ?
> > Thanks in advance, John.
> > P.S. the pppoe setup went fine thanks to a page at www.sympaticousers.org
> > and some further notes at www.freebsddiary.org
>
>
> ppp now has an option where it will force the negotiated packet size
> of new tcp sessions going through it down. (i.e it fiddles with the packets)
> check the man page.. I THINK it may be in 4.2, if not it's in -Stable

It didn't make 4.2 - it was MFC'd on December 18 :-(

Brian, may I quote you from a different thread? =)

"I think I've figured out the problem though... can you try the latest
version of ppp - should be available via
http://www.Awfulhak.org/ppp.html RSN (the 010204 archive) if you
don't get -current. "

John might not need that version, but shouldn't he be able to run a newer ppp on his 4.2-R without hitches?

        DocWilco --=====================_162724927==_.ALT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 16:28:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from paprika.michvhf.com (adsl-pool23-20.detroit.mi.ameritech.net [64.108.56.20]) by hub.freebsd.org (Postfix) with SMTP id D90DF37B401 for ; Sun, 4 Feb 2001 16:28:08 -0800 (PST) Received: (qmail 10759 invoked by uid 1001); 5 Feb 2001 00:28:08 -0000 Date: Sun, 4 Feb 2001 19:28:08 -0500 (EST) From: Vince Vielhaber To: "Rogier R. Mulhuijzen" Cc: Brian Somers , Julian Elischer , John Telford , , Subject: Re: Firewalling a PPPoE, any easy workaround to MTU on lan stations ? In-Reply-To: <4.3.2.7.0.20010205000202.00c47f00@mail.bsdchicks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 5 Feb 2001, Rogier R. Mulhuijzen wrote: > At 22:50 4-2-01 +0000, Brian Somers wrote: > > > John Telford wrote: > > > > > > > > I'm putting a 4.2 R firewall in for a ppoe connection. (sympatico) > > > > Is there any workaround I can use so I don't have to reduce the MTU > > on all > > > > the internal stations ? > > > > It's a mix of Windows 9x and Macs. And I've found only one utility > > capable > > > > of adjusting MTU on Macs. > > > > Can anything be done on the freebsd box as the traffic goes through it ? > > > > Thanks in advance, John. > > > > P.S. the pppoe setup went fine thanks to a page at www.sympaticousers.org > > > > and some further notes at www.freebsddiary.org > > > > > > > > > ppp now has an option where it will force the negotiated packet size > > > of new tcp sessions going through it down. (i.e it fiddles with the > > packets) > > > check the man page.. I THINK it may be in 4.2, if not it's in -Stable > > > >It didn't make 4.2 - it was MFC'd on December 18 :-( > > Brian, may I quote you from a different thread? =) > > "I think I've figured out the problem though... can you try the latest > version of ppp - should be available via > http://www.Awfulhak.org/ppp.html RSN (the 010204 archive) if you > don't get -current. " > > John might not need that version, but shouldn't he be able to run a newer > ppp on his 4.2-R without hitches? No reason why not.. I'm doing it. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ========================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 18:26:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from xena.gsicomp.on.ca (cr677933-a.ktchnr1.on.wave.home.com [24.43.230.149]) by hub.freebsd.org (Postfix) with ESMTP id 646BC37B65D; Sun, 4 Feb 2001 18:26:21 -0800 (PST) Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.9.3) with SMTP id f152OZi26799; Sun, 4 Feb 2001 21:24:35 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <004301c08f1c$22a8adb0$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: Cc: References: <000501c08ed2$2e1c5920$3227e540@johnny2k> <4.3.2.7.0.20010204201824.00bd33c0@mail.bsdchicks.com> Subject: Re: Firewalling a PPPoE, any easy workaround to MTU on lan stations ? Date: Sun, 4 Feb 2001 21:34:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > At 10:22 4-2-01 -0800, Julian Elischer wrote: > >John Telford wrote: > > > > > > I'm putting a 4.2 R firewall in for a ppoe connection. (sympatico) > > > Is there any workaround I can use so I don't have to reduce the MTU on all > > > the internal stations ? > > > It's a mix of Windows 9x and Macs. And I've found only one utility capable > > > of adjusting MTU on Macs. > > > Can anything be done on the freebsd box as the traffic goes through it ? > > > Thanks in advance, John. > > > P.S. the pppoe setup went fine thanks to a page at www.sympaticousers.org > > > and some further notes at www.freebsddiary.org > > > > > >ppp now has an option where it will force the negotiated packet size > >of new tcp sessions going through it down. (i.e it fiddles with the packets) > >check the man page.. I THINK it may be in 4.2, if not it's in -Stable > > Actually, I have just been playing with this. Userland ppp has the 'set > mtu' command which will make ppp try and set that MTU at negotiation time. Isn't the proper command 'set tcpmssfixup'? Sure, 'set mtu' will allow you to set the MTU, but 'set tpmssfixup' will ensure that any MTU bashing (explained very nicely at http://renaud.waldura.com/doc/freebsd-pppoe/) is properly accounted for.. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 18:53:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by hub.freebsd.org (Postfix) with ESMTP id B594F37B69E; Sun, 4 Feb 2001 18:53:28 -0800 (PST) Received: from johnny2k ([64.229.39.50]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010205025327.KANY6682.tomts7-srv.bellnexxia.net@johnny2k>; Sun, 4 Feb 2001 21:53:27 -0500 Message-ID: <000801c08f1e$e277d970$3227e540@johnny2k> From: "John Telford" To: "Vince Vielhaber" , "Rogier R. Mulhuijzen" Cc: "Brian Somers" , "Julian Elischer" , , References: Subject: Re: Firewalling a PPPoE, any easy workaround to MTU on lan stations? Date: Sun, 4 Feb 2001 21:53:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmm my timing for this topic seems right on :) Since I ran out of disk space trying to update to -stable this afternoon (now that's another topic for another day "Why so much space to keep up with -stable, when /stand/sysinstall can do an inplace update ?") So should a throw another drive in this thing and go -stable or not ? What does MFC'd mean ? Perhaps a summary of each of your thoughts would help me ? Thanks, I really appreaciate all the help. Regards, John. ----- Original Message ----- From: "Vince Vielhaber" To: "Rogier R. Mulhuijzen" Cc: "Brian Somers" ; "Julian Elischer" ; "John Telford" ; ; Sent: Sunday, February 04, 2001 7:28 PM Subject: Re: Firewalling a PPPoE, any easy workaround to MTU on lan stations? > On Mon, 5 Feb 2001, Rogier R. Mulhuijzen wrote: > > > At 22:50 4-2-01 +0000, Brian Somers wrote: > > > > John Telford wrote: > > > > > > > > > > I'm putting a 4.2 R firewall in for a ppoe connection. (sympatico) > > > > > Is there any workaround I can use so I don't have to reduce the MTU > > > on all > > > > > the internal stations ? > > > > > It's a mix of Windows 9x and Macs. And I've found only one utility > > > capable > > > > > of adjusting MTU on Macs. > > > > > Can anything be done on the freebsd box as the traffic goes through it ? > > > > > Thanks in advance, John. > > > > > P.S. the pppoe setup went fine thanks to a page at www.sympaticousers.org > > > > > and some further notes at www.freebsddiary.org > > > > > > > > > > > > ppp now has an option where it will force the negotiated packet size > > > > of new tcp sessions going through it down. (i.e it fiddles with the > > > packets) > > > > check the man page.. I THINK it may be in 4.2, if not it's in -Stable > > > > > >It didn't make 4.2 - it was MFC'd on December 18 :-( > > > > Brian, may I quote you from a different thread? =) > > > > "I think I've figured out the problem though... can you try the latest > > version of ppp - should be available via > > http://www.Awfulhak.org/ppp.html RSN (the 010204 archive) if you > > don't get -current. " > > > > John might not need that version, but shouldn't he be able to run a newer > > ppp on his 4.2-R without hitches? > > No reason why not.. I'm doing it. > > Vince. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 19:42:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id A910E37B4EC; Sun, 4 Feb 2001 19:42:02 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id TAA17163; Sun, 4 Feb 2001 19:41:34 -0800 (PST) (envelope-from richw) Date: Sun, 4 Feb 2001 19:41:34 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: "Rogier R. Mulhuijzen" Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? In-Reply-To: <4.3.2.7.0.20010204182315.00ce8100@mail.drwilco.net> Message-ID: <20010205032623.16758.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Rogier R. Mulhuijzen wrote: > Interesting. 4 interfaces in 2 clusters. I have a DSL connection with multiple static IP addresses at home. The rl0/xl0 cluster is so that I can have my main home machine appear to be directly on the Internet, even though in fact it is sitting behind the bridge (which also functions as a firewall). The pcn0/ed0 cluster is for the kids' machines, so they can access services (printing, Samba, and a SquidGuard web proxy) on the bridge/ firewall machine, but without needing public IP addresses or having any direct access to the Internet at large. "ed0" is a conventional Ethernet card; "pcn0" does HomePNA (Ethernet over in-house phone wiring). Right now, both kids' machines are on HomePNA, but I hope eventually to move one or both of them to regular 10baseT if I can manage to install some CAT-5 wiring in our house. > Do you have the same problem in the 2nd cluster? The kids' machines (on pcn0) have no problem contacting the bridge. I don't currently have anything at all connected to ed0. > Do you have the same problem without clustering? I.e., make > the bridge do all 4 interfaces at once. I haven't tried this, and (for security reasons, see above), I really don't want to try it. > What happens when you assign the IP to xl0 instead of rl0? Good question. I'll try that. Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 20: 1:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id 5AC6037B65D; Sun, 4 Feb 2001 20:01:00 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id UAA17498; Sun, 4 Feb 2001 20:00:48 -0800 (PST) (envelope-from richw) Date: Sun, 4 Feb 2001 20:00:48 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Robert Watson Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: BRIDGE breaks ARP? In-Reply-To: Message-ID: <20010205035021.16758.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson wrote: > at one point I was experimenting with userland bridging > software based on BPF, . . . An interesting side effect > of this was that locally sourced packets that came out of > the IP stack would not be bridged, . . . nodes on either > side of the bridge could talk to each other just fine, > but not to the bridge *unless* they were talking to the > bridge on an IP address configured on the interface on > their side of the bridge. . . . does this behavior sound > like something you're experiencing: . . . ? . . . I.e., > do you see behavior where the bridge is only IP-reachable > from one side of the bridge, and not the other? This might > suggest a problem with bridging of software-looped back > packets, possibly specific to the interfaces you're using. If anything, I would appear to be seeing the opposite behaviour, where hosts can talk to the bridge only if they're on the interface that is =NOT= configured with an IP address. Consider the following points: ==> I have the IP address for my bridge cluster configured on rl0 (an "internal" interface that goes to my main home machine). ==> Hosts contacting my bridge from the Internet at large (going through xl0, an "external" interface that goes to my DSL box) have no problems. ==> My main home machine (connected to the bridge via rl0, the interface which is configured with the IP address) cannot get an ARP reply from the bridge for the bridge's own hardware address. I clearly need to try configuring the bridge with the IP address associated with the other interface, and see what happens. I'll let people know what happens when I do this. Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 21:33:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id A714E37B491; Sun, 4 Feb 2001 21:33:00 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id VAA18938; Sun, 4 Feb 2001 21:32:49 -0800 (PST) (envelope-from richw) Date: Sun, 4 Feb 2001 21:32:49 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Robert Watson Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: BRIDGE breaks ARP? In-Reply-To: Message-ID: <20010205043816.18207.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I tried switching the interface on which the IP address was configured. I'm now giving xl0 (the "external" interface to the DSL modem and the Internet) the IP address, while rl0 (the "internal" interface linking the bridge machine to my main home machine) has no IP address. No difference. The bridge still doesn't respond to ARP queries for its own hardware address on the internal (rl0) interface -- but it does reply to such queries if they arrive on the external (xl0) interface. I ran "tcpdump -i rl0 arp" and "tcpdump -i xl0 arp" and confirmed the above. I saw one interesting thing in the "tcpdump" output: when my main home machine was sending ARP queries for the bridge via its "rl0" interface, the bridge not only failed to reply to these requests, but (after a while) it started passing them out via its "xl0" interface. The fact that the bridge is bridging ARP requests for itself strongly suggests that it's not recognizing the queries as applying to itself (at least if they arrive via the "rl0" interface). The question is still open as to why this is happening with the "rl0" interface, but not the "xl0" interface. As I said, it doesn't seem to have anything to do with which of the two bridged interfaces has the IP address attached to it. Does this help any? Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 22:29:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id F3A8F37B401; Sun, 4 Feb 2001 22:29:40 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f156Tel18525; Sun, 4 Feb 2001 22:29:40 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102050629.f156Tel18525@iguana.aciri.org> Subject: Re: BRIDGE breaks ARP? In-Reply-To: <20010205043816.18207.richw@wyattearp.stanford.edu> from Rich Wales at "Feb 4, 2001 9:32:49 pm" To: richw@webcom.com (Rich Wales) Date: Sun, 4 Feb 2001 22:28:19 -0800 (PST) Cc: rwatson@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org May i suggest to try a recent (feb.2, 2001) version of the code ? there have been long-standing problems with bridging on 4.x and in particular some related to the handling of broadcast packets (ARP requests are among them) which hopefully are fixed now. You need to default your firewall to open. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 22:38:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 56A5937B401 for ; Sun, 4 Feb 2001 22:38:28 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f156cLN18603; Sun, 4 Feb 2001 22:38:21 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102050638.f156cLN18603@iguana.aciri.org> Subject: Re: packet loss when 'ipfw pipe list' with dummynet and bridge In-Reply-To: <20010203132412V.ishizuka@onion.ish.org> from Masachika ISHIZUKA at "Feb 3, 2001 1:24:12 pm" To: ishizuka@ish.org (Masachika ISHIZUKA) Date: Sun, 4 Feb 2001 22:38:21 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > A better approach would probably be to set a semaphore before > > starting, and release it at the end, and keep interrupts enabled ... > > Dear, luigi-san. > > Thank you for mail. > As I set "net.inet.ip.dummynet.expire=0", if it will affect > only to ip addresses founded newly when a semaphore is introduced, > I'll be happy. not clear what you mean, but in any case that variable will not help solving the problem that you are having. net.inet.ip.dummynet.expire only controls when flow descriptors are deleted, but they are always deleted when the system runs out of space, and new ones are always created when necessary. cheers luigi > -- > ishizuka@ish.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 4 23:18:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-01.iinet.net.au (syncopation-01.iinet.net.au [203.59.24.37]) by hub.freebsd.org (Postfix) with SMTP id DE9C537B401 for ; Sun, 4 Feb 2001 23:18:26 -0800 (PST) Received: (qmail 9125 invoked by uid 666); 5 Feb 2001 07:25:29 -0000 Received: from reggae-03-137.nv.iinet.net.au (HELO elischer.org) (203.59.78.137) by mail.m.iinet.net.au with SMTP; 5 Feb 2001 07:25:29 -0000 Message-ID: <3A7E458E.70FB2BF6@elischer.org> Date: Sun, 04 Feb 2001 22:17:50 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Rich Wales Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: BRIDGE breaks ARP? (more info) References: <20010204143346.02926.richw@wyattearp.stanford.edu> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Rich Wales wrote: > > Julian Elischer wrote: > > > try using netgraph bridging instead. > > Can't do this until the netgraph code supports ipfirewall or ipfilter. why can't you use routing? (ipfw only REALLY works with IP packets anyhow..) OR you can do what some people do which is make a netgraph 'router' where appletalk and other NON-IP packets are bridged and IP packets are routed. > > Rich Wales richw@webcom.com http://www.webcom.com/richw/ -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 0: 8:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from onion.ish.org (onion.ish.org [210.145.219.202]) by hub.freebsd.org (Postfix) with ESMTP id DFD2737B401; Mon, 5 Feb 2001 00:08:03 -0800 (PST) Received: from localhost (ishizuka@localhost [127.0.0.1]) by onion.ish.org (8.11.2/8.11.1/2000-12-01) with ESMTP id f15881n04801; Mon, 5 Feb 2001 17:08:01 +0900 (JST) (envelope-from ishizuka@ish.org) To: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? In-Reply-To: <200102050629.f156Tel18525@iguana.aciri.org> References: <20010205043816.18207.richw@wyattearp.stanford.edu> <200102050629.f156Tel18525@iguana.aciri.org> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-PGP-Fingerprint20: 276D 697A C2CB 1580 C683 8F18 DA98 1A4A 50D2 C4CB X-PGP-Fingerprint16: C6 DE 46 24 D7 9F 22 EB 79 E2 90 AB 1B 9A 35 2E X-PGP-Public-Key: http://www.ish.org/pgp-public-key.txt X-URL: http://www.ish.org/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010205170801Q.ishizuka@onion.ish.org> Date: Mon, 05 Feb 2001 17:08:01 +0900 From: Masachika ISHIZUKA X-Dispatcher: imput version 20000414(IM141) Lines: 15 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > May i suggest to try a recent (feb.2, 2001) version of the code ? > there have been long-standing problems with bridging on 4.x and > in particular some related to the handling of broadcast packets (ARP > requests are among them) which hopefully are fixed now. > You need to default your firewall to open. I cvsuped three hours ago and the same ARP troubles happened. The RCS header of /sys/net/bridge.c is "$FreeBSD: src/sys/net/bridge.c,v 1.16.2.12 2001/02/01 20:25:08 luigi Exp $". I use two fxp (Intel Pro100B) NICs. This machine was worked fine with about two weeks older codes. -- ishizuka@ish.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 0:55:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id ADC1037B6A7; Mon, 5 Feb 2001 00:54:57 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f158srC20881; Mon, 5 Feb 2001 00:54:53 -0800 (PST) Date: Mon, 5 Feb 2001 00:54:53 -0800 From: Alfred Perlstein To: Masachika ISHIZUKA Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? Message-ID: <20010205005453.L26076@fw.wintelcom.net> References: <20010205043816.18207.richw@wyattearp.stanford.edu> <200102050629.f156Tel18525@iguana.aciri.org> <20010205170801Q.ishizuka@onion.ish.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010205170801Q.ishizuka@onion.ish.org>; from ishizuka@ish.org on Mon, Feb 05, 2001 at 05:08:01PM +0900 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Masachika ISHIZUKA [010205 00:09] wrote: > > May i suggest to try a recent (feb.2, 2001) version of the code ? > > there have been long-standing problems with bridging on 4.x and > > in particular some related to the handling of broadcast packets (ARP > > requests are among them) which hopefully are fixed now. > > You need to default your firewall to open. > > I cvsuped three hours ago and the same ARP troubles happened. > The RCS header of /sys/net/bridge.c is > "$FreeBSD: src/sys/net/bridge.c,v 1.16.2.12 2001/02/01 20:25:08 luigi Exp $". > > I use two fxp (Intel Pro100B) NICs. This machine was worked > fine with about two weeks older codes. I had a problem recently (it wound up being a bad network cable), but while going through the code I noticed that one of the routines was changed to return 0x40000, which may somehow conflict with 'normal' return values. In any case the 0x40000 should be a #define. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 1:18:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from tilion.sgn.sca.se (tilion.sgn.sca.se [195.124.135.5]) by hub.freebsd.org (Postfix) with ESMTP id 01D2637B699 for ; Mon, 5 Feb 2001 01:18:21 -0800 (PST) Received: from hygiene.sca.se ([10.80.8.224]) by tilion.sgn.sca.se (8.11.2/8.11.2) with ESMTP id f159IEe75772 for ; Mon, 5 Feb 2001 10:18:15 +0100 (CET) Message-ID: <3A7E715D.71465A50@hygiene.sca.se> Date: Mon, 05 Feb 2001 10:24:45 +0100 From: Edstrom Johan Reply-To: johan.edstrom@hygiene.sca.se Organization: SCA IT Services X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 Cc: freebsd-net@FreeBSD.ORG Subject: Re: VPN question References: <4.3.2.7.0.20010203132652.00acde00@mail.bsdchicks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org IRE Has a rather nice IPSec client for NT/2K/Win that (at least) operates rather nicely with Cisco and Altiga stuff. It's one of the most commonly used clients from an OEM point of view. I've never tested it against FreeBSD but I think it would be possible with Pre-Shared keys? (At least easy to implement) The client can "only" do 128 bit 3des though. -- Unix is like a wigwam - no gates, no windows, apache inside If windows is the answer, it must have been a stupid question. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 3:55:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 3A97F37B491; Mon, 5 Feb 2001 03:55:07 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f15Bt0p20537; Mon, 5 Feb 2001 03:55:00 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102051155.f15Bt0p20537@iguana.aciri.org> Subject: Re: BRIDGE breaks ARP? In-Reply-To: <20010205170801Q.ishizuka@onion.ish.org> from Masachika ISHIZUKA at "Feb 5, 2001 5: 8: 1 pm" To: ishizuka@ish.org (Masachika ISHIZUKA) Date: Mon, 5 Feb 2001 03:55:00 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I cvsuped three hours ago and the same ARP troubles happened. can you repeat exactly what the problem was (bridge machine not responding to ARP requests ?) and what is your exact setup (i am interested in ipfw config, and the following sysctl vars: net.link.ether.bridge net.link.ether.bridge_ipfw net.link.ether.bridge_cfg so i can try to reproduce the problem locally. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 4:32:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from onion.ish.org (onion.ish.org [210.145.219.202]) by hub.freebsd.org (Postfix) with ESMTP id 83FB337B699; Mon, 5 Feb 2001 04:31:55 -0800 (PST) Received: from localhost (ishizuka@localhost [127.0.0.1]) by onion.ish.org (8.11.2/8.11.1/2000-12-01) with ESMTP id f15CVrn16675; Mon, 5 Feb 2001 21:31:53 +0900 (JST) (envelope-from ishizuka@ish.org) To: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? In-Reply-To: <200102051155.f15Bt0p20537@iguana.aciri.org> References: <20010205170801Q.ishizuka@onion.ish.org> <200102051155.f15Bt0p20537@iguana.aciri.org> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-PGP-Fingerprint20: 276D 697A C2CB 1580 C683 8F18 DA98 1A4A 50D2 C4CB X-PGP-Fingerprint16: C6 DE 46 24 D7 9F 22 EB 79 E2 90 AB 1B 9A 35 2E X-PGP-Public-Key: http://www.ish.org/pgp-public-key.txt X-URL: http://www.ish.org/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010205213153T.ishizuka@onion.ish.org> Date: Mon, 05 Feb 2001 21:31:53 +0900 From: Masachika ISHIZUKA X-Dispatcher: imput version 20000414(IM141) Lines: 42 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> I cvsuped three hours ago and the same ARP troubles happened. > > can you repeat exactly what the problem was (bridge machine not > responding to ARP requests ?) and what is your exact setup (i > am interested in ipfw config, and the following sysctl vars: > > net.link.ether.bridge > net.link.ether.bridge_ipfw > net.link.ether.bridge_cfg The problem is that the bridge machine can not communicate any other machines unless net.link.ether.bridge=0. That is no response from/to any other machines to ping command. sysctl variables are shown bellow. net.link.ether.bridge=1 net.link.ether.bridge_ipfw=1 net.inet.ip.dummynet.expire=0 net.link.ether.bridge_cfg=fxp0:1,fxp1:1 And ipfw setup is shown as follows. ip="My IP address" net="My network address" ipfw add pass all from any to any via lo0 ipfw add deny all from any to 127.0.0.0/8 ipfw add pass ospf from ${net} to any bridged ipfw add pass all from ${net} to ${net} ipfw pipe 1 config mask dst-ip 0xffffffff buckets 1024 ipfw pipe 2 config mask src-ip 0xffffffff buckets 1024 ipfw add pipe 1 all from any to any bridged via fxp0 in ipfw add pipe 2 all from any to any bridged via fxp1 in ipfw add pass icmp from any to any ipfw add pass tcp from any to any established ipfw add pass tcp from any to ${ip} 53,110,113 setup ipfw add pass tcp from ${ip} to any setup ipfw add pass udp from any to ${ip} 33434-33500 #traceroute ipfw add pass udp from ${ip} to any 33434-33500 #traceroute ipfw add deny log all from any to ${ip} -- ishizuka@ish.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 5: 8:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from onion.ish.org (onion.ish.org [210.145.219.202]) by hub.freebsd.org (Postfix) with ESMTP id 58ECA37B503 for ; Mon, 5 Feb 2001 05:08:07 -0800 (PST) Received: from localhost (ishizuka@localhost [127.0.0.1]) by onion.ish.org (8.11.2/8.11.1/2000-12-01) with ESMTP id f15D86n18466 for ; Mon, 5 Feb 2001 22:08:06 +0900 (JST) (envelope-from ishizuka@ish.org) To: freebsd-net@FreeBSD.ORG Subject: Re: packet loss when 'ipfw pipe list' with dummynet and bridge In-Reply-To: <200102050638.f156cLN18603@iguana.aciri.org> References: <20010203132412V.ishizuka@onion.ish.org> <200102050638.f156cLN18603@iguana.aciri.org> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-PGP-Fingerprint20: 276D 697A C2CB 1580 C683 8F18 DA98 1A4A 50D2 C4CB X-PGP-Fingerprint16: C6 DE 46 24 D7 9F 22 EB 79 E2 90 AB 1B 9A 35 2E X-PGP-Public-Key: http://www.ish.org/pgp-public-key.txt X-URL: http://www.ish.org/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010205220806S.ishizuka@onion.ish.org> Date: Mon, 05 Feb 2001 22:08:06 +0900 From: Masachika ISHIZUKA X-Dispatcher: imput version 20000414(IM141) Lines: 20 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>> A better approach would probably be to set a semaphore before >>> starting, and release it at the end, and keep interrupts enabled >> >> As I set "net.inet.ip.dummynet.expire=0", if it will affect >> only to ip addresses founded newly when a semaphore is introduced, >> I'll be happy. > > not clear what you mean, but in any case that variable will not help > solving the problem that you are having. > net.inet.ip.dummynet.expire only controls when flow descriptors > are deleted, but they are always deleted when the system runs out > of space, and new ones are always created when necessary. I am happy if no loss happened for bridged packets. I keep the system not run out and no flow descriptors is deleted because I collect traffic stats for my ip address range. I can accept that the flow descriptors just now created are not reported. -- ishizuka@ish.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 8:19:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id EC02837B4EC for ; Mon, 5 Feb 2001 08:15:45 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14PoLv-0000KN-00; Mon, 05 Feb 2001 09:18:55 -0700 Message-ID: <3A7ED26E.4C5F8A0D@softweyr.com> Date: Mon, 05 Feb 2001 09:18:54 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Motonori Shindo , mcarlile@interkeel.com, freebsd-net@FreeBSD.ORG Subject: Re: VPN question References: <000001c08d72$b9ec6780$b101a8c0@contractor4> <20010203.122641.74755745.mshindo@mshindo.net> <3A7BAD76.8969D960@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer wrote: > > Motonori Shindo wrote: > > > > Mark, > > > > There are two that I know of; one is PPTP implementation and another > > is L2TP implementation. > > > > There is a ports/packages for PPTP called 'pptpclient'. You many need > > to modify pppd a little bit, depending on how the peering Windows is > > configured. > > mpd in ports/net has a full pptp implementation allowing mutiple pptp links > concurrently and acting as both a server and a client. > (on copy of mpd running can handle N sessions concurrently) Win2K has IPSec built in. I haven't tried it vs. FreeBSD yet, but will be soon. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 8:52:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 3BB8437B6A0 for ; Mon, 5 Feb 2001 08:52:24 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f15GqK123560; Mon, 5 Feb 2001 08:52:20 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102051652.f15GqK123560@iguana.aciri.org> Subject: Re: packet loss when 'ipfw pipe list' with dummynet and bridge In-Reply-To: <20010205220806S.ishizuka@onion.ish.org> from Masachika ISHIZUKA at "Feb 5, 2001 10: 8: 6 pm" To: ishizuka@ish.org (Masachika ISHIZUKA) Date: Mon, 5 Feb 2001 08:52:20 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >>> A better approach would probably be to set a semaphore before > >>> starting, and release it at the end, and keep interrupts enabled > >> > >> As I set "net.inet.ip.dummynet.expire=0", if it will affect > >> only to ip addresses founded newly when a semaphore is introduced, > >> I'll be happy. > > > > not clear what you mean, but in any case that variable will not help > > solving the problem that you are having. > > net.inet.ip.dummynet.expire only controls when flow descriptors > > are deleted, but they are always deleted when the system runs out > > of space, and new ones are always created when necessary. > > I am happy if no loss happened for bridged packets. > I keep the system not run out and no flow descriptors is deleted > because I collect traffic stats for my ip address range. I can accept > that the flow descriptors just now created are not reported. but it is not like this. At the moment, irrespective of the sysctl variables, reading the stats will put the kernel in a critical section where network interrupts are ignored until the copy is complete. cheers luigi > -- > ishizuka@ish.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 8:59:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 0735137B6A8; Mon, 5 Feb 2001 08:59:00 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f15Gwwm23608; Mon, 5 Feb 2001 08:58:58 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102051658.f15Gwwm23608@iguana.aciri.org> Subject: Re: BRIDGE breaks ARP? In-Reply-To: <20010205213153T.ishizuka@onion.ish.org> from Masachika ISHIZUKA at "Feb 5, 2001 9:31:53 pm" To: ishizuka@ish.org (Masachika ISHIZUKA) Date: Mon, 5 Feb 2001 08:58:58 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > can you repeat exactly what the problem was (bridge machine not > > responding to ARP requests ?) and what is your exact setup (i ... > The problem is that the bridge machine can not communicate any > other machines unless net.link.ether.bridge=0. That is no response > from/to any other machines to ping command. well that description is a bit too generic to help. does the machine doing the ping have an arp entry for the bridge ? can you see (using tcpdump) the ARP and ping requests and replies on the client doing the ping and on the interface of the bridge ? it was my understanding that the problem lied in failure to reply to ARP messages. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 9:52:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id 7D98137B503; Mon, 5 Feb 2001 09:52:02 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id JAA40449; Mon, 5 Feb 2001 09:51:15 -0800 (PST) (envelope-from richw) Date: Mon, 5 Feb 2001 09:51:15 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Julian Elischer Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: netgraph router? (was Re: BRIDGE breaks ARP?) In-Reply-To: <3A7E458E.70FB2BF6@elischer.org> Message-ID: <20010205172708.36311.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer wrote: > > > try using netgraph bridging instead. and I replied: > > Can't do this until the netgraph code supports ipfirewall > > or ipfilter. to which Julian replied: > why can't you use routing? (ipfw only REALLY works with IP > packets anyhow..) OR you can do what some people do which > is make a netgraph 'router' where appletalk and other NON-IP > packets are bridged and IP packets are routed. Could you explain this in more detail -- possibly directing me to an example? My requirements are: ==> I need to protect my main desktop machine behind a firewall (which is why I'm running IPFIREWALL on my bridge). ==> My main desktop machine needs to have its own, "public" IP address (my work requires me to use some Kerberized security services that won't survive NAT-munging through a router). ==> I have DSL with multiple static IP addresses at home (work perk), but my static block of addresses isn't big enough for me to be able to split it further into mini-subnets for routing purposes, which is why I want to run a bridge rather than a conventional router. ==> I don't need my firewall to pass any kind of non-IP packets, other than ARP. Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 10: 0:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153]) by hub.freebsd.org (Postfix) with ESMTP id 6FCED37B491 for ; Mon, 5 Feb 2001 10:00:37 -0800 (PST) Received: from frmta003.netfr.alcatel.fr (frmta003.netfr.alcatel.fr [155.132.251.32]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id TAA11164 for ; Mon, 5 Feb 2001 19:00:40 +0100 (MET) Received: by frmta003.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C12569EA.0062EB3B ; Mon, 5 Feb 2001 19:00:27 +0100 X-Lotus-FromDomain: ALCATEL From: Thierry.Herbelot@alcatel.fr To: freebsd-net@freebsd.org Message-ID: Date: Mon, 5 Feb 2001 19:00:24 +0100 Subject: diskless boot of a PXE-compatible machine : finally done ! Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, this a simili victory report : the PC now boots via PXE (this is a Motorola rack-mount PC, with a no-thrills BX motherboard and an fxp NIC, with a strictly 4.2-Release installation) the rc.diskless2 must be wrong (I've not yet checked with -Stable), as it tries to chmod, chgrp and find in /var before mounting /usr (this must be a chicken-and-egg question, as a forced /usr mount in the beginning of rc.diskless2 gives an error message about /var/db/mounttab not being there) in the limited tests I have done, I have not been able to start the machine with a strict bootp setup : the PXE ROM says there are no answers if I force the dhcpd as a BOOTP server (I want to control the correspondance between the MAC and IP addresses) the PXE boot rom is a 2.0 release, compile number 68 (is there any more stable or better version ?) TfH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 10:40:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 7513C37B401 for ; Mon, 5 Feb 2001 10:39:49 -0800 (PST) Received: (qmail 17784 invoked by uid 666); 5 Feb 2001 18:47:30 -0000 Received: from reggae-15-111.nv.iinet.net.au (HELO elischer.org) (203.59.74.111) by mail.m.iinet.net.au with SMTP; 5 Feb 2001 18:47:30 -0000 Message-ID: <3A7EE540.AA3A1AF0@elischer.org> Date: Mon, 05 Feb 2001 09:39:12 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Rich Wales Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: netgraph router? (was Re: BRIDGE breaks ARP?) References: <20010205172708.36311.richw@wyattearp.stanford.edu> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Rich Wales wrote: > > Julian Elischer wrote: > > > > > try using netgraph bridging instead. > > and I replied: > > > > Can't do this until the netgraph code supports ipfirewall > > > or ipfilter. > > to which Julian replied: > > > why can't you use routing? (ipfw only REALLY works with IP > > packets anyhow..) OR you can do what some people do which > > is make a netgraph 'router' where appletalk and other NON-IP > > packets are bridged and IP packets are routed. > > Could you explain this in more detail -- possibly directing me to > an example? some people run a bridge between two ethernet segments, but give them different IP netranges, thas IP goes via the IP code and routes while other protocols 'see' each other directly and go through the bridge. THe clients are told to go vi the router (bsd machine) so they do.. I don't see how this would help in your situation though. > > My requirements are: > > ==> I need to protect my main desktop machine behind a firewall > (which is why I'm running IPFIREWALL on my bridge). > > ==> My main desktop machine needs to have its own, "public" IP > address (my work requires me to use some Kerberized security > services that won't survive NAT-munging through a router). > > ==> I have DSL with multiple static IP addresses at home (work > perk), but my static block of addresses isn't big enough > for me to be able to split it further into mini-subnets for > routing purposes, which is why I want to run a bridge rather > than a conventional router. > > ==> I don't need my firewall to pass any kind of non-IP packets, > other than ARP. so how does bridging help? this is what I'd do.. real | nat addresses | addresses | --internet--[firewall]------------[workstation+NAT]---------[othermachines] | | In fact it is possible you could run both the 10.x.x.x. net and the 'real' net on the same interface/cable and use the firewall to NAT them as well (just assign two addresses to the interface). (I'd have to look at the rules that are installed for NATD but I'm sure you could work something out. > Rich Wales richw@webcom.com http://www.webcom.com/richw/ -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 11:37:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id 6B38F37B491; Mon, 5 Feb 2001 11:37:02 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id LAA50425; Mon, 5 Feb 2001 11:36:59 -0800 (PST) (envelope-from richw) Date: Mon, 5 Feb 2001 11:36:59 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Julian Elischer Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: netgraph router? (was Re: BRIDGE breaks ARP?) In-Reply-To: <3A7EE540.AA3A1AF0@elischer.org> Message-ID: <20010205191633.48479.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer wrote: > some people run a bridge between two ethernet segments, > but give them different IP netranges, . . . I suppose I could do this, provided I could specify a more-or-less arbitrary range or set of IP addresses for each segment. I can't do conventional IP subnetting (one subnet for each segment), because this approach takes up too many addresses for overhead (two addresses for the bridge, plus wasted addresses with "all zeroes" and "all ones" in the low-order host bits, and my DSL service only gives me five IP addresses to play with as it is). > so how does bridging help? By allowing my desktop machine to use a publicly accessible Internet address, even though there is a firewall between it and the outside. My current bridge setup, in conjunction with IPFIREWALL, already does =almost= everything I need. The biggest problem I'm having right now is with ARP replies from (=not= through) the bridge box itself -- and I assume that will eventually get fixed, and I can work around that bug with an "arp -s" command until it is fixed. I'd also prefer being able to filter (and, potentially, block) ARP packets going through the bridge, but that feature isn't crucial for me, and I can live without it if necessary. > In fact, it is possible you could run both the 10.x.x.x. net > and the 'real' net on the same interface/cable and use the > firewall to NAT them as well . . . . As long as I don't have to depend on NAT for access to my desktop. As I explained earlier, I need to access some services from my desktop (Kerberos-based authentication and encryption stuff) that demand a straight end-to-end connection (no NAT, web proxies, etc.). Getting back to my original question, though, I need some help under- standing how I can =filter= IP packets going through a "netgraph" bridge -- that is, allow or block packets or streams based on things like the source and destination IP addresses, TCP/UDP port numbers, etc. -- the kind of thing which IPFIREWALL and IPFILTER can do, and which I (possibly mis?)understood that NETGRAPH cannot currently do. I thought you were saying that there was in fact a way to do this sort of filtering on a netgraph bridge. If not, then the netgraph facility won't help me any. Sorry if I misunderstood your earlier message, or if you misunderstood my requirements. Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 11:44:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable026.106-200-24.mtl.mc.videotron.ca [24.200.106.26]) by hub.freebsd.org (Postfix) with SMTP id 1828E37B491 for ; Mon, 5 Feb 2001 11:44:07 -0800 (PST) Received: (qmail 81355 invoked from network); 5 Feb 2001 19:44:05 -0000 Received: from cognac.local.mindstep.com (HELO cognac) (192.168.10.9) by jacuzzi.local.mindstep.com with SMTP; 5 Feb 2001 19:44:05 -0000 From: "Patrick Bihan-Faou" To: Cc: "Rich Wales" Subject: Re: BRIDGE breaks ARP? (more info) Date: Mon, 5 Feb 2001 14:45:28 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! "Rich Wales" wrote in message news:<20010204162724.04832.richw@wyattearp.stanford.edu>... > Robert Watson wrote: > > > There used to be a kludge that mapped the ether_header.ether_type > > field of non-IP packets into the UDP port number for the purposes > > of certain IPFW rules when bridging. This was pretty awful. :-) > > I should add something else. My bridge =does= pass ARP info between > the two bridged NIC's. Thus, for example, a machine on the "rl0" side > of the bridge can successfully use a default Internet gateway which is > on the "xl0" side of the bridge (and "arp -a" on the rl0-side machine > shows the hardware address of the xl0-side gateway). > > So the problem doesn't seem to have anything to do with ARP bridging. > Even though ARP packets are being passed through the bridge, the bridge > itself doesn't reply to ARP requests asking it for its own MAC address. > (Or, to be more precise, it sometimes does send out ARP replies, but > only sporadically and unpredictably.) I am seeing exactly the same behaviour here. I have up-to-date FreeBSD -STABLE code. What I am seeing is that the FreeBSD machine running bridging does not answer ARP request asking for its own mac address. At first I thought I was seeing a me-only problem, but it seems that it is not the case. Also as Rich mentions, this problem is sporadic: it will work sometimes (i.e. FreeBSD answers the ARP request) but not at other times. I have not been able to determine the set of conditions that make the problem occur. The behaviour seems consistent for an entire "booted" session: if it works when the machine starts, it will always work, if it does not work when the machine starts, it will never work. Also I am using a combination of "rl", "ed" and "xl" cards. I have all the setup to do testing and tracing of this problem. So if anybody has suggestions I am available, this very problem is #1 on my work list... Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 12:11:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 7351637B65D; Mon, 5 Feb 2001 12:11:26 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f15KBJb24985; Mon, 5 Feb 2001 12:11:19 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102052011.f15KBJb24985@iguana.aciri.org> Subject: Re: BRIDGE breaks ARP? (more info) In-Reply-To: from Patrick Bihan-Faou at "Feb 5, 2001 2:45:28 pm" To: patrick@netzuno.com (Patrick Bihan-Faou) Date: Mon, 5 Feb 2001 12:11:19 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org as a matter of fact -- i believe the recent commit by julian on netinet/if_ether.c (1.74 -> 1.75 and 1.64.2.5 -> 1.64.2.6, specifically the first part of the patch) is responsible for this bug. Essentially: before that patch, as the comment near to the code clearly says, if bridging was active, an address match must be attempted irrespective of the interface the packet is coming from, because you do not know on which side the client is. After this patch, when bridging is active, the code never attempts to match the address and so an ARP reply is never generated. Hate to say this, but I do not understand the hurry for applying this patch without testing that it does the right thing and without contacting the committers involved with this code (me in this case). The PR was reported only a few days ago, it is not critical at all, and is wrong anyways because what you really want, even if you have bridging enabled, is to try an address match only on the interfaces which are part of the same cluster the input interface belongs to. cheers luigi > > I should add something else. My bridge =does= pass ARP info between > > the two bridged NIC's. Thus, for example, a machine on the "rl0" side > > of the bridge can successfully use a default Internet gateway which is > > on the "xl0" side of the bridge (and "arp -a" on the rl0-side machine > > shows the hardware address of the xl0-side gateway). > > > > So the problem doesn't seem to have anything to do with ARP bridging. > > Even though ARP packets are being passed through the bridge, the bridge > > itself doesn't reply to ARP requests asking it for its own MAC address. > > (Or, to be more precise, it sometimes does send out ARP replies, but > > only sporadically and unpredictably.) > > > I am seeing exactly the same behaviour here. I have up-to-date > FreeBSD -STABLE code. What I am seeing is that the FreeBSD machine running > bridging does not answer ARP request asking for its own mac address. At > first I thought I was seeing a me-only problem, but it seems that it is not > the case. Also as Rich mentions, this problem is sporadic: it will work > sometimes (i.e. FreeBSD answers the ARP request) but not at other times. I > have not been able to determine the set of conditions that make the problem > occur. The behaviour seems consistent for an entire "booted" session: if it > works when the machine starts, it will always work, if it does not work when > the machine starts, it will never work. > > Also I am using a combination of "rl", "ed" and "xl" cards. > > I have all the setup to do testing and tracing of this problem. So if > anybody has suggestions I am available, this very problem is #1 on my work > list... > > Patrick. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 12:26:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id E173B37B401; Mon, 5 Feb 2001 12:26:28 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f15KQOJ25113; Mon, 5 Feb 2001 12:26:24 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102052026.f15KQOJ25113@iguana.aciri.org> Subject: Re: BRIDGE breaks ARP? In-Reply-To: <20010205005453.L26076@fw.wintelcom.net> from Alfred Perlstein at "Feb 5, 2001 0:54:53 am" To: bright@wintelcom.net (Alfred Perlstein) Date: Mon, 5 Feb 2001 12:26:24 -0800 (PST) Cc: ishizuka@ish.org, freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > was changed to return 0x40000, which may somehow conflict with > 'normal' return values. In any case the 0x40000 should be a > #define. It does not conflict with a normal value, those are in the range 0-65535 (0xffff). The 0x40000 was supposed to be a #define in ip_fw.h (it is in -current, i just forgot to carry it over in the MFC..) cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 12:39:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 18F4D37B491 for ; Mon, 5 Feb 2001 12:39:38 -0800 (PST) Received: (qmail 23268 invoked by uid 666); 5 Feb 2001 20:47:15 -0000 Received: from reggae-14-42.nv.iinet.net.au (HELO elischer.org) (203.59.77.42) by mail.m.iinet.net.au with SMTP; 5 Feb 2001 20:47:15 -0000 Message-ID: <3A7F014E.FC4536C@elischer.org> Date: Mon, 05 Feb 2001 11:38:55 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Luigi Rizzo Cc: Patrick Bihan-Faou , freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) References: <200102052011.f15KBJb24985@iguana.aciri.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo wrote: > > as a matter of fact -- i believe the recent commit by julian on > netinet/if_ether.c (1.74 -> 1.75 and 1.64.2.5 -> 1.64.2.6, specifically > the first part of the patch) is responsible for this bug. > > Essentially: before that patch, as the comment near to the code > clearly says, if bridging was active, an address match must be > attempted irrespective of the interface the packet is coming from, > because you do not know on which side the client is. After this > patch, when bridging is active, the code never attempts to match > the address and so an ARP reply is never generated. all the patch does is look at the sysctl variable, and if the sysctl variable says that Bridging is turned off, then it acts exactly as if bridging were not compiled in. At least that's my reading of it and it is what id seemed to do when I tested it. > > Hate to say this, but I do not understand the hurry for applying > this patch without testing that it does the right thing and without > contacting the committers involved with this code (me in this case). > > The PR was reported only a few days ago, it is not critical at all, > and is wrong anyways because what you really want, even if you have > bridging enabled, is to try an address match only on the interfaces > which are part of the same cluster the input interface belongs to. yes but my reading of it is that the behaviour should be unchanged for when bridging is turned on. > > cheers > luigi > > > > I should add something else. My bridge =does= pass ARP info between > > > the two bridged NIC's. Thus, for example, a machine on the "rl0" side > > > of the bridge can successfully use a default Internet gateway which is > > > on the "xl0" side of the bridge (and "arp -a" on the rl0-side machine > > > shows the hardware address of the xl0-side gateway). > > > > > > So the problem doesn't seem to have anything to do with ARP bridging. > > > Even though ARP packets are being passed through the bridge, the bridge > > > itself doesn't reply to ARP requests asking it for its own MAC address. > > > (Or, to be more precise, it sometimes does send out ARP replies, but > > > only sporadically and unpredictably.) > > > > > > I am seeing exactly the same behaviour here. I have up-to-date > > FreeBSD -STABLE code. What I am seeing is that the FreeBSD machine running > > bridging does not answer ARP request asking for its own mac address. At > > first I thought I was seeing a me-only problem, but it seems that it is not > > the case. Also as Rich mentions, this problem is sporadic: it will work > > sometimes (i.e. FreeBSD answers the ARP request) but not at other times. I > > have not been able to determine the set of conditions that make the problem > > occur. The behaviour seems consistent for an entire "booted" session: if it > > works when the machine starts, it will always work, if it does not work when > > the machine starts, it will never work. > > > > Also I am using a combination of "rl", "ed" and "xl" cards. > > > > I have all the setup to do testing and tracing of this problem. So if > > anybody has suggestions I am available, this very problem is #1 on my work > > list... > > > > Patrick. > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 12:44:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 1408937B401 for ; Mon, 5 Feb 2001 12:44:12 -0800 (PST) Received: (qmail 23454 invoked by uid 666); 5 Feb 2001 20:51:52 -0000 Received: from reggae-14-42.nv.iinet.net.au (HELO elischer.org) (203.59.77.42) by mail.m.iinet.net.au with SMTP; 5 Feb 2001 20:51:52 -0000 Message-ID: <3A7F0265.80104C75@elischer.org> Date: Mon, 05 Feb 2001 11:43:33 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Luigi Rizzo Cc: Patrick Bihan-Faou , freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) References: <200102052011.f15KBJb24985@iguana.aciri.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo wrote: > > as a matter of fact -- i believe the recent commit by julian on > netinet/if_ether.c (1.74 -> 1.75 and 1.64.2.5 -> 1.64.2.6, specifically > the first part of the patch) is responsible for this bug. > > Essentially: before that patch, as the comment near to the code > clearly says, if bridging was active, an address match must be > attempted irrespective of the interface the packet is coming from, > because you do not know on which side the client is. After this > patch, when bridging is active, the code never attempts to match > the address and so an ARP reply is never generated. > > Hate to say this, but I do not understand the hurry for applying > this patch without testing that it does the right thing and without > contacting the committers involved with this code (me in this case). > > The PR was reported only a few days ago, it is not critical at all, > and is wrong anyways because what you really want, even if you have > bridging enabled, is to try an address match only on the interfaces > which are part of the same cluster the input interface belongs to. who cares about clusters if bridging is disabled? I want bridging to completely dissappear if it's disabled in the sysctl. If this is changing the behaviour of bridging when it is enabled then I misread the code and I will go check it again now. .. The reason I put it in -stable is because people were complaining to me that if they compiled it with bridging compiled in but disabled then it was screwing up Netgraph bridging. > > cheers > luigi > > > > I should add something else. My bridge =does= pass ARP info between > > > the two bridged NIC's. Thus, for example, a machine on the "rl0" side > > > of the bridge can successfully use a default Internet gateway which is > > > on the "xl0" side of the bridge (and "arp -a" on the rl0-side machine > > > shows the hardware address of the xl0-side gateway). > > > > > > So the problem doesn't seem to have anything to do with ARP bridging. > > > Even though ARP packets are being passed through the bridge, the bridge > > > itself doesn't reply to ARP requests asking it for its own MAC address. > > > (Or, to be more precise, it sometimes does send out ARP replies, but > > > only sporadically and unpredictably.) > > > > > > I am seeing exactly the same behaviour here. I have up-to-date > > FreeBSD -STABLE code. What I am seeing is that the FreeBSD machine running > > bridging does not answer ARP request asking for its own mac address. At > > first I thought I was seeing a me-only problem, but it seems that it is not > > the case. Also as Rich mentions, this problem is sporadic: it will work > > sometimes (i.e. FreeBSD answers the ARP request) but not at other times. I > > have not been able to determine the set of conditions that make the problem > > occur. The behaviour seems consistent for an entire "booted" session: if it > > works when the machine starts, it will always work, if it does not work when > > the machine starts, it will never work. > > > > Also I am using a combination of "rl", "ed" and "xl" cards. > > > > I have all the setup to do testing and tracing of this problem. So if > > anybody has suggestions I am available, this very problem is #1 on my work > > list... > > > > Patrick. > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 13: 8:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 2066437B401 for ; Mon, 5 Feb 2001 13:08:15 -0800 (PST) Received: (qmail 24493 invoked by uid 666); 5 Feb 2001 21:15:53 -0000 Received: from reggae-14-42.nv.iinet.net.au (HELO elischer.org) (203.59.77.42) by mail.m.iinet.net.au with SMTP; 5 Feb 2001 21:15:53 -0000 Message-ID: <3A7F0806.9B81D98@elischer.org> Date: Mon, 05 Feb 2001 12:07:34 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Luigi Rizzo Cc: Patrick Bihan-Faou , freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) References: <200102052011.f15KBJb24985@iguana.aciri.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, mea culpa I figured it out.. Luigi.. does this fix it? (void)memcpy(&itaddr, ea->arp_tpa, sizeof (itaddr)); TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { #ifdef BRIDGE /* * For a bridge, we want to check the address irrespective * of the receive interface. (This will change slightly * when we have clusters of interfaces). */ #define BRIDGE_TEST (do_bridge) #else #define BRIDGE_TEST 0 /* cc will optiise the test away */ #endif if ((BRIDGE_TEST) || (ia->ia_ifp == &ac->ac_if)) { maybe_ia = ia; if ((itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) || (isaddr.s_addr == ia->ia_addr.sin_addr.s_addr)) { break; } } } if (maybe_ia == 0) { m_freem(m); return; } myaddr = ia ? ia->ia_addr.sin_addr : maybe_ia->ia_addr.sin_addr; if (!bcmp((caddr_t)ea->arp_sha, (caddr_t)ac->ac_enaddr, sizeof (ea->arp_sha))) { m_freem(m); /* it's from me, ignore it. */ return; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 13:14: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable026.106-200-24.mtl.mc.videotron.ca [24.200.106.26]) by hub.freebsd.org (Postfix) with SMTP id 167B837B491 for ; Mon, 5 Feb 2001 13:13:40 -0800 (PST) Received: (qmail 85295 invoked from network); 5 Feb 2001 21:13:30 -0000 Received: from cognac.local.mindstep.com (HELO cognac) (192.168.10.9) by jacuzzi.local.mindstep.com with SMTP; 5 Feb 2001 21:13:30 -0000 From: "Patrick Bihan-Faou" To: "Julian Elischer" , "Luigi Rizzo" Cc: , , Subject: RE: BRIDGE breaks ARP? (more info) Date: Mon, 5 Feb 2001 16:14:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3A7F0806.9B81D98@elischer.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ah! Yep this seems to be fixing my problem here. I actually reimplemented Julian's patch on a test system here, but luckily did not get confused by the order of the test (the first test should be if(do_bridge || ...) rather than if (!do_bridge)). To Julian's defence, the use of a #ifdef BRIDGE in one place and $ifndef BRIDGE in the other place was confusing though. Patrick. > -----Original Message----- > From: julian@zeweb.mindstep.com [mailto:julian@zeweb.mindstep.com]On > Behalf Of Julian Elischer > Sent: February 5, 2001 15:08 > To: Luigi Rizzo > Cc: Patrick Bihan-Faou; freebsd-net@FreeBSD.ORG; richw@webcom.com; > julian@FreeBSD.ORG > Subject: Re: BRIDGE breaks ARP? (more info) > > > Ok, mea culpa > > I figured it out.. > Luigi.. does this fix it? > > > > > (void)memcpy(&itaddr, ea->arp_tpa, sizeof (itaddr)); > TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { > #ifdef BRIDGE > /* > * For a bridge, we want to check the address irrespective > * of the receive interface. (This will change slightly > * when we have clusters of interfaces). > */ > #define BRIDGE_TEST (do_bridge) > #else > #define BRIDGE_TEST 0 /* cc will optiise the test away */ > #endif > if ((BRIDGE_TEST) || (ia->ia_ifp == &ac->ac_if)) { > maybe_ia = ia; > if ((itaddr.s_addr == > ia->ia_addr.sin_addr.s_addr) || > (isaddr.s_addr == > ia->ia_addr.sin_addr.s_addr)) { > break; > } > } > } > if (maybe_ia == 0) { > m_freem(m); > return; > } > myaddr = ia ? ia->ia_addr.sin_addr : maybe_ia->ia_addr.sin_addr; > if (!bcmp((caddr_t)ea->arp_sha, (caddr_t)ac->ac_enaddr, > sizeof (ea->arp_sha))) { > m_freem(m); /* it's from me, ignore it. */ > return; > } > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 13:19:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from illustrious.cnchost.com (illustrious.concentric.net [207.155.252.7]) by hub.freebsd.org (Postfix) with ESMTP id 2A76337B401 for ; Mon, 5 Feb 2001 13:18:57 -0800 (PST) Received: from auvo.com (4032268D.ptr.dia.nextlink.net [64.50.38.141]) by illustrious.cnchost.com id QAA24805; Mon, 5 Feb 2001 16:18:56 -0500 (EST) [ConcentricHost SMTP Relay 1.10] Message-ID: <3A7F18A6.AF0DD822@auvo.com> Date: Mon, 05 Feb 2001 15:18:30 -0600 From: Mike Bytnar Reply-To: mbytnar@auvo.com Organization: Auvo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: PCMCIA 10/100BaseT Cards That Support Promiscuous Mode Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Any suggestions for a 4.2-RELEASE supported 10/100BaseT, PCMCIA card suitable for bridging? If this is not the correct list to ask, please direct me to an appropriate list. I found that the WaveLAN PCMCIA supports promiscuous mode, however, I need a wired card. And, as I also found out, the "Low Power Ethernet Adapter (Socket Communications, Inc)" PCMCIA card does not support promiscuous mode. Regards, --Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 13:22:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id AADAA37B4EC; Mon, 5 Feb 2001 13:22:22 -0800 (PST) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id FAA04036; Tue, 6 Feb 2001 05:22:20 +0800 Received: from elischer.org (reggae-14-42.nv.iinet.net.au [203.59.77.42]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id FAA19281; Tue, 6 Feb 2001 05:19:50 +0800 Message-ID: <3A7F0B56.4DD77852@elischer.org> Date: Mon, 05 Feb 2001 12:21:42 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Patrick Bihan-Faou Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Patrick Bihan-Faou wrote: > > Ah! > > Yep this seems to be fixing my problem here. I actually reimplemented > Julian's patch on a test system here, but luckily did not get confused by > the order of the test (the first test should be if(do_bridge || ...) rather > than if (!do_bridge)). > > To Julian's defence, the use of a #ifdef BRIDGE in one place and $ifndef > BRIDGE in the other place was confusing though. > > Patrick. reimplememted? -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 13:23:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from atro.pine.nl (atro.pine.nl [213.156.0.2]) by hub.freebsd.org (Postfix) with ESMTP id BE11437B401 for ; Mon, 5 Feb 2001 13:22:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by atro.pine.nl (8.11.1/8.11.1) with ESMTP id f15LMnE09507; Mon, 5 Feb 2001 22:22:50 +0100 (MET) Date: Mon, 5 Feb 2001 22:22:49 +0100 (MET) From: Mark Lastdrager To: Mike Bytnar Cc: Subject: Re: PCMCIA 10/100BaseT Cards That Support Promiscuous Mode In-Reply-To: <3A7F18A6.AF0DD822@auvo.com> Message-ID: X-NCC-RegID: nl.pine MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At Mon, 5 Feb 2001, owner-freebsd-net@FreeBSD.ORG wrote: >Any suggestions for a 4.2-RELEASE supported 10/100BaseT, PCMCIA card >suitable for bridging? If this is not the correct list to ask, please >direct me to an appropriate list. > >I found that the WaveLAN PCMCIA supports promiscuous mode, however, I >need a wired card. >And, as I also found out, the "Low Power Ethernet Adapter (Socket >Communications, Inc)" PCMCIA card does not support promiscuous mode. My 3com 3C574B supports it and was recognized by the 4.2-REL CD-ROM. ep0: <3Com 3C574B, Megahertz 3CCFE574BT or Fast Etherlink 3C574-TX> at port 0x240-0x25f irq 10 slot 0 on pccard0 Mark Lastdrager -- Pine Internet BV :: tel. +31-70-3111010 :: fax. +31-70-3111011 PGP 92BB81D1 fingerprint 0059 7D7B C02B 38D2 A853 2785 8C87 3AF1 Today's excuse: Your packets were eaten by the terminator To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 13:23:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 9315D37B67D; Mon, 5 Feb 2001 13:23:22 -0800 (PST) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id FAA04086; Tue, 6 Feb 2001 05:23:21 +0800 Received: from elischer.org (reggae-14-42.nv.iinet.net.au [203.59.77.42]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id FAA19324; Tue, 6 Feb 2001 05:20:54 +0800 Message-ID: <3A7F0B95.35887B1D@elischer.org> Date: Mon, 05 Feb 2001 12:22:45 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Patrick Bihan-Faou Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Patrick Bihan-Faou wrote: > > Ah! > > Yep this seems to be fixing my problem here. I actually reimplemented > Julian's patch on a test system here, but luckily did not get confused by > the order of the test (the first test should be if(do_bridge || ...) rather > than if (!do_bridge)). > > To Julian's defence, the use of a #ifdef BRIDGE in one place and $ifndef > BRIDGE in the other place was confusing though. no, the problem is that I didn't test the 'obvious' case because it was 'obvious' (and wrong) > > Patrick. reimplememted? -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 13:38: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 5570237B491; Mon, 5 Feb 2001 13:37:49 -0800 (PST) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id FAA04861; Tue, 6 Feb 2001 05:37:46 +0800 Received: from elischer.org (reggae-14-42.nv.iinet.net.au [203.59.77.42]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id FAA20060; Tue, 6 Feb 2001 05:35:19 +0800 Message-ID: <3A7F0EF6.2E0F8878@elischer.org> Date: Mon, 05 Feb 2001 12:37:10 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Patrick Bihan-Faou Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Patrick Bihan-Faou wrote: > > Ah! > > Yep this seems to be fixing my problem here. I actually reimplemented > Julian's patch on a test system here, but luckily did not get confused by > the order of the test (the first test should be if(do_bridge || ...) rather > than if (!do_bridge)). > > To Julian's defence, the use of a #ifdef BRIDGE in one place and $ifndef > BRIDGE in the other place was confusing though. > > Patrick. can you (or someone) test what I just MFC'd to 4.x? I cannot test it on 4.2 as I don't have it.. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 13:40:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable026.106-200-24.mtl.mc.videotron.ca [24.200.106.26]) by hub.freebsd.org (Postfix) with SMTP id DA08B37B401 for ; Mon, 5 Feb 2001 13:39:48 -0800 (PST) Received: (qmail 86249 invoked from network); 5 Feb 2001 21:39:40 -0000 Received: from cognac.local.mindstep.com (HELO cognac) (192.168.10.9) by jacuzzi.local.mindstep.com with SMTP; 5 Feb 2001 21:39:40 -0000 From: "Patrick Bihan-Faou" To: "Julian Elischer" Cc: "Luigi Rizzo" , , , Subject: RE: BRIDGE breaks ARP? (more info) Date: Mon, 5 Feb 2001 16:41:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3A7F0B95.35887B1D@elischer.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Julian, > > Yep this seems to be fixing my problem here. I actually reimplemented > > Julian's patch on a test system here, but luckily did not get > confused by > > the order of the test (the first test should be if(do_bridge || > ...) rather > > than if (!do_bridge)). > > > > To Julian's defence, the use of a #ifdef BRIDGE in one place and $ifndef > > BRIDGE in the other place was confusing though. > > no, the problem is that I didn't test the 'obvious' case because it > was 'obvious' (and wrong) > > > > > Patrick. > > reimplememted? Yep I started from revision 1.64.2.5 of if_ether.c last night, and implemented what you tried to do in 1.64.2.6. I came up with the fix that you just sent to the list a few minutes ago, and it seems to be working better for me. As you said, the test in 1.64.2.6 is wrong, the one you sent earlier is the right one. The reason why I said that #ifndef BRIDGE was being confusing is that it really should have been a #ifdef BRIDGE, followed by a "if (!do_bridge)" (this is the second part of the patch). Whereas the first part of the patch is definitelly "if (do_bridge || ...)" as fixed in your post. Anyway, my test machine here seems happy now. I'll retest at some other places where I have been experiencing the same problem and I'll keep you updated if anything bad happens. Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 13:53:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 32F8A37B401; Mon, 5 Feb 2001 13:53:21 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f15LrCH25651; Mon, 5 Feb 2001 13:53:12 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102052153.f15LrCH25651@iguana.aciri.org> Subject: Re: BRIDGE breaks ARP? (more info) In-Reply-To: <3A7F0806.9B81D98@elischer.org> from Julian Elischer at "Feb 5, 2001 12: 7:34 pm" To: julian@elischer.org (Julian Elischer) Date: Mon, 5 Feb 2001 13:53:12 -0800 (PST) Cc: rizzo@aciri.org, patrick@netzuno.com, freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > [Charset iso-8859-15 unsupported, skipping...] > Luigi.. does this fix it? it looks like it essentially reverts to the old (1.75) behaviour, which means it does not fix bugs, it is only a workaround to let people run kernels with bridging compiled-in as if it was not compiled-in. I think the problem people were (and still will be) having is the following: when bridging is compiled in (and now, when bridging is enabled), arp requests do not consider the interface from which the request cam from. This is ok as long as you have bridging enabled on all of your interfaces, but there are some cases where you are doing bridging separately on clusters of interfaces, and/or no bridging at all on others, and then you need to look only at those interfaces which belong to the same "logical ethernet" as the IF from which you got the packet. This could be a single interface on which bridging is disabled, or interfaces with the same cluster-id in net.link.ether.bridge_cfg. If people wonders what is this "cluster-id" -- that code comes from some unreleased code that i wrote in 2.2.x times which makes FreeBSD work as a VLAN bridge. So the cluster-id is essentially the VLAN-ID, and the special ID 0 corresponds to a "trunk" (where essentially all traffic goes prefixed with the VLAN header). cheers luigi > > > > (void)memcpy(&itaddr, ea->arp_tpa, sizeof (itaddr)); > TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { > #ifdef BRIDGE > /* > * For a bridge, we want to check the address irrespective > * of the receive interface. (This will change slightly > * when we have clusters of interfaces). > */ > #define BRIDGE_TEST (do_bridge) > #else > #define BRIDGE_TEST 0 /* cc will optiise the test away */ > #endif > if ((BRIDGE_TEST) || (ia->ia_ifp == &ac->ac_if)) { > maybe_ia = ia; > if ((itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) || > (isaddr.s_addr == ia->ia_addr.sin_addr.s_addr)) { > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 13:56:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable026.106-200-24.mtl.mc.videotron.ca [24.200.106.26]) by hub.freebsd.org (Postfix) with SMTP id BFB4837B503 for ; Mon, 5 Feb 2001 13:56:13 -0800 (PST) Received: (qmail 86948 invoked from network); 5 Feb 2001 21:56:13 -0000 Received: from cognac.local.mindstep.com (HELO cognac) (192.168.10.9) by jacuzzi.local.mindstep.com with SMTP; 5 Feb 2001 21:56:13 -0000 From: "Patrick Bihan-Faou" To: "Julian Elischer" Cc: "Luigi Rizzo" , , , Subject: RE: BRIDGE breaks ARP? (more info) Date: Mon, 5 Feb 2001 16:57:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3A7F0EF6.2E0F8878@elischer.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi again, Maybe I am misunderstanding things, but since the arp-request we recieve are for our IP address, do we need to forward them to the other segments ? Here is my setup: [PC : 192.168.1.254]--------[rl0]---[FreeBSD : 192.168.1.1]---[fxp0]----[] On the freebsd machine I have 2 tcpdumps running looking for arps on each interface. Now if I do a "ping 192.168.1.254", I get a "arp who-as 192.168.1.1 tell 192.168.1.254" line on both tcpdumps. The arp-reply goes out only on rl0 (this seem correct). Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 14: 3:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id 949ED37B401; Mon, 5 Feb 2001 14:03:00 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id OAA64838; Mon, 5 Feb 2001 14:02:53 -0800 (PST) (envelope-from richw) Date: Mon, 5 Feb 2001 14:02:53 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Luigi Rizzo Cc: Julian Elischer , patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) In-Reply-To: <200102052153.f15LrCH25651@iguana.aciri.org> Message-ID: <20010205215641.59637.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo wrote: > it looks like it essentially reverts to the old (1.75) behaviour, > . . . when bridging is compiled in (and now, when bridging is > enabled), arp requests do not consider the interface from which > the request came from. . . . there are some cases where you are > doing bridging separately on clusters of interfaces, . . . In my case, I want to maintain two distinct clusters on my bridge -- one cluster with publicly accessible IP addresses (part of the Internet at large), and another cluster with private IP addresses (for a local network that is allowed to access the Internet only through proxies). If I implement Julian's mod in my bridge, am I going to run into problems with misdirected ARP packets? Or should I be safe because my two clusters are dealing with completely separate groups of IP addresses (one external, the other internal)? Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 14: 8:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id BA9C737B4EC; Mon, 5 Feb 2001 14:08:22 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f15M8Fl25811; Mon, 5 Feb 2001 14:08:15 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102052208.f15M8Fl25811@iguana.aciri.org> Subject: Re: BRIDGE breaks ARP? (more info) In-Reply-To: from Patrick Bihan-Faou at "Feb 5, 2001 4:57:36 pm" To: patrick@netzuno.com (Patrick Bihan-Faou) Date: Mon, 5 Feb 2001 14:08:15 -0800 (PST) Cc: julian@elischer.org, rizzo@aciri.org, freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org btw sorry but i keep getting this msg from elm when i try to reply to you... [Charset iso-8859-15 unsupported, skipping...] and it prevents me from including the original msg in the reply, i need to do a cut&paste... > Maybe I am misunderstanding things, but since the arp-request we recieve are > for our IP address, do we need to forward them to the other segments ? by the time the local stack processes the msg, bridging has already passed the request around. You can always instruct the bridging layer to do arp filtering but apart from code bloat and Layering Violation (which some would consider a federal crime), in a sense you would change the semantics -- requests are broadcast and as such should go everywhere. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 14:17:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id CF22E37B401; Mon, 5 Feb 2001 14:17:22 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f15MFQ129172; Mon, 5 Feb 2001 14:15:26 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102052215.f15MFQ129172@iguana.aciri.org> Subject: Re: BRIDGE breaks ARP? (more info) In-Reply-To: <20010205215641.59637.richw@wyattearp.stanford.edu> from Rich Wales at "Feb 5, 2001 2: 2:53 pm" To: richw@webcom.com (Rich Wales) Date: Mon, 5 Feb 2001 14:15:26 -0800 (PST) Cc: rizzo@aciri.org, julian@elischer.org, patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Luigi Rizzo wrote: > > > it looks like it essentially reverts to the old (1.75) behaviour, > > . . . when bridging is compiled in (and now, when bridging is > > enabled), arp requests do not consider the interface from which > > the request came from. . . . there are some cases where you are > > doing bridging separately on clusters of interfaces, . . . > > In my case, I want to maintain two distinct clusters on my bridge -- > one cluster with publicly accessible IP addresses (part of the Internet > at large), and another cluster with private IP addresses (for a local > network that is allowed to access the Internet only through proxies). > > If I implement Julian's mod in my bridge, am I going to run into > problems with misdirected ARP packets? Or should I be safe because > my two clusters are dealing with completely separate groups of IP > addresses (one external, the other internal)? the answer is in the first line... it will be the same as before. There are surely situation where you can have misbehaviours, though i cannot think of an easy and general example. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 14:29:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id BCB1E37B401; Mon, 5 Feb 2001 14:29:00 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id OAA67357; Mon, 5 Feb 2001 14:28:19 -0800 (PST) (envelope-from richw) Date: Mon, 5 Feb 2001 14:28:19 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Luigi Rizzo Cc: julian@elischer.org, patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (Julian's patch) In-Reply-To: <200102052215.f15MFQ129172@iguana.aciri.org> Message-ID: <20010205222630.59637.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo wrote: > the answer is in the first line... it will be the same as before. > There are surely situations where you can have misbehaviours, > though i cannot think of an easy and general example. OK, I'll try this patch (hopefully tonight, when I get home from work) and I'll let you know what happens. Thanks. Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 16:13:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id 7060D37B503; Mon, 5 Feb 2001 16:13:00 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id QAA76708; Mon, 5 Feb 2001 16:12:28 -0800 (PST) (envelope-from richw) Date: Mon, 5 Feb 2001 16:12:28 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Luigi Rizzo Cc: julian@elischer.org, patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG Subject: Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch)) In-Reply-To: <20010205222630.59637.richw@wyattearp.stanford.edu> Message-ID: <20010205234036.74638.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Good news and bad news. First the good news: The bridge is answering ARP requests for its own hardware address on the internal (rl0) interface now. I rebooted my bridge (from work, via the DSL line) just now, with a new kernel incorporating Julian's patch from earlier today. I then deleted the permanent ARP entry for the bridge on my desk- top (after setting up a delayed background command as a "dead man's switch" to restore the ARP entry if needed in case I got locked out -- remember, I was doing all this remotely). My desktop got an ARP reply from the bridge as soon as I deleted the permanent entry. I confirmed this by running "tcpdump -i rl0 arp" on the desktop. Now the bad news: ARP replies from the bridge to the DSL modem (via the external i/f) are still getting sent to the desktop (via the internal i/f), and the desktop is using them to change its idea of the bridge's hardware address. This causes a log message like the following: /kernel: arp: 171.66.188.114 moved from 00:e0:29:68:64:3e to 00:60:97:05:32:cd on rl0 The desktop can contact the bridge using either of the bridge's hardware addresses, of course -- but I still think the bridge ought to send out its ARP replies =only= on the interface from which the query came that the bridge is replying to. FWIW, the desktop is still running 4.2-RELEASE. Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 16:15: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 4AA1D37B491 for ; Mon, 5 Feb 2001 16:14:48 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f160EdM33420; Mon, 5 Feb 2001 16:14:39 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102060014.f160EdM33420@iguana.aciri.org> Subject: Re: diskless boot of a PXE-compatible machine : finally done ! In-Reply-To: from "Thierry.Herbelot@alcatel.fr" at "Feb 5, 2001 7: 0:24 pm" To: Thierry.Herbelot@alcatel.fr Date: Mon, 5 Feb 2001 16:14:39 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org in your rc.conf or rc.conf.local, you should set early_nfs_mounts="YES" so that /usr and friends are mounted before rc.diskless2 is invoked. This has worked for me at least in 3.1-something (the scripts in the CVS repository derive from the setup i have prepared on that version). not sure about the /var/db/mounttab problem because i do not see this file on my 4.x system, and strings `which mount` | grep mount does not reveal any reference to that file... maybe it is a -CURRENT thing ? cheers luigi > > Hello, > > this a simili victory report : the PC now boots via PXE (this is a Motorola > rack-mount PC, with a no-thrills BX motherboard and an fxp NIC, with a > strictly 4.2-Release installation) > > the rc.diskless2 must be wrong (I've not yet checked with -Stable), > as it tries to chmod, chgrp and find in /var > before mounting /usr (this must be a chicken-and-egg question, as a forced > /usr mount in the beginning of rc.diskless2 gives an error message about > /var/db/mounttab not being there) > > in the limited tests I have done, I have not been able to start the machine > with a strict bootp setup : the PXE ROM says there are no answers if I > force the dhcpd as a BOOTP server (I want to control the correspondance > between the MAC and IP addresses) > > the PXE boot rom is a 2.0 release, compile number 68 (is there any more > stable or better version ?) > > TfH > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 16:32: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from tao.org.uk (genesis.tao.org.uk [194.242.131.94]) by hub.freebsd.org (Postfix) with ESMTP id CA5AF37B491; Mon, 5 Feb 2001 16:31:45 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id C7C353188; Tue, 6 Feb 2001 00:31:35 +0000 (GMT) Date: Tue, 6 Feb 2001 00:31:35 +0000 From: Josef Karthauser To: Luigi Rizzo Cc: Julian Elischer , patrick@netzuno.com, freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) Message-ID: <20010206003135.B65830@tao.org.uk> References: <3A7F0806.9B81D98@elischer.org> <200102052153.f15LrCH25651@iguana.aciri.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="wq9mPyueHGvFACwf" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102052153.f15LrCH25651@iguana.aciri.org>; from rizzo@aciri.org on Mon, Feb 05, 2001 at 01:53:12PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --wq9mPyueHGvFACwf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 05, 2001 at 01:53:12PM -0800, Luigi Rizzo wrote: >=20 > If people wonders what is this "cluster-id" -- that code comes > from some unreleased code that i wrote in 2.2.x times > which makes FreeBSD work as a VLAN bridge. > So the cluster-id is essentially the VLAN-ID, and the > special ID 0 corresponds to a "trunk" (where essentially > all traffic goes prefixed with the VLAN header). >=20 Talking about trunks and VLANs, I've got some code for implementing ISL, but no ISL switches to hand anymore, if anyone's interested? Joe --wq9mPyueHGvFACwf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjp/RecACgkQXVIcjOaxUBbOqACeO7APjaqYj4YN/zDaQVNaxnnF g1wAn1dMssZZPE24ny6WXzRcXRRKYci/ =IZ0I -----END PGP SIGNATURE----- --wq9mPyueHGvFACwf-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 16:34:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 1789737B503; Mon, 5 Feb 2001 16:34:08 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f160Xrt33550; Mon, 5 Feb 2001 16:33:53 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102060033.f160Xrt33550@iguana.aciri.org> Subject: Re: Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch)) In-Reply-To: <20010205234036.74638.richw@wyattearp.stanford.edu> from Rich Wales at "Feb 5, 2001 4:12:28 pm" To: richw@webcom.com (Rich Wales) Date: Mon, 5 Feb 2001 16:33:53 -0800 (PST) Cc: rizzo@aciri.org, julian@elischer.org, patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Good news and bad news. > > First the good news: > > The bridge is answering ARP requests for its own hardware address > on the internal (rl0) interface now. expected :) > Now the bad news: > > ARP replies from the bridge to the DSL modem (via the external > i/f) are still getting sent to the desktop (via the internal i/f), this is a bit less expected -- because the reply is unicast to the MAC of the host requesting the packet, and ether_output() is called with the correct interface pointer. What do you have in net.link.ether.bridge_cfg , and do you also see the ARP reply on the 'external' side (i suppose so) ? cheers luigi > and the desktop is using them to change its idea of the bridge's > hardware address. This causes a log message like the following: > > /kernel: arp: 171.66.188.114 moved from 00:e0:29:68:64:3e > to 00:60:97:05:32:cd on rl0 > > The desktop can contact the bridge using either of the bridge's > hardware addresses, of course -- but I still think the bridge > ought to send out its ARP replies =only= on the interface from > which the query came that the bridge is replying to. > > FWIW, the desktop is still running 4.2-RELEASE. > > Rich Wales richw@webcom.com http://www.webcom.com/richw/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 16:35:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 3D27337B503; Mon, 5 Feb 2001 16:34:57 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f160YoF33564; Mon, 5 Feb 2001 16:34:50 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102060034.f160YoF33564@iguana.aciri.org> Subject: Re: BRIDGE breaks ARP? (more info) In-Reply-To: <20010206003135.B65830@tao.org.uk> from Josef Karthauser at "Feb 6, 2001 0:31:35 am" To: joe@tao.org.uk (Josef Karthauser) Date: Mon, 5 Feb 2001 16:34:50 -0800 (PST) Cc: rizzo@aciri.org, julian@elischer.org, patrick@netzuno.com, freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > If people wonders what is this "cluster-id" -- that code comes > > from some unreleased code that i wrote in 2.2.x times > > which makes FreeBSD work as a VLAN bridge. ... > Talking about trunks and VLANs, I've got some code for implementing ISL, > but no ISL switches to hand anymore, if anyone's interested? for the ignorants (like me), what does ISL mean ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 16:41:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from tao.org.uk (genesis.tao.org.uk [194.242.131.94]) by hub.freebsd.org (Postfix) with ESMTP id C448937B401; Mon, 5 Feb 2001 16:41:09 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id CF02F31FB; Tue, 6 Feb 2001 00:41:07 +0000 (GMT) Date: Tue, 6 Feb 2001 00:41:07 +0000 From: Josef Karthauser To: Luigi Rizzo Cc: julian@elischer.org, patrick@netzuno.com, freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) Message-ID: <20010206004107.C65830@tao.org.uk> References: <20010206003135.B65830@tao.org.uk> <200102060034.f160YoF33564@iguana.aciri.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="oJ71EGRlYNjSvfq7" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102060034.f160YoF33564@iguana.aciri.org>; from rizzo@aciri.org on Mon, Feb 05, 2001 at 04:34:50PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --oJ71EGRlYNjSvfq7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 05, 2001 at 04:34:50PM -0800, Luigi Rizzo wrote: > > > If people wonders what is this "cluster-id" -- that code comes > > > from some unreleased code that i wrote in 2.2.x times > > > which makes FreeBSD work as a VLAN bridge. > .. > > Talking about trunks and VLANs, I've got some code for implementing ISL, > > but no ISL switches to hand anymore, if anyone's interested? >=20 > for the ignorants (like me), what does ISL mean ? It's Cisco's precursor to 802.1q trunking. It stands for something like Inter-Switch Link. It's a jumbo ether packet with a vlan/color header encapsulating the original ether frame. Lots of small older Cisco switches have it. We could plug a FreeBSD box into, say, a c1924 and have 24 virtual interfaces from the router, each on its own vlan. :) Joe --oJ71EGRlYNjSvfq7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjp/SCMACgkQXVIcjOaxUBYObgCgk3GxPSDPmidahLeVvHB2v2pW j0cAn2sjYAT8XcIaCtPVglsgh1optcJ8 =r0VC -----END PGP SIGNATURE----- --oJ71EGRlYNjSvfq7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 16:43:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id 80C1137B491; Mon, 5 Feb 2001 16:43:01 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id QAA79111; Mon, 5 Feb 2001 16:42:01 -0800 (PST) (envelope-from richw) Date: Mon, 5 Feb 2001 16:42:01 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Luigi Rizzo Cc: julian@elischer.org, patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG Subject: Re: Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch)) In-Reply-To: <200102060033.f160Xrt33550@iguana.aciri.org> Message-ID: <20010206003554.78441.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I wrote: > > ARP replies from the bridge to the DSL modem (via the > > external i/f) are still getting sent to the desktop > > (via the internal i/f), Luigi replied: > this is a bit less expected -- because the reply is unicast to > the MAC of the host requesting the packet, and ether_output() > is called with the correct interface pointer. What do you have > in net.link.ether.bridge_cfg, and do you also see the ARP reply > on the 'external' side (i suppose so) ? net.link.ether.bridge_cfg: rl0:1,xl0:1,pcn0:2,ed0:2, I'm running two clusters. rl0/xl0 (using public IP addresses) is the one that's been involved in all the bugs I've been reporting. pcn0/ed0 (using private IP addresses) is for our children's computers. And yes, as far as I'm aware, the ARP reply is being seen by the DSL modem on the "external" side of the rl0/xl0 cluster. I did some tests last night with "tcpdump" to confirm this. If absolutely necessary, I could probably bring a laptop home from work, hook it up to the external segment (alongside the DSL modem), and run "tcpdump" on said laptop to further confirm what's showing up out there. Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 16:47:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from hera.drwilco.net (10dyn83.dh.casema.net [212.64.31.83]) by hub.freebsd.org (Postfix) with ESMTP id D117B37B684; Mon, 5 Feb 2001 16:47:36 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.2/8.11.1) with ESMTP id f1619vo03970; Tue, 6 Feb 2001 02:09:59 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010206001535.00cd8530@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Feb 2001 00:17:55 +0100 To: Julian Elischer From: "Rogier R. Mulhuijzen" Subject: Re: BRIDGE breaks ARP? (more info) Cc: Luigi Rizzo , Patrick Bihan-Faou , freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG In-Reply-To: <3A7F0806.9B81D98@elischer.org> References: <200102052011.f15KBJb24985@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Not your culpa at all. It was my patch and I made a dumb mistake. *tries to hide face in shame* DocWilco At 12:07 5-2-01 -0800, you wrote: >Ok, mea culpa > >I figured it out.. >Luigi.. does this fix it? > > > (void)memcpy(&itaddr, ea->arp_tpa, sizeof (itaddr)); > TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { >#ifdef BRIDGE > /* > * For a bridge, we want to check the address irrespective > * of the receive interface. (This will change slightly > * when we have clusters of interfaces). > */ >#define BRIDGE_TEST (do_bridge) >#else >#define BRIDGE_TEST 0 /* cc will optiise the test away */ >#endif > if ((BRIDGE_TEST) || (ia->ia_ifp == &ac->ac_if)) { > maybe_ia = ia; > if ((itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) || > (isaddr.s_addr == > ia->ia_addr.sin_addr.s_addr)) { > break; > } > } > } > if (maybe_ia == 0) { > m_freem(m); > return; > } > myaddr = ia ? ia->ia_addr.sin_addr : maybe_ia->ia_addr.sin_addr; > if (!bcmp((caddr_t)ea->arp_sha, (caddr_t)ac->ac_enaddr, > sizeof (ea->arp_sha))) { > m_freem(m); /* it's from me, ignore it. */ > return; > } > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 16:52:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id A90AF37B491; Mon, 5 Feb 2001 16:52:31 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f160qKc33712; Mon, 5 Feb 2001 16:52:20 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102060052.f160qKc33712@iguana.aciri.org> Subject: Re: Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch)) In-Reply-To: <20010206003554.78441.richw@wyattearp.stanford.edu> from Rich Wales at "Feb 5, 2001 4:42: 1 pm" To: richw@webcom.com (Rich Wales) Date: Mon, 5 Feb 2001 16:52:20 -0800 (PST) Cc: rizzo@aciri.org, julian@elischer.org, patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > external i/f) are still getting sent to the desktop > > > (via the internal i/f), > > Luigi replied: > > > this is a bit less expected -- because the reply is unicast to > > the MAC of the host requesting the packet, and ether_output() > > is called with the correct interface pointer. What do you have > > in net.link.ether.bridge_cfg, and do you also see the ARP reply > > on the 'external' side (i suppose so) ? > > net.link.ether.bridge_cfg: rl0:1,xl0:1,pcn0:2,ed0:2, > > I'm running two clusters. rl0/xl0 (using public IP addresses) is the > one that's been involved in all the bugs I've been reporting. pcn0/ed0 > (using private IP addresses) is for our children's computers. ok, i have a half idea on why this happens, though it would mean that you are being unlucky and the MAC dst-address of the arp packet collides with some address and prevents the bridging code from locating the correct interface to use for output. [of course there should not be leaks across different clusters, but this is a bug which i have already located] cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 18:42:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id 12FF137B67D; Mon, 5 Feb 2001 18:42:01 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id SAA81572; Mon, 5 Feb 2001 18:41:30 -0800 (PST) (envelope-from richw) Date: Mon, 5 Feb 2001 18:41:30 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Luigi Rizzo Cc: julian@elischer.org, patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG Subject: Re: Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch)) In-Reply-To: <200102060052.f160qKc33712@iguana.aciri.org> Message-ID: <20010206023504.81447.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi wrote: > OK, I have a half idea on why this happens, though it would > mean that you are being unlucky and the MAC dst-address of > the ARP packet collides with some address and prevents the > bridging code from locating the correct interface to use > for output. I'll assume, then, that it would help you if you knew the hardware addresses of all interfaces involved. Here they are: DSL modem (171.66.188.113): 00:00:89:2a:c5:5e Bridge (171.66.188.114): (xl0, external i/f): 00:60:97:05:32:cd (rl0, internal i/f): 00:e0:29:68:64:3e (pcn0, home net): 00:20:78:b1:74:4a (ed0, home net): 00:80:48:c6:1d:ec Desktop (171.66.188.117): 00:48:54:6d:8d:4b If you need any more info about my setup, let me know. Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 21:29:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id CE2D137B401; Mon, 5 Feb 2001 21:29:00 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id VAA84663; Mon, 5 Feb 2001 21:28:58 -0800 (PST) (envelope-from richw) Date: Mon, 5 Feb 2001 21:28:58 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Luigi Rizzo Cc: julian@elischer.org, patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG Subject: Re: Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch)) In-Reply-To: <20010206023504.81447.richw@wyattearp.stanford.edu> Message-ID: <20010206044513.83942.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I just noticed something else weird. I did "arp -a" on my bridge, and one of the entries was for the bridge itself. In other words, the bridge had an ARP entry telling it its own hardware address (on its external, "xl0" interface, in case it matters). The superfluous ARP entry was marked as permanent, FWIW. I deleted the entry (with an "arp -d" command). This doesn't seem to have affected anything; I can still contact the bridge via either interface, and I can go through the bridge, and (so far, at least) the extraneous ARP entry has not returned. I haven't a clue as to where this ARP entry came from. I couldn't find anything in any configuration file on the bridge that might have added it explicitly. I rebooted the bridge, and the ARP entry isn't there. Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 22:24:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-01.iinet.net.au (syncopation-01.iinet.net.au [203.59.24.37]) by hub.freebsd.org (Postfix) with SMTP id 5F08937B4EC for ; Mon, 5 Feb 2001 22:24:06 -0800 (PST) Received: (qmail 8167 invoked by uid 666); 6 Feb 2001 06:31:04 -0000 Received: from reggae-03-98.nv.iinet.net.au (HELO elischer.org) (203.59.78.98) by mail.m.iinet.net.au with SMTP; 6 Feb 2001 06:31:04 -0000 Message-ID: <3A7F8A4F.94D6729F@elischer.org> Date: Mon, 05 Feb 2001 21:23:27 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Luigi Rizzo Cc: patrick@netzuno.com, freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) References: <200102052153.f15LrCH25651@iguana.aciri.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo wrote: > > > [Charset iso-8859-15 unsupported, skipping...] > > Luigi.. does this fix it? > > it looks like it essentially reverts to the old (1.75) behaviour, > which means it does not fix bugs, it is only a workaround to let > people run kernels with bridging compiled-in as if it was not > compiled-in. that's what I wanted.. > > I think the problem people were (and still will be) > having is the following: > > when bridging is compiled in (and now, when bridging is enabled), > arp requests do not consider the interface from which the request > cam from. > > This is ok as long as you have bridging enabled on all of your > interfaces, but there are some cases where you are doing bridging > separately on clusters of interfaces, and/or no bridging at all on > others, and then you need to look only at those interfaces which > belong to the same "logical ethernet" as the IF from which you got > the packet. This could be a single interface on which bridging is > disabled, or interfaces with the same cluster-id in > net.link.ether.bridge_cfg. A much cleaner solution is netgraph bridging, which disconnects the top end of all but one of the interfaces from the system, and diverts all incoming data from the bridged network to come in through that single interface.. In other words, the bridge machine is just as much fooled by the bridging as all teh other machines, into thinking that both segments of the bridge are really a single segment. This is a much better way of doing it and I think that we should concentrate on adding the features needed to that, rather than fixing the old bridging, which was written when there was no alternative. Now we have a better alternative and I think we should use it instead and deprecate the old bridge code. I can add code to the netgraph bridge to allow arbitrary filtering modules to be added so that shouldn;t be a problem. > > If people wonders what is this "cluster-id" -- that code comes > from some unreleased code that i wrote in 2.2.x times > which makes FreeBSD work as a VLAN bridge. > So the cluster-id is essentially the VLAN-ID, and the > special ID 0 corresponds to a "trunk" (where essentially > all traffic goes prefixed with the VLAN header). the whole cluster idea is already present in netgraph, by simply adding different interfaces on differnet bridge nodes. No extra work is required. I think that if instead if continuing to add hack on top of hack for a system that was designed to cope with a world where a hack was the only possibility, the same effort was put into bringing the netgraph family of nodes up to scratch, we'd have a much more flexible and useful system. I'm biased of course but I think legacy bridging should be declared a dead-end and left. > > cheers > luigi > > > > > > > > > (void)memcpy(&itaddr, ea->arp_tpa, sizeof (itaddr)); > > TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { > > #ifdef BRIDGE > > /* > > * For a bridge, we want to check the address irrespective > > * of the receive interface. (This will change slightly > > * when we have clusters of interfaces). > > */ > > #define BRIDGE_TEST (do_bridge) > > #else > > #define BRIDGE_TEST 0 /* cc will optiise the test away */ > > #endif > > if ((BRIDGE_TEST) || (ia->ia_ifp == &ac->ac_if)) { > > maybe_ia = ia; > > if ((itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) || > > (isaddr.s_addr == ia->ia_addr.sin_addr.s_addr)) { > > > > -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 22:25:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from herbelot.dyndns.org (s014.dhcp212-24.cybercable.fr [212.198.24.14]) by hub.freebsd.org (Postfix) with ESMTP id 4BB8437B4EC for ; Mon, 5 Feb 2001 22:25:18 -0800 (PST) Received: from free.fr (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id HAA95657; Tue, 6 Feb 2001 07:25:13 +0100 (CET) (envelope-from thierry.herbelot@free.fr) Message-ID: <3A7F98C9.8EF274A9@free.fr> Date: Tue, 06 Feb 2001 07:25:13 +0100 From: Thierry Herbelot X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: Thierry.Herbelot@alcatel.fr, freebsd-net@FreeBSD.ORG Subject: Re: diskless boot of a PXE-compatible machine : finally done ! References: <200102060014.f160EdM33420@iguana.aciri.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo wrote: > > in your rc.conf or rc.conf.local, you should set > > early_nfs_mounts="YES" Well : (I don't find this knob in a recent -Stable machine - it is indeed in the examples) multi# cd /etc multi# grep early rc* rc:# BOOTP diskless boot. We have to run the rc file early in order to rc:# Set sysctl variables as early as we can rc.network: # Establish ipfilter ruleset as early as possible (best in rc.network6: # Choose IPv6 default interface if it is not clearly specified. multi# uname -a FreeBSD multi.XXX.YYY 4.2-STABLE FreeBSD 4.2-STABLE #0: Mon Jan 1 14:05:12 CET 2001 root@multi.XXX.YYY:/files3/recup4/obj/files3/recup4/src/sys/multi i386 multi# this exists on a 3.5-Stable machine : (in /etc/rc) if [ "X$early_nfs_mounts" != "XYES" ]; then mount -a -t nonfs else mount -a fi early_nfs_mounts was removed with revision 1.209 of rc () TfH > > so that /usr and friends are mounted before rc.diskless2 > is invoked. This has worked for me at least in 3.1-something > (the scripts in the CVS repository derive from the setup > i have prepared on that version). > > not sure about the /var/db/mounttab problem because i do not > see this file on my 4.x system, and > > strings `which mount` | grep mount > > does not reveal any reference to that file... maybe it > is a -CURRENT thing ? > > cheers > luigi > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 22:27:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 663FF37B4EC; Mon, 5 Feb 2001 22:27:04 -0800 (PST) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id OAA10431; Tue, 6 Feb 2001 14:27:00 +0800 Received: from elischer.org (reggae-03-98.nv.iinet.net.au [203.59.78.98]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id OAA22815; Tue, 6 Feb 2001 14:24:30 +0800 Message-ID: <3A7F8AFC.9BA79F4B@elischer.org> Date: Mon, 05 Feb 2001 21:26:20 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Patrick Bihan-Faou Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Patrick Bihan-Faou wrote: > > Hi again, > > Maybe I am misunderstanding things, but since the arp-request we recieve are > for our IP address, do we need to forward them to the other segments ? > > Here is my setup: > > [PC : 192.168.1.254]--------[rl0]---[FreeBSD : 192.168.1.1]---[fxp0]----[] > > On the freebsd machine I have 2 tcpdumps running looking for arps on each > interface. > > Now if I do a "ping 192.168.1.254", I get a > "arp who-as 192.168.1.1 tell 192.168.1.254" line on both tcpdumps. The > arp-reply goes out only on rl0 (this seem correct). > > Patrick. this is correct and expected.. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 22:35:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-01.iinet.net.au (syncopation-01.iinet.net.au [203.59.24.37]) by hub.freebsd.org (Postfix) with SMTP id BB99F37B4EC for ; Mon, 5 Feb 2001 22:35:17 -0800 (PST) Received: (qmail 12454 invoked by uid 666); 6 Feb 2001 06:39:52 -0000 Received: from reggae-03-98.nv.iinet.net.au (HELO elischer.org) (203.59.78.98) by mail.m.iinet.net.au with SMTP; 6 Feb 2001 06:39:52 -0000 Message-ID: <3A7F8C60.D0AA954B@elischer.org> Date: Mon, 05 Feb 2001 21:32:16 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Rich Wales Cc: Luigi Rizzo , patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) References: <20010205215641.59637.richw@wyattearp.stanford.edu> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Rich Wales wrote: > > Luigi Rizzo wrote: > > > it looks like it essentially reverts to the old (1.75) behaviour, > > . . . when bridging is compiled in (and now, when bridging is > > enabled), arp requests do not consider the interface from which > > the request came from. . . . there are some cases where you are > > doing bridging separately on clusters of interfaces, . . . > > In my case, I want to maintain two distinct clusters on my bridge -- > one cluster with publicly accessible IP addresses (part of the Internet > at large), and another cluster with private IP addresses (for a local > network that is allowed to access the Internet only through proxies). > > If I implement Julian's mod in my bridge, am I going to run into > problems with misdirected ARP packets? Or should I be safe because > my two clusters are dealing with completely separate groups of IP > addresses (one external, the other internal)? the fix is to leave the behaviour as it was before in the case where bridging is enabled and to make it behave as if bridging is not compiled in when it is disabled. The behaviour in both these cases is defined by previous behaviour. If you want two totally separate bridged networks, then netgraph bridging already does that. Just define 2 bridge nodes and connect them to the appropriate interfaces. Instead of trying to fix the old bridging which was written when netgraph was not publically available (It was as good as could be done at the time, but it was like trying to fit a square peg into a round hole.... a hack at best) the same effort should be put into making netgraph bridging do what is needed by different people. it will be a lot easier and a lot more useful in the end. > > Rich Wales richw@webcom.com http://www.webcom.com/richw/ -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 23: 1:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id CEED837B401 for ; Mon, 5 Feb 2001 23:01:00 -0800 (PST) Received: (qmail 15484 invoked by uid 666); 6 Feb 2001 07:08:39 -0000 Received: from reggae-03-98.nv.iinet.net.au (HELO elischer.org) (203.59.78.98) by mail.m.iinet.net.au with SMTP; 6 Feb 2001 07:08:39 -0000 Message-ID: <3A7F92F5.A5C7971F@elischer.org> Date: Mon, 05 Feb 2001 22:00:21 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Rich Wales Cc: Luigi Rizzo , patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG Subject: Re: Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch)) References: <20010206003554.78441.richw@wyattearp.stanford.edu> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Rich Wales wrote: > > I wrote: > > > > ARP replies from the bridge to the DSL modem (via the > > > external i/f) are still getting sent to the desktop > > > (via the internal i/f), > > Luigi replied: > > > this is a bit less expected -- because the reply is unicast to > > the MAC of the host requesting the packet, and ether_output() > > is called with the correct interface pointer. What do you have > > in net.link.ether.bridge_cfg, and do you also see the ARP reply > > on the 'external' side (i suppose so) ? > > net.link.ether.bridge_cfg: rl0:1,xl0:1,pcn0:2,ed0:2, > > I'm running two clusters. rl0/xl0 (using public IP addresses) is the > one that's been involved in all the bugs I've been reporting. pcn0/ed0 > (using private IP addresses) is for our children's computers. > > And yes, as far as I'm aware, the ARP reply is being seen by the DSL > modem on the "external" side of the rl0/xl0 cluster. I did some tests > last night with "tcpdump" to confirm this. If absolutely necessary, > I could probably bring a laptop home from work, hook it up to the > external segment (alongside the DSL modem), and run "tcpdump" on said > laptop to further confirm what's showing up out there. > What is happenning (I THINK) is that the original arp request is received on both interfaces, (it's being bridged) and two replies are sent. The last one received is taken as being true, and that is the one that came through the internal interface, and this gives that address. Both replies are sent out the 'external interface, because the bridge code knows that that is where the target is. From then on the modem will use the address of the internal address. It should still work fine though. Netgraph bridging would not have a prolem with this because there is only one interface to the system which connects to the entire bridged network and all traffic to and from the bridged network is seen as passing through that interface from the system point of view. > Rich Wales richw@webcom.com http://www.webcom.com/richw/ -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 23:23:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 1846B37B6A1; Mon, 5 Feb 2001 23:23:34 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f167NG335858; Mon, 5 Feb 2001 23:23:16 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102060723.f167NG335858@iguana.aciri.org> Subject: Re: BRIDGE breaks ARP? (more info) In-Reply-To: <3A7F8C60.D0AA954B@elischer.org> from Julian Elischer at "Feb 5, 2001 9:32:16 pm" To: julian@elischer.org (Julian Elischer) Date: Mon, 5 Feb 2001 23:23:16 -0800 (PST) Cc: richw@webcom.com, rizzo@aciri.org, patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Instead of trying to fix the old bridging which was written when netgraph was > not publically available (It was as good as could be done at the time, > but it was like trying to fit a square peg into a round hole.... a hack at > best) the same effort should be put into making netgraph > bridging do what is needed by different people. it will be a lot easier and > a lot more useful in the end. julian, it is all a matter on how much time people can dedicate to things. Feel free to improve netgraph bridging, integrate it with ipfw, etc -- i will be glad to suggest to abandon the existing bridging code when netgraph (which i consider a very nice and appealing mechanism) is on par with it (oh, do not forget performance and code size -- many many people are using picobsd images to build filtering/shaping bridges). Until then, please realize that it takes much less time to me to fix existing code than to learn how to work on netgraph modules. Not to mention that a lot of the work i have done on the past two weeks was to cleanup poorly designed or buggy interfaces, and fix the effects of some untested commits done in the past. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 23:29:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 7295737B6B3 for ; Mon, 5 Feb 2001 23:29:37 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f167TTp35897; Mon, 5 Feb 2001 23:29:29 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102060729.f167TTp35897@iguana.aciri.org> Subject: Re: diskless boot ... In-Reply-To: ll double entries in /var/db/mounttab when "rpc.umntall" is invoked To: thierry.herbelot@free.fr (Thierry Herbelot) Date: Mon, 5 Feb 2001 23:29:29 -0800 (PST) Cc: rizzo@aciri.org, Thierry.Herbelot@alcatel.fr, freebsd-net@FreeBSD.ORG, hanges@aciri.org, are:@FreeBSD.ORG Action: st patch recieved from dan ) Reply-To: pc.umntall@aciri.org, timeout@aciri.org, has@aciri.org, been@aciri.org, lowered@aciri.org, from@aciri.org, two@aciri.org, days@aciri.org (too high), to@aciri.org, one@aciri.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Luigi Rizzo wrote: > > > > in your rc.conf or rc.conf.local, you should set > > > > early_nfs_mounts="YES" > > Well : (I don't find this knob in a recent -Stable machine - it is > indeed in the examples) > multi# cd /etc > multi# grep early rc* > rc:# BOOTP diskless boot. We have to run the rc file early in order to > rc:# Set sysctl variables as early as we can > rc.network: # Establish ipfilter ruleset as early as possible (best > in > rc.network6: # Choose IPv6 default interface if it is not clearly > specified. > multi# uname -a > FreeBSD multi.XXX.YYY 4.2-STABLE FreeBSD 4.2-STABLE #0: Mon Jan 1 > 14:05:12 CET 2001 > root@multi.XXX.YYY:/files3/recup4/obj/files3/recup4/src/sys/multi i386 > multi# > > this exists on a 3.5-Stable machine : (in /etc/rc) > if [ "X$early_nfs_mounts" != "XYES" ]; then > mount -a -t nonfs > else > mount -a > fi > > early_nfs_mounts was removed with revision 1.209 of rc > () > > TfH > > > > > so that /usr and friends are mounted before rc.diskless2 > > is invoked. This has worked for me at least in 3.1-something > > (the scripts in the CVS repository derive from the setup > > i have prepared on that version). > > > > not sure about the /var/db/mounttab problem because i do not > > see this file on my 4.x system, and > > > > strings `which mount` | grep mount > > > > does not reveal any reference to that file... maybe it > > is a -CURRENT thing ? > > > > cheers > > luigi > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 5 23:34:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id B2ADD37B69C; Mon, 5 Feb 2001 23:34:12 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f167YCf35946; Mon, 5 Feb 2001 23:34:12 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102060734.f167YCf35946@iguana.aciri.org> Subject: Re: diskless boot of a PXE-compatible machine : finally done ! In-Reply-To: <3A7F98C9.8EF274A9@free.fr> from Thierry Herbelot at "Feb 6, 2001 7:25:13 am" To: green@freebsd.org Date: Mon, 5 Feb 2001 23:34:12 -0800 (PST) Cc: rizzo@aciri.org, Thierry.Herbelot@alcatel.fr, freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, while looking into diskless operation it was noticed that: > early_nfs_mounts was removed with revision 1.209 of rc > () do you remember why that was done ? It was used for diskless operation -- essentially it was needed to mount /usr before things such as "find" and "cpio" were used in the rc* scripts cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 2:12:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 29B3537B401; Tue, 6 Feb 2001 02:12:14 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f16AC9X37187; Tue, 6 Feb 2001 02:12:09 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102061012.f16AC9X37187@iguana.aciri.org> Subject: Re: Almost fixed (was Re: BRIDGE breaks ARP? (Julian's patch)) In-Reply-To: <20010206044513.83942.richw@wyattearp.stanford.edu> from Rich Wales at "Feb 5, 2001 9:28:58 pm" To: richw@webcom.com (Rich Wales) Date: Tue, 6 Feb 2001 02:12:09 -0800 (PST) Cc: rizzo@aciri.org, julian@elischer.org, patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I just noticed something else weird. > > I did "arp -a" on my bridge, and one of the entries was for the bridge > itself. > > In other words, the bridge had an ARP entry telling it its own hardware > address (on its external, "xl0" interface, in case it matters). > The superfluous ARP entry was marked as permanent, FWIW. it is not related to bridging -- i have seen this over time on many FreeBSD systems even without bridging. I do not know how the entry gets installed or deleted. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 2:16:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from onion.ish.org (onion.ish.org [210.145.219.202]) by hub.freebsd.org (Postfix) with ESMTP id 4883B37B401 for ; Tue, 6 Feb 2001 02:16:12 -0800 (PST) Received: from localhost (ishizuka@localhost [127.0.0.1]) by onion.ish.org (8.11.2/8.11.1/2000-12-01) with ESMTP id f16AGAn99544 for ; Tue, 6 Feb 2001 19:16:10 +0900 (JST) (envelope-from ishizuka@ish.org) To: freebsd-net@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) In-Reply-To: <3A7F0806.9B81D98@elischer.org> References: <200102052011.f15KBJb24985@iguana.aciri.org> <3A7F0806.9B81D98@elischer.org> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-PGP-Fingerprint20: 276D 697A C2CB 1580 C683 8F18 DA98 1A4A 50D2 C4CB X-PGP-Fingerprint16: C6 DE 46 24 D7 9F 22 EB 79 E2 90 AB 1B 9A 35 2E X-PGP-Public-Key: http://www.ish.org/pgp-public-key.txt X-URL: http://www.ish.org/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010206191610Q.ishizuka@onion.ish.org> Date: Tue, 06 Feb 2001 19:16:10 +0900 From: Masachika ISHIZUKA X-Dispatcher: imput version 20000414(IM141) Lines: 10 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Ok, mea culpa > > I figured it out.. > Luigi.. does this fix it? Thank you. This patch fixes my ARP problem. -- ishizuka@ish.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 3:51:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 2180B37B401; Tue, 6 Feb 2001 03:51:05 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id E602728E45; Tue, 6 Feb 2001 17:50:52 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 7408928DEE; Tue, 6 Feb 2001 17:50:52 +0600 (ALMT) Date: Tue, 6 Feb 2001 17:50:52 +0600 (ALMT) From: Boris Popov To: freebsd-arch@freebsd.org Cc: freebsd-net@freebsd.org Subject: CFR: Sequential mbuf read/write extensions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Please trim CC list as necessary] Hello, Before starting import process for smbfs, I would like to introduce new API which greatly simplifies process of packaging data into mbufs and fetching it back (in fact, similar API already presented in the tree, but it is private to the netncp code and it will be really nice to share it). Basically, it requires additional structure (working context) and related functions: struct mbdata { struct mbuf * mb_top; struct mbuf * mb_cur; u_char * mb_pos; int mb_count; }; Where mb_top points at the first mbuf in the chain and mb_cur to the current mbuf. Here is a slightly truncated API to illustrate how it works: int mb_init(struct mbdata *mbp); int mb_initm(struct mbdata *mbp, struct mbuf *m); int mb_done(struct mbdata *mbp); int mb_put_byte(struct mbdata *mbp, u_int8_t x); int mb_put_wordbe(struct mbdata *mbp, u_int16_t x); int mb_put_wordle(struct mbdata *mbp, u_int16_t x); int mb_put_dwordbe(struct mbdata *mbp, u_int32_t x); int mb_get_byte(struct mbdata *mbp, u_int8_t *x); int mb_get_word(struct mbdata *mbp, u_int16_t *x); int mb_get_wordle(struct mbdata *mbp, u_int16_t *x); int mb_get_wordbe(struct mbdata *mbp, u_int16_t *x); The mb_put* functions allow to append new data to mbuf chain. These functions take care about necessary mbuf allocations and additional data conversions. For example, mb_put_wordbe will store a 16 bit integer in the network format while mb_put_wordle will convert it to the little endian format if necessary. The mb_get* functions allow to fetch data from mbuf chains with appropriate handling of mbuf borders and data conversions. Here is a simple examples (error checks are omitted): Send: error = mb_init(mbp); if (error) return error; mb_put_mem(mbp, SMB_SIGNATURE, SMB_SIGLEN, MB_MSYSTEM); mb_put_byte(mbp, cmd); mb_put_dwordle(mbp, 1234); mb_put_byte(mbp, vcp->vc_hflags); mb_fixhdr(mbp); my_great_send_function(mbp->mb_top); mb_done(mbp); Receive: mb_initm(mbp, just_received_mbuf_chain); mb_get_byte(mbp, &rqp->sr_rpflags); mb_get_wordle(mbp, &rqp->sr_rpflags2); mb_get_dword(mbp, &tdw); mb_get_dword(mbp, &tdw); mb_get_dword(mbp, &tdw); mb_get_wordle(mbp, &rqp->sr_rptid); mb_get_wordle(mbp, &rqp->sr_rppid); mb_get_wordle(mbp, &rqp->sr_rpuid); mb_get_wordle(mbp, &rqp->sr_rpmid); Since currently there isn't many consumers of this code I can suggest to define an option LIBMBUF in the kernel configuration file and add KLD libmbuf (with interface libmbuf), so kernel footprint will not be significantly affected. The names of source and header files are questionable too and I would appreciate good suggestions (currently they are subr_mbuf.c and subr_mbuf.h). Well, and finally here you will find full source code of proposed API: http://www.butya.kz/~bp/mbuf/ Any comments and suggestions are greatly appreciated. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 10:13:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153]) by hub.freebsd.org (Postfix) with ESMTP id 5D0F237B69C; Tue, 6 Feb 2001 10:13:09 -0800 (PST) Received: from frmta003.netfr.alcatel.fr (frmta003.netfr.alcatel.fr [155.132.251.32]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id TAA03287; Tue, 6 Feb 2001 19:13:13 +0100 (MET) Received: by frmta003.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C12569EB.00641367 ; Tue, 6 Feb 2001 19:13:05 +0100 X-Lotus-FromDomain: ALCATEL From: Thierry.Herbelot@alcatel.fr To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Message-ID: Date: Tue, 6 Feb 2001 19:13:01 +0100 Subject: What is the latest "known-good" PXE build ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I'm trying to use the pxeboot loader from 4.2-RELEASE, to diskless boot some rack-mount PCs. Using documentation from Alfred Perlstein and Mike Smith, I've configured a DHCP server and a tftp server, and I'm still having problems with at least one machine not being able to start each time it is powered on : BTX halts (sometimes it is "Stack underflow", some other times, it goes to a register crash dump, with eip often equal to ffffff - I'm going to redirect the BIOS output to a serial port) the configuration of the server must be correct as the diskless machine sometimes can start (it loads pxeboot and the kernel via tftp, and then the rest of the partitions via NFS). The BIOS trace says the PXE is revision 2.0, build 68 : is there some other, perhaps better version of it ? (the on-board NIC on the machine is an fxp) TfH PS : As I've seen, rc has been modified to get rid of "early_nfs_mounts". After this change, the rc.diskless2 does no longer work, as this script uses /usr/bin/find and /usr is not yet mounted. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 10:30:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 67FBF37B401 for ; Tue, 6 Feb 2001 10:30:02 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f16ITwD16942; Tue, 6 Feb 2001 10:29:58 -0800 (PST) Date: Tue, 6 Feb 2001 10:29:58 -0800 From: Alfred Perlstein To: Luigi Rizzo Cc: net@freebsd.org Subject: IPFIREWALL + BRIDGE + IPDIVERT doesn't work? Message-ID: <20010206102958.N26076@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Let me apologize in advance for this shoddyish bug report. In a recent -stable (since the new ipfw fixes) if you build a kernel with options: IPFIREWALL IPFIREWALL_VERBOSE IPFIREWALL_DEFAULT_TO_ACCEPT IPDIVERT BRIDGE DUMMYNET You wind up with a kernel that doesn't grok the ipfw 'via' keyword. Basically any rule that has a 'via' in it makes the userland ipfw tool get a 'invalid setsockopt'. Anyone booting a kernel on a system that relies on 'via' keywords is in for a big suprise as all those rules won't load. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 10:32:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 63C1737B491; Tue, 6 Feb 2001 10:32:17 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f16IXZ000881; Tue, 6 Feb 2001 10:33:36 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200102061833.f16IXZ000881@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thierry.Herbelot@alcatel.fr Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: What is the latest "known-good" PXE build ? In-reply-to: Your message of "Tue, 06 Feb 2001 19:13:01 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Feb 2001 10:33:35 -0800 From: Mike Smith Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > The BIOS trace says the PXE is revision 2.0, build 68 : is there some other, > perhaps better version of it ? (the on-board NIC on the machine is an fxp) Build 068 is a disaster; you ideally want 082 or later. > PS : As I've seen, rc has been modified to get rid of > "early_nfs_mounts". After this change, the rc.diskless2 does no longer > work, as this script uses /usr/bin/find and /usr is not yet mounted. I haven't tracked these changes, and am still using some slightly older rc files. I've updated my rc.diskless stuff to use mdconfig now though; if there's interest I'll put it up for review. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 10:35:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id AE3E937B6CB; Tue, 6 Feb 2001 10:34:46 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f16IYkl41554; Tue, 6 Feb 2001 10:34:46 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102061834.f16IYkl41554@iguana.aciri.org> Subject: Re: What is the latest "known-good" PXE build ? In-Reply-To: <200102061833.f16IXZ000881@mass.dis.org> from Mike Smith at "Feb 6, 2001 10:33:35 am" To: msmith@FreeBSD.ORG (Mike Smith) Date: Tue, 6 Feb 2001 10:34:46 -0800 (PST) Cc: Thierry.Herbelot@alcatel.fr, freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I haven't tracked these changes, and am still using some slightly older > rc files. I've updated my rc.diskless stuff to use mdconfig now though; > if there's interest I'll put it up for review. yes please... i'd like to fix things as needed so that diskless scripts work correctly in our next release (4.3) and current. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 10:36:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 8699637B491; Tue, 6 Feb 2001 10:36:15 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f16IaFl41590; Tue, 6 Feb 2001 10:36:15 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102061836.f16IaFl41590@iguana.aciri.org> Subject: Re: What is the latest "known-good" PXE build ? In-Reply-To: <200102061833.f16IXZ000881@mass.dis.org> from Mike Smith at "Feb 6, 2001 10:33:35 am" To: msmith@FreeBSD.ORG (Mike Smith) Date: Tue, 6 Feb 2001 10:36:15 -0800 (PST) Cc: Thierry.Herbelot@alcatel.fr, freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > The BIOS trace says the PXE is revision 2.0, build 68 : is there some other, > > perhaps better version of it ? (the on-board NIC on the machine is an fxp) > > Build 068 is a disaster; you ideally want 082 or later. is there some standard way to upgrade the pxe code on the cards ? in case, where do i get it from ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 10:41:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id E955137B491 for ; Tue, 6 Feb 2001 10:41:01 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f16If1041610; Tue, 6 Feb 2001 10:41:01 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102061841.f16If1041610@iguana.aciri.org> Subject: Re: IPFIREWALL + BRIDGE + IPDIVERT doesn't work? In-Reply-To: <20010206102958.N26076@fw.wintelcom.net> from Alfred Perlstein at "Feb 6, 2001 10:29:58 am" To: bright@wintelcom.net (Alfred Perlstein) Date: Tue, 6 Feb 2001 10:39:40 -0800 (PST) Cc: rizzo@aciri.org, net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org i assume you have upgraded the .h files in /usr/include/net and /usr/include/netinet and recompiled the userland ipfw, right ? your report is kind of strange because none of the recent changes (unless you mean the tcp security fixes) involves additional specifiers in ipfw rules. Sure the ipfw struct and the pipe descriptor have changed size, but then the problem would occur for all rules not just the "via" ones. can you give use some more detail ? cheers luigi > Let me apologize in advance for this shoddyish bug report. > > In a recent -stable (since the new ipfw fixes) if you build > a kernel with options: > > IPFIREWALL > IPFIREWALL_VERBOSE > IPFIREWALL_DEFAULT_TO_ACCEPT > IPDIVERT > BRIDGE > DUMMYNET > > You wind up with a kernel that doesn't grok the ipfw 'via' keyword. > > Basically any rule that has a 'via' in it makes the userland ipfw > tool get a 'invalid setsockopt'. Anyone booting a kernel on a > system that relies on 'via' keywords is in for a big suprise as > all those rules won't load. > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 10:46:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 6DD1137B401 for ; Tue, 6 Feb 2001 10:45:54 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f16Ijsk17564; Tue, 6 Feb 2001 10:45:54 -0800 (PST) Date: Tue, 6 Feb 2001 10:45:53 -0800 From: Alfred Perlstein To: Luigi Rizzo Cc: net@freebsd.org Subject: Re: IPFIREWALL + BRIDGE + IPDIVERT doesn't work? Message-ID: <20010206104553.P26076@fw.wintelcom.net> References: <20010206102958.N26076@fw.wintelcom.net> <200102061841.f16If1041610@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102061841.f16If1041610@iguana.aciri.org>; from rizzo@aciri.org on Tue, Feb 06, 2001 at 10:39:40AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Luigi Rizzo [010206 10:41] wrote: > i assume you have upgraded the .h files in > /usr/include/net and /usr/include/netinet and recompiled > the userland ipfw, right ? Yes, buildworld/installworld was done. > your report is kind of strange because none of the recent > changes (unless you mean the tcp security fixes) involves > additional specifiers in ipfw rules. This is post-security fixes. > Sure the ipfw struct and the pipe descriptor have changed size, > but then the problem would occur for all rules not just the "via" > ones. I thought so as well, but simple rules without via work... > can you give use some more detail ? Yea, I'll try, it would be helpful if you could try to boot a kernel with all those options just to make sure it's not just me. -Alfred > > Let me apologize in advance for this shoddyish bug report. > > > > In a recent -stable (since the new ipfw fixes) if you build > > a kernel with options: > > > > IPFIREWALL > > IPFIREWALL_VERBOSE > > IPFIREWALL_DEFAULT_TO_ACCEPT > > IPDIVERT > > BRIDGE > > DUMMYNET > > > > You wind up with a kernel that doesn't grok the ipfw 'via' keyword. > > > > Basically any rule that has a 'via' in it makes the userland ipfw > > tool get a 'invalid setsockopt'. Anyone booting a kernel on a > > system that relies on 'via' keywords is in for a big suprise as > > all those rules won't load. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 10:49:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 2A3E737B491; Tue, 6 Feb 2001 10:48:48 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f16Io9001002; Tue, 6 Feb 2001 10:50:09 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200102061850.f16Io9001002@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: What is the latest "known-good" PXE build ? In-reply-to: Your message of "Tue, 06 Feb 2001 10:36:15 PST." <200102061836.f16IaFl41590@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Feb 2001 10:50:09 -0800 From: Mike Smith Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > The BIOS trace says the PXE is revision 2.0, build 68 : is there some other, > > > perhaps better version of it ? (the on-board NIC on the machine is an fxp) > > > > Build 068 is a disaster; you ideally want 082 or later. > > is there some standard way to upgrade the pxe code on the cards ? > in case, where do i get it from ? You should be able to get updates from Intel, or if you have access to a Windows development system you can grab the PXE reference implementation kit and build your own. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 10:49:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from ebola.biohz.net (ebola.biohz.net [206.80.1.35]) by hub.freebsd.org (Postfix) with ESMTP id 19DE437B684; Tue, 6 Feb 2001 10:49:20 -0800 (PST) Received: from flu (localhost [127.0.0.1]) by ebola.biohz.net (Postfix) with SMTP id A84C63A4C6; Mon, 5 Feb 2001 13:09:57 -0800 (PST) Message-ID: <01f301c08fb7$fe86ad00$0402010a@biohz.net> From: "Renaud Waldura" To: Cc: , References: <000801c08f1e$e277d970$3227e540@johnny2k> Subject: Re: Firewalling a PPPoE, any easy workaround to MTU on lan stations? Date: Mon, 5 Feb 2001 13:09:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If all you want is sort out the MTU mess, you only need to download the latest ppp sources from Brian's site at: http://www.Awfulhak.org/ppp.html Compile, install, and include: enable tcpmssfixup in your /etc/ppp/ppp.conf. --Renaud ----- Original Message ----- From: "John Telford" To: "Vince Vielhaber" ; "Rogier R. Mulhuijzen" Cc: "Brian Somers" ; "Julian Elischer" ; ; Sent: Sunday, February 04, 2001 6:53 PM Subject: Re: Firewalling a PPPoE, any easy workaround to MTU on lan stations? > Hmm my timing for this topic seems right on :) > Since I ran out of disk space trying to update to -stable this afternoon > (now that's another topic for another day "Why so much space to keep up > with -stable, when /stand/sysinstall can do an inplace update ?") > So should a throw another drive in this thing and go -stable or not ? > What does MFC'd mean ? > Perhaps a summary of each of your thoughts would help me ? > Thanks, I really appreaciate all the help. > Regards, John. > > ----- Original Message ----- > From: "Vince Vielhaber" > To: "Rogier R. Mulhuijzen" > Cc: "Brian Somers" ; "Julian Elischer" > ; "John Telford" ; > ; > Sent: Sunday, February 04, 2001 7:28 PM > Subject: Re: Firewalling a PPPoE, any easy workaround to MTU on lan > stations? > > > > On Mon, 5 Feb 2001, Rogier R. Mulhuijzen wrote: > > > > > At 22:50 4-2-01 +0000, Brian Somers wrote: > > > > > John Telford wrote: > > > > > > > > > > > > I'm putting a 4.2 R firewall in for a ppoe connection. > (sympatico) > > > > > > Is there any workaround I can use so I don't have to reduce the > MTU > > > > on all > > > > > > the internal stations ? > > > > > > It's a mix of Windows 9x and Macs. And I've found only one utility > > > > capable > > > > > > of adjusting MTU on Macs. > > > > > > Can anything be done on the freebsd box as the traffic goes > through it ? > > > > > > Thanks in advance, John. > > > > > > P.S. the pppoe setup went fine thanks to a page at > www.sympaticousers.org > > > > > > and some further notes at www.freebsddiary.org > > > > > > > > > > > > > > > ppp now has an option where it will force the negotiated packet size > > > > > of new tcp sessions going through it down. (i.e it fiddles with the > > > > packets) > > > > > check the man page.. I THINK it may be in 4.2, if not it's > in -Stable > > > > > > > >It didn't make 4.2 - it was MFC'd on December 18 :-( > > > > > > Brian, may I quote you from a different thread? =) > > > > > > "I think I've figured out the problem though... can you try the latest > > > version of ppp - should be available via > > > http://www.Awfulhak.org/ppp.html RSN (the 010204 archive) if you > > > don't get -current. " > > > > > > John might not need that version, but shouldn't he be able to run a > newer > > > ppp on his 4.2-R without hitches? > > > > No reason why not.. I'm doing it. > > > > Vince. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 10:59:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 2968337B401; Tue, 6 Feb 2001 10:59:01 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f16Iwkd17957; Tue, 6 Feb 2001 10:58:46 -0800 (PST) Date: Tue, 6 Feb 2001 10:58:46 -0800 From: Alfred Perlstein To: Boris Popov Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: Sequential mbuf read/write extensions Message-ID: <20010206105846.Q26076@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bp@butya.kz on Tue, Feb 06, 2001 at 05:50:52PM +0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Boris Popov [010206 03:51] wrote: > [Please trim CC list as necessary] > > Hello, > > Before starting import process for smbfs, I would like to > introduce new API which greatly simplifies process of packaging data into > mbufs and fetching it back (in fact, similar API already presented in the > tree, but it is private to the netncp code and it will be really nice to > share it). [snip] Looks really cool, I can't get to http://www.butya.kz/~bp/mbuf/, but from the examples it looks very useful. I was wondering if you planned or already had an API for reading/writing from/into host/network byte order? Not that it's needed, but would be nice to have. Also any chance we'll get manpages that describe these functions/macros? On other idea is to give each op a 'count' parameter, your examples seem to show various functions being called several times in a row, maybe they would help optimize certain codepaths? Not that any of these suggestions are really required, I just wanted to give you some feedback. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 11:23:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id 6DEC637B401; Tue, 6 Feb 2001 11:23:00 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id LAA12268; Tue, 6 Feb 2001 11:22:03 -0800 (PST) (envelope-from richw) Date: Tue, 6 Feb 2001 11:22:03 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Luigi Rizzo Cc: Julian Elischer , patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) In-Reply-To: <200102060723.f167NG335858@iguana.aciri.org> Message-ID: <20010206190650.09873.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I agree with Luigi's sentiments on the current bridging vs. netgraph. I'll be more than happy to switch over to using netgraph bridging, as soon as it has the features I need -- specifically, firewall filtering via ipfw, ipfilter, or something equivalent. Lack of filtering in the current netgraph code is, for me, a non-negotiable showstopper. Until that's been dealt with, I need the current bridging code to work properly. I'm very grateful for everything that people have been doing in this regard during the past several days. My bridge basically seems to be running OK now. The only remaining problem I'm aware of right now (and it's a nuisance, but not a showstopping bug) is the "dueling ARP reply" issue, where both interfaces on the bridge are advertising themselves to my desktop system. Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 11:23:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from illustrious.cnchost.com (illustrious.concentric.net [207.155.252.7]) by hub.freebsd.org (Postfix) with ESMTP id 9876637B4EC for ; Tue, 6 Feb 2001 11:23:25 -0800 (PST) Received: from auvo.com (4032268D.ptr.dia.nextlink.net [64.50.38.141]) by illustrious.cnchost.com id OAA17220; Tue, 6 Feb 2001 14:23:24 -0500 (EST) [ConcentricHost SMTP Relay 1.10] Message-ID: <3A804EEA.34BB4099@auvo.com> Date: Tue, 06 Feb 2001 13:22:18 -0600 From: Mike Bytnar Reply-To: mbytnar@auvo.com Organization: Auvo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: NFS - 'showmount' returns non-existant connections Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Has anyone else encountered showmount returning connections that do not exist? I have kill'ed the portmap, nfs*, and mountd processes with no luck. I have even rebooted and the same mount information shows up, although no attempt has been made to mount the directories from remote. Further, any new connections create additional entries in the list returned by showmount. Any ideas? Thanks, --Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 11:28: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 77F5837B6A2 for ; Tue, 6 Feb 2001 11:27:44 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA34069; Tue, 6 Feb 2001 14:27:31 -0500 (EST) (envelope-from wollman) Date: Tue, 6 Feb 2001 14:27:31 -0500 (EST) From: Garrett Wollman Message-Id: <200102061927.OAA34069@khavrinen.lcs.mit.edu> To: mbytnar@auvo.com Cc: freebsd-net@FreeBSD.ORG Subject: NFS - 'showmount' returns non-existant connections In-Reply-To: <3A804EEA.34BB4099@auvo.com> References: <3A804EEA.34BB4099@auvo.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Has anyone else encountered showmount returning connections that do not > exist? Since NFS is usually connectionless, the best `showmount' can do is to tell you which clients have *ever* received the root file handle for the given filesystem. (Until such time as that file system is recreated, posession of the file handle is enough information for the client to access the file system when the NFS server is running.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 13: 1:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 0514C37B401 for ; Tue, 6 Feb 2001 13:01:36 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f16L1PI44593; Tue, 6 Feb 2001 13:01:25 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102062101.f16L1PI44593@iguana.aciri.org> Subject: Re: IPFIREWALL + BRIDGE + IPDIVERT doesn't work? In-Reply-To: <20010206104553.P26076@fw.wintelcom.net> from Alfred Perlstein at "Feb 6, 2001 10:45:53 am" To: bright@wintelcom.net (Alfred Perlstein) Date: Tue, 6 Feb 2001 13:01:25 -0800 (PST) Cc: rizzo@aciri.org, net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org well i just tested things here and everything works fine. "via" rules are accepted. i have the same set of options that you mentioned IPFW DIVERT open firewall dummynet and bridge. This is on an essentially up-to-date STABLE (net/ and netinet/ are same as in -stable). cheers luigi > * Luigi Rizzo [010206 10:41] wrote: > > i assume you have upgraded the .h files in > > /usr/include/net and /usr/include/netinet and recompiled > > the userland ipfw, right ? > > Yes, buildworld/installworld was done. > > > your report is kind of strange because none of the recent > > changes (unless you mean the tcp security fixes) involves > > additional specifiers in ipfw rules. > > This is post-security fixes. > > > Sure the ipfw struct and the pipe descriptor have changed size, > > but then the problem would occur for all rules not just the "via" > > ones. > > I thought so as well, but simple rules without via work... > > > can you give use some more detail ? > > Yea, I'll try, it would be helpful if you could try to boot a kernel > with all those options just to make sure it's not just me. > > -Alfred > > > > Let me apologize in advance for this shoddyish bug report. > > > > > > In a recent -stable (since the new ipfw fixes) if you build > > > a kernel with options: > > > > > > IPFIREWALL > > > IPFIREWALL_VERBOSE > > > IPFIREWALL_DEFAULT_TO_ACCEPT > > > IPDIVERT > > > BRIDGE > > > DUMMYNET > > > > > > You wind up with a kernel that doesn't grok the ipfw 'via' keyword. > > > > > > Basically any rule that has a 'via' in it makes the userland ipfw > > > tool get a 'invalid setsockopt'. Anyone booting a kernel on a > > > system that relies on 'via' keywords is in for a big suprise as > > > all those rules won't load. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 13:44:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id 5713337B401; Tue, 6 Feb 2001 13:44:11 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id NAA25812; Tue, 6 Feb 2001 13:43:05 -0800 (PST) (envelope-from richw) Date: Tue, 6 Feb 2001 13:43:05 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Luigi Rizzo Cc: Julian Elischer , patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG Subject: Dueling ARP replies and firewall filtering In-Reply-To: <20010206190650.09873.richw@wyattearp.stanford.edu> Message-ID: <20010206212535.24026.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Another thought about the "dueling ARP reply" issue. In one way, I suppose it's not a serious problem, because even if the "wrong" hardware address gets cached, packets still get through, and communication is not cut off. On the other hand, it =may= be a problem from a security standpoint. Suppose I want to protect myself from spoofing attacks, by ensuring that traffic from a given IP address only uses a specific interface. In my case, since I =know= that my desktop is connected to my bridge via the bridge's "rl0" NIC, any traffic arriving on the bridge's "xl0" NIC (my link to the Internet at large) -- but claiming to be from the desktop's IP address -- is clearly a sign of an impostor trying to break into my network. Now, if I were using a conventional (non-bridge) router, I could pro- tect myself from such spoof attacks by tailoring my firewall rules to match the receiving interface, as well as the IP address. I =think= I should be able to do the same with a bridging router too, but will this work if the desktop is using the "wrong" MAC address to contact the bridge? Stated another way, if my desktop thinks that the bridge's MAC address is the address of its "xl0" NIC, does this mean that traffic arriving on the bridge from the desktop will appear (for firewall purposes) to be arriving via "xl0" -- even though it really came in via "rl0"? Julian, when the firewall code (ipfw or ipfilter, I don't really care which) is finally integrated into the netgraph bridge code, will this issue be taken into account? Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 13:47:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id BDA3937B4EC; Tue, 6 Feb 2001 13:47:25 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f16LlKQ44847; Tue, 6 Feb 2001 13:47:20 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102062147.f16LlKQ44847@iguana.aciri.org> Subject: Re: Dueling ARP replies and firewall filtering In-Reply-To: <20010206212535.24026.richw@wyattearp.stanford.edu> from Rich Wales at "Feb 6, 2001 1:43: 5 pm" To: richw@webcom.com (Rich Wales) Date: Tue, 6 Feb 2001 13:47:20 -0800 (PST) Cc: rizzo@aciri.org, julian@elischer.org, patrick@netzuno.com, freebsd-net@FreeBSD.ORG, julian@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Another thought about the "dueling ARP reply" issue. people, it's a minor bug, i am looking into fixing it, just be patient. Securitywise, also remember that all bridges or switches can 'leak' packets to interfaces other than the one where the designated receiver is. cheers luigi > In one way, I suppose it's not a serious problem, because even if > the "wrong" hardware address gets cached, packets still get through, > and communication is not cut off. > > On the other hand, it =may= be a problem from a security standpoint. > Suppose I want to protect myself from spoofing attacks, by ensuring > that traffic from a given IP address only uses a specific interface. > > In my case, since I =know= that my desktop is connected to my bridge > via the bridge's "rl0" NIC, any traffic arriving on the bridge's "xl0" > NIC (my link to the Internet at large) -- but claiming to be from the > desktop's IP address -- is clearly a sign of an impostor trying to > break into my network. > > Now, if I were using a conventional (non-bridge) router, I could pro- > tect myself from such spoof attacks by tailoring my firewall rules to > match the receiving interface, as well as the IP address. I =think= > I should be able to do the same with a bridging router too, but will > this work if the desktop is using the "wrong" MAC address to contact > the bridge? > > Stated another way, if my desktop thinks that the bridge's MAC address > is the address of its "xl0" NIC, does this mean that traffic arriving > on the bridge from the desktop will appear (for firewall purposes) to > be arriving via "xl0" -- even though it really came in via "rl0"? > > Julian, when the firewall code (ipfw or ipfilter, I don't really care > which) is finally integrated into the netgraph bridge code, will this > issue be taken into account? > > Rich Wales richw@webcom.com http://www.webcom.com/richw/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 15:23:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id C314437B491; Tue, 6 Feb 2001 15:23:14 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1000) id 59CEF2B5D7; Tue, 6 Feb 2001 17:23:14 -0600 (CST) Date: Tue, 6 Feb 2001 15:23:14 -0800 From: Paul Saab To: Mike Smith Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: What is the latest "known-good" PXE build ? Message-ID: <20010206152314.A20757@elvis.mu.org> References: <200102061836.f16IaFl41590@iguana.aciri.org> <200102061850.f16Io9001002@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102061850.f16Io9001002@mass.dis.org>; from msmith@freebsd.org on Tue, Feb 06, 2001 at 10:50:09AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Smith (msmith@freebsd.org) wrote: > > > > The BIOS trace says the PXE is revision 2.0, build 68 : is there some other, > > > > perhaps better version of it ? (the on-board NIC on the machine is an fxp) > > > > > > Build 068 is a disaster; you ideally want 082 or later. > > > > is there some standard way to upgrade the pxe code on the cards ? > > in case, where do i get it from ? > > You should be able to get updates from Intel, or if you have access to a > Windows development system you can grab the PXE reference implementation > kit and build your own. You still need the code to drive the nic, and noone gives this out. I have the latest stuff at: http://people.freebsd.org/~ps/pxeroms/ Unfortunately you need windows to extract the files.. I can put up a few more of the files later when I get back from Munich which wont require you to use windows. -- Paul Saab Technical Yahoo paul@mu.org - ps@yahoo-inc.com - ps@freebsd.org Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 18:18:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id E3C2437B401; Tue, 6 Feb 2001 18:17:59 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id 40E6B29059; Wed, 7 Feb 2001 08:17:54 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 312C628698; Wed, 7 Feb 2001 08:17:54 +0600 (ALMT) Date: Wed, 7 Feb 2001 08:17:53 +0600 (ALMT) From: Boris Popov To: Alfred Perlstein Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: Sequential mbuf read/write extensions In-Reply-To: <20010206105846.Q26076@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 6 Feb 2001, Alfred Perlstein wrote: > Looks really cool, I can't get to http://www.butya.kz/~bp/mbuf/, > but from the examples it looks very useful. Sorry, server was brought down and I wasn't notified :(. It should be ok now. > I was wondering if you planned or already had an API for reading/writing > from/into host/network byte order? Not that it's needed, but would > be nice to have. Also any chance we'll get manpages that describe > these functions/macros? Yes, the header file contains macros which supports not only host to network (big-endian) byte order conversion, but also to the little-endian byte order. And of course, there will be a manpage(s) if this is going to become a part of kernel API. > On other idea is to give each op a 'count' parameter, your examples > seem to show various functions being called several times in a row, > maybe they would help optimize certain codepaths? Yes, there is a mb_{get|put}_mem() functions which allow reading/writing of big memory regions (including user space). So, if protocol is well designed and layout of the packet can be described as structure, it is possible to fill it in the normal memory and copy the mbuf chain in single operation. > > Not that any of these suggestions are really required, I just wanted > to give you some feedback. :) Thanks :) -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 19:42:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 30A4E37B491; Tue, 6 Feb 2001 19:42:27 -0800 (PST) Received: from jehovah ([24.201.144.31]) by VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G8DBJZ05.88O; Tue, 6 Feb 2001 22:40:47 -0500 Message-ID: <003001c090b8$0b067a50$1f90c918@jehovah> From: "Bosko Milekic" To: "Boris Popov" , Cc: References: Subject: Re: Sequential mbuf read/write extensions Date: Tue, 6 Feb 2001 22:42:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Boris Popov wrote: [...] > Since currently there isn't many consumers of this code I can > suggest to define an option LIBMBUF in the kernel configuration file and > add KLD libmbuf (with interface libmbuf), so kernel footprint will not be I am in favor of such an option on the condition that it is temporary. In other words, only until we decide "we have converted enough code to use this code so we should remove the option now." The reason is that otherwise, we will be faced with numerous "#ifdef LIBMBUF ... #else ... #endif" code. I assume this is what you meant, anyway, so I have no objections. :-) The API looks great by the way, and I will try to give a more detailed review in the next few days. :-) For now: #define M_TRYWAIT M_WAIT is not right. (M_WAIT is no longer to be used in the mbuf code.) The succesfull return values are 0, I don't have a problem with this, specifically, but I would assume that this: if (!mb_init(mbp)) ... would be more "logical" (I use the term loosely) if it meant: "if initialization fails" (now it means "if initialization is succesful"). > significantly affected. The names of source and header files are > questionable too and I would appreciate good suggestions (currently they > are subr_mbuf.c and subr_mbuf.h). Hmmm. Maybe subr_mblib.c and libmb.h ? I don't want to turn this into a bikeshed ( :-) ), so I suggest that you decide. Personally, I would prefer that it be something other than "subr_mbuf.c" simply because it may be a little misleading in some cases. > Well, and finally here you will find full source code of proposed > API: http://www.butya.kz/~bp/mbuf/ > > Any comments and suggestions are greatly appreciated. > > -- > Boris Popov > http://www.butya.kz/~bp/ Boris, this is really a great interface and nice looking, clean code. Thank you! Regards, Bosko. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 20:40:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by hub.freebsd.org (Postfix) with ESMTP id CEB1637B491; Tue, 6 Feb 2001 20:40:03 -0800 (PST) Received: from johnny2k ([64.229.44.2]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010207044002.YYD20800.tomts5-srv.bellnexxia.net@johnny2k>; Tue, 6 Feb 2001 23:40:02 -0500 Message-ID: <002601c090c0$1e6e7590$022ce540@johnny2k> From: "John Telford" To: "Renaud Waldura" Cc: , References: <000801c08f1e$e277d970$3227e540@johnny2k> <01f301c08fb7$fe86ad00$0402010a@biohz.net> Subject: Re: Firewalling a PPPoE, any easy workaround to MTU on lan stations? Date: Tue, 6 Feb 2001 23:40:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks, thats now my plan. Thanks to the pointer from Matthew Emmerton to your articles too, good stuff. I also got a bigger hard drive because I will have to update this thing sooner or later so may as well start off with enough drive space. I now have a new easy question for you all, watch for it in -questions. Regards to all, John. > If all you want is sort out the MTU mess, you only need to download the > latest ppp sources from Brian's site at: > > http://www.Awfulhak.org/ppp.html > > Compile, install, and include: > > enable tcpmssfixup > > in your /etc/ppp/ppp.conf. > > --Renaud > > > > ----- Original Message ----- > From: "John Telford" > To: "Vince Vielhaber" ; "Rogier R. Mulhuijzen" > > Cc: "Brian Somers" ; "Julian Elischer" > ; ; > > Sent: Sunday, February 04, 2001 6:53 PM > Subject: Re: Firewalling a PPPoE, any easy workaround to MTU on lan > stations? > > > > Hmm my timing for this topic seems right on :) > > Since I ran out of disk space trying to update to -stable this afternoon > > (now that's another topic for another day "Why so much space to keep up > > with -stable, when /stand/sysinstall can do an inplace update ?") > > So should a throw another drive in this thing and go -stable or not ? > > What does MFC'd mean ? > > Perhaps a summary of each of your thoughts would help me ? > > Thanks, I really appreaciate all the help. > > Regards, John. > > > > ----- Original Message ----- > > From: "Vince Vielhaber" > > To: "Rogier R. Mulhuijzen" > > Cc: "Brian Somers" ; "Julian Elischer" > > ; "John Telford" ; > > ; > > Sent: Sunday, February 04, 2001 7:28 PM > > Subject: Re: Firewalling a PPPoE, any easy workaround to MTU on lan > > stations? > > > > > > > On Mon, 5 Feb 2001, Rogier R. Mulhuijzen wrote: > > > > > > > At 22:50 4-2-01 +0000, Brian Somers wrote: > > > > > > John Telford wrote: > > > > > > > > > > > > > > I'm putting a 4.2 R firewall in for a ppoe connection. > > (sympatico) > > > > > > > Is there any workaround I can use so I don't have to reduce the > > MTU > > > > > on all > > > > > > > the internal stations ? > > > > > > > It's a mix of Windows 9x and Macs. And I've found only one > utility > > > > > capable > > > > > > > of adjusting MTU on Macs. > > > > > > > Can anything be done on the freebsd box as the traffic goes > > through it ? > > > > > > > Thanks in advance, John. > > > > > > > P.S. the pppoe setup went fine thanks to a page at > > www.sympaticousers.org > > > > > > > and some further notes at www.freebsddiary.org > > > > > > > > > > > > > > > > > > ppp now has an option where it will force the negotiated packet > size > > > > > > of new tcp sessions going through it down. (i.e it fiddles with > the > > > > > packets) > > > > > > check the man page.. I THINK it may be in 4.2, if not it's > > in -Stable > > > > > > > > > >It didn't make 4.2 - it was MFC'd on December 18 :-( > > > > > > > > Brian, may I quote you from a different thread? =) > > > > > > > > "I think I've figured out the problem though... can you try the latest > > > > version of ppp - should be available via > > > > http://www.Awfulhak.org/ppp.html RSN (the 010204 archive) if you > > > > don't get -current. " > > > > > > > > John might not need that version, but shouldn't he be able to run a > > newer > > > > ppp on his 4.2-R without hitches? > > > > > > No reason why not.. I'm doing it. > > > > > > Vince. > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 22:13:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from samar.sasi.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 2284C37B491; Tue, 6 Feb 2001 22:13:06 -0800 (PST) Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id LAA25114; Wed, 7 Feb 2001 11:43:00 +0530 (IST) Received: from pcs111.sasi.com ([10.0.36.111]) by samar.sasi.com; Wed, 07 Feb 2001 11:42:59 +0000 (IST) Received: from localhost (madhavis@localhost) by pcs111.sasi.com (8.9.3/8.9.3) with ESMTP id LAA01468; Wed, 7 Feb 2001 11:42:57 +0530 X-Authentication-Warning: pcs111.sasi.com: madhavis owned process doing -bs Date: Wed, 7 Feb 2001 11:42:57 +0530 (IST) From: Madhavi Suram X-Sender: madhavis@pcs111.sasi.com To: freebsd-questions@FreeBSD.ORG Cc: freebsd-net@FreeBSD.ORG Subject: getting hardware address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi All Is there any function in 'C' to get ethernet hardware address from IP address (not only for interfaces on the same machine... For any IP address), equivalent to 'arp' command on FreeBSD? If there isn't any such function, can you suggest me any other way of achieving this? NOTE: I am not sure to which mailing list this has to be posted. So, I am posting it to both. Sorry for the inconvenience. Could you please CC the reply to my e-mail id also? I am not registered to freebsd-questions. Thanks in advance Madhavi. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 22:19:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by hub.freebsd.org (Postfix) with ESMTP id 9B72B37B491; Tue, 6 Feb 2001 22:19:37 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f176Jsj07542; Wed, 7 Feb 2001 08:19:54 +0200 (EET) Received: from esebh12nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 7 Feb 2001 08:19:35 +0200 Received: by esebh12nok with Internet Mail Service (5.5.2652.78) id <1LYQ3DHL>; Wed, 7 Feb 2001 08:19:35 +0200 Message-ID: From: chunan.li@nokia.com To: freebsd-questions@freebsd.org Cc: freebsd-net@freebsd.org Subject: What's the callback mechanism? Date: Wed, 7 Feb 2001 08:14:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Could you tell me how to implement the callback mechanism in FreeBSD? Thanks! ChunAn Li ---------------------------------------------------------------------------- ----------------- IP Specialist Advanced Internet Technologies Group Nokia Research Center, Communication Systems Lab/Beijing House 1, No.11 Hepingli Dongjie, Dongchend District, Beijing P.R.C. 100013 E-mail: chunan.li@nokia.com Tel: +86 10 842299222 Ext. 2870 MP: +86 13601028331 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 22:24:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from proxy.outblaze.com (proxy.outblaze.com [202.77.223.120]) by hub.freebsd.org (Postfix) with SMTP id 0538C37B491 for ; Tue, 6 Feb 2001 22:24:34 -0800 (PST) Received: (qmail 82371 invoked from network); 7 Feb 2001 06:24:31 -0000 Received: from unknown (HELO yusufg.portal2.com) (202.77.181.217) by proxy.outblaze.com with SMTP; 7 Feb 2001 06:24:31 -0000 Received: (qmail 30108 invoked by uid 500); 7 Feb 2001 06:28:53 -0000 Date: Wed, 7 Feb 2001 14:28:53 +0800 From: Yusuf Goolamabbas To: Joao Carlos Mendes Luis Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG, freebsd-stable@freebsd.org, phk@freebsd.org, dwmalone@FreeBSD.org Subject: Re: Solved: Bridging and dummynet seems to destroy dmesg output Message-ID: <20010207142853.A30058@outblaze.com> References: <200101312212.f0VMCHj08290@iguana.aciri.org> <3A79B707.3DF0B6D@jonny.eng.br> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3A79B707.3DF0B6D@jonny.eng.br>; from jonny@jonny.eng.br on Thu, Feb 01, 2001 at 05:20:39PM -0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I cvsupped today and got all of Luigi's commit [the one where he does 1.16.2.13 of bridge.c alongwith a few others], I also have David Malone's fix to syslogd.c [1.59.2.5] If I don't have the following sysctl net.inet.ip.fw.verbose_limit=10 then dmesg gets busted as mentioned earlier and if I do a sync;reboot then I get a huge amount of ipfw messages scrolling on the console [It's as if they were backlogged in some buffer somewhere] and after a few seconds the syncing disk messages comes along I have the following in my kernel config options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options BRIDGE options DUMMYNET my /etc/sysctl.conf is as follows net.link.ether.bridge_ipfw=1 net.link.ether.bridge=1 net.inet.ip.fw.verbose=1 net.inet.ip.fw.verbose_limit=10 > Luigi Rizzo wrote: > > > > > I tried only removing DUMMYNET from config, and the bug continues. Should > > > I try the changes below? > > > > no-they only affect dummynet. But this seems to suggest that > > the problem is unrelated to my changes... > > > > cheers > > luigi > > Hi, > > I found the problem! > > I started searching for the point where ipfw writes to the msgbuf, and > like all other kernel modules, it uses the log(9) function. But differently > from the other modules, ip_fw.c uses a LOG_SECURITY argument. I removed it, > recompiled, reboot, and BINGO! Probably the log(9) function does not expect a > facility parameter, as it is assumed to be LOG_KERNEL. > > Searching the cvsweb tree, I assume the changes that made it fail were > made to kern/subr_prf.c, and not directly to netinet/ip_fw.c. Probably a > longer search should be made to detect if any other call to log(9) uses this > approach. (CC: to phk, who made the change to kern/subr_prf.c, 1.61.2.1, at > 2000.01.16) > > Hoping this is the final solution and waiting for the cvs commit, thanks > to everybody, > > Jonny > > -- > João Carlos Mendes Luís jonny@embratel.net.br > Networking Engineer jonny@jonny.eng.br > Internet via Embratel jcml@ieee.org -- Yusuf Goolamabbas yusufg@outblaze.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 6 23:43: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B61B337B491; Tue, 6 Feb 2001 23:42:41 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f177gdH07964; Tue, 6 Feb 2001 23:42:39 -0800 (PST) Date: Tue, 6 Feb 2001 23:42:39 -0800 From: Alfred Perlstein To: chunan.li@nokia.com Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: What's the callback mechanism? Message-ID: <20010206234239.M26076@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from chunan.li@nokia.com on Wed, Feb 07, 2001 at 08:14:46AM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * chunan.li@nokia.com [010206 22:19] wrote: > Hi > Could you tell me how to implement the callback mechanism in FreeBSD? see the signal manpage for an example of how to specify a callback paramter. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 0: 2:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from hera.drwilco.net (10dyn83.dh.casema.net [212.64.31.83]) by hub.freebsd.org (Postfix) with ESMTP id AA66537B401; Wed, 7 Feb 2001 00:02:23 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.2/8.11.1) with ESMTP id f178P2o08047; Wed, 7 Feb 2001 09:25:05 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010207070518.00bc4760@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Feb 2001 07:06:22 +0100 To: Alfred Perlstein , chunan.li@nokia.com From: "Rogier R. Mulhuijzen" Subject: Re: What's the callback mechanism? Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <20010206234239.M26076@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 23:42 6-2-01 -0800, Alfred Perlstein wrote: >* chunan.li@nokia.com [010206 22:19] wrote: > > Hi > > Could you tell me how to implement the callback mechanism in FreeBSD? > >see the signal manpage for an example of how to specify a callback >paramter. When I read his question I thought he meant callbacks with modems... =) Can you be more specific in your question maybe? DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 0:34:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 5EA3737B401; Wed, 7 Feb 2001 00:34:12 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id JAA24496; Wed, 7 Feb 2001 09:33:15 +0100 (MET) Date: Wed, 7 Feb 2001 09:33:15 +0100 (CET) From: Harti Brandt To: Boris Popov Cc: , Subject: Re: CFR: Sequential mbuf read/write extensions In-Reply-To: <20010206105846.Q26076@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Looks nice, just what I needed two weeks ago and partly had to implement myself :-) But, I would recommend to stick with the ususal naming of size dependend things, by appending a numeric suffix. Something like: int mb_get8(struct mbdata *mbp, u_int8_t *x); int mb_get16(struct mbdata *mbp, u_int16_t *x); int mb_get16le(struct mbdata *mbp, u_int16_t *x); int mb_get16be(struct mbdata *mbp, u_int16_t *x); int mb_get32(struct mbdata *mbp, u_int32_t *x); ... Using 'word' and 'doubleword' is rather confusing (when speeking of words I would think of 32 bit nowadays). harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, harti@begemot.org, lhbrandt@mail.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 1:11:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from d9168.upc-d.chello.nl (d9168.upc-d.chello.nl [213.46.9.168]) by hub.freebsd.org (Postfix) with ESMTP id C4D0737B6A1; Wed, 7 Feb 2001 01:11:20 -0800 (PST) Received: by d9168.upc-d.chello.nl (Postfix, from userid 1001) id C69E03AE; Wed, 7 Feb 2001 10:11:19 +0100 (CET) Date: Wed, 7 Feb 2001 10:11:19 +0100 From: Edwin Groothuis To: Madhavi Suram Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: getting hardware address Message-ID: <20010207101119.W62745@d9168.upc-d.chello.nl> Mail-Followup-To: Edwin Groothuis , Madhavi Suram , freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from madhavis@sasken.com on Wed, Feb 07, 2001 at 11:42:57AM +0530 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Feb 07, 2001 at 11:42:57AM +0530, Madhavi Suram wrote: > Is there any function in 'C' to get ethernet hardware address from IP > address (not only for interfaces on the same machine... For any IP > address), equivalent to 'arp' command on FreeBSD? If there isn't any such > function, can you suggest me any other way of achieving this? You could check the source of arp of course, /usr/src/usr.sbin/arp/arp.c Edwin -- Edwin Groothuis | Interested in MUDs? Visit Fatal Dimensions: mavetju@chello.nl | http://fataldimensions.nl.eu.org/ ------------------+ telnet://fataldimensions.nl.eu.org:4000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 1:29:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 7863E37B684; Wed, 7 Feb 2001 01:28:59 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id E5B812868D; Wed, 7 Feb 2001 15:28:49 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id D66D82868A; Wed, 7 Feb 2001 15:28:49 +0600 (ALMT) Date: Wed, 7 Feb 2001 15:28:49 +0600 (ALMT) From: Boris Popov To: Bosko Milekic Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Sequential mbuf read/write extensions In-Reply-To: <003001c090b8$0b067a50$1f90c918@jehovah> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 6 Feb 2001, Bosko Milekic wrote: > > Since currently there isn't many consumers of this code I can > > suggest to define an option LIBMBUF in the kernel configuration file > and > > add KLD libmbuf (with interface libmbuf), so kernel footprint will > not be > > I am in favor of such an option on the condition that it is > temporary. In other words, only until we decide "we have converted > enough code to use this code so we should remove the option now." The > reason is that otherwise, we will be faced with numerous "#ifdef > LIBMBUF ... #else ... #endif" code. I assume this is what you meant, Not exactly so. 'option LIBMBUF' will just connect the source file to kernel makefile. There is no need for any #ifdef's in the code. > #define M_TRYWAIT M_WAIT is not right. > (M_WAIT is no longer to be used in the mbuf code.) You omitted the surrounding "#ifndef M_TRYWAIT" which makes this code portable to RELENG_4 (mind you, this code taken from smbfs). Of course, this should be stripped before import. > The succesfull return values are 0, I don't have a problem with this, > specifically, but I would assume that this: > if (!mb_init(mbp)) ... would be more "logical" (I use the term > loosely) if it meant: "if initialization fails" (now it means "if > initialization is succesful"). I'm generally don't like such syntax if function or variable name do not clearly specify which value it should have/return on success. Nearly all functions in this file return zero or error code, so the correct syntax of the above will be: error = mb_init(mbp); if (!error) or if (error) return error; or if (mb_init(mbp) != 0) return ESOMETHINGEVIL; > > significantly affected. The names of source and header files are > > questionable too and I would appreciate good suggestions (currently > they > > are subr_mbuf.c and subr_mbuf.h). > > Hmmm. Maybe subr_mblib.c and libmb.h ? I don't want to turn this > into a bikeshed ( :-) ), so I suggest that you decide. Personally, I > would prefer that it be something other than "subr_mbuf.c" simply > because it may be a little misleading in some cases. Good point. > Boris, this is really a great interface and nice looking, clean code. I'm sure, this code can be significantly improved by mbuf gurus :) -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 1:35:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id BE07737B699; Wed, 7 Feb 2001 01:35:18 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id CCF6A28648; Wed, 7 Feb 2001 15:35:16 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id C394528647; Wed, 7 Feb 2001 15:35:16 +0600 (ALMT) Date: Wed, 7 Feb 2001 15:35:16 +0600 (ALMT) From: Boris Popov To: Harti Brandt Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: Sequential mbuf read/write extensions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 7 Feb 2001, Harti Brandt wrote: > But, I would recommend to stick with the ususal naming of size dependend > things, by appending a numeric suffix. Something like: > > int mb_get8(struct mbdata *mbp, u_int8_t *x); > int mb_get16(struct mbdata *mbp, u_int16_t *x); > int mb_get16le(struct mbdata *mbp, u_int16_t *x); > int mb_get16be(struct mbdata *mbp, u_int16_t *x); > int mb_get32(struct mbdata *mbp, u_int32_t *x); > ... > > Using 'word' and 'doubleword' is rather confusing (when speeking of words > I would think of 32 bit nowadays). Well, it depends. For me 'word', 'dword' and 'qword' are clear from the good old 8bit days :) If numbers in the function names looks good I can live with it. Opinions ? -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 1:57:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id AED2037B69E; Wed, 7 Feb 2001 01:57:17 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id KAA01306; Wed, 7 Feb 2001 10:44:55 +0100 (MET) Date: Wed, 7 Feb 2001 10:44:55 +0100 (CET) From: Harti Brandt To: Boris Popov Cc: , Subject: Re: CFR: Sequential mbuf read/write extensions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 7 Feb 2001, Boris Popov wrote: BP>> Using 'word' and 'doubleword' is rather confusing (when speeking of words BP>> I would think of 32 bit nowadays). BP> BP> Well, it depends. For me 'word', 'dword' and 'qword' are clear BP>from the good old 8bit days :) BP> BP> If numbers in the function names looks good I can live with it. Well, I just looked back to the bus_space stuff and discovered, that they use suffixes of _[1234] to count the number of bytes the functions operate on. Perhaps this is a better variant? Anyway, I think, numbers are much clearer, than words in this case (As an example, what does ntohl operate on if longs are 64 bit??). As a side note: Someone told me that Mickeysoft is trying to persuade the C standardisation people to drop the requirement that longs should not be shorter than int's. This is, he said, because of their braindamage with DWORD in -zillions of header files... If I look how they continue to cripple C, this may also slip through :-( harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, harti@begemot.org, lhbrandt@mail.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 4:36:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from eng05.embratel.net.br (eng05.embratel.net.br [200.255.125.133]) by hub.freebsd.org (Postfix) with ESMTP id B2E7D37B69F; Wed, 7 Feb 2001 04:36:11 -0800 (PST) Received: from jonny.eng.br (willow [200.255.125.142]) by eng05.embratel.net.br (Postfix) with ESMTP id ACD8924D33; Wed, 7 Feb 2001 10:36:08 -0200 (BRST) Message-ID: <3A814168.533ADAFC@jonny.eng.br> Date: Wed, 07 Feb 2001 10:36:56 -0200 From: Joao Carlos Mendes Luis Organization: Internet via Embratel X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Yusuf Goolamabbas Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, phk@FreeBSD.ORG, dwmalone@FreeBSD.ORG Subject: Re: Solved: Bridging and dummynet seems to destroy dmesg output References: <200101312212.f0VMCHj08290@iguana.aciri.org> <3A79B707.3DF0B6D@jonny.eng.br> <20010207142853.A30058@outblaze.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Yusuf, As described by cvsweb, the patches to IPFW did not change the behavior with log messages. To be more exactly, either netinet/ip_fw.c either kern/subr_prf.c should be changed to match each other. In my local setup I use a patch script after cvsup to fix ip_fw.c, removing all instances of "LOG_SECURITY |". Luigi/Poul, have you at least decided where the changes should be made? There's no log(9) man page to decide which one is the correct syntax. IMHO, -stable is not stable while this bug persists. Yusuf Goolamabbas wrote: > > Hi, I cvsupped today and got all of Luigi's commit [the one where he > does 1.16.2.13 of bridge.c alongwith a few others], I also have David > Malone's fix to syslogd.c [1.59.2.5] > > If I don't have the following sysctl > > net.inet.ip.fw.verbose_limit=10 > > then dmesg gets busted as mentioned earlier and if I do a sync;reboot > then I get a huge amount of ipfw messages scrolling on the console [It's > as if they were backlogged in some buffer somewhere] and after a few > seconds the syncing disk messages comes along > > I have the following in my kernel config > > options IPFIREWALL > options IPFIREWALL_DEFAULT_TO_ACCEPT > options BRIDGE > options DUMMYNET > > my /etc/sysctl.conf is as follows > > net.link.ether.bridge_ipfw=1 > net.link.ether.bridge=1 > net.inet.ip.fw.verbose=1 > net.inet.ip.fw.verbose_limit=10 > > > Luigi Rizzo wrote: > > > > > > > I tried only removing DUMMYNET from config, and the bug continues. Should > > > > I try the changes below? > > > > > > no-they only affect dummynet. But this seems to suggest that > > > the problem is unrelated to my changes... > > > > > > cheers > > > luigi > > > > Hi, > > > > I found the problem! > > > > I started searching for the point where ipfw writes to the msgbuf, and > > like all other kernel modules, it uses the log(9) function. But differently > > from the other modules, ip_fw.c uses a LOG_SECURITY argument. I removed it, > > recompiled, reboot, and BINGO! Probably the log(9) function does not expect a > > facility parameter, as it is assumed to be LOG_KERNEL. > > > > Searching the cvsweb tree, I assume the changes that made it fail were > > made to kern/subr_prf.c, and not directly to netinet/ip_fw.c. Probably a > > longer search should be made to detect if any other call to log(9) uses this > > approach. (CC: to phk, who made the change to kern/subr_prf.c, 1.61.2.1, at > > 2000.01.16) > > > > Hoping this is the final solution and waiting for the cvs commit, thanks > > to everybody, > > > > Jonny > > > > -- > > João Carlos Mendes Luís jonny@embratel.net.br > > Networking Engineer jonny@jonny.eng.br > > Internet via Embratel jcml@ieee.org > > -- > Yusuf Goolamabbas > yusufg@outblaze.com -- Jonny -- João Carlos Mendes Luís jonny@embratel.net.br Networking Engineer jonny@jonny.eng.br Internet via Embratel jcml@ieee.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 4:41:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from brunel.uk1.vbc.net (brunel.uk1.vbc.net [194.207.2.8]) by hub.freebsd.org (Postfix) with ESMTP id 9B1C637B6A0 for ; Wed, 7 Feb 2001 04:41:20 -0800 (PST) Received: from localhost (jcv@localhost) by brunel.uk1.vbc.net (8.11.0/8.11.0) with ESMTP id f17CfIP71546 for ; Wed, 7 Feb 2001 12:41:18 GMT X-Authentication-Warning: brunel.uk1.vbc.net: jcv owned process doing -bs Date: Wed, 7 Feb 2001 12:41:18 +0000 (GMT) From: Jean-Christophe Varaillon X-Sender: jcv@brunel.uk1.vbc.net To: freebsd-net@FreeBSD.ORG Subject: - Interface Question - Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If a "dmesg | grep fxp2" does not show any messages at all, does it means that the interface is not existing ? If yes how it comes I can see this interface fully configured by "ifconfig fxp2" ? fxp2: flags=8843 mtu 1500 inet xx.xx.xx.104 netmask 0xfffffe00 broadcast xx.xx.xx.255 ether **** media: autoselect (100baseTX) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP JC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 4:45:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id AEED837B6A2 for ; Wed, 7 Feb 2001 04:44:37 -0800 (PST) Received: (qmail 44481 invoked by uid 1001); 7 Feb 2001 22:44:20 +1000 X-Posted-By: GJB-Post 2.12 07-Feb-2001 X-Operating-System: FreeBSD 4.1-RELEASE i386 X-URL: http://www.gbch.net/gjb/ X-Image-URL: http://www.gbch.net/gjb/img/gjb-auug048.gif X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 X-PGP-Public-Key: http://www.gbch.net/gjb/gjb-pgpkey.asc Message-Id: Date: Wed, 07 Feb 2001 22:44:20 +1000 From: Greg Black To: Jean-Christophe Varaillon Cc: freebsd-net@FreeBSD.ORG Subject: Re: - Interface Question - References: In-reply-to: of Wed, 07 Feb 2001 12:41:18 GMT Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jean-Christophe Varaillon wrote: > If a "dmesg | grep fxp2" does not show any messages at all, does it means > that the interface is not existing ? No, try: grep fxp2 /var/run/dmesg.boot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 5:14:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id C949137B401; Wed, 7 Feb 2001 05:14:31 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f17DELt59699; Wed, 7 Feb 2001 05:14:21 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200102071314.f17DELt59699@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Rogier R. Mulhuijzen" Cc: Alfred Perlstein , chunan.li@nokia.com, freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: What's the callback mechanism? In-Reply-To: <4.3.2.7.0.20010207070518.00bc4760@mail.bsdchicks.com> Date: Wed, 07 Feb 2001 05:14:21 -0800 From: Peter Wemm Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Rogier R. Mulhuijzen" wrote: > At 23:42 6-2-01 -0800, Alfred Perlstein wrote: > >* chunan.li@nokia.com [010206 22:19] wrote: > > > Hi > > > Could you tell me how to implement the callback mechanism in FreeBSD? > > > >see the signal manpage for an example of how to specify a callback > >paramter. > > When I read his question I thought he meant callbacks with modems... =) > > Can you be more specific in your question maybe? Nokia use an embedded FreeBSD kernel in their router product, I suspect he means something to do with the networking stack - possibly the socket upcall mechanism. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 8:32: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from brisefer.cediti.be (brisefer.cediti.be [193.190.156.67]) by hub.freebsd.org (Postfix) with ESMTP id 470E237B491 for ; Wed, 7 Feb 2001 08:31:50 -0800 (PST) Received: by brisefer.cediti.be with Internet Mail Service (5.5.2650.21) id <1LDHYCG9>; Wed, 7 Feb 2001 17:32:09 +0100 Message-ID: From: Olivier Cherrier To: 'freebsd-net' Subject: pptp server Date: Wed, 7 Feb 2001 17:32:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi. I would like to install a pptp server on a FreeBox 4.2 firewall. I have to allow remote connections from windows clients (Win 98 - 2k) to this firewall. This firewall runs IPF and IPNat. I tried mpd 3.2 (ftp://ftp.freebsd.org/pub/FreeBSD/branches/-current/ports/net/mpd-netgraph/ pkg-descr). But, I don't success in establishing a vpn between a windows and my pptp server : windows don't accept the mpd encryption protocol. Has someone succeed in using mpd as pptp server with windows clients ? I would like to ask you whether someone knows a solution to do VPNs between a BSD and many windows clients (with or without mpd)? Thanks a lot in advance. Olivier Cherrier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 8:39:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-01.iinet.net.au (syncopation-01.iinet.net.au [203.59.24.37]) by hub.freebsd.org (Postfix) with SMTP id D7F8337B401 for ; Wed, 7 Feb 2001 08:39:20 -0800 (PST) Received: (qmail 8284 invoked by uid 666); 7 Feb 2001 16:46:10 -0000 Received: from reggae-22-100.nv.iinet.net.au (HELO elischer.org) (203.59.87.100) by mail.m.iinet.net.au with SMTP; 7 Feb 2001 16:46:10 -0000 Message-ID: <3A817A31.8C08203D@elischer.org> Date: Wed, 07 Feb 2001 08:39:13 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Olivier Cherrier Cc: 'freebsd-net' Subject: Re: pptp server References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Olivier Cherrier wrote: > > Hi. > > I would like to install a pptp server on a FreeBox 4.2 firewall. > I have to allow remote connections from windows clients (Win 98 - 2k) to > this firewall. This firewall runs IPF and IPNat. > > I tried mpd 3.2 > (ftp://ftp.freebsd.org/pub/FreeBSD/branches/-current/ports/net/mpd-netgraph/ > pkg-descr). > But, I don't success in establishing a vpn between a windows and my pptp > server : windows don't accept the mpd encryption protocol. > > Has someone succeed in using mpd as pptp server with windows clients ? yes many many have.. I have done it but not here. It was relatively easy.. wait for archie to come on line (He's in California) to help find your problem.. > > I would like to ask you whether someone knows a solution to do VPNs between > a BSD and many windows clients (with or without mpd)? > > Thanks a lot in advance. > > Olivier Cherrier > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 8:47:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from brisefer.cediti.be (brisefer.cediti.be [193.190.156.67]) by hub.freebsd.org (Postfix) with ESMTP id 9A93837B491 for ; Wed, 7 Feb 2001 08:46:59 -0800 (PST) Received: by brisefer.cediti.be with Internet Mail Service (5.5.2650.21) id <1LDHYCHP>; Wed, 7 Feb 2001 17:47:19 +0100 Message-ID: From: Olivier Cherrier To: 'Julian Elischer' Cc: 'freebsd-net' Subject: RE: pptp server Date: Wed, 7 Feb 2001 17:47:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-15" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Has someone succeed in using mpd as pptp server with windows >clients ? > >yes many many have.. > >I have done it but not here. It was relatively easy.. >wait for archie to come on line (He's in California) >to help find your problem.. > Yes, I've already asked him .... I am a little bit confused that I don't succeed ... :( Maybe it is my fuc... windows 2k which is the problem .... Olivier. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 9:14:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 3A4C937B4EC for ; Wed, 7 Feb 2001 09:14:13 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f17HEDH75274; Wed, 7 Feb 2001 09:14:13 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102071714.f17HEDH75274@iguana.aciri.org> Subject: send problem on udp socket... To: net@freebsd.org Date: Wed, 7 Feb 2001 09:14:08 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, just occurred to me that there exists the following feature of send/sendmsg and probably also write on UDP sockets, and it would be worth documenting. When you attempt to send() to an udp socket, the socket buffer (which has no function other than bounding the max message size for UDP sockets) is just bypassed, and the low-level routine gets called. The latter (typically ip_output() or ether_output()) can return an ENOBUFS message if some queue fills up down there (typically the interface queue), and the error message is passed up. Now, the send() manpage is technically correct as it only mentions the socket buffer full as the reason for blocking, but in my opinion the above is not _that_ obvious and it would be worth documenting. As a matter of fact, i wonder if it would be a good idea to try and improve this behaviour by letting sosend() do a tsleep() on the device/subsystem reporting the failure, and have the latter issue a wakeup when space frees again. The only thing is, i believe this has some odd ramifications with handling select/poll, and might break some software that does not handle blocking send() on UDP sockets. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 9:37:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3E03437B684 for ; Wed, 7 Feb 2001 09:37:33 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f17HbVg21370; Wed, 7 Feb 2001 09:37:31 -0800 (PST) Date: Wed, 7 Feb 2001 09:37:31 -0800 From: Alfred Perlstein To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: send problem on udp socket... Message-ID: <20010207093731.N26076@fw.wintelcom.net> References: <200102071714.f17HEDH75274@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102071714.f17HEDH75274@iguana.aciri.org>; from rizzo@aciri.org on Wed, Feb 07, 2001 at 09:14:08AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Luigi Rizzo [010207 09:14] wrote: > Hi, > > just occurred to me that there exists the following feature of > send/sendmsg and probably also write on UDP sockets, and it would > be worth documenting. Yes it is. [snip] > When you attempt to send() to an udp socket, the socket buffer > (which has no function other than bounding the max message size > for UDP sockets) is just bypassed, and the low-level routine gets > called. The latter (typically ip_output() or ether_output()) can > return an ENOBUFS message if some queue fills up down there (typically > the interface queue), and the error message is passed up. > > Now, the send() manpage is technically correct as it only > mentions the socket buffer full as the reason for blocking, > but in my opinion the above is not _that_ obvious and it would > be worth documenting. > > As a matter of fact, i wonder if it would be a good idea to > try and improve this behaviour by letting sosend() do a tsleep() > on the device/subsystem reporting the failure, and have the > latter issue a wakeup when space frees again. The only thing > is, i believe this has some odd ramifications with handling > select/poll, and might break some software that does not > handle blocking send() on UDP sockets. ENOBUFS == ESYSADMINNEEDSTORAISENMBCLUSTERS Sorry, basically you shouldn't see ENOBUFS unless you're doing something wrong, running a box that isn't set up to handle the amount of traffic you want to push through it. If you're unclear on how to fix it then leave it be. If you can fix it such that: In the non-block case: ENOBUFS translates into EWOULDBLOCK In the blocking case: ENOBUFS restarts the syscall But in both cases: It sets a callback such that the select()/poll()/kevent() filter gets a callback when the mbuf subsystem becomes free enough. The problem here, is that you still have a race, you can return "ready to send" but yet another subsystem decideds to chew mbufs before you get to restart your call. I guess we have to document that as well, but is it allowable via any spec out there? "_maybe_ ready for more data" ie. select() return ok, but write return not ok? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 9:57:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id B2E9D37B491 for ; Wed, 7 Feb 2001 09:57:20 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f17HvGu75581; Wed, 7 Feb 2001 09:57:16 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102071757.f17HvGu75581@iguana.aciri.org> Subject: Re: send problem on udp socket... In-Reply-To: <20010207093731.N26076@fw.wintelcom.net> from Alfred Perlstein at "Feb 7, 2001 9:37:31 am" To: bright@wintelcom.net (Alfred Perlstein) Date: Wed, 7 Feb 2001 09:57:16 -0800 (PST) Cc: rizzo@aciri.org, net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > When you attempt to send() to an udp socket, the socket buffer > > (which has no function other than bounding the max message size > > for UDP sockets) is just bypassed, and the low-level routine gets > > called. The latter (typically ip_output() or ether_output()) can > > return an ENOBUFS message if some queue fills up down there (typically > > the interface queue), and the error message is passed up. ... > ENOBUFS == ESYSADMINNEEDSTORAISENMBCLUSTERS > > Sorry, basically you shouldn't see ENOBUFS unless you're doing > something wrong, running a box that isn't set up to handle the > amount of traffic you want to push through it. not really. The problem is not running out of mbufs, is that the interface queue (usually limited to net.inet.ip.intr_queue_maxlen) fills up, and this has nothing to do with NMBCLUSTERS. This used not to be a problem in the past precisely because boxes were slower than ethernet cards. And trying to push through a device more than it can handle happens all the time with disks, and it is the reason why you want to have blocking behaviour. Re. the race that you mention below, again it happens all the times -- select tells you can do X, then someone else is faster and your X syscall fails. See the case of multiple servers trying to accept() on a socket. cheers luigi > The problem here, is that you still have a race, you can return > "ready to send" but yet another subsystem decideds to chew mbufs > before you get to restart your call. I guess we have to document > that as well, but is it allowable via any spec out there? > "_maybe_ ready for more data" ie. select() return ok, but write > return not ok? > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 10: 4:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id DEB4437B503 for ; Wed, 7 Feb 2001 10:00:44 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14QYkr-0000OL-00; Wed, 07 Feb 2001 10:51:45 -0700 Message-ID: <3A818B31.9B12C8B3@softweyr.com> Date: Wed, 07 Feb 2001 10:51:45 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Luigi Rizzo , net@FreeBSD.ORG Subject: Re: send problem on udp socket... References: <200102071714.f17HEDH75274@iguana.aciri.org> <20010207093731.N26076@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred Perlstein wrote: > > * Luigi Rizzo [010207 09:14] wrote: > > Hi, > > > > just occurred to me that there exists the following feature of > > send/sendmsg and probably also write on UDP sockets, and it would > > be worth documenting. > > Yes it is. > > [snip] > > When you attempt to send() to an udp socket, the socket buffer > > (which has no function other than bounding the max message size > > for UDP sockets) is just bypassed, and the low-level routine gets > > called. The latter (typically ip_output() or ether_output()) can > > return an ENOBUFS message if some queue fills up down there (typically > > the interface queue), and the error message is passed up. > > > > Now, the send() manpage is technically correct as it only > > mentions the socket buffer full as the reason for blocking, > > but in my opinion the above is not _that_ obvious and it would > > be worth documenting. > > > > As a matter of fact, i wonder if it would be a good idea to > > try and improve this behaviour by letting sosend() do a tsleep() > > on the device/subsystem reporting the failure, and have the > > latter issue a wakeup when space frees again. The only thing > > is, i believe this has some odd ramifications with handling > > select/poll, and might break some software that does not > > handle blocking send() on UDP sockets. > > ENOBUFS == ESYSADMINNEEDSTORAISENMBCLUSTERS Or perhaps ENOBUFS == E_SYSTEM_NEEDS_TO_RAISE_NMBCLUSTERS_ALL_ON_ITS_OWN? A starting point, increment, and ceiling, based on the memory size of the system, might be a more reasonable design for a lot of these hard-coded parameters left over from the days of the VAX 750. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 10:13:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 1019F37B65D for ; Wed, 7 Feb 2001 10:13:17 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f17IDA975689; Wed, 7 Feb 2001 10:13:10 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102071813.f17IDA975689@iguana.aciri.org> Subject: Re: send problem on udp socket... In-Reply-To: <3A818B31.9B12C8B3@softweyr.com> from Wes Peters at "Feb 7, 2001 10:51:45 am" To: wes@softweyr.com (Wes Peters) Date: Wed, 7 Feb 2001 10:13:10 -0800 (PST) Cc: bright@wintelcom.net, rizzo@aciri.org, net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > ENOBUFS == ESYSADMINNEEDSTORAISENMBCLUSTERS > > Or perhaps ENOBUFS == E_SYSTEM_NEEDS_TO_RAISE_NMBCLUSTERS_ALL_ON_ITS_OWN? it is not an NMBCLUSTERS problem, it is just the device queue which is filling up, and this is a perfectly normal and desired behaviour. One would just want that to be handled as in the case of writes to a disk or the like -- i.e. wait until the subsystem (in this case the network device) is ready. For disks and TCP the synchronization is achieved through the socket buffer and (presumably for disks as well, i am no expert on filesystems) explicit acks on write ops. For UDP sockets things are unfortunately a bit more complex as there is no ack nor socket buffers. Plus there might be around a ton of software which relies on the current behaviour... cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 10:32:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 97DB637B4EC for ; Wed, 7 Feb 2001 10:32:11 -0800 (PST) Received: (qmail 20293 invoked by uid 666); 7 Feb 2001 18:39:41 -0000 Received: from reggae-22-100.nv.iinet.net.au (HELO elischer.org) (203.59.87.100) by mail.m.iinet.net.au with SMTP; 7 Feb 2001 18:39:41 -0000 Message-ID: <3A8194A6.6E01AC1D@elischer.org> Date: Wed, 07 Feb 2001 10:32:06 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Luigi Rizzo Cc: net@freebsd.org Subject: Re: send problem on udp socket... References: <200102071714.f17HEDH75274@iguana.aciri.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo wrote: > > Hi, > > just occurred to me that there exists the following feature of > send/sendmsg and probably also write on UDP sockets, and it would > be worth documenting. > > When you attempt to send() to an udp socket, the socket buffer > (which has no function other than bounding the max message size > for UDP sockets) is just bypassed, and the low-level routine gets > called. The latter (typically ip_output() or ether_output()) can > return an ENOBUFS message if some queue fills up down there (typically > the interface queue), and the error message is passed up. > > Now, the send() manpage is technically correct as it only > mentions the socket buffer full as the reason for blocking, > but in my opinion the above is not _that_ obvious and it would > be worth documenting. > > As a matter of fact, i wonder if it would be a good idea to > try and improve this behaviour by letting sosend() do a tsleep() > on the device/subsystem reporting the failure, and have the > latter issue a wakeup when space frees again. The only thing > is, i believe this has some odd ramifications with handling > select/poll, and might break some software that does not > handle blocking send() on UDP sockets. this is not just UDP but any packet based protocol. ping(8)(1?) uses this fact when you do a ping -f. if it get's a ENOBUFS, it does a usleep and backs off a bit. don't change it as it's teh expected behaviour. (well, at least I expect it....) > > cheers > luigi > ----------------------------------+----------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > Phone: (510) 666 2927 > ----------------------------------+----------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 10:59:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D710537B401 for ; Wed, 7 Feb 2001 10:59:06 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f17Ix6623446; Wed, 7 Feb 2001 10:59:06 -0800 (PST) Date: Wed, 7 Feb 2001 10:59:06 -0800 From: Alfred Perlstein To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: send problem on udp socket... Message-ID: <20010207105906.O26076@fw.wintelcom.net> References: <20010207093731.N26076@fw.wintelcom.net> <200102071757.f17HvGu75581@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102071757.f17HvGu75581@iguana.aciri.org>; from rizzo@aciri.org on Wed, Feb 07, 2001 at 09:57:16AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Luigi Rizzo [010207 09:57] wrote: > > not really. The problem is not running out of mbufs, is that the > interface queue (usually limited to net.inet.ip.intr_queue_maxlen) > fills up, and this has nothing to do with NMBCLUSTERS. This used > not to be a problem in the past precisely because boxes were slower > than ethernet cards. > > And trying to push through a device more than it can handle > happens all the time with disks, and it is the reason why > you want to have blocking behaviour. > > exhaustion whereas the problem is elsewhere> Oh, sorry, I'm pretty used to seeing the issue I _thought_ you brought up so I instictively sent the pre-thought out message. :) > Re. the race that you mention below, again it happens all > the times -- select tells you can do X, then someone else > is faster and your X syscall fails. See the case of multiple > servers trying to accept() on a socket. Er, that I understand. But it's not that expected when you're the only one writing/accepting. I guess defensive coding is a good thing. :) Since this is UDP, I'm not sure much should be done, perhaps just document the return value, but honestly since it's _U_DP it could just easily fail silently as long as local datagrams are allowed to be lossy. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 11: 9: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 1E53337B491 for ; Wed, 7 Feb 2001 11:08:49 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f17J8mr77641; Wed, 7 Feb 2001 11:08:48 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102071908.f17J8mr77641@iguana.aciri.org> Subject: Re: send problem on udp socket... In-Reply-To: <20010207105906.O26076@fw.wintelcom.net> from Alfred Perlstein at "Feb 7, 2001 10:59: 6 am" To: bright@wintelcom.net (Alfred Perlstein) Date: Wed, 7 Feb 2001 11:08:48 -0800 (PST) Cc: rizzo@aciri.org, net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Since this is UDP, I'm not sure much should be done, perhaps > just document the return value, but honestly since it's _U_DP exactly -- documenting is the only thing we can do. There are far too many apps that might break if we change this behaviour. Ideally one could add a setsockopt to implement a truly blocking behaviour on sockets where there is not an explicit underlying flow control scheme, but flow control info can still be derived by other means. > it could just easily fail silently as long as local datagrams > are allowed to be lossy. i am not much concerned about this, but rather by the fact that those apps which want to send as fast as possible have no better way than looping around a non-blocking call, whereas it would be much more efficient to pass signals up. Next life... cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 11:16: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id 267FF37B503; Wed, 7 Feb 2001 11:15:42 -0800 (PST) Received: from xor.obsecurity.org ([64.165.226.103]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G8E006HTFVGMT@mta6.snfc21.pbi.net>; Wed, 7 Feb 2001 10:12:56 -0800 (PST) Received: by xor.obsecurity.org (Postfix, from userid 1000) id 261596739A; Wed, 07 Feb 2001 10:14:18 -0800 (PST) Date: Wed, 07 Feb 2001 10:14:18 -0800 From: Kris Kennaway Subject: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] To: net@freebsd.org, security-officer@freebsd.org Message-id: <20010207101417.A28791@mollari.cthul.hu> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Can anyone comment on this patch? http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/kern/uipc_socket.c Kris ----- Forwarded message from itojun@iijlab.net ----- Delivered-To: kkenn@localhost.obsecurity.org Delivered-To: kris@freebsd.org To: merge@kame.net Subject: accept(2) behavior with tcp RST right after handshake X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Wed, 07 Feb 2001 21:39:49 +0900 X-UIDL: aff7d2fbee72775e2137abcde0bef0d0 i believe you will want to merge this. scenario: - you are listening to tcp port - someone comes in, handshake (SYN, SYNACK, ACK) - someone sends RST - your server issues accept(2) previous behavior: accept(2) returns successful result with zero- length sockaddr. new behavior: return ECONNABORTED. effect: - if someone runs nmap against your machine, and you are unlucky, your server listening to tcp port (like BIND9) can get segv/abort due to unexpected zero-length sockaddr + successful error return on accept(2). itojun ------- Forwarded Messages Return-Path: owner-cvs-kame@kame.net Return-Path: Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id VAA00242 for ; Wed, 7 Feb 2001 21:35:16 +0900 (JST) Received: (from daemon@localhost) by orange.kame.net (8.9.3+3.2W/3.7W/smtpfeed 1.06) id VAA48429; Wed, 7 Feb 2001 21:35:16 +0900 (JST) Received: (from itojun@localhost) by orange.kame.net (8.9.3+3.2W/3.7W) id VAA48423; Wed, 7 Feb 2001 21:35:15 +0900 (JST) Date: Wed, 7 Feb 2001 21:35:15 +0900 (JST) From: Jun-ichiro itojun Hagino Message-Id: <200102071235.VAA48423@orange.kame.net> To: cvs-kame:; Subject: kame cvs commit: kame/freebsd4/sys/kern uipc_socket.c kame/netbsd/= sys/kern uipc_socket.c kame/openbsd/sys/kern uipc_socket.c Reply-to: core@kame.net X-Filter: mailagent [version 3.0 PL68] for itojun@itojun.org itojun 2001/02/07 21:35:15 JST Modified files: freebsd4/sys/kern uipc_socket.c=20 netbsd/sys/kern uipc_socket.c=20 openbsd/sys/kern uipc_socket.c=20 Log: return ECONNABORTED, if the socket (tcp connection for example) is disconnected by RST right before accept(2). fixes PR 10698/12027. checked with SUSv2, XNET 5.2, and Stevens (unix network programming vol 1 2nd ed) section 5.11. =20 Revision Changes Path 1.2 +243 -10 kame/freebsd4/sys/kern/uipc_socket.c 1.3 +1 -1 kame/netbsd/sys/kern/uipc_socket.c 1.3 +1 -1 kame/openbsd/sys/kern/uipc_socket.c ------- Message 2 Return-Path: owner-cvs-kame-local@kame.net Return-Path: Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id VAA00253 for ; Wed, 7 Feb 2001 21:35:20 +0900 (JST) Received: (from itojun@localhost) by orange.kame.net (8.9.3+3.2W/3.7W/smtpfeed 1.06) id VAA48466; Wed, 7 Feb 2001 21:35:19 +0900 (JST) Date: Wed, 7 Feb 2001 21:35:19 +0900 (JST) From: Jun-ichiro itojun Hagino Message-Id: <200102071235.VAA48466@orange.kame.net> To: cvs-kame-local@kame.net Subject: kame-local cvs commit: kame/bsdi4/sys/kern uipc_socket.c X-Filter: mailagent [version 3.0 PL68] for itojun@itojun.org itojun 2001/02/07 21:35:19 JST Modified files: bsdi4/sys/kern uipc_socket.c=20 Log: return ECONNABORTED, if the socket (tcp connection for example) is disconnected by RST right before accept(2). fixes PR 10698/12027. checked with SUSv2, XNET 5.2, and Stevens (unix network programming vol 1 2nd ed) section 5.11. =20 Revision Changes Path 1.4 +1 -1 kame/bsdi4/sys/kern/uipc_socket.c ------- End of Forwarded Messages ----- End forwarded message ----- --5vNYLRcllDrimb99 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6gZB5Wry0BWjoQKURAs2KAKD5KiANKY0SY1HZCIc+J9EZkpH/bQCfb1D3 3CMK+LoXzPSOciTi/KXwOIY= =MyXZ -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 11:20:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id A687E37B401 for ; Wed, 7 Feb 2001 11:19:55 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA45590; Wed, 7 Feb 2001 14:19:44 -0500 (EST) (envelope-from wollman) Date: Wed, 7 Feb 2001 14:19:44 -0500 (EST) From: Garrett Wollman Message-Id: <200102071919.OAA45590@khavrinen.lcs.mit.edu> To: Alfred Perlstein Cc: net@FreeBSD.ORG Subject: Re: send problem on udp socket... In-Reply-To: <20010207093731.N26076@fw.wintelcom.net> References: <200102071714.f17HEDH75274@iguana.aciri.org> <20010207093731.N26076@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > ENOBUFS == ESYSADMINNEEDSTORAISENMBCLUSTERS BZZZZT! Wrong, but thanks for playing. ENOBUFS is returned in many more circumstances than simply ``out of mbufs''. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 11:24: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id B494837B491 for ; Wed, 7 Feb 2001 11:23:50 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f17JNmH77765; Wed, 7 Feb 2001 11:23:48 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102071923.f17JNmH77765@iguana.aciri.org> Subject: Re: send problem on udp socket... In-Reply-To: <200102071919.OAA45590@khavrinen.lcs.mit.edu> from Garrett Wollman at "Feb 7, 2001 2:19:44 pm" To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Wed, 7 Feb 2001 11:23:48 -0800 (PST) Cc: bright@wintelcom.net, net@FreeBSD.ORG, rizzo@aciri.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garret, on a similar subject (UDP sockets), i notice that socket buffers do not have a pointer to the end of the queued mbufs, so sbappend*() routines have to scan the list of queued bufs. As you can imagine this is causing some nasty effect when a receiver is slow. Is it worthhwile to fix this (or maybe it has been done already) ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 11:50:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 7CCDF37B401 for ; Wed, 7 Feb 2001 11:50:35 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA45795; Wed, 7 Feb 2001 14:48:59 -0500 (EST) (envelope-from wollman) Date: Wed, 7 Feb 2001 14:48:59 -0500 (EST) From: Garrett Wollman Message-Id: <200102071948.OAA45795@khavrinen.lcs.mit.edu> To: Wes Peters Cc: net@FreeBSD.ORG Subject: Re: send problem on udp socket... In-Reply-To: <3A818B31.9B12C8B3@softweyr.com> References: <200102071714.f17HEDH75274@iguana.aciri.org> <20010207093731.N26076@fw.wintelcom.net> <3A818B31.9B12C8B3@softweyr.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > A starting point, increment, and ceiling NMBCLUSTERS *is* the ceiling. No memory is actually allocated (although virtual address space is) until those clusters are actually requested. > based on the memory size of the system That would be an improvement, but recall that many of these sorts of parameters are there in order to limit fragmentation of the kernel virtual address space. There's no safe way to GC kernel virtual space. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 12: 1:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 04CE237B503; Wed, 7 Feb 2001 12:01:07 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA45955; Wed, 7 Feb 2001 15:00:52 -0500 (EST) (envelope-from wollman) Date: Wed, 7 Feb 2001 15:00:52 -0500 (EST) From: Garrett Wollman Message-Id: <200102072000.PAA45955@khavrinen.lcs.mit.edu> To: Kris Kennaway Cc: net@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: <20010207101417.A28791@mollari.cthul.hu> References: <20010207101417.A28791@mollari.cthul.hu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 < said: > Can anyone comment on this patch? > http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/kern/uipc_socket.c I don't necessarily agree that the previous behavior was wrong, but I'm willing to bet that a lot of programs don't bother to check for that condition, and [ECONNABORTED] is a Standard-sanctioned error return for this case. (I'd prefer an interface which allowed the caller to find out the address of the peer who allegedly aborted, but that's not possible.) - -GAWollman -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6galwI+eG6b7tlG4RAq6FAJ9l+TNMAh3zDaBv3bf/ClhAR9uyFQCfVMuc vFqdTRrdWeTdVpURBi4ufhA= =opkE -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 12: 9:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 7F62337B503 for ; Wed, 7 Feb 2001 12:09:05 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA46020; Wed, 7 Feb 2001 15:09:03 -0500 (EST) (envelope-from wollman) Date: Wed, 7 Feb 2001 15:09:03 -0500 (EST) From: Garrett Wollman Message-Id: <200102072009.PAA46020@khavrinen.lcs.mit.edu> To: Luigi Rizzo Cc: wollman@khavrinen.lcs.mit.edu (Garrett Wollman), bright@wintelcom.net, net@FreeBSD.ORG Subject: Re: send problem on udp socket... In-Reply-To: <200102071923.f17JNmH77765@iguana.aciri.org> References: <200102071919.OAA45590@khavrinen.lcs.mit.edu> <200102071923.f17JNmH77765@iguana.aciri.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > on a similar subject (UDP sockets), i notice that > socket buffers do not have a pointer to the end of > the queued mbufs, so sbappend*() routines have to scan the > list of queued bufs. As you can imagine this is > causing some nasty effect when a receiver is slow. I've thought about this problem before, in the context of a TCP sender, where the best solution is both (a) hard and (b) significantly different. I had not thought about it in the case of UDP, but yes, that could be a significant issue, particularly since UDP packets on the receive queue can never be coalesced (so there's DoS potential). I think adding a (sort of) tail pointer to the socket buffer might be helpful. I think you want it to point to the mbuf before the last *record* in the socket buffer, in order for sbcompress() to do its work, which means that you may still have to traverse a chain of mbufs (hopefully just not as many). -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 12:18: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 92E8B37B491; Wed, 7 Feb 2001 12:17:39 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f17KHYh18273; Wed, 7 Feb 2001 15:17:34 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 7 Feb 2001 15:17:34 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Kris Kennaway Cc: net@freebsd.org, security-officer@freebsd.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: <20010207101417.A28791@mollari.cthul.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Won't comment on the implementation as I have't had a chance to review it yet, but the description sounds right, and compatible with http://www.opengroup.org/orc/DOCS/XNS/text/accept.htm http://www.fifi.org/cgi-bin/man2html/usr/share/man/man2/accept.2.gz There are some interesting comments with noting in a quote in http://www.humanfactor.com/cgi-bin/cgi-delegate/apache-ML/nh/1997/Jan/1176.html I hope to take a look at the implementation this evening. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Wed, 7 Feb 2001, Kris Kennaway wrote: > Can anyone comment on this patch? > > http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/kern/uipc_socket.c > > Kris > > ----- Forwarded message from itojun@iijlab.net ----- > > Delivered-To: kkenn@localhost.obsecurity.org > Delivered-To: kris@freebsd.org > To: merge@kame.net > Subject: accept(2) behavior with tcp RST right after handshake > X-Template-Reply-To: itojun@itojun.org > X-Template-Return-Receipt-To: itojun@itojun.org > X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 > From: itojun@iijlab.net > Date: Wed, 07 Feb 2001 21:39:49 +0900 > X-UIDL: aff7d2fbee72775e2137abcde0bef0d0 > > i believe you will want to merge this. > scenario: > - you are listening to tcp port > - someone comes in, handshake (SYN, SYNACK, ACK) > - someone sends RST > - your server issues accept(2) > previous behavior: accept(2) returns successful result with zero- > length sockaddr. > new behavior: return ECONNABORTED. > > effect: > - if someone runs nmap against your machine, and you are unlucky, > your server listening to tcp port (like BIND9) can get > segv/abort due to unexpected zero-length sockaddr + successful > error return on accept(2). > > itojun > > ------- Forwarded Messages > > Return-Path: owner-cvs-kame@kame.net > Return-Path: > Received: from orange.kame.net (orange.kame.net [203.178.141.194]) > by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id VAA00242 > for ; Wed, 7 Feb 2001 21:35:16 +0900 (JST) > Received: (from daemon@localhost) > by orange.kame.net (8.9.3+3.2W/3.7W/smtpfeed 1.06) id VAA48429; > Wed, 7 Feb 2001 21:35:16 +0900 (JST) > Received: (from itojun@localhost) > by orange.kame.net (8.9.3+3.2W/3.7W) id VAA48423; > Wed, 7 Feb 2001 21:35:15 +0900 (JST) > Date: Wed, 7 Feb 2001 21:35:15 +0900 (JST) > From: Jun-ichiro itojun Hagino > Message-Id: <200102071235.VAA48423@orange.kame.net> > To: cvs-kame:; > Subject: kame cvs commit: kame/freebsd4/sys/kern uipc_socket.c kame/netbsd/sys/kern > uipc_socket.c kame/openbsd/sys/kern uipc_socket.c > Reply-to: core@kame.net > X-Filter: mailagent [version 3.0 PL68] for itojun@itojun.org > > itojun 2001/02/07 21:35:15 JST > > Modified files: > freebsd4/sys/kern uipc_socket.c > netbsd/sys/kern uipc_socket.c > openbsd/sys/kern uipc_socket.c > Log: > return ECONNABORTED, if the socket (tcp connection for example) > is disconnected by RST right before accept(2). fixes PR 10698/12027. > checked with SUSv2, XNET 5.2, and Stevens (unix network programming > vol 1 2nd ed) section 5.11. > > Revision Changes Path > 1.2 +243 -10 kame/freebsd4/sys/kern/uipc_socket.c > 1.3 +1 -1 kame/netbsd/sys/kern/uipc_socket.c > 1.3 +1 -1 kame/openbsd/sys/kern/uipc_socket.c > > ------- Message 2 > > Return-Path: owner-cvs-kame-local@kame.net > Return-Path: > Received: from orange.kame.net (orange.kame.net [203.178.141.194]) > by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id VAA00253 > for ; Wed, 7 Feb 2001 21:35:20 +0900 (JST) > Received: (from itojun@localhost) > by orange.kame.net (8.9.3+3.2W/3.7W/smtpfeed 1.06) id VAA48466; > Wed, 7 Feb 2001 21:35:19 +0900 (JST) > Date: Wed, 7 Feb 2001 21:35:19 +0900 (JST) > From: Jun-ichiro itojun Hagino > Message-Id: <200102071235.VAA48466@orange.kame.net> > To: cvs-kame-local@kame.net > Subject: kame-local cvs commit: kame/bsdi4/sys/kern uipc_socket.c > X-Filter: mailagent [version 3.0 PL68] for itojun@itojun.org > > itojun 2001/02/07 21:35:19 JST > > Modified files: > bsdi4/sys/kern uipc_socket.c > Log: > return ECONNABORTED, if the socket (tcp connection for example) > is disconnected by RST right before accept(2). fixes PR 10698/12027. > checked with SUSv2, XNET 5.2, and Stevens (unix network programming > vol 1 2nd ed) section 5.11. > > Revision Changes Path > 1.4 +1 -1 kame/bsdi4/sys/kern/uipc_socket.c > > ------- End of Forwarded Messages > > > > ----- End forwarded message ----- > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 12:23: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 24EB637B65D for ; Wed, 7 Feb 2001 12:22:45 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f17KMdR84116; Wed, 7 Feb 2001 12:22:39 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102072022.f17KMdR84116@iguana.aciri.org> Subject: Re: send problem on udp socket... In-Reply-To: <200102072009.PAA46020@khavrinen.lcs.mit.edu> from Garrett Wollman at "Feb 7, 2001 3: 9: 3 pm" To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Wed, 7 Feb 2001 12:22:39 -0800 (PST) Cc: rizzo@aciri.org, wollman@khavrinen.lcs.mit.edu, bright@wintelcom.net, net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I've thought about this problem before, in the context of a TCP > sender, where the best solution is both (a) hard and (b) significantly > different. I had not thought about it in the case of UDP, but yes, > that could be a significant issue, particularly since UDP packets on > the receive queue can never be coalesced (so there's DoS potential). > > I think adding a (sort of) tail pointer to the socket buffer might be > helpful. I think you want it to point to the mbuf before the last > *record* in the socket buffer, in order for sbcompress() to do its oh yes, this is what i am actually implementing now: struct sockbuf { ... struct mbuf *sb_mb_head; /* the old sb_mb */ struct mbuf *sb_mb_tail; /* last record in chain */ ... the renaming of sb_mb is just a temporary thing to easily locate where the field is used. sb_mb_tail is only significant if sb_mb_head!=NULL and it is such that sb_mb_tail->m_nextpkt is always NULL. The change seems not too invasive, the only place which is unclear to me is uipc_usrreq.c:unp_scan(). Does the above sounds right ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 12:27:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 6BBB737B491 for ; Wed, 7 Feb 2001 12:27:36 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f17KSlL77553; Wed, 7 Feb 2001 14:28:47 -0600 (CST) (envelope-from jlemon) Date: Wed, 7 Feb 2001 14:28:47 -0600 (CST) From: Jonathan Lemon Message-Id: <200102072028.f17KSlL77553@prism.flugsvamp.com> To: kris@obsecurity.org, net@freebsd.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] X-Newsgroups: local.mail.freebsd-net In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: >-=-=-=-=-=- > >Can anyone comment on this patch? > >http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/kern/uipc_socket.c Looks good to me (although the patch is mixed in with a bunch of other crud). I've tested it out locally and will commit it unless there are any objections. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 13: 6:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from brisefer.cediti.be (brisefer.cediti.be [193.190.156.67]) by hub.freebsd.org (Postfix) with ESMTP id 263D437B699 for ; Wed, 7 Feb 2001 13:06:40 -0800 (PST) Received: by brisefer.cediti.be with Internet Mail Service (5.5.2650.21) id <1LDHYCM9>; Wed, 7 Feb 2001 22:06:59 +0100 Message-ID: From: Olivier Cherrier To: Olivier Cherrier Cc: 'freebsd-net' Subject: RE: pptp server Date: Wed, 7 Feb 2001 22:06:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-15" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >Yes, I've already asked him .... I am a little bit confused >that I don't >succeed ... :( >Maybe it is my fuc... windows 2k which is the problem .... > Ho, I think that I found my problem ... maybe In fact, the "mppe encryption" is included in the MS-Chap protocol, isn't it ? The encryption, as mpd 3.2 calls it, isn't supported by windows clients. I tcpdumped a session between my pptp server and a windows client : I got : << ... 22:14:37.382601 193.190.156.147 > mirador.cediti.be: gre-proto-0x880B (gre encap) 22:14:37.383061 mirador.cediti.be > 193.190.156.147: gre-proto-0x880B (gre encap) 22:14:37.383187 193.190.156.147 > mirador.cediti.be: gre-proto-0x880B (gre encap) 22:14:37.383325 193.190.156.147 > mirador.cediti.be: gre-proto-0x880B (gre encap) 22:14:37.383667 193.190.156.147 > mirador.cediti.be: gre-proto-0x880B (gre encap) 22:14:37.383773 193.190.156.147 > mirador.cediti.be: gre-proto-0x880B (gre encap) 22:14:37.384508 mirador.cediti.be > 193.190.156.147: gre-proto-0x880B (gre encap) 22:14:37.384949 mirador.cediti.be > 193.190.156.147: gre-proto-0x880B (gre encap) ... >> Is this the proof that the communication is encrypted ? (sorry for this newbie question but I am't a guru .... not yet -:) It is surprising because on the windows client side, I set in the security option : _ Optional encryption (If I want "require encryption", the error "encryption not supported by server" occurs) _ Allow these protocols: MS-CHAP So, if I am right, MS-CHAP includes MPPE encryption even if encryption is not explicitely set; don't it ? Thanks a lot for your help. Olivier. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 13:38:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id AEE6237B6A6; Wed, 7 Feb 2001 13:38:09 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id OAA05271; Wed, 7 Feb 2001 14:32:13 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAOCaGMh; Wed Feb 7 14:29:51 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA24445; Wed, 7 Feb 2001 14:35:45 -0700 (MST) From: Terry Lambert Message-Id: <200102072135.OAA24445@usr08.primenet.com> Subject: Re: CFR: Sequential mbuf read/write extensions To: bp@butya.kz (Boris Popov) Date: Wed, 7 Feb 2001 21:35:44 +0000 (GMT) Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: from "Boris Popov" at Feb 06, 2001 05:50:52 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Before starting import process for smbfs, I would like to > introduce new API which greatly simplifies process of packaging data into > mbufs and fetching it back (in fact, similar API already presented in the > tree, but it is private to the netncp code and it will be really nice to > share it). [ ... ] Please include the ability to determine the length of the current contents (as a marcro?) so that buffers can be padded, as necessary, since some hardware and some protocols require this. Also consider protecting the structure with a mutex, at least in kernel space (this would make the macro harder to write, which is why I put it into a parenthetical, question-marjed statement). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 17:14:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id A9ED237B65D for ; Wed, 7 Feb 2001 17:13:54 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA09386; Thu, 8 Feb 2001 10:13:40 +0900 (JST) To: Jonathan Lemon Cc: kris@obsecurity.org, net@freebsd.org In-reply-to: jlemon's message of Wed, 07 Feb 2001 14:28:47 CST. <200102072028.f17KSlL77553@prism.flugsvamp.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] From: itojun@iijlab.net Date: Thu, 08 Feb 2001 10:13:40 +0900 Message-ID: <9384.981594820@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Looks good to me (although the patch is mixed in with a bunch >of other crud). I've tested it out locally and will commit it >unless there are any objections. it is because of cvs issue. the important portion is below. itojun @@ -320,11 +359,8 @@ soaccept(so, nam) so->so_state &= ~SS_NOFDREF; if ((so->so_state & SS_ISDISCONNECTED) == 0) error = (*so->so_proto->pr_usrreqs->pru_accept)(so, nam); - else { - if (nam) - *nam = 0; - error = 0; - } + else + error = ECONNABORTED; splx(s); return (error); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 17:30:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 4027637B65D for ; Wed, 7 Feb 2001 17:30:04 -0800 (PST) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id RAA03782; Wed, 7 Feb 2001 17:34:07 -0800 (PST) Message-Id: <200102080134.RAA03782@implode.root.com> To: itojun@iijlab.net Cc: Jonathan Lemon , kris@obsecurity.org, net@FreeBSD.ORG Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-reply-to: Your message of "Thu, 08 Feb 2001 10:13:40 +0900." <9384.981594820@coconut.itojun.org> From: David Greenman Reply-To: dg@root.com Date: Wed, 07 Feb 2001 17:34:07 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>Looks good to me (although the patch is mixed in with a bunch >>of other crud). I've tested it out locally and will commit it >>unless there are any objections. > > it is because of cvs issue. the important portion is below. Looks good to me as well. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 17:33:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 7249737B491 for ; Wed, 7 Feb 2001 17:33:36 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA09621; Thu, 8 Feb 2001 10:33:29 +0900 (JST) To: Jonathan Lemon , kris@obsecurity.org, net@freebsd.org In-reply-to: itojun's message of Thu, 08 Feb 2001 10:13:40 JST. <9384.981594820@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] From: itojun@iijlab.net Date: Thu, 08 Feb 2001 10:33:29 +0900 Message-ID: <9619.981596009@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>Looks good to me (although the patch is mixed in with a bunch >>of other crud). I've tested it out locally and will commit it >>unless there are any objections. > it is because of cvs issue. the important portion is below. oops, need some change in uipc_syscalls.c side... hold on. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 17:39:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 4F5F937B401 for ; Wed, 7 Feb 2001 17:39:31 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f181eeP88216 for net@freebsd.org; Wed, 7 Feb 2001 19:40:40 -0600 (CST) (envelope-from jlemon) Date: Wed, 7 Feb 2001 19:40:40 -0600 From: Jonathan Lemon To: net@freebsd.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010207194040.O650@prism.flugsvamp.com> References: <9384.981594820@coconut.itojun.org> <9619.981596009@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <9619.981596009@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Current updated patch for comments is below. Jayanth did make one point that an application could assume that the error return from accept was in regards to the listening socket instead of the new socket, so that may be a concern. -- Jonathan Index: uipc_socket.c =================================================================== RCS file: /ncvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.68.2.11 diff -u -r1.68.2.11 uipc_socket.c --- uipc_socket.c 2000/12/22 10:25:21 1.68.2.11 +++ uipc_socket.c 2001/02/07 20:30:29 @@ -365,11 +365,8 @@ so->so_state &= ~SS_NOFDREF; if ((so->so_state & SS_ISDISCONNECTED) == 0) error = (*so->so_proto->pr_usrreqs->pru_accept)(so, nam); - else { - if (nam) - *nam = 0; - error = 0; - } + else + error = ECONNABORTED; splx(s); return (error); } Index: uipc_syscalls.c =================================================================== RCS file: /ncvs/src/sys/kern/uipc_syscalls.c,v retrieving revision 1.65.2.6 diff -u -r1.65.2.6 uipc_syscalls.c --- uipc_syscalls.c 2000/12/02 00:47:50 1.65.2.6 +++ uipc_syscalls.c 2001/02/07 21:27:03 @@ -283,7 +283,19 @@ nfp->f_ops = &socketops; nfp->f_type = DTYPE_SOCKET; sa = 0; - (void) soaccept(so, &sa); + error = soaccept(so, &sa); + if (error) { + /* + * return a namelen of zero for older code which might + * ignore the return value from accept. + */ + if (uap->name != NULL) { + namelen = 0; + (void) copyout((caddr_t)&namelen, + (caddr_t)uap->anamelen, sizeof(*uap->anamelen)); + } + goto noconnection; + } if (sa == NULL) { namelen = 0; if (uap->name) @@ -307,6 +319,7 @@ error = copyout((caddr_t)&namelen, (caddr_t)uap->anamelen, sizeof (*uap->anamelen)); } +noconnection: if (sa) FREE(sa, M_SONAME); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 17:40:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 71E0537B491 for ; Wed, 7 Feb 2001 17:40:03 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA09724; Thu, 8 Feb 2001 10:39:56 +0900 (JST) To: Jonathan Lemon , kris@obsecurity.org, net@freebsd.org In-reply-to: itojun's message of Thu, 08 Feb 2001 10:33:29 JST. <9619.981596009@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] From: itojun@iijlab.net Date: Thu, 08 Feb 2001 10:39:56 +0900 Message-ID: <9722.981596396@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>Looks good to me (although the patch is mixed in with a bunch >>>of other crud). I've tested it out locally and will commit it >>>unless there are any objections. >> it is because of cvs issue. the important portion is below. > oops, need some change in uipc_syscalls.c side... hold on. this diff is taken against 4.2-RELEASE (in kame tree), sorry. also i need to say that i ran no tests (i have no environment). uipc_syscalls.c change: make very sure to nuke file descriptor on errors uipc_socket.c change: return ECONNABORTED itojun Index: kern/uipc_socket.c =================================================================== RCS file: /cvsroot/kame/kame/freebsd4/sys/kern/uipc_socket.c,v retrieving revision 1.1.1.3 retrieving revision 1.3 diff -u -r1.1.1.3 -r1.3 --- kern/uipc_socket.c 2001/01/19 02:25:59 1.1.1.3 +++ kern/uipc_socket.c 2001/02/08 01:37:42 1.3 @@ -362,7 +362,7 @@ else { if (nam) *nam = 0; - error = 0; + error = ECONNABORTED; } splx(s); return (error); Index: kern/uipc_syscalls.c =================================================================== RCS file: /cvsroot/kame/kame/freebsd4/sys/kern/uipc_syscalls.c,v retrieving revision 1.1.1.3 retrieving revision 1.2 diff -u -r1.1.1.3 -r1.2 --- kern/uipc_syscalls.c 2001/01/19 02:26:00 1.1.1.3 +++ kern/uipc_syscalls.c 2001/02/08 01:37:42 1.2 @@ -270,28 +270,22 @@ fp->f_ops = &socketops; fp->f_type = DTYPE_SOCKET; sa = 0; - (void) soaccept(so, &sa); - if (sa == 0) { - namelen = 0; - if (uap->name) - goto gotnoname; - splx(s); - return 0; - } - if (uap->name) { + error = soaccept(so, &sa); + if (!error && uap->name) { /* check sa_len before it is destroyed */ - if (namelen > sa->sa_len) - namelen = sa->sa_len; + if (sa) { + if (namelen > sa->sa_len) + namelen = sa->sa_len; #ifdef COMPAT_OLDSOCK - if (compat) - ((struct osockaddr *)sa)->sa_family = - sa->sa_family; + if (compat) + ((struct osockaddr *)sa)->sa_family = + sa->sa_family; #endif - error = copyout(sa, (caddr_t)uap->name, (u_int)namelen); - if (!error) -gotnoname: - error = copyout((caddr_t)&namelen, - (caddr_t)uap->anamelen, sizeof (*uap->anamelen)); + error = copyout(sa, (caddr_t)uap->name, (u_int)namelen); + } else + namelen = 0; + error = copyout((caddr_t)&namelen, + (caddr_t)uap->anamelen, sizeof (*uap->anamelen)); } if (sa) FREE(sa, M_SONAME); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 18:16:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from VL-MS-MR001.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 435B937B401; Wed, 7 Feb 2001 18:16:23 -0800 (PST) Received: from jehovah ([24.201.144.31]) by VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G8F28Y04.TDM; Wed, 7 Feb 2001 21:14:58 -0500 Message-ID: <00ec01c09175$3a0cea60$1f90c918@jehovah> From: "Bosko Milekic" To: , "Rich Wales" Cc: Subject: Fw: if_ed.c && BRIDGE Date: Wed, 7 Feb 2001 21:17:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Luigi, -net: There seems to be a problem with the BRIDGE-specific "optimization" in if_ed.c. What it does is avoid getting a packet from the card if bridge_in() says that we're going to drop it. However, the code is broken and something eventually leads to a page fault. Disactivating this portion of if_ed.c rids us of the problem, but doesn't "fix it" properly. Rich has some debugging information including, I believe, a crash dump. Rich, if you can please post that here (i.e. the backtraces and fault information) as I seemed to have lost it (grrrrr, sorry about that). I would rather not just disable the BRIDGE section of if_ed.c to "mask out" the problem. Regards, Bosko. Rich Wales wrote: > Bosko -- > > That "if_ed.c" patch you had me try (commenting out the packet-dropping > optimization) seems to be quite solid. If you wanted to go ahead and > commit it into -STABLE . . . . > > Rich Wales richw@webcom.com http://www.webcom.com/richw/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 18:31: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 2B52A37B401; Wed, 7 Feb 2001 18:30:48 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f182Uax06671; Wed, 7 Feb 2001 18:30:36 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102080230.f182Uax06671@iguana.aciri.org> Subject: Re: Fw: if_ed.c && BRIDGE In-Reply-To: <00ec01c09175$3a0cea60$1f90c918@jehovah> from Bosko Milekic at "Feb 7, 2001 9:17: 3 pm" To: bmilekic@technokratis.com (Bosko Milekic) Date: Wed, 7 Feb 2001 18:30:35 -0800 (PST) Cc: luigi@FreeBSD.ORG, richw@webcom.com, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hi Luigi, -net: just one thing, before posting details could you verify that the problem still occurs with the code that is in -STABLE as of today ? I have done a bunch of changes to this and related code over the last couple of weeks, including testing on an "ed" card, and have not seen any panic on that lately (i did manage to produce a panic before some of these commits so i am not claiming that the problem never existed). cheers luigi > There seems to be a problem with the BRIDGE-specific > "optimization" in if_ed.c. What it does is avoid getting a packet from > the card if bridge_in() says that we're going to drop it. However, the > code is broken and something eventually leads to a page fault. > Disactivating this portion of if_ed.c rids us of the problem, but > doesn't "fix it" properly. > > Rich has some debugging information including, I believe, a crash > dump. Rich, if you can please post that here (i.e. the backtraces and > fault information) as I seemed to have lost it (grrrrr, sorry about > that). > > I would rather not just disable the BRIDGE section of if_ed.c to > "mask out" the problem. > > Regards, > Bosko. > > Rich Wales wrote: > > > Bosko -- > > > > That "if_ed.c" patch you had me try (commenting out the > packet-dropping > > optimization) seems to be quite solid. If you wanted to go ahead > and > > commit it into -STABLE . . . . > > > > Rich Wales richw@webcom.com > http://www.webcom.com/richw/ > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 18:58:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 2B71637B65D for ; Wed, 7 Feb 2001 18:58:07 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f182w7c08367; Wed, 7 Feb 2001 18:58:07 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102080258.f182w7c08367@iguana.aciri.org> Subject: [patch] fast sbappend*, please try... To: net@freebsd.org Date: Wed, 7 Feb 2001 18:58:07 -0800 (PST) Cc: rizzo@aciri.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I would be grateful if someone could test the attached patch which deals with the following problem: on all *BSD version, socket buffers contain a list of incoming and/or outgoing mbufs. Unfortunately the list only has a pointer to the head, meaning that all append operations require to scan the full list. The overhead can be very bad in some cases (e.g. small UDP packets), and becomes worse and worse as the socket buffer size increases (which is what one would commonly do when expecting a lot of traffic!). The attached patch implements a tail pointer to the list, so that you can append in constant time. By default, the code works exactly as before -- the tail of the list is reached with the usual linear scan, and the pointer to the tail is only used for comparison purposes to make sure that it yields the same value. If you enable the fast behaviour with sysctl -w kern.ipc.fastscan=1 then the new code takes over and linear scans are replaced by dereferences of the tail pointer. Apart from the obvious benefits of using O(1) instead of O(n) algorithms, your mileage may vary. When the socket buffer is almost always empty (fast receivers) then you have no gain. When the socket buffer is almost always full you also have no gain, because the decision to drop the packet only requires a comparison. However, this code can really avoid trashing in those cases where the queue size oscillates. I'd like to commit this (or similar) code after proper testing, so i'd like people to try it out -- I am reasonably confident about it, and have done a fair amount of testing under heavy udp load, but want to be sure that there are no side effects. The attached patch applies to 4.2 (and hopefully to CURRENT as well). cheers luigi Index: sys/socketvar.h =================================================================== RCS file: /home/iguana/u0/rizzo/ncvs/src/sys/sys/socketvar.h,v retrieving revision 1.46.2.4 diff -u -r1.46.2.4 socketvar.h --- sys/socketvar.h 2000/11/26 02:30:08 1.46.2.4 +++ sys/socketvar.h 2001/02/08 00:58:31 @@ -93,6 +93,7 @@ u_long sb_mbmax; /* max chars of mbufs to use */ long sb_lowat; /* low water mark */ struct mbuf *sb_mb; /* the mbuf chain */ + struct mbuf *sb_mb_tail; /* last pkt in chain (if sb_mb != NULL) */ struct selinfo sb_sel; /* process selecting read/write */ short sb_flags; /* flags, see below */ short sb_timeo; /* timeout for read/write */ Index: kern/uipc_socket.c =================================================================== RCS file: /home/iguana/u0/rizzo/ncvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.68.2.10 diff -u -r1.68.2.10 uipc_socket.c --- kern/uipc_socket.c 2000/11/17 19:47:27 1.68.2.10 +++ kern/uipc_socket.c 2001/02/08 01:40:04 @@ -772,6 +772,12 @@ goto restart; } dontblock: + /* + * On entry here, m points to the first record on the socket buffer. + * While we process the initial mbufs containing address and control + * info we save a copy of m->m_nextpkt into nextrecord. We do need + * to take care of sb_mb_tail until later. + */ if (uio->uio_procp) uio->uio_procp->p_stats->p_ru.ru_msgrcv++; nextrecord = m->m_nextpkt; @@ -815,9 +821,17 @@ controlp = &(*controlp)->m_next; } } + /* + * If m is non-null, we have some data to read. From now on, make + * sure to keep sb_mb_tail consistent when working on the last + * packet on the chain (nextrecord==NULL) and we change m->m_nextpkt. + */ if (m) { - if ((flags & MSG_PEEK) == 0) + if ((flags & MSG_PEEK) == 0) { m->m_nextpkt = nextrecord; + if (nextrecord == NULL) + so->so_rcv.sb_mb_tail = m ; + } type = m->m_type; if (type == MT_OOBDATA) flags |= MSG_OOB; @@ -873,8 +887,11 @@ MFREE(m, so->so_rcv.sb_mb); m = so->so_rcv.sb_mb; } - if (m) + if (m) { m->m_nextpkt = nextrecord; + if (nextrecord == NULL) + so->so_rcv.sb_mb_tail = m ; + } } } else { if (flags & MSG_PEEK) @@ -931,8 +948,11 @@ (void) sbdroprecord(&so->so_rcv); } if ((flags & MSG_PEEK) == 0) { - if (m == 0) + if (m == 0) { so->so_rcv.sb_mb = nextrecord; + if (nextrecord == NULL || nextrecord->m_nextpkt == NULL) + so->so_rcv.sb_mb_tail = nextrecord ; + } if (pr->pr_flags & PR_WANTRCVD && so->so_pcb) (*pr->pr_usrreqs->pru_rcvd)(so, flags); } Index: kern/uipc_socket2.c =================================================================== RCS file: /home/iguana/u0/rizzo/ncvs/src/sys/kern/uipc_socket2.c,v retrieving revision 1.55.2.7 diff -u -r1.55.2.7 uipc_socket2.c --- kern/uipc_socket2.c 2000/09/07 19:13:37 1.55.2.7 +++ kern/uipc_socket2.c 2001/02/08 01:44:53 @@ -55,6 +55,8 @@ int maxsockets; +int fastscan; /* XXX see below */ + /* * Primitive routines for operating on sockets and socket buffers */ @@ -477,7 +479,51 @@ * or sbdroprecord() when the data is acknowledged by the peer. */ +static struct mbuf * +sbgettail(struct sockbuf *sb, char *msg, struct mbuf *m0); /* + * sbgettail returns a pointer to the last record of the socketbuffer. + * If m0 is non-null, it also appends m0 to the chain. + */ +static struct mbuf * +sbgettail(struct sockbuf *sb, char *msg, struct mbuf *m0) +{ + struct mbuf *m = sb->sb_mb; + + if (m == NULL) + goto done; + if (sb->sb_mb_tail == NULL) + printf("%s: null tail\n", msg); + if (fastscan && sb->sb_mb_tail != NULL) { + m = sb->sb_mb_tail ; + if (m == NULL) + panic ("sbgettail returns NULL"); + if (m->m_nextpkt == NULL) /* ok ... */ + goto done; + /* otherwise continue scan */ + printf("%s: sbgettail m_nextpkt != NULL\n", msg); + } + while (m->m_nextpkt) + m = m->m_nextpkt ; + if (m != sb->sb_mb_tail) { + if (sb->sb_mb_tail != NULL) + printf("%s: bad tail 0x%p instead of 0x%p\n", + msg, sb->sb_mb_tail, m); + sb->sb_mb_tail = m ; + } +done: + if (m0) { + if (m) + m->m_nextpkt = m0; + else + sb->sb_mb = m0; + sb->sb_mb_tail = m0 ; + m = m0 ; + } + return m ; +} + +/* * Append mbuf chain m to the last record in the * socket buffer sb. The additional space associated * the mbuf chain is recorded in sb. Empty mbufs are @@ -492,10 +538,8 @@ if (m == 0) return; - n = sb->sb_mb; + n = sbgettail(sb, "sbappend", NULL); if (n) { - while (n->m_nextpkt) - n = n->m_nextpkt; do { if (n->m_flags & M_EOR) { sbappendrecord(sb, m); /* XXXXXX!!!! */ @@ -545,19 +589,13 @@ if (m0 == 0) return; - m = sb->sb_mb; - if (m) - while (m->m_nextpkt) - m = m->m_nextpkt; /* * Put the first mbuf on the queue. * Note this permits zero length records. */ sballoc(sb, m0); - if (m) - m->m_nextpkt = m0; - else - sb->sb_mb = m0; + m = sbgettail(sb, "sbappendrecord", m0); + if (m0->m_nextpkt != NULL) printf("ouch! sbappendrecord nextpkt!=NULL\n"); m = m0->m_next; m0->m_next = 0; if (m && (m0->m_flags & M_EOR)) { @@ -603,6 +641,8 @@ */ sballoc(sb, m0); m0->m_nextpkt = *mp; + if (*mp == NULL) /* m0 is actually the new tail */ + sb->sb_mb_tail = m0 ; *mp = m0; m = m0->m_next; m0->m_next = 0; @@ -653,13 +693,7 @@ m->m_next = control; for (n = m; n; n = n->m_next) sballoc(sb, n); - n = sb->sb_mb; - if (n) { - while (n->m_nextpkt) - n = n->m_nextpkt; - n->m_nextpkt = m; - } else - sb->sb_mb = m; + n = sbgettail(sb, "sbappendaddr", m); return (1); } @@ -686,13 +720,7 @@ n->m_next = m0; /* concatenate data to control */ for (m = control; m; m = m->m_next) sballoc(sb, m); - n = sb->sb_mb; - if (n) { - while (n->m_nextpkt) - n = n->m_nextpkt; - n->m_nextpkt = control; - } else - sb->sb_mb = control; + n = sbgettail(sb, "sbappendcontrol", control); return (1); } @@ -731,7 +759,7 @@ if (n) n->m_next = m; else - sb->sb_mb = m; + sb->sb_mb = sb->sb_mb_tail = m; sballoc(sb, m); n = m; m->m_flags &= ~M_EOR; @@ -1003,6 +1031,8 @@ SYSCTL_INT(_kern_ipc, KIPC_SOCKBUF_WASTE, sockbuf_waste_factor, CTLFLAG_RW, &sb_efficiency, 0, ""); +SYSCTL_INT(_kern_ipc, OID_AUTO, fastscan, CTLFLAG_RW, + &fastscan, 0, "Fast scanning of socket queues for append"); /* * Initialise maxsockets */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 20:27:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id BD09A37B4EC; Wed, 7 Feb 2001 20:27:00 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id UAA71301; Wed, 7 Feb 2001 20:26:58 -0800 (PST) (envelope-from richw) Date: Wed, 7 Feb 2001 20:26:58 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Luigi Rizzo Cc: Bosko Milekic , luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Fw: if_ed.c && BRIDGE In-Reply-To: <200102080230.f182Uax06671@iguana.aciri.org> Message-ID: <20010208042021.71196.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi wrote: > Just one thing, before posting details could you verify that > the problem still occurs with the code that is in -STABLE as > of today? I have done a bunch of changes to this and related > code over the last couple of weeks, including testing on an > "ed" card, and have not seen any panic on that lately (I did > manage to produce a panic before some of these commits so I > am not claiming that the problem never existed). I built a new kernel from the -STABLE code (cvsup'ed last night, Tue. 2/6 at 20:26), and stress-tested it by downloading a large file over a high-speed (1.3Mbit/sec) DSL line using a Compex NE2000-compatible PCI NIC (ed0) as part of a bridge cluster. It crashed; see below for a trace of the crash dump. Rich Wales richw@webcom.com http://www.webcom.com/richw/ ======================================================================== gateway# gdb -k GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd". (kgdb) symbol-file kernel-d.debug Reading symbols from kernel.debug...done. (kgdb) exec-file /var/crash/kernel.3 (kgdb) core-file /var/crash/vmcore.3 IdlePTD 4284416 initial pcb at 374340 panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc0947000 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02aa2b9 stack pointer = 0x10:0xc0342a7c frame pointer = 0x10:0xc0342a88 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = net dumping to dev #ad/0x30001, offset 53248 dump ata0: resetting devices .. done 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 dumpsys () at /big/4.2/usr/STABLE/src/sys/kern/kern_shutdown.c:469 469 if (dumping++) { (kgdb) where #0 dumpsys () at /big/4.2/usr/STABLE/src/sys/kern/kern_shutdown.c:469 #1 0xc013a495 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0xc03428e8 "4)4À") at /big/4.2/usr/STABLE/src/sys/ddb/db_command.c:532 #2 0xc013a2c1 in db_command (last_cmdp=0xc0345d1c, cmd_table=0xc0345b7c, aux_cmd_tablep=0xc036f034) at /big/4.2/usr/STABLE/src/sys/ddb/db_command.c:333 #3 0xc013a386 in db_command_loop () at /big/4.2/usr/STABLE/src/sys/ddb/db_command.c:455 #4 0xc013c493 in db_trap (type=12, code=0) at /big/4.2/usr/STABLE/src/sys/ddb/db_trap.c:71 #5 0xc02be0ba in kdb_trap (type=12, code=0, regs=0xc0342a3c) at /big/4.2/usr/STABLE/src/sys/i386/i386/db_interface.c:158 #6 0xc02cd2c0 in trap_fatal (frame=0xc0342a3c, eva=3230953472) at /big/4.2/usr/STABLE/src/sys/i386/i386/trap.c:946 #7 0xc02ccf99 in trap_pfault (frame=0xc0342a3c, usermode=0, eva=3230953472) at /big/4.2/usr/STABLE/src/sys/i386/i386/trap.c:844 #8 0xc02ccb0f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = -1064013824, tf_esi = 54272, tf_ebp = -1070323064, tf_isp = -1070323096, tf_ebx = 16, tf_edx = 54288, tf_ecx = 27932, tf_eax = -1061304128, tf_trapno = 12, tf_err = 2, tf_eip = -1070947655, tf_cs = 8, tf_eflags = 66118, tf_esp = 6126, tf_ss = -1064017366}) at /big/4.2/usr/STABLE/src/sys/i386/i386/trap.c:443 #9 0xc02aa2b9 in ed_pio_readmem (sc=0xc0bdda00, src=19456, dst=0xc094622a "ÔF·GõCÄ3\211ç\005®Ô\2004gÅ¡c\204H\2135Éÿ\023¬xog@\025\226ã¥z\a+Óþôt\217p¦upô", amount=59406) at machine/cpufunc.h:213 #10 0xc02aa12b in ed_get_packet (sc=0xc0bdda00, buf=0x6804cannot read proc at 0 ) at /big/4.2/usr/STABLE/src/sys/dev/ed/if_ed.c:2587 #11 0xc02a9a2b in edintr (arg=0xc0bdda00) at /big/4.2/usr/STABLE/src/sys/dev/ed/if_ed.c:2179 #12 0xc02d52a5 in intr_mux (arg=0xc08b64e0) at /big/4.2/usr/STABLE/src/sys/i386/isa/intr_machdep.c:582 (kgdb) ======================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 20:29:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id F0F9D37B401; Wed, 7 Feb 2001 20:29:07 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id NAA12241; Thu, 8 Feb 2001 13:28:55 +0900 (JST) To: Kris Kennaway Cc: net@freebsd.org, security-officer@freebsd.org In-reply-to: kris's message of Wed, 07 Feb 2001 10:14:18 PST. <20010207101417.A28791@mollari.cthul.hu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] From: itojun@iijlab.net Date: Thu, 08 Feb 2001 13:28:55 +0900 Message-ID: <12239.981606535@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > i believe you will want to merge this. > scenario: > - you are listening to tcp port > - someone comes in, handshake (SYN, SYNACK, ACK) > - someone sends RST > - your server issues accept(2) > previous behavior: accept(2) returns successful result with zero- > length sockaddr. > new behavior: return ECONNABORTED. > > effect: > - if someone runs nmap against your machine, and you are unlucky, > your server listening to tcp port (like BIND9) can get > segv/abort due to unexpected zero-length sockaddr + successful > error return on accept(2). FYI: 9.1.0 had assert() against sockaddr returned by accept(2). therefore BIND 9.1.0 will get killed (or go suicide) by remote nmap with "previous (kernel) behavior" presented above. (it will only happen you are very unlucky - it is timing issue) BIND 9.1.1rc1 now includes workaround (no assert). itojun > 727. [port] Work around OS bug where accept() succeeds but > fails to fill in the peer address of the accepted > connection, by treating it as an error rather than > an assertion failure. [RT #809] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 21:24:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 5755537B491 for ; Wed, 7 Feb 2001 21:24:11 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA57535; Wed, 7 Feb 2001 21:24:06 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id VAA54629; Wed, 7 Feb 2001 21:24:05 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200102080524.VAA54629@curve.dellroad.org> Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: <20010207194040.O650@prism.flugsvamp.com> "from Jonathan Lemon at Feb 7, 2001 07:40:40 pm" To: Jonathan Lemon Date: Wed, 7 Feb 2001 21:24:05 -0800 (PST) Cc: net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jonathan Lemon writes: > Jayanth did make one point that an application could assume that > the error return from accept was in regards to the listening socket > instead of the new socket, so that may be a concern. Yes I have always assumed this to be true. If the connection is already broken before I get it, why bother giving it to me?? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 21:42:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id E6B2437B503 for ; Wed, 7 Feb 2001 21:42:12 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA57618; Wed, 7 Feb 2001 21:42:12 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id VAA54671; Wed, 7 Feb 2001 21:42:11 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200102080542.VAA54671@curve.dellroad.org> Subject: Re: pptp server In-Reply-To: "from Olivier Cherrier at Feb 7, 2001 10:06:53 pm" To: Olivier Cherrier Date: Wed, 7 Feb 2001 21:42:11 -0800 (PST) Cc: "'freebsd-net'" X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Olivier Cherrier writes: > Ho, I think that I found my problem ... maybe > In fact, the "mppe encryption" is included in the MS-Chap protocol, isn't it MPPE encryption piggybacks on MPPC compression. You can have either or both of 'E' and/or 'C'. Mpd only supports 'E' because 'C' requires proprietary files. MS-CHAP is required *for* MPPE encryption, in order to generate the keys. > 22:14:37.384949 mirador.cediti.be > 193.190.156.147: gre-proto-0x880B (gre > encap) > > Is this the proof that the communication is encrypted ? (sorry for this > newbie question but I am't a guru .... not yet -:) No, the encryption is only of the inner payload. > It is surprising because on the windows client side, I set in the security > option: > _ Optional encryption (If I want "require encryption", the error > "encryption not supported by server" occurs) > _ Allow these protocols: MS-CHAP > > So, if I am right, MS-CHAP includes MPPE encryption even if encryption is > not explicitely set; don't it ? No. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 7 22:30: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 695A037B67D for ; Wed, 7 Feb 2001 22:29:52 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id PAA13782; Thu, 8 Feb 2001 15:29:44 +0900 (JST) To: Archie Cobbs Cc: Jonathan Lemon , net@FreeBSD.ORG In-reply-to: archie's message of Wed, 07 Feb 2001 21:24:05 PST. <200102080524.VAA54629@curve.dellroad.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] From: itojun@iijlab.net Date: Thu, 08 Feb 2001 15:29:44 +0900 Message-ID: <13780.981613784@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Jayanth did make one point that an application could assume that >> the error return from accept was in regards to the listening socket >> instead of the new socket, so that may be a concern. >Yes I have always assumed this to be true. If the connection is >already broken before I get it, why bother giving it to me?? can we cancel sorwakeup() (happens on handshake completion)? I believed not. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 0: 1:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 47A1637B401; Thu, 8 Feb 2001 00:01:01 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f1880s410219; Thu, 8 Feb 2001 00:00:54 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102080800.f1880s410219@iguana.aciri.org> Subject: Re: Fw: if_ed.c && BRIDGE In-Reply-To: <20010208042021.71196.richw@wyattearp.stanford.edu> from Rich Wales at "Feb 7, 2001 8:26:58 pm" To: richw@webcom.com (Rich Wales) Date: Thu, 8 Feb 2001 00:00:49 -0800 (PST) Cc: rizzo@aciri.org, bmilekic@technokratis.com, luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org interesting dump... because it shows a bogus "length" parameter passed to ed_pio_readmem() Can you by chance find out what is the "len" value passed to ed_get_packet ? The printout in line #10 below is partially deleted by some error message. Now, NE2000 clones if you look at the driver are known for occasionally swapping the bytes of the length, but the driver was supposed to take care of this. Evidently there is some odd thing... cheers luigi > > > Just one thing, before posting details could you verify that > > the problem still occurs with the code that is in -STABLE as > > of today? I have done a bunch of changes to this and related > > code over the last couple of weeks, including testing on an > > "ed" card, and have not seen any panic on that lately (I did > > manage to produce a panic before some of these commits so I > > am not claiming that the problem never existed). > > I built a new kernel from the -STABLE code (cvsup'ed last night, Tue. > 2/6 at 20:26), and stress-tested it by downloading a large file over > a high-speed (1.3Mbit/sec) DSL line using a Compex NE2000-compatible > PCI NIC (ed0) as part of a bridge cluster. It crashed; see below for > a trace of the crash dump. > > Rich Wales richw@webcom.com http://www.webcom.com/richw/ > > ======================================================================== > > gateway# gdb -k > GNU gdb 4.18 > Copyright 1998 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-unknown-freebsd". > (kgdb) symbol-file kernel-d.debug > Reading symbols from kernel.debug...done. > (kgdb) exec-file /var/crash/kernel.3 > (kgdb) core-file /var/crash/vmcore.3 > IdlePTD 4284416 > initial pcb at 374340 > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xc0947000 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc02aa2b9 > stack pointer = 0x10:0xc0342a7c > frame pointer = 0x10:0xc0342a88 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = Idle > interrupt mask = net > > dumping to dev #ad/0x30001, offset 53248 > dump ata0: resetting devices .. done > 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 > --- > #0 dumpsys () at /big/4.2/usr/STABLE/src/sys/kern/kern_shutdown.c:469 > 469 if (dumping++) { > (kgdb) where > #0 dumpsys () at /big/4.2/usr/STABLE/src/sys/kern/kern_shutdown.c:469 > #1 0xc013a495 in db_fncall (dummy1=0, dummy2=0, dummy3=0, > dummy4=0xc03428e8 "4)4À") > at /big/4.2/usr/STABLE/src/sys/ddb/db_command.c:532 > #2 0xc013a2c1 in db_command (last_cmdp=0xc0345d1c, cmd_table=0xc0345b7c, > aux_cmd_tablep=0xc036f034) > at /big/4.2/usr/STABLE/src/sys/ddb/db_command.c:333 > #3 0xc013a386 in db_command_loop () > at /big/4.2/usr/STABLE/src/sys/ddb/db_command.c:455 > #4 0xc013c493 in db_trap (type=12, code=0) > at /big/4.2/usr/STABLE/src/sys/ddb/db_trap.c:71 > #5 0xc02be0ba in kdb_trap (type=12, code=0, regs=0xc0342a3c) > at /big/4.2/usr/STABLE/src/sys/i386/i386/db_interface.c:158 > #6 0xc02cd2c0 in trap_fatal (frame=0xc0342a3c, eva=3230953472) > at /big/4.2/usr/STABLE/src/sys/i386/i386/trap.c:946 > #7 0xc02ccf99 in trap_pfault (frame=0xc0342a3c, usermode=0, eva=3230953472) > at /big/4.2/usr/STABLE/src/sys/i386/i386/trap.c:844 > #8 0xc02ccb0f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, > tf_edi = -1064013824, tf_esi = 54272, tf_ebp = -1070323064, > tf_isp = -1070323096, tf_ebx = 16, tf_edx = 54288, tf_ecx = 27932, > tf_eax = -1061304128, tf_trapno = 12, tf_err = 2, tf_eip = -1070947655, > tf_cs = 8, tf_eflags = 66118, tf_esp = 6126, tf_ss = -1064017366}) > at /big/4.2/usr/STABLE/src/sys/i386/i386/trap.c:443 > #9 0xc02aa2b9 in ed_pio_readmem (sc=0xc0bdda00, src=19456, > dst=0xc094622a "ÔF·GõCÄ3\211ç\005®Ô\2004gÅ¡c\204H\2135Éÿ\023¬xog@\025\226ã¥z\a+Óþôt\217p¦upô", amount=59406) at machine/cpufunc.h:213 > #10 0xc02aa12b in ed_get_packet (sc=0xc0bdda00, buf=0x6804cannot read proc at 0 > ) > at /big/4.2/usr/STABLE/src/sys/dev/ed/if_ed.c:2587 > #11 0xc02a9a2b in edintr (arg=0xc0bdda00) > at /big/4.2/usr/STABLE/src/sys/dev/ed/if_ed.c:2179 > #12 0xc02d52a5 in intr_mux (arg=0xc08b64e0) > at /big/4.2/usr/STABLE/src/sys/i386/isa/intr_machdep.c:582 > (kgdb) > > ======================================================================== > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 0:52:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-01.iinet.net.au (syncopation-01.iinet.net.au [203.59.24.37]) by hub.freebsd.org (Postfix) with SMTP id 8150637B491 for ; Thu, 8 Feb 2001 00:51:51 -0800 (PST) Received: (qmail 18542 invoked by uid 666); 8 Feb 2001 08:58:38 -0000 Received: from reggae-14-250.nv.iinet.net.au (HELO elischer.org) (203.59.77.250) by mail.m.iinet.net.au with SMTP; 8 Feb 2001 08:58:38 -0000 Message-ID: <3A825E21.911852D2@elischer.org> Date: Thu, 08 Feb 2001 00:51:45 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Archie Cobbs Cc: Olivier Cherrier , 'freebsd-net' Subject: Re: pptp server References: <200102080542.VAA54671@curve.dellroad.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs wrote: > > Olivier Cherrier writes: > > Ho, I think that I found my problem ... maybe > > In fact, the "mppe encryption" is included in the MS-Chap protocol, isn't it > > MPPE encryption piggybacks on MPPC compression. You can have > either or both of 'E' and/or 'C'. Mpd only supports 'E' because > 'C' requires proprietary files. > > MS-CHAP is required *for* MPPE encryption, in order to generate the keys. > > > 22:14:37.384949 mirador.cediti.be > 193.190.156.147: gre-proto-0x880B (gre > > encap) > > > > Is this the proof that the communication is encrypted ? (sorry for this > > newbie question but I am't a guru .... not yet -:) > > No, the encryption is only of the inner payload. > > > It is surprising because on the windows client side, I set in the security > > option: > > _ Optional encryption (If I want "require encryption", the error > > "encryption not supported by server" occurs) > > _ Allow these protocols: MS-CHAP > > > > So, if I am right, MS-CHAP includes MPPE encryption even if encryption is > > not explicitely set; don't it ? > > No. so, does he have a chance of it working or not? > > -Archie -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 4:34:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id DAA3737B65D; Thu, 8 Feb 2001 04:33:51 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 8 Feb 2001 12:33:50 +0000 (GMT) To: Boris Popov Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org, iedowse@maths.tcd.ie Subject: Re: CFR: Sequential mbuf read/write extensions In-Reply-To: Your message of "Tue, 06 Feb 2001 17:50:52 +0600." Date: Thu, 08 Feb 2001 12:33:50 +0000 From: Ian Dowse Message-ID: <200102081233.aa16167@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Boris Popo v writes: > Before starting import process for smbfs, I would like to >introduce new API which greatly simplifies process of packaging data into >mbufs and fetching it back (in fact, similar API already presented in the >tree, but it is private to the netncp code and it will be really nice to >share it). Hi Boris, These mbuf chain manipulation primitives look great! I was playing around with some similar code myself a while ago, so I'll just mention a few of the general issues that may be worth thinking about. I don't have any strong opinions about what approaches are best, so please don't take anything I say too seriously unless you agree with it :-) It may be beneficial to use separate structs for the build and breakdown operations. The two cases have slightly different requirements: the mb_count field is only useful when building, and mb_pos is only strictly necessary when breaking down mbuf chains. The main advantage of using separate structs is better compiler type checking, especially in the arguments to functions that need to break down one chain and build another. The i386 architecture is not fussy about alignment of multi-byte types in memory operations. However other architectures are not so forgiving. Some NIC drivers have to do magic to ensure that IP packets are 4-byte aligned, but this will not help if you are using a protocol that does not guarantee 4-byte alignment of 32- or 64-bit quantities within the IP packet. Doing a mb_get_dword(...); mb_get_byte(...); mb_get_dword(...); will cause an alignment exception on the alpha, for example. Someone suggested using numeric names to indicate the size of the types rather than 'byte', 'word' etc. I'd agree with this too; the text names are not intuitive unless you have used dos/windows for too long :-) Maybe use names such as mb_get_uint32, so that it is obvious what C type should be passed as an argument. I wonder if 'mbdata' is the best name for the struct? I think I had used something like 'mchain', but if separate build/breakdown structs are used, maybe mbuild/mbreakdown or mbchain/mdchain? (the NFS code uses the words 'build' and 'dissect' to refer to the two operations). The main idea would just be to try and have the name indicate what information is held by the struct. Another useful 'put' function would be something that adds a number of bytes of 'empty' space to the end of the chain, and sets up a uio/iovec pointing to this space. e.g to read from a file to an mbuf chain you could use: error = mb_put_muio(mbp, &uio, size, &iovp); ... error = VOP_READ(vp, &uio, flag, cred); ... FREE(iovp, M_TEMP); For cases where there is a small (< MLEN) but relatively complex data structure to be extracted from a chain, it may be useful to have a function which just rearranges the mbufs to ensure that a number of bytes become contiguous. It can make an in-mbuf pointer to that space available. In most cases this will avoid having to copy the data. I wonder if these routines are the correct place for the endian conversions? It certainly simplifies the code that must build and parse requests, but requires duplication of each mb_get/mb_put operation. I understand that there isn't currently code in the tree for dealing with odd protocols that use little-endian format for data transmitted on the network (smb is one of these?). Sometimes it is useful to have idempotent init() and free() functions. For example, consider a function which builds a request and sends it, but which must handle errors both before and after the mbuf chain is sent off to the protocol. If mb_init simply NULL'd out the mb_top pointer, then the code could look like this: mb_init(&mb); if (mb_add_xxx(...) != 0) goto out; ...->pru_sosend(..., mb.mb_top, ...); mb_init(&mb); ... if (error) goto out; out: mb_free(&mb); return (error); The pru_sosend() function takes over ownership of the mbuf chain, so there is a need to just blank out the mbdata structure without freeing the chain, and without performing any allocations. An init function which cannot fail also simplifies the code. See callout_init() in kern_timeout.c for similar code. The mb_put_pstring function maybe belongs in the protocol-specific code rather than here, since there are just too many different ways of encoding strings. Different protocols are likely to encode strings in different ways, with respect to length field type and padding/alignment. Some of these mb_ functions return EBADRPC when not enough bytes of data are found in the mbuf chain. It might be better to choose a more generic return code, since these routines are not specific to RPC. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 6:32:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.flashnet.it (ems.flashnet.it [194.247.160.44]) by hub.freebsd.org (Postfix) with ESMTP id 55B3337B401 for ; Thu, 8 Feb 2001 06:32:07 -0800 (PST) Received: from smtp.flashnet.it (ip159.pool-173.cyb.it [195.191.181.160]) by relay.flashnet.it (EMS-RELAY/8.10.0) with SMTP id f18EW3113944 for ; Thu, 8 Feb 2001 15:32:04 +0100 Message-Id: <200102081432.f18EW3113944@relay.flashnet.it> To: freebsd-net@freebsd.org X-Mailer: Post Road Mailer for OS/2 (Green Edition Ver 3.0) Date: Thu, 8 Feb 2001 15:32:03 EST From: Andrea Venturoli Reply-To: Andrea Venturoli Subject: Meditation on rl driver Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello. I'd like to share some thought on what happened to me: I had an external ADSL modem from Alcatel connected (with a straight cable, since the device has a reversed ethernet port) to a RealTek card on a FreeBSD 4.1-RELEASE box. I used the simple line in rc.conf: ifconfig_rl1="inet 10.0.0.6 netmask 255.0.0.0" Everything would work for a while, but under heavy load the modem would hang so bad it had to be cycle-powered, because it wouldn't communicate anymore (the led on its ethernet port would turn off). After trying a lot of things and reading the modem manual over and over I saw that they required the ethernet card on the computer to be set to half-duplex. So I issued an ifconfig and saw that the card was set to media autoselect (NONE). I tried with ifconfig rl1 inet 10.0.0.6 netmask 255.0.0.0 media 10baseT/UTP mediaopt half-duplex but it would not accept the last parameter. I ended up with the following in rc.conf: ifconfig_rl1="inet 10.0.0.6 netmask 255.0.0.0 media 10baseT/UTP mediaopt -full-duplex" and now everything works fine. My wonderings are: _ "mediaopt full-duplex" does not work, while it's documented in the rl man page; isn't this a bug? _ autoselecting the media obviously does not work correctly, does it? _ if two devices are connected and one speaks half-duplex, the other full-duplex, shouldn't they fail to communicate at all? Is the hang-up after a while and under heavy load normal? _ has anything changed in the rl driver after 4.1-RELEASE? I also hope this might help other people... Bye & Thanks av. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 7:15:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id E953437B401 for ; Thu, 8 Feb 2001 07:15:33 -0800 (PST) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id KAA02026; Thu, 8 Feb 2001 10:18:11 -0500 (EST) Date: Thu, 8 Feb 2001 10:18:11 -0500 (EST) From: Alex Pilosov To: Andrea Venturoli Cc: freebsd-net@FreeBSD.ORG Subject: Re: Meditation on rl driver In-Reply-To: <200102081432.f18EW3113944@relay.flashnet.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 8 Feb 2001, Andrea Venturoli wrote: > My wonderings are: _ "mediaopt full-duplex" does not work, while it's > documented in the rl man page; isn't this a bug? According to your email, mediaopt full-duplex works, but only if it is specified concurrently with media keyword. half-duplex doesn't seem to work... > _ autoselecting the media obviously does not work correctly, does it? For that card, apparently ;) > _ if two devices are connected and one speaks half-duplex, the other > full-duplex, shouldn't they fail to communicate at all? Is the hang-up > after a while and under heavy load normal? Here's the sequence of events: 1) Heavy load generates LOADS of collisions when alcatel is trying to send something but constantly gets collided with incoming stream. 2) At some point, alcatel decides that this is one too many collisions (or a packet that its trying to send gets consecutively 'backed-off' too many times) and decides that interface is borken and it's best to shut it down ;) > _ has anything changed in the rl driver after 4.1-RELEASE? mediaopt half-duplex still doesn't work on rl in 4.2-RELEASE, so... -alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 8:45:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B15B737B491 for ; Thu, 8 Feb 2001 08:45:22 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f18GjGh31127; Thu, 8 Feb 2001 11:45:16 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 8 Feb 2001 11:45:16 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Archie Cobbs Cc: Jonathan Lemon , net@FreeBSD.ORG Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: <200102080524.VAA54629@curve.dellroad.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 7 Feb 2001, Archie Cobbs wrote: > Jonathan Lemon writes: > > Jayanth did make one point that an application could assume that > > the error return from accept was in regards to the listening socket > > instead of the new socket, so that may be a concern. > > Yes I have always assumed this to be true. If the connection is > already broken before I get it, why bother giving it to me?? Well, for the purposes of propagating information up to applications consistently on both sides of a connection, the ideal behavior from my perspective is: When a connection comes in and is reset/closed before accept() can occur, accept() should return success with a properly filled out sockaddr. When the first operation occurs on the socket, it should return an appropriate error message based on the close of the socket (ECONNRESET most likely). This allows the application to be notified of the event at the TCP level, log the address or the like, and continue. The only real issue with this behavior is that most applications assume that a successful accept() call returns a live socket, and may go through expensive overhead before their next socket operation -- for example, fork(). It seems that the ECONNABORTED is the "standard" way to address this scenario; it might be an interesting exercise for someone to look at the common application suites and see how they respond to various failure modes in accept(). It certainly appears that BIND9 expects that. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 9: 0:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 170CB37B401 for ; Thu, 8 Feb 2001 09:00:27 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f18H1Vp17229; Thu, 8 Feb 2001 11:01:31 -0600 (CST) (envelope-from jlemon) Date: Thu, 8 Feb 2001 11:01:31 -0600 (CST) From: Jonathan Lemon Message-Id: <200102081701.f18H1Vp17229@prism.flugsvamp.com> To: archie@dellroad.org, net@freebsd.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: >Jonathan Lemon writes: >> Jayanth did make one point that an application could assume that >> the error return from accept was in regards to the listening socket >> instead of the new socket, so that may be a concern. > >Yes I have always assumed this to be true. If the connection is >already broken before I get it, why bother giving it to me?? Because the connection may be broken between the point where we've notified the user that there is a valid connection, and when accept returns. E.g.: 1. SYN, SYN/ACK, ACK (connection accepted) 2. select/poll/kevent wakes up 3. RST arrives (connection aborted) 4. user calls accept() Now, (assuming there is no other pending connection), there's three choices: an error return, return with with a zero-sized addrlen, or block/EWOULDBLOCK. While the latter seems to be the most attractive, it would probably break the most semantics, since the select call did indicate there was a pending connection. So this means that the app must either test for ECONNABORTED, or test the addrlen before using the returned sockaddr. I would guess that code is more likely to check for an error return from accept() than it is to check the return size from the sockaddr, so this change will proabably not result in breaking a large amount of code. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 9: 7:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id F09C637B6AD; Thu, 8 Feb 2001 09:07:02 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f18H87U17376; Thu, 8 Feb 2001 11:08:07 -0600 (CST) (envelope-from jlemon) Date: Thu, 8 Feb 2001 11:08:07 -0600 (CST) From: Jonathan Lemon Message-Id: <200102081708.f18H87U17376@prism.flugsvamp.com> To: rwatson@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: > >On Wed, 7 Feb 2001, Archie Cobbs wrote: > >> Jonathan Lemon writes: >> > Jayanth did make one point that an application could assume that >> > the error return from accept was in regards to the listening socket >> > instead of the new socket, so that may be a concern. >> >> Yes I have always assumed this to be true. If the connection is >> already broken before I get it, why bother giving it to me?? > >Well, for the purposes of propagating information up to applications >consistently on both sides of a connection, the ideal behavior from my >perspective is: > > When a connection comes in and is reset/closed before accept() can > occur, accept() should return success with a properly filled out > sockaddr. When the first operation occurs on the socket, it should > return an appropriate error message based on the close of the socket > (ECONNRESET most likely). The difficulty with this is that the peer address is being held in the inpcb, which is released by tcp_close upon receipt of a RST. So at the moment, there isn't anywhere to retrieve the sockaddr from. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 9:12:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id 4CCCA37B491; Thu, 8 Feb 2001 09:12:01 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id JAA88667; Thu, 8 Feb 2001 09:11:52 -0800 (PST) (envelope-from richw) Date: Thu, 8 Feb 2001 09:11:52 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Luigi Rizzo Cc: bmilekic@technokratis.com, luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Fw: if_ed.c && BRIDGE In-Reply-To: <200102080800.f1880s410219@iguana.aciri.org> Message-ID: <20010208163904.85396.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo wrote: > interesting dump... because it shows a bogus "length" > parameter passed to ed_pio_readmem(). Bosko and I were discussing my problem offline a couple of weeks ago, and in the course of a single morning I managed to create about 15 crashes. A couple of them were just like this latest one -- in ed_pio_readmem() -- but most of the others were in rl_encap(), which was called via a chain including rl_start(), bdg_forward(), ether_input(), and ed_get_packet(). It looks, to me, like some sort of data corruption that is causing a crash later on (but not immediately). And, as I reported earlier, these crashes went away completely after I commented out the bridge- specific code in if_ed.c (per a suggestion from Bosko). I don't have crash dumps from those earlier crashes -- I was (and still am) having unresolved problems getting the system to copy a crash dump into swap space automatically after a panic, and I hadn't yet hit upon the kludge of typing "call dumpsys" at the DDB prompt -- but I did write down some tracing info from DDB for the earlier crashes. See below for what I have; please understand that this is all I have. > Can you by chance find out what is the "len" value passed > to ed_get_packet? The printout in line #10 below is par- > tially deleted by some error message. Sure. I did "up 10", followed by "print len", and the value of this parameter was reported as 10. > Now, NE2000 clones if you look at the driver are known > for occasionally swapping the bytes of the length, but > the driver was supposed to take care of this. Evidently > there is some odd thing... Please note that I've tried two different NE2000 clone cards -- one ISA, one PCI -- and I got the same kinds of crashes from both. (The crash I described last night was with the PCI card.) Also, as I said, these crashes went away completely after I commented out the BRIDGE-specific code in if_ed.c, per Bosko's recommendation. I'm willing to agree with Bosko that leaving out this code is a tem- porary workaround, and not a true fix -- but do you think it might be possible to take it out in -STABLE for now, until the problem is found? Rich Wales richw@webcom.com http://www.webcom.com/richw/ ======================================================================== (5 times) Fatal trap 12: page fault while in kernel mode rl_encap + 0x120 rl_start + 0x23 bdg_forward + 0x468 ether_input + 0x7b ed_get_packet + 0x3b8 edintr + 0x5af Xresume5 + 0x2b (4 times) Fatal trap 12: page fault while in kernel mode rl_encap + 0x78 rl_start + 0x23 bdg_forward + 0x468 ether_input + 0x7b ed_get_packet + 0x3b8 edintr + 0x5af Xresume5 + 0x2b (2 times) Fatal trap 12: page fault while in kernel mode rl_encap + 0x117 rl_start + 0x23 bdg_forward + 0x468 ether_input + 0x7b ed_get_packet + 0x3b8 edintr + 0x5af Xresume5 + 0x2b (2 times) Fatal trap 12: page fault while in kernel mode ed_pio_readmem + 0x161 ed_get_packet + 0x393 edintr + 0x5af Xresume5 + 0x2b (1 time) Fatal trap 12: page fault while in kernel mode bpf_mtap + 0x18 ether_input + 0x2f pcn_rxeof + 0xe1 pcn_intr + 0x8a Xresume9 + 0x2b (1 time) Fatal trap 12: page fault while in kernel mode (DDB went into endless loop) ======================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 9:35:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id EA85437B503; Thu, 8 Feb 2001 09:35:37 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f18HZY515166; Thu, 8 Feb 2001 09:35:34 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102081735.f18HZY515166@iguana.aciri.org> Subject: Re: Fw: if_ed.c && BRIDGE In-Reply-To: <20010208163904.85396.richw@wyattearp.stanford.edu> from Rich Wales at "Feb 8, 2001 9:11:52 am" To: richw@webcom.com (Rich Wales) Date: Thu, 8 Feb 2001 09:35:34 -0800 (PST) Cc: rizzo@aciri.org, bmilekic@technokratis.com, luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Bosko and I were discussing my problem offline a couple of weeks ago, you see, a couple of weeks ago the whole bridging-related code had all sort of race conditions involving pointers to memory areas about to be freed. I think/hope to have fixed most of them now so it is probably worthwhile concentrating on the one problem with recent code. > > Can you by chance find out what is the "len" value passed > > to ed_get_packet? The printout in line #10 below is par- > > tially deleted by some error message. > > Sure. I did "up 10", followed by "print len", and the value of this > parameter was reported as 10. interesting enough, because this 10 cannot be a valid packet. The min ethernet header is 14 bytes, so even if this calls refers to the packet after the header extraction (and it is probably not the case), you still should have 50 bytes for a valid packet. Try the following patch: near line 2209 of if_ed.c * we have a length that will fit into one mbuf cluster or less; * the upper layer protocols can then figure out the length from * their own length field(s). */ - if ((len > sizeof(struct ed_ring)) && + if ((len > ETHER_HDR_LEN + sizeof(struct ed_ring)) && (len <= MCLBYTES) && so that at least we avoid passing around mbufs with negative length, and other odd things. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 9:46:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from cgaylord.async.vt.edu (e028121.vtacs.vt.edu [63.164.28.121]) by hub.freebsd.org (Postfix) with ESMTP id 3F54E37B503 for ; Thu, 8 Feb 2001 09:46:08 -0800 (PST) Received: by cgaylord.async.vt.edu (Postfix, from userid 1000) id 45465FE; Thu, 8 Feb 2001 12:46:06 -0500 (EST) Date: Thu, 8 Feb 2001 12:46:06 -0500 From: Clark Gaylord To: Andrea Venturoli Cc: freebsd-net@freebsd.org Subject: Re: Meditation on rl driver Message-ID: <20010208124605.A22600@cgaylord.async.vt.edu> References: <200102081432.f18EW3113944@relay.flashnet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102081432.f18EW3113944@relay.flashnet.it>; from ml.ventu@flashnet.it on Thu, Feb 08, 2001 at 03:32:03PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Feb 08, 2001 at 03:32:03PM -0500, Andrea Venturoli wrote: > So I issued an ifconfig and saw that the card was set to media autoselect (NONE). > I tried with > > ifconfig rl1 inet 10.0.0.6 netmask 255.0.0.0 media 10baseT/UTP mediaopt half-duplex > > but it would not accept the last parameter. > I ended up with the following in rc.conf: > > ifconfig_rl1="inet 10.0.0.6 netmask 255.0.0.0 media 10baseT/UTP mediaopt > -full-duplex" > ... > _ has anything changed in the rl driver after 4.1-RELEASE? It used to be the case that mediaopt half-duplex worked. It stopped working at some point (I don't recall exactly when ... somewhere between 4.0 and 4.2 I think), but it seems that this is the default (as it should be) if you specify 10baseT/UTP. I would be concerned that the -full-duplex setting might actually be setting to *use* full-duplex, not turn it off. Check the src on this; clearly the man page is just plain wrong. > _ autoselecting the media obviously does not work correctly, does it? Autoselect of duplex gets it right, in general, about 51.045% of the time, and should be considered an Evil Spawn of Satan (ESS). When you say full-duplex doesn't work are you saying that the driver barfs at the mention of it or that your NIC does not work properly when it is set (which is correct, as your modem is hdx). Does it accept the parameter when the card is set to 100 (while fdx 10 does exist, it is less common, and I have seen drivers/NICs that only support fdx at 100Mbps)? > _ if two devices are connected and one speaks half-duplex, the other full-duplex, shouldn't > they fail to communicate at all? No, but load would cause this to fail. Basically fdx means "ignore collisions;" as long as you wouldn't have had a collision, all works fine. But, of course, at high loads, the hdx is going to expect the fdx guy to respect collisions. You'll get a lot of errors when duplex is wrong, but it will work some at light load. It does really great things to TCP window sizes too. > Is the hang-up after a while and under heavy load normal? I have no problem with my DSL modem under various loads, but I can't say that I have sustained very high loads (e.g. ttcp tests) for more than twenty minutes or so. Most DSL modems follow the long-standing definition of modem (i.e.: 'see "suck"'). -- Clark K. Gaylord Blacksburg, Virginia USA cgaylord@vt.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 10: 0:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 7AD4837B699 for ; Thu, 8 Feb 2001 09:59:59 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id JAA61322; Thu, 8 Feb 2001 09:59:42 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id JAA56499; Thu, 8 Feb 2001 09:59:41 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200102081759.JAA56499@curve.dellroad.org> Subject: Re: pptp server In-Reply-To: <3A825E21.911852D2@elischer.org> "from Julian Elischer at Feb 8, 2001 00:51:45 am" To: Julian Elischer Date: Thu, 8 Feb 2001 09:59:41 -0800 (PST) Cc: Archie Cobbs , Olivier Cherrier , "'freebsd-net'" X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer writes: > > Olivier Cherrier writes: > > > Ho, I think that I found my problem ... maybe > > > In fact, the "mppe encryption" is included in the MS-Chap protocol, isn't it > > > > MPPE encryption piggybacks on MPPC compression. You can have > > either or both of 'E' and/or 'C'. Mpd only supports 'E' because > > 'C' requires proprietary files. > > > > MS-CHAP is required *for* MPPE encryption, in order to generate the keys. > > > > > 22:14:37.384949 mirador.cediti.be > 193.190.156.147: gre-proto-0x880B (gre > > > encap) > > > > > > Is this the proof that the communication is encrypted ? (sorry for this > > > newbie question but I am't a guru .... not yet -:) > > > > No, the encryption is only of the inner payload. > > > > > It is surprising because on the windows client side, I set in the security > > > option: > > > _ Optional encryption (If I want "require encryption", the error > > > "encryption not supported by server" occurs) > > > _ Allow these protocols: MS-CHAP > > > > > > So, if I am right, MS-CHAP includes MPPE encryption even if encryption is > > > not explicitely set; don't it ? > > > > No. > > so, does he have a chance of it working or not? It should work with all Windows clients as long as they don't require MS-CHAP version 2 authentication. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 10: 5:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 7ECC237B69F; Thu, 8 Feb 2001 10:05:33 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id KAA61412; Thu, 8 Feb 2001 10:05:32 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id KAA56533; Thu, 8 Feb 2001 10:05:32 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200102081805.KAA56533@curve.dellroad.org> Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: "from Robert Watson at Feb 8, 2001 11:45:16 am" To: Robert Watson Date: Thu, 8 Feb 2001 10:05:32 -0800 (PST) Cc: jlemon@flugsvamp.com, net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson writes: > > Jonathan Lemon writes: > > > Jayanth did make one point that an application could assume that > > > the error return from accept was in regards to the listening socket > > > instead of the new socket, so that may be a concern. > > > > Yes I have always assumed this to be true. If the connection is > > already broken before I get it, why bother giving it to me?? > > Well, for the purposes of propagating information up to applications > consistently on both sides of a connection, the ideal behavior from my > perspective is: > > When a connection comes in and is reset/closed before accept() can > occur, accept() should return success with a properly filled out > sockaddr. When the first operation occurs on the socket, it should > return an appropriate error message based on the close of the socket > (ECONNRESET most likely). This makes the most sense to me. If you get an error from accept(), the implication (in my mind, and I suspect many others) is that the error is with the *listening* socket. If the error is really with the *new* socket then the error should "wait" until a read(), getpeername(), etc. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 10:13: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 7DE6837B69F for ; Thu, 8 Feb 2001 10:12:48 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id KAA61440; Thu, 8 Feb 2001 10:12:43 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id KAA56568; Thu, 8 Feb 2001 10:12:43 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200102081812.KAA56568@curve.dellroad.org> Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: <200102081701.f18H1Vp17229@prism.flugsvamp.com> "from Jonathan Lemon at Feb 8, 2001 11:01:31 am" To: Jonathan Lemon Date: Thu, 8 Feb 2001 10:12:43 -0800 (PST) Cc: net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jonathan Lemon writes: > >> Jayanth did make one point that an application could assume that > >> the error return from accept was in regards to the listening socket > >> instead of the new socket, so that may be a concern. > > > >Yes I have always assumed this to be true. If the connection is > >already broken before I get it, why bother giving it to me?? > > Because the connection may be broken between the point where we've > notified the user that there is a valid connection, and when accept > returns. E.g.: It was a rhetorical question. I like Robert's suggestion to return the socket but have the first operation on the socket fail. If you want to positively verify the new socket you can do a getpeername(), etc. > I would guess that code is more likely to check for an error > return from accept() than it is to check the return size from > the sockaddr, so this change will proabably not result in breaking > a large amount of code. IMHO the app is more likely to close the listen socket and stop accepting new connections if it gets an error from accept(). For example, from an initial scan of sendmail (daemon.c:403) if it gets an error from accept(2) it will close the (listen) socket and reopen it. Sendmail is robust enough not to "break" but this shows that if it gets an accept(2) error it assumes the problem is with the *listening* socket, not the new socket. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 10:31:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id C73B137B6AA for ; Thu, 8 Feb 2001 10:31:40 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f18IWd120580; Thu, 8 Feb 2001 12:32:39 -0600 (CST) (envelope-from jlemon) Date: Thu, 8 Feb 2001 12:32:39 -0600 From: Jonathan Lemon To: Archie Cobbs Cc: Jonathan Lemon , net@freebsd.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010208123239.P650@prism.flugsvamp.com> References: <200102081701.f18H1Vp17229@prism.flugsvamp.com> <200102081812.KAA56568@curve.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200102081812.KAA56568@curve.dellroad.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Feb 08, 2001 at 10:12:43AM -0800, Archie Cobbs wrote: > Jonathan Lemon writes: > > >> Jayanth did make one point that an application could assume that > > >> the error return from accept was in regards to the listening socket > > >> instead of the new socket, so that may be a concern. > > > > > >Yes I have always assumed this to be true. If the connection is > > >already broken before I get it, why bother giving it to me?? > > > > Because the connection may be broken between the point where we've > > notified the user that there is a valid connection, and when accept > > returns. E.g.: > > It was a rhetorical question. I like Robert's suggestion to return > the socket but have the first operation on the socket fail. > > If you want to positively verify the new socket you can do a > getpeername(), etc. > > > I would guess that code is more likely to check for an error > > return from accept() than it is to check the return size from > > the sockaddr, so this change will proabably not result in breaking > > a large amount of code. > > IMHO the app is more likely to close the listen socket and stop > accepting new connections if it gets an error from accept(). > > For example, from an initial scan of sendmail (daemon.c:403) if > it gets an error from accept(2) it will close the (listen) socket > and reopen it. Sendmail is robust enough not to "break" but this > shows that if it gets an accept(2) error it assumes the problem is > with the *listening* socket, not the new socket. Yes, I looked at sendmail, ftpd, sshd, telnetd, inetd, and apache. Only apache does the right thing in this case. All the other applications either: 1. handle the error from accept() in some form (which may include terminating the application), or 2. blindly use the returned sockname. So in sendmail's case, it currently does: t = accept(.., (struct sockaddr *)&RealHostAddr, &lotherend); .... p = hostnamebyanyaddr(&RealHostAddr); which will proabably coredump since it dereferences a NULL pointer. I'd think that at least having sendmail close/reopen the listen socket will result in slightly more robust behavior. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 10:52:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id 8373937B6AA for ; Thu, 8 Feb 2001 10:51:57 -0800 (PST) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.1/8.11.1) with ESMTP id f18Ipti96340 for ; Thu, 8 Feb 2001 11:51:55 -0700 (MST) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200102081851.f18Ipti96340@orthanc.ab.ca> To: freebsd-net@freebsd.org subject: mobile ipv4 status Organization: The Frobozz Magic Homing Pigeon Company Date: Thu, 08 Feb 2001 11:51:55 -0700 From: Lyndon Nerenberg Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From what I've been able to dig up on the net it appears that the only promising work on mobile IPv4 for FreeBSD (at U Oregon) pretty much dried up in 1998. Do any of you know of any current work being done to integrate mobile IPv4 into FreeBSD? --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 11:14:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 79DF937B684; Thu, 8 Feb 2001 11:14:16 -0800 (PST) Received: from jehovah ([24.201.144.31]) by VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G8GDFD04.BFD; Thu, 8 Feb 2001 14:14:01 -0500 Message-ID: <013201c09203$971be9c0$1f90c918@jehovah> From: "Bosko Milekic" To: "Boris Popov" Cc: , References: Subject: Re: Sequential mbuf read/write extensions Date: Thu, 8 Feb 2001 14:16:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Boris Popov wrote: [...] > Not exactly so. 'option LIBMBUF' will just connect the source file > to kernel makefile. There is no need for any #ifdef's in the code. Right. But I assume LIBMBUF will absolutely be needed if code that uses the routines is compiled. What I just meant to say was: "when the code using these routines grows to be significant enough, then we can just remove the option." > > #define M_TRYWAIT M_WAIT is not right. > > (M_WAIT is no longer to be used in the mbuf code.) > > You omitted the surrounding "#ifndef M_TRYWAIT" which makes this > code portable to RELENG_4 (mind you, this code taken from smbfs). Of > course, this should be stripped before import. I did, you're right. I guess I saw the "ifndef" wrong... I read this with only -CURRENT in mind and was afraid that the mbuf code flags would start mixing in with the malloc code flags -- something I tried to fight off in the past while. > > The succesfull return values are 0, I don't have a problem with this, > > specifically, but I would assume that this: > > if (!mb_init(mbp)) ... would be more "logical" (I use the term > > loosely) if it meant: "if initialization fails" (now it means "if > > initialization is succesful"). > > I'm generally don't like such syntax if function or variable name > do not clearly specify which value it should have/return on success. > Nearly all functions in this file return zero or error code, so the > correct syntax of the above will be: > > error = mb_init(mbp); > if (!error) > > or > > if (error) > return error; > > or > > if (mb_init(mbp) != 0) > return ESOMETHINGEVIL; OK. > > > significantly affected. The names of source and header files are > > > questionable too and I would appreciate good suggestions (currently > > they > > > are subr_mbuf.c and subr_mbuf.h). > > > > Hmmm. Maybe subr_mblib.c and libmb.h ? I don't want to turn this > > into a bikeshed ( :-) ), so I suggest that you decide. Personally, I > > would prefer that it be something other than "subr_mbuf.c" simply > > because it may be a little misleading in some cases. > > Good point. > > > Boris, this is really a great interface and nice looking, clean code. > > I'm sure, this code can be significantly improved by mbuf gurus :) > > -- > Boris Popov > http://www.butya.kz/~bp/ Ok, I have a few things to add (although I'm sure you'll be more into reading Ian Dowse's comments) :-) in mb_append_record(), you walk all the "record" mbufs to get to the last "record." How good would be the tradeoff? i.e. keeping a pointer to the last pkt in the mbdata structure's mbuf chain? We would grow the structure by a pointer, and we may have to maintain the last record pointer; but isn't the only place where we would have to "maintain it" in mb_append_record() anyway? in mb_init(), the m->m_pkthdr.rcvif = NULL; can be ommitted, as MGETHDR() will do that. The m->m_len = 0 should stay for now. m_getm() looks like it should belong in uipc_mbuf.c -- it looks quite a bit like the "all or nothing" allocation routine I have sitting here. The difference is that mine doesn't take size as an argument, but rather the actual count of mbufs and all it does is allocate `count' mbufs and attach a cluster to each one of them. If it can't allocate a cluster or an mbuf at any point, it frees everything and returns. Now that I think about it, I'd much rather have `size' passed in instead, even though some callers may not know the `size' (think drivers that pre-allocate mbufs + clusters, they typically know the `count'), it turns out that it is cheaper to compute the count from the size than the optimal size from the count, in the mbuf case. If you don't mind, I would strongly recommend moving m_getm() to uipc_mbuf.c. Code that doesn't know the `size' but knows the `count' (like some driver code) can do; m = m_get(M_TRYWAIT, MT_DATA); if (m == NULL) { /* we can't even allocate one mbuf, we're really low, so don't even bother calling m_getm(). The other option would be to have m_getm() not require us to pre-allocate an mbuf at all and do all the work, but then that may interfere with code like yours which needs to pass in an existing mbuf that has already been allocated. */ m_free(m); /* fail right here */ } else { size = count * (MLEN + MCLBYTES); if (m_getm(m, size) == NULL) { /* everything has been properly freed for us, we don't have to worry about leaking mbufs. */ /* fail right here. */ } } For this to work, though, m_getm() needs to be modified to free all of `top' chain if it can't get either a cluster or an mbuf. I don't know if this was intentional, but it seems to me that there is a subtle problem in m_getm() as it is now: if (len > MINCLSIZE) { MCLGET(m, M_TRYWAIT); if ((m->m_flags & M_EXT) == 0) { m_freem(m); <------ frees only one mbuf return NULL; } } I think what may happen here is that you will leak your `top' chain if you fail to allocate a cluster. Assuming that the leak does exist and that it is fixed, we have a pretty good mechanism for doing 'all or nothing' allocations. :-) Later, Bosko. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 11:20:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from brisefer.cediti.be (brisefer.cediti.be [193.190.156.67]) by hub.freebsd.org (Postfix) with ESMTP id 41E9037B698 for ; Thu, 8 Feb 2001 11:20:14 -0800 (PST) Received: by brisefer.cediti.be with Internet Mail Service (5.5.2650.21) id <1RZ2FVJK>; Thu, 8 Feb 2001 20:20:36 +0100 Message-ID: From: Olivier Cherrier To: 'freebsd-net' Subject: RE: pptp server Date: Thu, 8 Feb 2001 20:20:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >It should work with all Windows clients as long as they don't >require MS-CHAP version 2 authentication. > Yes, it works. It works fine. But there is no encryption of data between MPD and windows clients... When I do some work in a such connection, I can read data with a tcpdump ... Nevertheless, mpd is a beautifull soft. Congratulations. Olivier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 13:25:31 2001 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id E8D7D37B6AA; Thu, 8 Feb 2001 13:25:09 -0800 (PST) Subject: call for testers: port aggregation netgraph module To: hackers@freebsd.org, net@freebsd.org Date: Thu, 8 Feb 2001 13:25:09 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010208212509.E8D7D37B6AA@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz This is a call for testers for a netgraph module that can be used to aggregate 2 or 4 ethernet interfaces into a single interface. Basically, it lets you do things like the following: # kldload ./ng_fec.ko # ngctl mkpeer fec dummy fec # ngctl msg fec0: add_iface '"dc0"' # ngctl msg fec0: add_iface '"dc1"' # ngctl msg fec0: add_iface '"dc2"' # ngctl msg fec0: add_iface '"dc3"' # ngctl msg fec0: set_mode_inet The fec module will work with *any* combination of interfaces, not just multiport ethernet cards, however the port failover mechanism will not work unless the interface supports ifmedia and is able to report the link status. Cards that use the fxp, de, xl, tl, rl, sis, dc, wb, ste, sf, vr, ti and sk drivers should work. Yes, that means you can aggregate RealTek cards and gigabit ethernet cards together. The channel bonding is done using the Cisco fast etherchannel mechanism. The default hashing mechanism uses the MAC address, however you can select IP address hashing as well. IPv4 and IPv6 address *should* work, though I must admit I've been using IPv4 until now. If someone actually has a Cisco switch that implements fast ethetchannel, I'd be interested to know if it works with this module. At the moment, my test environment consist of two machines with multiport ethernet cards wired up using four crossover cables. Each link is checked once every second to see if the link is still up. An attempt to send a packet over a dead link will cause the packet to be shifted over to the next link in the bundle. There are tarballs for 4.x and 5.x systems. The 4.x tarball should work on 4.2-RELEASE or later. The 5.x one will work on -current. Both source and pre-compiled modules for x86 are provided. This code should work on the alpha as well. You can create more than one bundle by using more than one mkpeer command with ngctl(8). You can delete interfaces from a bundle using the del_iface command, which works just like the add_iface command. The fec0 pseudo-interface will inherit the MAC address of the first real interface to be added to the bundle, and that same MAC address will be propagated to all subsequent interfaces that are added. The MAC addresses are restored when an interface is removed from a bundle. Once the bundle is created, you can manipulate the fec0 interface as though it were a real ethernet interface. You must have either 2 or 4 NICs in the bundle. Share, enjoy, test, and report back to me any problems you encounter. -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 16:46:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 9F8B637B65D for ; Thu, 8 Feb 2001 16:46:06 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f190k6K06283; Thu, 8 Feb 2001 16:46:06 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102090046.f190k6K06283@iguana.aciri.org> Subject: dead code in ip_output.c and udp_var.h To: net@freebsd.org Date: Thu, 8 Feb 2001 16:46:06 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org So, ip_output.c contains the following: #ifdef vax #include #endif ... #ifndef vax if (m->m_len % sizeof(int32_t)) goto bad; #endif and maybe it would be the case to remove the first block and the conditionals on the second one. I don't think we plan a port to the vax, am i wrong ? udp_var.h contains a definition of "struct udpcb" and "inptoudpcb()" which are never used anywhere. Again if there are no objections i would like to nuke them. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 17: 2:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id DBAD337B684 for ; Thu, 8 Feb 2001 17:02:05 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f19125x06386; Thu, 8 Feb 2001 17:02:05 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102090102.f19125x06386@iguana.aciri.org> Subject: potential infinite loop in network device drivers To: net@freebsd.org Date: Thu, 8 Feb 2001 17:02:05 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, it occurs to me that there is a potential infinite loop in most if not all ethernet drivers. Basically, on a receive interrupt, such drivers loop around the status word until the receive queue is drained. If the body of the loop takes approx the same as the packet interarrival time, you might end up stuck in the loop forever (and typically holding locks or with most interrupts masked off). I would suggest that we slightly redesign such loops so that we limit the amt of time spent in them. This probably affects only 100M/1G interfaces these days, but still... cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 18:10:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 443B237B699 for ; Thu, 8 Feb 2001 18:09:57 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id VAA60712; Thu, 8 Feb 2001 21:09:53 -0500 (EST) (envelope-from wollman) Date: Thu, 8 Feb 2001 21:09:53 -0500 (EST) From: Garrett Wollman Message-Id: <200102090209.VAA60712@khavrinen.lcs.mit.edu> To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: potential infinite loop in network device drivers In-Reply-To: <200102090102.f19125x06386@iguana.aciri.org> References: <200102090102.f19125x06386@iguana.aciri.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > it occurs to me that there is a potential infinite loop in > most if not all ethernet drivers. Basically, on a > receive interrupt, such drivers loop around the status word > until the receive queue is drained. One possible right way to deal with this is to get rid of the two-level interrupt scheme (for fast interfaces at least) and push the packets all the way through the network stack. This will ensure that if packets are arriving faster than we can handle them, they will be dropped by the network interface with an ``insufficient resources'' error. Another possible right way to deal with this is to move all network processing into the lower level, and poll round-robin for packets (with network interrupts disabled) until all network interfaces are finished (or we need to give the user a time slice). Both techniques were described in a paper by Jeff Mogul (then at DEC in Palo Alto) about five years ago; I have a physical copy of the paper buried somewhere in my office. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 18:13:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 1385E37B6A0; Thu, 8 Feb 2001 18:13:36 -0800 (PST) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id UAA69320; Thu, 8 Feb 2001 20:13:33 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Thu, 8 Feb 2001 20:13:33 -0600 (CST) From: Chris Dillon To: Bill Paul Cc: , Subject: Re: call for testers: port aggregation netgraph module In-Reply-To: <20010208212509.E8D7D37B6AA@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 8 Feb 2001, Bill Paul wrote: > http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz > http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz > > This is a call for testers for a netgraph module that can be used > to aggregate 2 or 4 ethernet interfaces into a single interface. > Basically, it lets you do things like the following: [snip] > The fec module will work with *any* combination of interfaces, not > just multiport ethernet cards, however the port failover mechanism > will not work unless the interface supports ifmedia and is able to > report the link status. Cards that use the fxp, de, xl, tl, rl, > sis, dc, wb, ste, sf, vr, ti and sk drivers should work. Yes, that > means you can aggregate RealTek cards and gigabit ethernet cards > together. Awesome! I've been using channel bonding/port-failover on my NT servers for at least a couple of years now. One thing, though, wouldn't the plural of 'fec' be 'feces'? :-) > The channel bonding is done using the Cisco fast etherchannel > mechanism. The default hashing mechanism uses the MAC address, > however you can select IP address hashing as well. IPv4 and IPv6 > address *should* work, though I must admit I've been using IPv4 > until now. If someone actually has a Cisco switch that implements > fast ethetchannel, I'd be interested to know if it works with this > module. At the moment, my test environment consist of two machines > with multiport ethernet cards wired up using four crossover > cables. Apparently there is another way to do channel bonding with switches that don't support Cisco's EtherChannel, since I'm doing it with 3COM's (piece of *hit) SuperStackII switches and I don't have EtherChannel support enabled in Compaq's NT drivers for their Intel NICs. I will try this out on -stable at work, but the only switches I have handy that support EtherChannel are some HP ProCurve 4000Ms. Is there any chance that the EtherChannel method would work on something like a 3COM SuperStackII 3300, which doesn't claim to support EtherChannel? > Each link is checked once every second to see if the link is still > up. An attempt to send a packet over a dead link will cause the > packet to be shifted over to the next link in the bundle. Apparently Compaq's NT driver (actually most likely Intel's, slightly modified by Compaq) sends out a heartbeat packet from each interface if there has been no incoming traffic on the interfaces within the heartbeat period. I haven't sniffed the heartbeat packet yet to figure out if it is simply sent to a broadcast address (which it appears to be, since the switch appears to forward it to all ports), or if it is sending it from one interface addressed to another interface, or even to the same interface. [snip] > The fec0 pseudo-interface will inherit the MAC address of the first > real interface to be added to the bundle, and that same MAC address > will be propagated to all subsequent interfaces that are added. [snip] Hmmm... The non-EtherChannel method apparently uses a different MAC for each interface, since when I have looked at the forwarding tables of my switches where I have two bonded channels from a server, each port shows a different MAC address. Any idea how that would work? It would be really cool if you could choose either the EtherChannel method or some other non-EtherChannel method that will work with other switches, if we can figure out how it works. :-) -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 18:31:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id E3CA837B401; Thu, 8 Feb 2001 18:30:57 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id A23A328E1C; Fri, 9 Feb 2001 08:30:48 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 8565D2863E; Fri, 9 Feb 2001 08:30:48 +0600 (ALMT) Date: Fri, 9 Feb 2001 08:30:48 +0600 (ALMT) From: Boris Popov To: Ian Dowse Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: CFR: Sequential mbuf read/write extensions In-Reply-To: <200102081233.aa16167@salmon.maths.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 8 Feb 2001, Ian Dowse wrote: > It may be beneficial to use separate structs for the build and > breakdown operations. The two cases have slightly different > requirements: the mb_count field is only useful when building, and > mb_pos is only strictly necessary when breaking down mbuf chains. > The main advantage of using separate structs is better compiler > type checking, especially in the arguments to functions that need > to break down one chain and build another. Yes, I've been thinking about it, because once I've managed to mix build and breakdown buffers :). The only (not essential) disadvantage is that it will require two init/done functions. > The i386 architecture is not fussy about alignment of multi-byte > types in memory operations. However other architectures are not > so forgiving. Some NIC drivers have to do magic to ensure that IP > packets are 4-byte aligned, but this will not help if you are using > a protocol that does not guarantee 4-byte alignment of 32- or 64-bit > quantities within the IP packet. Doing a > > mb_get_dword(...); > mb_get_byte(...); > mb_get_dword(...); > > will cause an alignment exception on the alpha, for example. No, in the current implementation mb_get* functions will work properly. But mb_put* will fail. This can be avoided by implementing alignment-safe set* macros (which can be written in two variants - first form is for aligned objects and second for bad aligned ones). > Someone suggested using numeric names to indicate the size of the > types rather than 'byte', 'word' etc. I'd agree with this too; the > text names are not intuitive unless you have used dos/windows for > too long :-) Maybe use names such as mb_get_uint32, so that it is > obvious what C type should be passed as an argument. Ok, I'd like type/numeric notation. It is definitely better than just mb_get32. > I wonder if 'mbdata' is the best name for the struct? I think I > had used something like 'mchain', but if separate build/breakdown > structs are used, maybe mbuild/mbreakdown or mbchain/mdchain? (the > NFS code uses the words 'build' and 'dissect' to refer to the two > operations). The main idea would just be to try and have the name > indicate what information is held by the struct. Good point and good names too. > Another useful 'put' function would be something that adds a number > of bytes of 'empty' space to the end of the chain, and sets up a > uio/iovec pointing to this space. e.g to read from a file to an > mbuf chain you could use: > > error = mb_put_muio(mbp, &uio, size, &iovp); > ... > error = VOP_READ(vp, &uio, flag, cred); > ... > FREE(iovp, M_TEMP); This can be added later when the code will be written. > For cases where there is a small (< MLEN) but relatively complex > data structure to be extracted from a chain, it may be useful to > have a function which just rearranges the mbufs to ensure that a > number of bytes become contiguous. It can make an in-mbuf pointer > to that space available. In most cases this will avoid having to > copy the data. Hmm, this can cause weird things if one have two or more such structures in the mbuf chain. Eg, at first point mbufs will be rearranged to place first structure properly but will misplace second structure. But in general case - yes, this is useful. > I wonder if these routines are the correct place for the endian > conversions? It certainly simplifies the code that must build and > parse requests, but requires duplication of each mb_get/mb_put > operation. I understand that there isn't currently code in the tree > for dealing with odd protocols that use little-endian format for > data transmitted on the network (smb is one of these?). sys/netncp is another example of the code which deals with little-endian formatted protocol (and mb* code was derived from sys/netncp/ncp_rq.c) I think it is good idea to provide functions for an in-place conversions because it makes code much more readable and reduces the size of generated code. Few additional functions is a good price for that. > Sometimes it is useful to have idempotent init() and free() functions. > For example, consider a function which builds a request and sends > it, but which must handle errors both before and after the mbuf > chain is sent off to the protocol. If mb_init simply NULL'd out > the mb_top pointer, then the code could look like this: [skip] > The pru_sosend() function takes over ownership of the mbuf chain, > so there is a need to just blank out the mbdata structure without > freeing the chain, and without performing any allocations. An init > function which cannot fail also simplifies the code. See callout_init() > in kern_timeout.c for similar code. Hmm, since so_send() can fail and some erros can be recovered by another call to so_send(), I'm just called m_copym() to duplicate the mbuf chain and give it to so_send(). > The mb_put_pstring function maybe belongs in the protocol-specific > code rather than here, since there are just too many different ways > of encoding strings. Different protocols are likely to encode > strings in different ways, with respect to length field type and > padding/alignment. The name 'pstring' associated with 'pascal' type string which is known as 'byte of length followed by data'. If this function doesn't suits to be general then it can be omitted (only netncp/nwfs code uses it). > Some of these mb_ functions return EBADRPC when not enough bytes > of data are found in the mbuf chain. It might be better to choose > a more generic return code, since these routines are not specific > to RPC. EBADRPC returned by all mb_get* functions to indicate that the format of reply is unexpected. > Ian Thanks for great review :) -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 18:48:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id B44AF37B4EC; Thu, 8 Feb 2001 18:48:29 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id 0B5A828867; Fri, 9 Feb 2001 08:48:26 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id ED14D28695; Fri, 9 Feb 2001 08:48:26 +0600 (ALMT) Date: Fri, 9 Feb 2001 08:48:26 +0600 (ALMT) From: Boris Popov To: Bosko Milekic Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Sequential mbuf read/write extensions In-Reply-To: <013201c09203$971be9c0$1f90c918@jehovah> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 8 Feb 2001, Bosko Milekic wrote: > in mb_init(), the m->m_pkthdr.rcvif = NULL; can be ommitted, as > MGETHDR() will do that. The m->m_len = 0 should stay for now. Ok. > drivers that pre-allocate mbufs + clusters, they typically know the > `count'), it turns out that it is cheaper to compute the count from > the size than the optimal size from the count, in the mbuf case. If > you don't mind, I would strongly recommend moving m_getm() to > uipc_mbuf.c. Code that doesn't know the `size' but knows the `count' Agreed, that why this function have a prefix 'm_' :) [code sample skipped] > For this to work, though, m_getm() needs to be modified to free all of > `top' chain if it can't get either a cluster or an mbuf. I don't know > if this was intentional, but it seems to me that there is a subtle > problem in m_getm() as it is now: > > if (len > MINCLSIZE) { > MCLGET(m, M_TRYWAIT); > if ((m->m_flags & M_EXT) == 0) { > m_freem(m); <------ frees only one mbuf ^^^^^^^^^^ cluster is not in the chain yet, so it have to be freed. > return NULL; > } > } > > I think what may happen here is that you will leak your `top' chain if > you fail to allocate a cluster. The original semantic was not to free an entire chain because m_getm() do not reallocates original (top) mbuf(s) (which may contain data) and only adds new mbufs/clusters if possible. So, the calls like m_get(mb->mb_top) will not left the wild pointer. There is also simple way to deal with such behavior: mtop = m_get(...); if (mtop == NULL) fail; if (m_getm(mtop) == NULL) { m_freem(mtop); fail; } Probably m_getm() should return error code rather than pointer to mbuf to avoid confusion. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 19: 0:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (s206m1.whistle.com [207.76.206.1]) by hub.freebsd.org (Postfix) with ESMTP id 5F5E337B491 for ; Thu, 8 Feb 2001 19:00:42 -0800 (PST) Received: from [207.76.207.169] (PBG3.whistle.com [207.76.207.169]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id SAA93475; Thu, 8 Feb 2001 18:58:08 -0800 (PST) Mime-Version: 1.0 X-Sender: mark@207.76.206.1 Message-Id: In-Reply-To: <200102090209.VAA60712@khavrinen.lcs.mit.edu> References: <200102090102.f19125x06386@iguana.aciri.org> <200102090209.VAA60712@khavrinen.lcs.mit.edu> Date: Thu, 8 Feb 2001 18:58:11 -0800 To: Garrett Wollman From: Mark Peek Subject: Re: potential infinite loop in network device drivers Cc: net@FreeBSD.ORG, Luigi Rizzo Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 9:09 PM -0500 2/8/01, Garrett Wollman wrote: >One possible right way to deal with this is to get rid of the >two-level interrupt scheme (for fast interfaces at least) and push the >packets all the way through the network stack. This will ensure that >if packets are arriving faster than we can handle them, they will be >dropped by the network interface with an ``insufficient resources'' >error. > >Another possible right way to deal with this is to move all network >processing into the lower level, and poll round-robin for packets >(with network interrupts disabled) until all network interfaces are >finished (or we need to give the user a time slice). > >Both techniques were described in a paper by Jeff Mogul (then at DEC >in Palo Alto) about five years ago; I have a physical copy of the >paper buried somewhere in my office. Is this the paper you were referring to? Mark --------- Mark Peek Director of Internet Technology IBM Global Small Business/Whistle Communications Work: (650) 577-7052 Email: mark@whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 19: 7:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from VL-MS-MR001.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 1AC5837B401; Thu, 8 Feb 2001 19:07:22 -0800 (PST) Received: from jehovah ([24.201.144.31]) by VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G8GZC902.6Z2; Thu, 8 Feb 2001 22:07:21 -0500 Message-ID: <001301c09245$b7400a00$1f90c918@jehovah> From: "Bosko Milekic" To: "Boris Popov" Cc: , References: Subject: Re: Sequential mbuf read/write extensions Date: Thu, 8 Feb 2001 22:09:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Boris Popov wrote: [...] > > For this to work, though, m_getm() needs to be modified to free all of > > `top' chain if it can't get either a cluster or an mbuf. I don't know > > if this was intentional, but it seems to me that there is a subtle > > problem in m_getm() as it is now: > > > > if (len > MINCLSIZE) { > > MCLGET(m, M_TRYWAIT); > > if ((m->m_flags & M_EXT) == 0) { > > m_freem(m); <------ frees only one mbuf > ^^^^^^^^^^ cluster is not in the chain yet, so it have to be > freed. m_free() may be more appropriate than m_freem() then, but see below. > > return NULL; > > } > > } > > > > I think what may happen here is that you will leak your `top' chain if > > you fail to allocate a cluster. > > The original semantic was not to free an entire chain because > m_getm() do not reallocates original (top) mbuf(s) (which may contain > data) and only adds new mbufs/clusters if possible. So, the calls like > m_get(mb->mb_top) will not left the wild pointer. There is also simple way > to deal with such behavior: > > mtop = m_get(...); > if (mtop == NULL) > fail; > if (m_getm(mtop) == NULL) { > m_freem(mtop); > fail; > } > > Probably m_getm() should return error code rather than pointer to > mbuf to avoid confusion. I understand this part, but what I think you missed in my comment is that m_getm() should probably free what it already allocated before finally failing. It may not need to free `top' because of the wild pointer, as you say. But think of this: m_getm() is called with a larger `size' - it decides that given the `size' it will need to allocate a total of exactly 6 mbufs and 6 clusters for each mbuf. It loops and allocates, succesfully, 5 of those mbufs and 5 clusters. So `top' chain has now grown and includes those mbufs. Then what happens in the last iteration is that it allocates the 6th mbuf OK (it has not yet placed it on the chain) and fails to allocate a cluster, so it frees just that one mbuf (and not the mbufs it allocated in prior iterations and attached to `top' chain) and returns NULL. Your code that calls m_getm() then just fails, leaving `top' with what it could allocate. Note that in my mail I said "assuming this is a leak," thus recognizing the possibility that you did this intentionally. :-) Right now, I'll assume that this _was_ intentional, as that is what I understand from the above. But in any case, if we do move this to uipc_mbuf.c, we need to do one of the following: (a) make m_getm() free what it allocated in previous loop iterations before it failed (as described above) or (b) leave m_getm() the way it is BUT write an additional function that will simply wrap the call to m_getm() and flush properly for it if it fails (EXACTLY like your code snippet above). I'll gladly settle for either, but if we do go with (b), then the m_freem() should be changed to an m_free(), as it reflects the fact that we are only freeing the one mbuf and we should document this behavior, certainly. If you want, I'll roll up a diff in a few days (once I get what is presently dragging in my "commit this" queue out) and commit it. If you prefer to do this yourself, then feel free. :-) > -- > Boris Popov > http://www.butya.kz/~bp/ Regards, Bosko. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 21: 0:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 91CB337B401; Thu, 8 Feb 2001 20:59:56 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id C8FF428695; Fri, 9 Feb 2001 10:59:43 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id BE4992863E; Fri, 9 Feb 2001 10:59:43 +0600 (ALMT) Date: Fri, 9 Feb 2001 10:59:43 +0600 (ALMT) From: Boris Popov To: Bosko Milekic Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Sequential mbuf read/write extensions In-Reply-To: <001301c09245$b7400a00$1f90c918@jehovah> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 8 Feb 2001, Bosko Milekic wrote: > any case, if we do move this to uipc_mbuf.c, we need to do one of the > following: > > (a) make m_getm() free what it allocated in previous loop iterations > before it failed (as described above) or > > (b) leave m_getm() the way it is BUT write an additional function that > will simply wrap the call to m_getm() and flush properly for it if it > fails (EXACTLY like your code snippet above). Ok, I think the (a) is a right way. There is no point to hold partially allocated mbuf chain. And function should return error code, not a pointer. > I'll gladly settle for either, but if we do go with (b), then the > m_freem() should be changed to an m_free(), as it reflects the fact > that we are only freeing the one mbuf and we should document this > behavior, certainly. If you want, I'll roll up a diff in a few days > (once I get what is presently dragging in my "commit this" queue out) > and commit it. If you prefer to do this yourself, then feel free. :-) Yes, I would appreciate your help on it. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 21:58:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id AFD5037B401; Thu, 8 Feb 2001 21:58:00 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id VAA19427; Thu, 8 Feb 2001 21:57:33 -0800 (PST) (envelope-from richw) Date: Thu, 8 Feb 2001 21:57:33 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Luigi Rizzo Cc: bmilekic@technokratis.com, luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Fw: if_ed.c && BRIDGE In-Reply-To: <200102081735.f18HZY515166@iguana.aciri.org> Message-ID: <20010209055043.19329.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi wrote: > Try the following patch: near line 2209 of if_ed.c > - if ((len > sizeof(struct ed_ring)) && > + if ((len > ETHER_HDR_LEN + sizeof(struct ed_ring)) && I did, and it appears to avoid panics. I downloaded 400 MB worth of data just now, over my home DSL line, through a bridge cluster with an "ed" card; the files were transferred correctly, and the bridge didn't crash. I got four "NIC memory corrupt - invalid packet length" messages. Three of these messages reported a packet length of 18; one reported a length of 10. I'll try running my download test in a loop overnight and make sure it doesn't crash. Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 8 22:45:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-01.iinet.net.au (syncopation-01.iinet.net.au [203.59.24.37]) by hub.freebsd.org (Postfix) with SMTP id 2487337B491 for ; Thu, 8 Feb 2001 22:45:09 -0800 (PST) Received: (qmail 8280 invoked by uid 666); 9 Feb 2001 06:51:49 -0000 Received: from reggae-14-106.nv.iinet.net.au (HELO elischer.org) (203.59.77.106) by mail.m.iinet.net.au with SMTP; 9 Feb 2001 06:51:49 -0000 Message-ID: <3A8391E8.89DF969A@elischer.org> Date: Thu, 08 Feb 2001 22:44:56 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Mark Peek Cc: Garrett Wollman , net@FreeBSD.ORG, Luigi Rizzo Subject: Re: potential infinite loop in network device drivers References: <200102090102.f19125x06386@iguana.aciri.org> <200102090209.VAA60712@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mark Peek wrote: > > At 9:09 PM -0500 2/8/01, Garrett Wollman wrote: > >One possible right way to deal with this is to get rid of the > >two-level interrupt scheme (for fast interfaces at least) and push the > >packets all the way through the network stack. This will ensure that > >if packets are arriving faster than we can handle them, they will be > >dropped by the network interface with an ``insufficient resources'' > >error. > > > >Another possible right way to deal with this is to move all network > >processing into the lower level, and poll round-robin for packets > >(with network interrupts disabled) until all network interfaces are > >finished (or we need to give the user a time slice). > > > >Both techniques were described in a paper by Jeff Mogul (then at DEC > >in Palo Alto) about five years ago; I have a physical copy of the > >paper buried somewhere in my office. > > Is this the paper you were referring to? > I remember a paper on this at USEnix about the same time (maybe 96/7) > > Mark > > --------- > Mark Peek > Director of Internet Technology > IBM Global Small Business/Whistle Communications > Work: (650) 577-7052 Email: mark@whistle.com -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 2:29: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 443CA37B401; Fri, 9 Feb 2001 02:28:41 -0800 (PST) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id SAA01950; Fri, 9 Feb 2001 18:28:39 +0800 Received: from elischer.org (reggae-13-227.nv.iinet.net.au [203.59.79.227]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id SAA07291; Fri, 9 Feb 2001 18:26:06 +0800 Message-ID: <3A83C653.2B68DACE@elischer.org> Date: Fri, 09 Feb 2001 02:28:35 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Bill Paul Cc: hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: call for testers: port aggregation netgraph module References: <20010208212509.E8D7D37B6AA@hub.freebsd.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Welcome to netgraph.. I hope it was not an unpleasant experience.. Suggestions and complaints are definitly eccepted with pleasure. E.g. Was the differnce between 4.x and 5.x too much of a pain.? (it was needed for SMP) I will be making a backport of SOME of the added functionality of 5.x to 4.x which will mean a minor change to the prototypes for the rcvmsg method, but if you don't use the new features the only effect will the added argument. so far there are very few 3rd party netgraph authors. so this should be ok.. I will look at your modules with an eye for "traps for young players" Thankyou for your confidence in Netgraph! Bill Paul wrote: > > http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz > http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz > > This is a call for testers for a netgraph module that can be used to > aggregate 2 or 4 ethernet interfaces into a single interface. Basically, > it lets you do things like the following: > > # kldload ./ng_fec.ko > # ngctl mkpeer fec dummy fec > # ngctl msg fec0: add_iface '"dc0"' > # ngctl msg fec0: add_iface '"dc1"' > # ngctl msg fec0: add_iface '"dc2"' > # ngctl msg fec0: add_iface '"dc3"' > # ngctl msg fec0: set_mode_inet > > The fec module will work with *any* combination of interfaces, not > just multiport ethernet cards, however the port failover mechanism > will not work unless the interface supports ifmedia and is able to > report the link status. Cards that use the fxp, de, xl, tl, rl, sis, > dc, wb, ste, sf, vr, ti and sk drivers should work. Yes, that means > you can aggregate RealTek cards and gigabit ethernet cards together. > > The channel bonding is done using the Cisco fast etherchannel mechanism. > The default hashing mechanism uses the MAC address, however you can > select IP address hashing as well. IPv4 and IPv6 address *should* work, > though I must admit I've been using IPv4 until now. If someone actually > has a Cisco switch that implements fast ethetchannel, I'd be interested > to know if it works with this module. At the moment, my test environment > consist of two machines with multiport ethernet cards wired up using > four crossover cables. > > Each link is checked once every second to see if the link is still up. > An attempt to send a packet over a dead link will cause the packet to > be shifted over to the next link in the bundle. > > There are tarballs for 4.x and 5.x systems. The 4.x tarball should > work on 4.2-RELEASE or later. The 5.x one will work on -current. Both > source and pre-compiled modules for x86 are provided. This code should > work on the alpha as well. > > You can create more than one bundle by using more than one mkpeer > command with ngctl(8). You can delete interfaces from a bundle using > the del_iface command, which works just like the add_iface command. > The fec0 pseudo-interface will inherit the MAC address of the first > real interface to be added to the bundle, and that same MAC address > will be propagated to all subsequent interfaces that are added. The > MAC addresses are restored when an interface is removed from a bundle. > Once the bundle is created, you can manipulate the fec0 interface > as though it were a real ethernet interface. You must have either 2 > or 4 NICs in the bundle. > > Share, enjoy, test, and report back to me any problems you encounter. > > -Bill > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 2:39:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.flashnet.it (ems.flashnet.it [194.247.160.44]) by hub.freebsd.org (Postfix) with ESMTP id D945537B401 for ; Fri, 9 Feb 2001 02:39:17 -0800 (PST) Received: from smtp.flashnet.it (ip202.pool-173.cyb.it [195.191.181.203]) by relay.flashnet.it (EMS-RELAY/8.10.0) with SMTP id f19AdGl25740 for ; Fri, 9 Feb 2001 11:39:16 +0100 Message-Id: <200102091039.f19AdGl25740@relay.flashnet.it> To: freebsd-net@freebsd.org X-Mailer: Post Road Mailer for OS/2 (Green Edition Ver 3.0) Date: Fri, 9 Feb 2001 11:39:14 EST From: Andrea Venturoli Reply-To: Andrea Venturoli Subject: Re: Meditation on rl driver Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ** Reply to note from Clark Gaylord Thu, 8 Feb 2001 12:46:06 -0500 > It used to be the case that mediaopt half-duplex worked. It stopped > working at some point (I don't recall exactly when ... somewhere > between 4.0 and 4.2 I think), So this IS a bug. > but it seems that this is the default > (as it should be) if you specify 10baseT/UTP. Just wish the man page would say this. > I would be concerned > that the -full-duplex setting might actually be setting to *use* > full-duplex, not turn it off. Check the src on this; clearly the > man page is just plain wrong. Well, it's been working for a couple of weeks now, so I guess -full-duplex turns it off. > > _ autoselecting the media obviously does not work correctly, does it? > > Autoselect of duplex gets it right, in general, about 51.045% of > the time, and should be considered an Evil Spawn of Satan (ESS). Did not know this. I always used autoselect in a lot of computers with various OSes and different NICs, and this is the first time I had any problem. > When you say full-duplex doesn't work are you saying that the driver > barfs at the mention of it or that your NIC does not work properly > when it is set (which is correct, as your modem is hdx). I don't remember the exact message (and I don't have the box here now), but it was ifconfig that just refused the option (seemed that it could not get the driver to accept it). > Does it > accept the parameter when the card is set to 100 (while fdx 10 does > exist, it is less common, and I have seen drivers/NICs that only support > fdx at 100Mbps)? Didn't have the chance to try. Bye & Thanks av. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 3:31: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from hq1.tyfon.net (hq1.tyfon.net [217.27.162.35]) by hub.freebsd.org (Postfix) with ESMTP id CF5D937B684 for ; Fri, 9 Feb 2001 03:30:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hq1.tyfon.net (Postfix) with ESMTP id 1DA2B1C7D8 for ; Fri, 9 Feb 2001 12:30:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by hq1.tyfon.net (Postfix) with ESMTP id 49A191C7C0 for ; Fri, 9 Feb 2001 12:30:39 +0100 (CET) Date: Fri, 9 Feb 2001 12:30:39 +0100 (CET) From: Dan Larsson To: Subject: pptp (mpd-netgraph) through a firewall Message-ID: Organization: Tyfon Svenska AB X-NCC-NIC: DL1999-RIPE X-NCC-RegID: se.tyfon MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by hq1.tyfon.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Are the following ipfw lines sufficent to allow pptp?: ${fwcmd} add pass tcp from any to any established ${fwcmd} add pass tcp from any to ${EXT_IF} pptp setup ${fwcmd} add pass gre from any to any Comments/suggestions? Regards +------ Dan Larsson | Tel: +46 8 550 120 21 Tyfon Svenska AB | Fax: +46 8 550 120 02 GPG and PGP keys | finger dl@hq1.tyfon.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 4:28:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from brunel.uk1.vbc.net (brunel.uk1.vbc.net [194.207.2.8]) by hub.freebsd.org (Postfix) with ESMTP id 9344037B821 for ; Fri, 9 Feb 2001 04:27:55 -0800 (PST) Received: from localhost (jcv@localhost) by brunel.uk1.vbc.net (8.11.0/8.11.0) with ESMTP id f19CRrT87547 for ; Fri, 9 Feb 2001 12:27:53 GMT X-Authentication-Warning: brunel.uk1.vbc.net: jcv owned process doing -bs Date: Fri, 9 Feb 2001 12:27:53 +0000 (GMT) From: Jean-Christophe Varaillon X-Sender: jcv@brunel.uk1.vbc.net To: freebsd-net@FreeBSD.ORG Subject: - Interface Full Duplex - In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I am looking for the syntaxe to configure an ethernet interface as fullduplex. If it is just by "ifconfig", I just know the beginning: ifconfig -fxp0="inet... netmask ... broadcast... media ???" Thanks, JC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 8:23:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from timesync.vci.com (timesink.vci.com [205.230.105.115]) by hub.freebsd.org (Postfix) with SMTP id 7CF2437BB7A for ; Fri, 9 Feb 2001 07:24:42 -0800 (PST) Received: from gateway.vci.com by timesync.vci.com via smtpd (for hub.freebsd.org [216.136.204.18]) with SMTP; 9 Feb 2001 15:24:34 UT Received: from mail.vci.com (unverified) by gateway.vci.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 9 Feb 2001 10:25:48 -0500 Received: by exchange.vci.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Feb 2001 10:24:54 -0500 Message-ID: <76AE66BFB2FBD211A30B0008C7DF6C2D01718451@exchange.vci.com> From: Clark Jarvis To: net@freebsd.org Subject: RE: potential infinite loop in network device drivers Date: Fri, 9 Feb 2001 10:24:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > it occurs to me that there is a potential infinite loop in > most if not all ethernet drivers. Basically, on a > receive interrupt, such drivers loop around the status word > until the receive queue is drained. > > If the body of the loop takes approx the same as > the packet interarrival time, you might end up stuck in > the loop forever (and typically holding locks or with most > interrupts masked off). > > I would suggest that we slightly redesign such loops so that > we limit the amt of time spent in them. This probably > affects only 100M/1G interfaces these days, but still... I remember thinking about this at one point, and deciding that it wasn't worth working around. The problem was that if you leave before cleaning up all the interrupt conditions, you'll just get another interrupt and be right back almost immediately anyway. Yeah, you get a little window for other things to happen, but not much, and you add overhead, slowing down what is obviously a busy device. It'll still be interesting to read the papers Garrett mentioned... -- Clark ********************************************************************** This email, and any files transmitted with it, are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please advise ismail@vci.com. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 9:12:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from secure.webhotel.net (secure.webhotel.net [195.41.202.80]) by hub.freebsd.org (Postfix) with SMTP id 07CF937BBE1 for ; Fri, 9 Feb 2001 08:29:59 -0800 (PST) Received: (qmail 72669324 invoked from network); 9 Feb 2001 16:32:20 -0000 Received: from mail-gateway.webhotel.net (195.41.202.215) by mail.webhotel.net with SMTP; 9 Feb 2001 16:32:20 -0000 X-Authenticated-Timestamp: 17:32:20(CET) on February 09, 2001 Received: (from hroi@localhost) by chewbacca.netgroup.dk (8.11.2/8.9.3) id f19GU8N95039; Fri, 9 Feb 2001 17:30:08 +0100 (CET) (envelope-from hroi) Date: Fri, 9 Feb 2001 17:30:08 +0100 From: Hroi Sigurdsson To: Jean-Christophe Varaillon Cc: freebsd-net@FreeBSD.ORG Subject: Re: - Interface Full Duplex - Message-ID: <20010209173008.A94270@chewbacca.netgroup.dk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jcv@vbc.net on Fri, Feb 09, 2001 at 12:27:53PM +0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Feb 09, 2001 at 12:27:53PM +0000, Jean-Christophe Varaillon wrote: > I am looking for the syntaxe to configure an ethernet interface as > fullduplex. Try this: ifconfig fxp0 media 100baseTX mediaopt full-duplex -- Hroi Sigurdsson hroi@netgroup.dk Netgroup A/S http://www.netgroup.dk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 9:14:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id 7012E37BBEE for ; Fri, 9 Feb 2001 08:34:10 -0800 (PST) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f19GsIn57036; Fri, 9 Feb 2001 10:54:18 -0600 (CST) (envelope-from nick@rogness.net) Date: Fri, 9 Feb 2001 10:54:17 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Jean-Christophe Varaillon Cc: freebsd-net@FreeBSD.ORG Subject: Re: - Interface Full Duplex - In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 9 Feb 2001, Jean-Christophe Varaillon wrote: > Hi, Hello. > > I am looking for the syntaxe to configure an ethernet interface as > fullduplex. > > If it is just by "ifconfig", I just know the beginning: > > ifconfig -fxp0="inet... netmask ... broadcast... media ???" mediaopt full-duplex Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 9:15:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (unknown [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id E3A6037B74A; Fri, 9 Feb 2001 08:40:20 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id IAA30861; Fri, 9 Feb 2001 08:38:13 -0800 (PST) (envelope-from richw) Date: Fri, 9 Feb 2001 08:38:13 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: Luigi Rizzo Cc: bmilekic@technokratis.com, luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Fw: if_ed.c && BRIDGE In-Reply-To: <20010209055043.19329.richw@wyattearp.stanford.edu> Message-ID: <20010209163300.30303.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just to follow up for everyone on my e-mail of last night, I ran my bridge download test overnight (to check out Luigi's packet length patch in if_ed.c), and it ran fine, with no crashes. I did get about 70 "invalid packet length" incidents overnight (with abnormally short packets of length 10, 14, or 18); the driver logged these and kept going. Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 9:16:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from stewart.chicago.il.us (dsl-64-128-23-213.telocity.com [64.128.23.213]) by hub.freebsd.org (Postfix) with ESMTP id F0D8137B787 for ; Fri, 9 Feb 2001 08:49:56 -0800 (PST) Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id KAA23228 for ; Fri, 9 Feb 2001 10:50:23 -0600 Message-ID: <3A841FCF.9A4EDBDF@stewart.chicago.il.us> Date: Fri, 09 Feb 2001 10:50:23 -0600 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Subject: SCTP and FreeBSD? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello: Has anyone considered doing a SCTP stack implementation for FreeBSD? I have a user space version working.. but before I start doing one for the kernel space.. just curious? Don't want to duplicate anyones efforts.. R -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 9:56: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 3C21837B6A4 for ; Fri, 9 Feb 2001 09:55:32 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14RHug-0000JW-00; Fri, 09 Feb 2001 11:04:54 -0700 Message-ID: <3A843146.BFC863B9@softweyr.com> Date: Fri, 09 Feb 2001 11:04:54 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: Luigi Rizzo , net@FreeBSD.ORG Subject: Re: potential infinite loop in network device drivers References: <200102090102.f19125x06386@iguana.aciri.org> <200102090209.VAA60712@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman wrote: > > < said: > > > it occurs to me that there is a potential infinite loop in > > most if not all ethernet drivers. Basically, on a > > receive interrupt, such drivers loop around the status word > > until the receive queue is drained. > > One possible right way to deal with this is to get rid of the > two-level interrupt scheme (for fast interfaces at least) and push the > packets all the way through the network stack. This will ensure that > if packets are arriving faster than we can handle them, they will be > dropped by the network interface with an ``insufficient resources'' > error. > > Another possible right way to deal with this is to move all network > processing into the lower level, and poll round-robin for packets > (with network interrupts disabled) until all network interfaces are > finished (or we need to give the user a time slice). This is similar to the way most VxWorks network drivers operate: the "packet available" interrupt handler simply schedules tNetTask to retrieve the packet using a driver-specific callback function. If the buffer on the network card gets filled up before tNetTask can get around to it, packets are dropped until the system becomes less busy. The programmer can tune the behavior by juggling the priorities of tNetTask and other busy parts of the system. This helps to avoid the problems of too many receive interrupts driving the system into interrupt livelock, as long as the card is smart enough to discard packets without interrupting when its own buffers are full. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 10: 4:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from hawaii.rr.com (hnlmail1.hawaii.rr.com [24.25.227.33]) by hub.freebsd.org (Postfix) with ESMTP id E750037B698 for ; Fri, 9 Feb 2001 10:04:02 -0800 (PST) Received: from hawaii.rr.com ([216.235.38.55]) by hawaii.rr.com with Microsoft SMTPSVC(5.5.1877.517.51); Fri, 9 Feb 2001 08:04:02 -1000 From: jvolack@hawaii.rr.com Reply-To: jvolack@hawaii.rr.com To: Jean-Christophe Varaillon , freebsd-net@FreeBSD.ORG Date: Fri, 9 Feb 2001 08:05:52 -1000 Subject: Re: - Interface Full Duplex - X-Mailer: DMailWeb Web to Mail Gateway 2.3t, http://netwinsite.com/top_mail.htm Message-id: <3a843180.b2.0@hawaii.rr.com> X-User-Info: 204.210.124.203 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Aloha, I think you need to do an ifconfig -a on your system, and use the media and/or mediaopt option of ifconfig. My system at home has a de0 interface, and as I recall the parameters are slightly different from those shown below... server# ifconfig pn0 media 100baseTX mediaopt full-duplex server# ifconfig -a pn0: flags=8843 mtu 1500 inet 172.16.1.21 netmask 0xfffff000 broadcast 172.16.15.255 inet 172.31.209.21 netmask 0xfffff000 broadcast 172.31.223.255 ipx 1H.a0cc3cc717 ether 00:a0:cc:3c:c7:17 media: 100baseTX supported media: autoselect 100baseTX 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 10baseT/UTP >Hi, > > > >I am looking for the syntaxe to configure an ethernet interface as >fullduplex. > >If it is just by "ifconfig", I just know the beginning: > >ifconfig -fxp0="inet... netmask ... broadcast... media ???" > > > >Thanks, >JC. > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 10:57:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id C829937B69B for ; Fri, 9 Feb 2001 10:56:53 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id NAA79128; Fri, 9 Feb 2001 13:56:40 -0500 (EST) (envelope-from wollman) Date: Fri, 9 Feb 2001 13:56:40 -0500 (EST) From: Garrett Wollman Message-Id: <200102091856.NAA79128@khavrinen.lcs.mit.edu> To: Wes Peters Cc: net@FreeBSD.ORG Subject: Re: potential infinite loop in network device drivers In-Reply-To: <3A843146.BFC863B9@softweyr.com> References: <200102090102.f19125x06386@iguana.aciri.org> <200102090209.VAA60712@khavrinen.lcs.mit.edu> <3A843146.BFC863B9@softweyr.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > This is similar to the way most VxWorks network drivers operate: Right -- in fact, as I recall, Mogul's paper mentions that his solution is very similar to the way many RTOSes operate. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 13: 3:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id CE89337B67D; Fri, 9 Feb 2001 13:03:10 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id f19L33w00394; Fri, 9 Feb 2001 15:03:03 -0600 (CST) (envelope-from dan) Date: Fri, 9 Feb 2001 15:03:03 -0600 From: Dan Nelson To: Chris Dillon Cc: Bill Paul , hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: call for testers: port aggregation netgraph module Message-ID: <20010209150303.A22605@dan.emsphone.com> References: <20010208212509.E8D7D37B6AA@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.14i In-Reply-To: ; from "Chris Dillon" on Thu Feb 8 20:13:33 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In the last episode (Feb 08), Chris Dillon said: > > The channel bonding is done using the Cisco fast etherchannel > > mechanism. The default hashing mechanism uses the MAC address, > > however you can select IP address hashing as well. IPv4 and IPv6 > > address *should* work, though I must admit I've been using IPv4 > > until now. If someone actually has a Cisco switch that implements > > fast ethetchannel, I'd be interested to know if it works with this > > module. At the moment, my test environment consist of two machines > > with multiport ethernet cards wired up using four crossover cables. > > Apparently there is another way to do channel bonding with switches > that don't support Cisco's EtherChannel, since I'm doing it with > 3COM's (piece of *hit) SuperStackII switches and I don't have > EtherChannel support enabled in Compaq's NT drivers for their Intel > NICs. I've just finished scouring Cisco's documentation, and it doesn't look like FEC is anything beyond plain old trunking (with the option of autoconfiguration on some hardware). As long as you configure the appropriate ports on the switch on the other end as "SA-Trunk", or "Trunk", you should be okay. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 13:10:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from mass.dis.org (c228380-a.sfmissn1.sfba.home.com [24.20.90.44]) by hub.freebsd.org (Postfix) with ESMTP id 81C7337B4EC; Fri, 9 Feb 2001 13:10:30 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f19LC9H00950; Fri, 9 Feb 2001 13:12:13 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200102092112.f19LC9H00950@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Dan Nelson Cc: hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: call for testers: port aggregation netgraph module In-reply-to: Your message of "Fri, 09 Feb 2001 15:03:03 CST." <20010209150303.A22605@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Feb 2001 13:12:09 -0800 From: Mike Smith Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I've just finished scouring Cisco's documentation, and it doesn't look > like FEC is anything beyond plain old trunking (with the option of > autoconfiguration on some hardware). As long as you configure the > appropriate ports on the switch on the other end as "SA-Trunk", or > "Trunk", you should be okay. The important thing to understand is that Etherchannel is just a mechanism for selecting an outbound port in a trunk; it's completely agnostic about where stuff comes in from, and involves no peer negotiation or anything funky like one might expect. An interesting corollary of this is that Bill's code could easily be expanded to support symmetrical or asymmetrical load balancing, true link redundancy, etc. by an enterprising individual. Also, just to state the obvious - if people want this code tested with a particular piece of hardware, just send it to Bill. He can't resist that sort of temptation. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 13:24:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id CCCDF37B491 for ; Fri, 9 Feb 2001 13:24:13 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f19LODE19284 for net@freebsd.org; Fri, 9 Feb 2001 13:24:13 -0800 (PST) Date: Fri, 9 Feb 2001 13:24:13 -0800 From: Alfred Perlstein To: net@freebsd.org Subject: shutdown(2) patch for 2.2.x Message-ID: <20010209132413.N26076@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'd like to see this in 2.2.x, any objections? Index: sys/sys/socket.h =================================================================== RCS file: /home/ncvs/src/sys/sys/socket.h,v retrieving revision 1.15.2.1 diff -u -u -r1.15.2.1 socket.h --- sys/sys/socket.h 1999/09/05 08:22:55 1.15.2.1 +++ sys/sys/socket.h 2001/02/06 21:04:05 @@ -325,6 +325,13 @@ int msg_accrightslen; }; +/* + * howto arguments for shutdown(2), specified by Posix.1g. + */ +#define SHUT_RD 0 /* shut down the reading side */ +#define SHUT_WR 1 /* shut down the writing side */ +#define SHUT_RDWR 2 /* shut down both sides */ + #ifndef KERNEL #include Index: lib/libc/sys/shutdown.2 =================================================================== RCS file: /home/ncvs/src/lib/libc/sys/shutdown.2,v retrieving revision 1.2.2.1 diff -u -u -r1.2.2.1 shutdown.2 --- lib/libc/sys/shutdown.2 1997/01/12 00:09:34 1.2.2.1 +++ lib/libc/sys/shutdown.2 2001/02/06 20:49:10 @@ -50,13 +50,13 @@ to be shut down. If .Fa how -is 0, further receives will be disallowed. +is SHUT_RD (0), further receives will be disallowed. If .Fa how -is 1, further sends will be disallowed. +is SHUT_WR (1), further sends will be disallowed. If .Fa how -is 2, further sends and receives will be disallowed. +is SHUT_RDWR (2), further sends and receives will be disallowed. .Sh RETURN VALUES A 0 is returned if the call succeeds, -1 if it fails. .Sh ERRORS -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 14:16: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id A524937B401; Fri, 9 Feb 2001 14:15:42 -0800 (PST) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id QAA85794; Fri, 9 Feb 2001 16:15:38 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Fri, 9 Feb 2001 16:15:38 -0600 (CST) From: Chris Dillon To: Dan Nelson Cc: Bill Paul , , Subject: Re: call for testers: port aggregation netgraph module In-Reply-To: <20010209150303.A22605@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 9 Feb 2001, Dan Nelson wrote: > In the last episode (Feb 08), Chris Dillon said: > > > The channel bonding is done using the Cisco fast etherchannel > > > mechanism. The default hashing mechanism uses the MAC address, > > > however you can select IP address hashing as well. IPv4 and IPv6 > > > address *should* work, though I must admit I've been using IPv4 > > > until now. If someone actually has a Cisco switch that implements > > > fast ethetchannel, I'd be interested to know if it works with this > > > module. At the moment, my test environment consist of two machines > > > with multiport ethernet cards wired up using four crossover cables. > > > > Apparently there is another way to do channel bonding with switches > > that don't support Cisco's EtherChannel, since I'm doing it with > > 3COM's (piece of *hit) SuperStackII switches and I don't have > > EtherChannel support enabled in Compaq's NT drivers for their Intel > > NICs. > > I've just finished scouring Cisco's documentation, and it doesn't > look like FEC is anything beyond plain old trunking (with the > option of autoconfiguration on some hardware). As long as you > configure the appropriate ports on the switch on the other end as > "SA-Trunk", or "Trunk", you should be okay. Cool, if thats all it will take, I'll give it a try. But, whatever method Compaq/Intel is using doesn't require me to set up the ports on the switch as being part of a trunk. It "just works". And IIRC, when I actually tried to set the ports on the 3COM switch up as trunk ports, it didn't work right. Maybe 3COM is doing something entirely different. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 14:20:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id 511CC37B401; Fri, 9 Feb 2001 14:20:20 -0800 (PST) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id RAA17273; Fri, 9 Feb 2001 17:23:03 -0500 (EST) Date: Fri, 9 Feb 2001 17:23:02 -0500 (EST) From: Alex Pilosov To: Chris Dillon Cc: Dan Nelson , Bill Paul , hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: call for testers: port aggregation netgraph module In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 9 Feb 2001, Chris Dillon wrote: > On Fri, 9 Feb 2001, Dan Nelson wrote: > Cool, if thats all it will take, I'll give it a try. But, whatever > method Compaq/Intel is using doesn't require me to set up the ports on > the switch as being part of a trunk. It "just works". And IIRC, when Its not real trunking. Your incoming traffic will still come on a single link, only outbound traffic will be shared. (Or at least that's how I think compaq stuff will work). > I actually tried to set the ports on the 3COM switch up as trunk > ports, it didn't work right. Maybe 3COM is doing something entirely > different. Prolly. FEC is cisco-specific thingy, like ISL... -alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 14:46: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 1AF6137B65D for ; Fri, 9 Feb 2001 14:45:44 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f19Mkdh73285; Fri, 9 Feb 2001 16:46:39 -0600 (CST) (envelope-from jlemon) Date: Fri, 9 Feb 2001 16:46:39 -0600 (CST) From: Jonathan Lemon Message-Id: <200102092246.f19Mkdh73285@prism.flugsvamp.com> To: randall@stewart.chicago.il.us, net@freebsd.org Subject: Re: SCTP and FreeBSD? X-Newsgroups: local.mail.freebsd-net In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: >Hello: > >Has anyone considered doing a SCTP stack >implementation for FreeBSD? I have a >user space version working.. but before >I start doing one for the kernel space.. just >curious? Don't want to duplicate anyones efforts.. I think that Jonathan Mischo did mention that he has some code, but I'm not sure if it's for Linux or FBSD. I'm also interested in this if I can find some spare cycles. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 14:46:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 9514137B67D; Fri, 9 Feb 2001 14:45:51 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.1/8.11.0) with ESMTP id f19MhFC11639; Fri, 9 Feb 2001 17:43:16 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200102092243.f19MhFC11639@whizzo.transsys.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Alex Pilosov Cc: Chris Dillon , Dan Nelson , Bill Paul , hackers@FreeBSD.ORG, net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: call for testers: port aggregation netgraph module References: In-reply-to: Your message of "Fri, 09 Feb 2001 17:23:02 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Feb 2001 17:43:15 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The crock in these trunking schemes is all the trouble and effort expended to avoid re-ordering frames across the trunk bundle. This is why you see things like the hashing techniques so that an individual flow of traffic doesn't get reordered because it always is serialized over the a single path. I'll observe that there's nothing in the IP architecture which (should) rely on packets not being reordered. I'll also observe that in a network with multiple ethernet switching running a spanning-tree protocol, you probably should't rely on packet reordering never happening when a link fails and the spanning tree computation is re-run. So, a clever implementation might choose to drain a single queue rather than having multiple queues, one per network interface. Of course, some network stacks don't deal well with TCP segments arriving out-of-order, but they are just broken. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 14:47:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 3729E37B65D; Fri, 9 Feb 2001 14:47:31 -0800 (PST) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id QAA86215; Fri, 9 Feb 2001 16:47:27 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Fri, 9 Feb 2001 16:47:27 -0600 (CST) From: Chris Dillon To: Alex Pilosov Cc: Dan Nelson , Bill Paul , , Subject: Re: call for testers: port aggregation netgraph module In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 9 Feb 2001, Alex Pilosov wrote: > On Fri, 9 Feb 2001, Chris Dillon wrote: > > > Cool, if thats all it will take, I'll give it a try. But, whatever > > method Compaq/Intel is using doesn't require me to set up the ports on > > the switch as being part of a trunk. It "just works". And IIRC, when > > Its not real trunking. Your incoming traffic will still come on a > single link, only outbound traffic will be shared. (Or at least > that's how I think compaq stuff will work). Yes, I think that is how it works. I'd guess that this doesn't matter in most cases since most servers are transmitting much more data than they are receiving. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 15: 1: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id D625637B401; Fri, 9 Feb 2001 15:00:49 -0800 (PST) Subject: Re: call for testers: port aggregation netgraph module In-Reply-To: from Alex Pilosov at "Feb 9, 2001 05:23:02 pm" To: alex@pilosoft.com (Alex Pilosov) Date: Fri, 9 Feb 2001 15:00:49 -0800 (PST) Cc: dnelson@emsphone.com, hackers@FreeBSD.ORG, net@FreeBSD.ORG, cdillon@wolves.k12.mo.us X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010209230049.D625637B401@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Fri, 9 Feb 2001, Chris Dillon wrote: > > > On Fri, 9 Feb 2001, Dan Nelson wrote: > > > Cool, if thats all it will take, I'll give it a try. But, whatever > > method Compaq/Intel is using doesn't require me to set up the ports on > > the switch as being part of a trunk. It "just works". And IIRC, when > Its not real trunking. Your incoming traffic will still come on a single > link, only outbound traffic will be shared. (Or at least that's how I > think compaq stuff will work). That doesn't make any sense. If a host on one side of the channel can transmit over multiple links, then the host on the other end by definintion has to be able to receive over multiple links. The ng_fec module does an XOR of the bottom few bits of the source and destination addresses of a packet. (You can use either the ethernet addresses or the IP addresses.) The resulting value is used to select a port from the bundle and the packet is transmitted over that port. This means that all traffic in a given 'flow' will use the same link. (If the link is dead, the next link over is used instead.) For reception, all the traffic received from all of the interfaces in the bundle is simply dumped into the input queue for the fec0 pseudo-interface. This involves intercepting frames at the top of ether_input() using one of the netgraph vectors that was added there, and chancing the rcvif pointer in the mbuf header. -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 15:51:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id BC81237B6B4; Fri, 9 Feb 2001 15:50:49 -0800 (PST) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.1/8.11.1) with ESMTP id f19NnHi02402; Fri, 9 Feb 2001 16:49:17 -0700 (MST) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200102092349.f19NnHi02402@orthanc.ab.ca> To: Chris Dillon Cc: Alex Pilosov , Dan Nelson , Bill Paul , hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: call for testers: port aggregation netgraph module In-reply-to: Your message of "Fri, 09 Feb 2001 16:47:27 CST." Date: Fri, 09 Feb 2001 16:49:17 -0700 From: Lyndon Nerenberg Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> "Chris" == Chris Dillon writes: >> Its not real trunking. Your incoming traffic will still come on >> a single link, only outbound traffic will be shared. (Or at >> least that's how I think compaq stuff will work). Chris> Yes, I think that is how it works. I'd guess that this Chris> doesn't matter in most cases since most servers are Chris> transmitting much more data than they are receiving. For the Cisco scheme, let n equal the number of network interfaces in the bundle. For each packet sent from the bundled host (i.e. the host with bundled interfaces) mask off all but the bottom log2(n) bits and use the result to select the interface to use. E.g.: u_int if_cnt = 4; /* we have four interfaces */ u_int64_t mac; /* the mac address we're sending to */ struct iftab if[n]; /* list of interface entries */ u_int64_t mask = ~0 & (n-1); /* mask for iftab index */ if[mac & mask]->send(data); (Thus if_cnt must be a power of 2.) At zero state, something ARPs for the hosts address. The calculation above determines which interface the response goes out on, and therefore determines which of the MAC addresses the requester sees for the host. The switches can (and usually do) have some smarts in them as well. They know which interfaces are part of the bundle for the host, allowing them to maximize the flow of traffic _to_ the host by redirecting packets to lightly used interfaces. (The bundled host doesn't care which interface the packets arrives on.) This is also necessary to work around interface failure. So assuming a 100 Mb/s switched network fabric and four interfaces on the bundled host, the bundled host can sustain up to 100 Mb/s full-duplex with each of four seperate remote hosts concurrently (400 Mb/s aggregate). It won't let you sustain 400 Mb/s to _one_ remote host (even if the remote also has four bundled interfaces). This works quite well for NFS servers if you have a lot of clients. And it's usually cheaper than putting in gigabit ethernet on the switch and server. (Plus you get redundency from the multiple interfaces.) --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 16: 0:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id D26EB37B6B8; Fri, 9 Feb 2001 16:00:06 -0800 (PST) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.1/8.11.1) with ESMTP id f1A006i02488; Fri, 9 Feb 2001 17:00:06 -0700 (MST) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200102100000.f1A006i02488@orthanc.ab.ca> To: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: call for testers: port aggregation netgraph module In-reply-to: Your message of "Fri, 09 Feb 2001 16:49:17 MST." <200102092349.f19NnHi02402@orthanc.ab.ca> Date: Fri, 09 Feb 2001 17:00:06 -0700 From: Lyndon Nerenberg Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry, my brain's fried this afternoon. < u_int64_t mask = ~0 & (n-1); /* mask for iftab index */ > u_int64_t mask = n-1; /* mask for iftab index */ --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 16:12:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id A4E5337B6C1 for ; Fri, 9 Feb 2001 16:12:28 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f1A0DNp76359; Fri, 9 Feb 2001 18:13:23 -0600 (CST) (envelope-from jlemon) Date: Fri, 9 Feb 2001 18:13:23 -0600 (CST) From: Jonathan Lemon Message-Id: <200102100013.f1A0DNp76359@prism.flugsvamp.com> To: rizzo@aciri.org, net@freebsd.org Subject: Re: [patch] fast sbappend*, please try... X-Newsgroups: local.mail.freebsd-net In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: > >I would be grateful if someone could test the attached patch which >deals with the following problem: > > on all *BSD version, socket buffers contain a list of > incoming and/or outgoing mbufs. Unfortunately the list only > has a pointer to the head, meaning that all append operations > require to scan the full list. The overhead can be very > bad in some cases (e.g. small UDP packets), and becomes > worse and worse as the socket buffer size increases (which > is what one would commonly do when expecting a lot of > traffic!). > >The attached patch implements a tail pointer to the list, so that >you can append in constant time. By default, the code works exactly >as before -- the tail of the list is reached with the usual linear >scan, and the pointer to the tail is only used for comparison >purposes to make sure that it yields the same value. Aside from the obvious style bugs, and debugging cruft, I have a couple of issues with this patch: - I dislike having sb_mb_tail only being valid if sb_mb is NULL; to me, this is non-obvious, and I feel it would be cleaner to always make it valid - sbgettail() is misnamed, it should reflect the function that it is being used for in most cases (appending the new mbuf to an existing chain) - I don't think that the fastscan sysctl is appropriate; either the code works, or it should be debugged further before committing. You could move the debugging checks under a KASSERT though. - Also, I believe that there may be a problem with the original patch, in that the sb_mb_tail is not updated in sbdrop(), in the case where we drop partial mbufs from the first packet train. In that spirit, I offer an amended patch below. -- Jonathan Index: kern/uipc_socket.c =================================================================== RCS file: /ncvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.68.2.11 diff -u -r1.68.2.11 uipc_socket.c --- kern/uipc_socket.c 2000/12/22 10:25:21 1.68.2.11 +++ kern/uipc_socket.c 2001/02/09 23:57:14 @@ -778,6 +778,11 @@ goto restart; } dontblock: + /* + * On entry here, m points to the first record on the socket buffer. + * While we process the initial mbufs containing address and control + * info we save a copy of m->m_nextpkt into nextrecord. + */ if (uio->uio_procp) uio->uio_procp->p_stats->p_ru.ru_msgrcv++; nextrecord = m->m_nextpkt; @@ -821,6 +826,18 @@ controlp = &(*controlp)->m_next; } } + /* + * if nextrecord == NULL (this is a single chain) then m_tail + * may not be valid here if m was changed earlier. + */ + if (nextrecord == NULL && (flags & MSG_PEEK) == 0) + so->so_rcv.sb_mb_tail = m; + + /* + * If m is non-null, we have some data to read. From now on, make + * sure to keep sb_mb_tail consistent when working on the last + * packet on the chain (nextrecord==NULL) and we change m->m_nextpkt. + */ if (m) { if ((flags & MSG_PEEK) == 0) m->m_nextpkt = nextrecord; @@ -881,6 +898,8 @@ } if (m) m->m_nextpkt = nextrecord; + if (nextrecord == NULL) + so->so_rcv.sb_mb_tail = m; } } else { if (flags & MSG_PEEK) @@ -937,8 +956,11 @@ (void) sbdroprecord(&so->so_rcv); } if ((flags & MSG_PEEK) == 0) { - if (m == 0) + if (m == 0) { so->so_rcv.sb_mb = nextrecord; + if (nextrecord == NULL || nextrecord->m_nextpkt == NULL) + so->so_rcv.sb_mb_tail = nextrecord; + } if (pr->pr_flags & PR_WANTRCVD && so->so_pcb) (*pr->pr_usrreqs->pru_rcvd)(so, flags); } Index: kern/uipc_socket2.c =================================================================== RCS file: /ncvs/src/sys/kern/uipc_socket2.c,v retrieving revision 1.55.2.8 diff -u -r1.55.2.8 uipc_socket2.c --- kern/uipc_socket2.c 2001/02/04 14:49:45 1.55.2.8 +++ kern/uipc_socket2.c 2001/02/09 23:59:16 @@ -63,6 +65,9 @@ static u_long sb_efficiency = 8; /* parameter for sbreserve() */ +static int sbtailchk(struct sockbuf *sb); +static __inline void sbappendmbuf(struct sockbuf *sb, struct mbuf *m0); + /* * Procedures to manipulate state flags of socket * and do appropriate wakeups. Normal sequence from the @@ -477,6 +482,29 @@ * or sbdroprecord() when the data is acknowledged by the peer. */ +static int +sbtailchk(struct sockbuf *sb) +{ + struct mbuf *m = sb->sb_mb; + + while (m && m->m_nextpkt) + m = m->m_nextpkt; + return (m == sb->sb_mb_tail); +} + +static __inline void +sbappendmbuf(struct sockbuf *sb, struct mbuf *m0) +{ + struct mbuf *m = sb->sb_mb_tail; + + KASSERT(sbtailchk(sb), ("sbappendmbuf: bad sb_mb_tail")); + if (m) + m->m_nextpkt = m0; + else + sb->sb_mb = m0; + sb->sb_mb_tail = m0; +} + /* * Append mbuf chain m to the last record in the * socket buffer sb. The additional space associated @@ -492,10 +520,9 @@ if (m == 0) return; - n = sb->sb_mb; + KASSERT(sbtailchk(sb), ("sbappend: bad sb_mb_tail")); + n = sb->sb_mb_tail; if (n) { - while (n->m_nextpkt) - n = n->m_nextpkt; do { if (n->m_flags & M_EOR) { sbappendrecord(sb, m); /* XXXXXX!!!! */ @@ -545,19 +572,12 @@ if (m0 == 0) return; - m = sb->sb_mb; - if (m) - while (m->m_nextpkt) - m = m->m_nextpkt; /* * Put the first mbuf on the queue. * Note this permits zero length records. */ sballoc(sb, m0); - if (m) - m->m_nextpkt = m0; - else - sb->sb_mb = m0; + sbappendmbuf(sb, m0); m = m0->m_next; m0->m_next = 0; if (m && (m0->m_flags & M_EOR)) { @@ -603,6 +623,8 @@ */ sballoc(sb, m0); m0->m_nextpkt = *mp; + if (*mp == NULL) /* m0 is actually the new tail */ + sb->sb_mb_tail = m0; *mp = m0; m = m0->m_next; m0->m_next = 0; @@ -653,13 +675,7 @@ m->m_next = control; for (n = m; n; n = n->m_next) sballoc(sb, n); - n = sb->sb_mb; - if (n) { - while (n->m_nextpkt) - n = n->m_nextpkt; - n->m_nextpkt = m; - } else - sb->sb_mb = m; + sbappendmbuf(sb, m); return (1); } @@ -686,13 +702,7 @@ n->m_next = m0; /* concatenate data to control */ for (m = control; m; m = m->m_next) sballoc(sb, m); - n = sb->sb_mb; - if (n) { - while (n->m_nextpkt) - n = n->m_nextpkt; - n->m_nextpkt = control; - } else - sb->sb_mb = control; + sbappendmbuf(sb, control); return (1); } @@ -733,7 +743,7 @@ if (n) n->m_next = m; else - sb->sb_mb = m; + sb->sb_mb = sb->sb_mb_tail = m; sballoc(sb, m); n = m; m->m_flags &= ~M_EOR; @@ -813,6 +823,9 @@ m->m_nextpkt = next; } else sb->sb_mb = next; + m = sb->sb_mb; + if (m == NULL || m->m_nextpkt == NULL) + sb->sb_mb_tail = m; } /* @@ -833,6 +846,9 @@ MFREE(m, mn); m = mn; } while (m); + m = sb->sb_mb; + if (m == NULL || m->m_nextpkt == NULL) + sb->sb_mb_tail = m; } } Index: sys/socketvar.h =================================================================== RCS file: /ncvs/src/sys/sys/socketvar.h,v retrieving revision 1.46.2.4 diff -u -r1.46.2.4 socketvar.h --- sys/socketvar.h 2000/11/26 02:30:08 1.46.2.4 +++ sys/socketvar.h 2001/02/08 17:55:46 @@ -93,6 +93,7 @@ u_long sb_mbmax; /* max chars of mbufs to use */ long sb_lowat; /* low water mark */ struct mbuf *sb_mb; /* the mbuf chain */ + struct mbuf *sb_mb_tail; /* last pkt in chain */ struct selinfo sb_sel; /* process selecting read/write */ short sb_flags; /* flags, see below */ short sb_timeo; /* timeout for read/write */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 16:19:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from stewart.chicago.il.us (dsl-64-128-23-213.telocity.com [64.128.23.213]) by hub.freebsd.org (Postfix) with ESMTP id B87B837B503 for ; Fri, 9 Feb 2001 16:19:36 -0800 (PST) Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id SAA24611; Fri, 9 Feb 2001 18:19:59 -0600 Message-ID: <3A84892F.22656DFE@stewart.chicago.il.us> Date: Fri, 09 Feb 2001 18:19:59 -0600 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lemon Cc: net@freebsd.org Subject: Re: SCTP and FreeBSD? References: <200102092246.f19Mkdh73285@prism.flugsvamp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jonathan: I know Taz quite well.. in fact I got their team started working on a Linux version of SCTP. I think if no volunteers spring forth other than Taz and co on the linux side.. I think I will start the effort.. I am already digging in to the ole an driver ... I think I can move up the stack and start... R Jonathan Lemon wrote: > > In article you write: > >Hello: > > > >Has anyone considered doing a SCTP stack > >implementation for FreeBSD? I have a > >user space version working.. but before > >I start doing one for the kernel space.. just > >curious? Don't want to duplicate anyones efforts.. > > I think that Jonathan Mischo did mention that > he has some code, but I'm not sure if it's for Linux or FBSD. I'm > also interested in this if I can find some spare cycles. > -- > Jonathan -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 16:46:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 4C29837B491 for ; Fri, 9 Feb 2001 16:46:13 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f1A0kBB12081; Fri, 9 Feb 2001 16:46:11 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102100046.f1A0kBB12081@iguana.aciri.org> Subject: Re: [patch] fast sbappend*, please try... In-Reply-To: <200102100013.f1A0DNp76359@prism.flugsvamp.com> from Jonathan Lemon at "Feb 9, 2001 6:13:23 pm" To: jlemon@flugsvamp.com (Jonathan Lemon) Date: Fri, 9 Feb 2001 16:46:11 -0800 (PST) Cc: rizzo@aciri.org, net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks for the feedback... there is another (performance) problem in my code, actually: with TCP, or non-datagram sockets, the socket buffer usually contains a single record, so that sbappend would still have to scan the chain m->m_next . An additional tail pointer would be needed to avoid that overhead as well in the generic case: sb_mb------>[ ]---[ ]---[ ] | [ ]---[ ]---[ ]---[ ] | [ ]---[ ] | sb_mb_tail->[ ]---[ ]---[ ]---[ ]<--sb_mb_end > - I dislike having sb_mb_tail only being valid if sb_mb is NULL; > to me, this is non-obvious, and I feel it would be cleaner to > always make it valid (actually, in my code sb_mb_tail is only valid if sb_mb is non_null, and to me this seems reasonable, as the append code needs to differentiate an empty queue anyways). I see your point, but the end result is probably not that different, with my approach sbappendmbuf would just be if (sb->sb_mb == NULL) sb->sb_mb = m ; else sb->sb_mb_tail->m_nextpkt = m; sb->sb_mb_tail = m ; instead of struct mbuf *m = sb->sb_mb_tail; if (m) m->m_nextpkt = m0; else sb->sb_mb = m0; sb->sb_mb_tail = m0; so basically you just change the variable to test. > - sbgettail() is misnamed, it should reflect the function that > it is being used for in most cases (appending the new mbuf to > an existing chain) yes, the fact is that i first implemented as a 'get' function and only at a later time realized that append was the most common usage. > - I don't think that the fastscan sysctl is appropriate; either that is part of the debugging cruft, and was useful in this stage to assert the difference in performance with and without the tail pointer. > - Also, I believe that there may be a problem with the original > patch, in that the sb_mb_tail is not updated in sbdrop(), in yes, i noticed it and already fixed in a similar way. Would you like to commit your patch to -current ? cheers luigi > train. > > In that spirit, I offer an amended patch below. > -- > Jonathan > > Index: kern/uipc_socket.c > =================================================================== > RCS file: /ncvs/src/sys/kern/uipc_socket.c,v > retrieving revision 1.68.2.11 > diff -u -r1.68.2.11 uipc_socket.c > --- kern/uipc_socket.c 2000/12/22 10:25:21 1.68.2.11 > +++ kern/uipc_socket.c 2001/02/09 23:57:14 > @@ -778,6 +778,11 @@ > goto restart; > } > dontblock: > + /* > + * On entry here, m points to the first record on the socket buffer. > + * While we process the initial mbufs containing address and control > + * info we save a copy of m->m_nextpkt into nextrecord. > + */ > if (uio->uio_procp) > uio->uio_procp->p_stats->p_ru.ru_msgrcv++; > nextrecord = m->m_nextpkt; > @@ -821,6 +826,18 @@ > controlp = &(*controlp)->m_next; > } > } > + /* > + * if nextrecord == NULL (this is a single chain) then m_tail > + * may not be valid here if m was changed earlier. > + */ > + if (nextrecord == NULL && (flags & MSG_PEEK) == 0) > + so->so_rcv.sb_mb_tail = m; > + > + /* > + * If m is non-null, we have some data to read. From now on, make > + * sure to keep sb_mb_tail consistent when working on the last > + * packet on the chain (nextrecord==NULL) and we change m->m_nextpkt. > + */ > if (m) { > if ((flags & MSG_PEEK) == 0) > m->m_nextpkt = nextrecord; > @@ -881,6 +898,8 @@ > } > if (m) > m->m_nextpkt = nextrecord; > + if (nextrecord == NULL) > + so->so_rcv.sb_mb_tail = m; > } > } else { > if (flags & MSG_PEEK) > @@ -937,8 +956,11 @@ > (void) sbdroprecord(&so->so_rcv); > } > if ((flags & MSG_PEEK) == 0) { > - if (m == 0) > + if (m == 0) { > so->so_rcv.sb_mb = nextrecord; > + if (nextrecord == NULL || nextrecord->m_nextpkt == NULL) > + so->so_rcv.sb_mb_tail = nextrecord; > + } > if (pr->pr_flags & PR_WANTRCVD && so->so_pcb) > (*pr->pr_usrreqs->pru_rcvd)(so, flags); > } > Index: kern/uipc_socket2.c > =================================================================== > RCS file: /ncvs/src/sys/kern/uipc_socket2.c,v > retrieving revision 1.55.2.8 > diff -u -r1.55.2.8 uipc_socket2.c > --- kern/uipc_socket2.c 2001/02/04 14:49:45 1.55.2.8 > +++ kern/uipc_socket2.c 2001/02/09 23:59:16 > @@ -63,6 +65,9 @@ > > static u_long sb_efficiency = 8; /* parameter for sbreserve() */ > > +static int sbtailchk(struct sockbuf *sb); > +static __inline void sbappendmbuf(struct sockbuf *sb, struct mbuf *m0); > + > /* > * Procedures to manipulate state flags of socket > * and do appropriate wakeups. Normal sequence from the > @@ -477,6 +482,29 @@ > * or sbdroprecord() when the data is acknowledged by the peer. > */ > > +static int > +sbtailchk(struct sockbuf *sb) > +{ > + struct mbuf *m = sb->sb_mb; > + > + while (m && m->m_nextpkt) > + m = m->m_nextpkt; > + return (m == sb->sb_mb_tail); > +} > + > +static __inline void > +sbappendmbuf(struct sockbuf *sb, struct mbuf *m0) > +{ > + struct mbuf *m = sb->sb_mb_tail; > + > + KASSERT(sbtailchk(sb), ("sbappendmbuf: bad sb_mb_tail")); > + if (m) > + m->m_nextpkt = m0; > + else > + sb->sb_mb = m0; > + sb->sb_mb_tail = m0; > +} > + > /* > * Append mbuf chain m to the last record in the > * socket buffer sb. The additional space associated > @@ -492,10 +520,9 @@ > > if (m == 0) > return; > - n = sb->sb_mb; > + KASSERT(sbtailchk(sb), ("sbappend: bad sb_mb_tail")); > + n = sb->sb_mb_tail; > if (n) { > - while (n->m_nextpkt) > - n = n->m_nextpkt; > do { > if (n->m_flags & M_EOR) { > sbappendrecord(sb, m); /* XXXXXX!!!! */ > @@ -545,19 +572,12 @@ > > if (m0 == 0) > return; > - m = sb->sb_mb; > - if (m) > - while (m->m_nextpkt) > - m = m->m_nextpkt; > /* > * Put the first mbuf on the queue. > * Note this permits zero length records. > */ > sballoc(sb, m0); > - if (m) > - m->m_nextpkt = m0; > - else > - sb->sb_mb = m0; > + sbappendmbuf(sb, m0); > m = m0->m_next; > m0->m_next = 0; > if (m && (m0->m_flags & M_EOR)) { > @@ -603,6 +623,8 @@ > */ > sballoc(sb, m0); > m0->m_nextpkt = *mp; > + if (*mp == NULL) /* m0 is actually the new tail */ > + sb->sb_mb_tail = m0; > *mp = m0; > m = m0->m_next; > m0->m_next = 0; > @@ -653,13 +675,7 @@ > m->m_next = control; > for (n = m; n; n = n->m_next) > sballoc(sb, n); > - n = sb->sb_mb; > - if (n) { > - while (n->m_nextpkt) > - n = n->m_nextpkt; > - n->m_nextpkt = m; > - } else > - sb->sb_mb = m; > + sbappendmbuf(sb, m); > return (1); > } > > @@ -686,13 +702,7 @@ > n->m_next = m0; /* concatenate data to control */ > for (m = control; m; m = m->m_next) > sballoc(sb, m); > - n = sb->sb_mb; > - if (n) { > - while (n->m_nextpkt) > - n = n->m_nextpkt; > - n->m_nextpkt = control; > - } else > - sb->sb_mb = control; > + sbappendmbuf(sb, control); > return (1); > } > > @@ -733,7 +743,7 @@ > if (n) > n->m_next = m; > else > - sb->sb_mb = m; > + sb->sb_mb = sb->sb_mb_tail = m; > sballoc(sb, m); > n = m; > m->m_flags &= ~M_EOR; > @@ -813,6 +823,9 @@ > m->m_nextpkt = next; > } else > sb->sb_mb = next; > + m = sb->sb_mb; > + if (m == NULL || m->m_nextpkt == NULL) > + sb->sb_mb_tail = m; > } > > /* > @@ -833,6 +846,9 @@ > MFREE(m, mn); > m = mn; > } while (m); > + m = sb->sb_mb; > + if (m == NULL || m->m_nextpkt == NULL) > + sb->sb_mb_tail = m; > } > } > > Index: sys/socketvar.h > =================================================================== > RCS file: /ncvs/src/sys/sys/socketvar.h,v > retrieving revision 1.46.2.4 > diff -u -r1.46.2.4 socketvar.h > --- sys/socketvar.h 2000/11/26 02:30:08 1.46.2.4 > +++ sys/socketvar.h 2001/02/08 17:55:46 > @@ -93,6 +93,7 @@ > u_long sb_mbmax; /* max chars of mbufs to use */ > long sb_lowat; /* low water mark */ > struct mbuf *sb_mb; /* the mbuf chain */ > + struct mbuf *sb_mb_tail; /* last pkt in chain */ > struct selinfo sb_sel; /* process selecting read/write */ > short sb_flags; /* flags, see below */ > short sb_timeo; /* timeout for read/write */ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 9 19:38:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id 51CAA37B491 for ; Fri, 9 Feb 2001 19:37:57 -0800 (PST) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.11.2/8.11.1) with SMTP id f1A3bmC59527; Fri, 9 Feb 2001 22:37:48 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa To: ml.ventu@flashnet.it (Andrea Venturoli) Cc: freebsd-net@freebsd.org Subject: Re: Meditation on rl driver Date: Fri, 09 Feb 2001 22:37:48 -0500 Message-ID: <9nd98tg8n1tbm0ridumhg0ng8b098gm1g0@4ax.com> References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 8 Feb 2001 09:32:34 -0500, in sentex.lists.freebsd.net you wrote: >Hello.=20 >I'd like to share some thought on what happened to me: I had an external= ADSL modem from =20 >Alcatel connected (with a straight cable, since the device has a = reversed ethernet port) to =20 >a RealTek card on a FreeBSD 4.1-RELEASE box.=20 >I used the simple line in rc.conf:=20 >=20 > ifconfig_rl1=3D"inet 10.0.0.6 netmask 255.0.0.0"=20 >=20 >Everything would work for a while, but under heavy load the modem would = hang so bad it had =20 >to be cycle-powered, because it wouldn't communicate anymore (the led on= its ethernet port =20 >would turn off).=20 I work for an ISP who has seen a lot of Alcatel modems. There were some firmware versions where the modem would crash. If its a speed touch, see about updating the firmware if possible. >After trying a lot of things and reading the modem manual over and over = I saw that they =20 >required the ethernet card on the computer to be set to half-duplex.=20 >So I issued an ifconfig and saw that the card was set to media = autoselect (NONE).=20 >I tried with=20 >=20 > ifconfig rl1 inet 10.0.0.6 netmask 255.0.0.0 media 10baseT/UTP mediaopt= half-duplex=20 Actually, just ifconfig rl1 media 10baseT/UTP will put it into half = duplex mode. The assumption being that without specifying media-opt, you get half-duplex on 10baseT/UTP e.g. cage# ifconfig rl0 rl0: flags=3D8843 mtu 1500 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 inet6 fe80::250:fcff:fe05:2624%rl0 prefixlen 64 scopeid 0x2=20 ether 00:50:fc:05:26:24=20 media: autoselect (none) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX cage# ifconfig rl0 media 10baseT/UTP cage# ifconfig rl0 rl0: flags=3D8843 mtu 1500 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 inet6 fe80::250:fcff:fe05:2624%rl0 prefixlen 64 scopeid 0x2=20 ether 00:50:fc:05:26:24=20 media: 10baseT/UTP status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX cage#=20 ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 10 9:10:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id D657837B491 for ; Sat, 10 Feb 2001 09:10:17 -0800 (PST) Received: (from uucp@localhost) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) id f1AHAG129565; Sat, 10 Feb 2001 18:10:16 +0100 (MET) >Received: (from bj@localhost) by warp.zuto.de (8.9.3/8.9.3/Debian 8.9.3-6) id PAA09387; Sat, 10 Feb 2001 15:29:17 +0100 Date: Sat, 10 Feb 2001 15:29:17 +0100 From: Rainer Clasen To: net@FreeBSD.ORG Cc: ticso@cicely.de Subject: Re: call for testers: port aggregation netgraph module Message-ID: <20010210152916.B25191@zuto.de> Reply-To: bj@zuto.de References: <20010208212509.E8D7D37B6AA@hub.freebsd.org> Mime-Version: 1.0 User-Agent: Mutt/1.0.1i In-Reply-To: <20010208212509.E8D7D37B6AA@hub.freebsd.org>; from wpaul@FreeBSD.ORG on Thu, Feb 08, 2001 at 01:25:09PM -0800 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Feb 08, 2001 at 01:25:09PM -0800, Bill Paul wrote: > http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz I've tried this with 4.2-RELEASE on a single PIII-500 with 128 MB RAM and 2 fxp0 Interfaces. It was attached to a Nortel Baystack 450 running a 2 port "Multinlink Trunk" Configuration. It worked absolutely flawlessly. When downloading a single 60MB file to 3 clients by FTP, it achieved ~21 MB/sek output (netstat -I fec0 -w10). I had to use 3 clients due to lack of a second speedy client. I'm impressed. Am I right that a single transfer is always limited to the bandwidth of a single interface? The above mentioned Switch and Linux ditribute traffic in a round robbing manner. Both cooperate with Cisco's Etherchannel (tested against a Catalyst 2924). How about adding a round robbing distribution, too? This is epecially usefull for getting higher throughput when traffic mostly takes place between 2 hosts. Rainer -- KeyID=759975BD fingerprint=887A 4BE3 6AB7 EE3C 4AE0 B0E1 0556 E25A 7599 75BD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 10 14:10:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 1F72337B401 for ; Sat, 10 Feb 2001 14:10:31 -0800 (PST) Received: (qmail 91324 invoked by uid 1000); 10 Feb 2001 22:10:27 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Feb 2001 22:10:27 -0000 Date: Sat, 10 Feb 2001 16:10:27 -0600 (CST) From: Mike Silbersack To: Subject: Cloned routes and refcounts question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've been doing some playing around with syn-ack ratelimiting, and I think I've just noticed a problem in the refcounting of routes. Specifically, I'm doing testing by synflooding from 10.1.1.1 to 10.1.1.3 with 10.1.1.1 set to deny all tcp packets coming back from 10.1.1.3. After a few seconds of this, the route table on 10.1.1.3 contains this entry: Destination Gateway Flags Refs Use Netif Expire 10.1.1.1 0:a0:cc:23:82:91 UHLW 75284 151583 dc0 638 The refs field worries me. As I understand it, refs should simply be the count of the number of active connections using that route - clearly the number should be much lower. Note that 10.1.1.1 is also the default gateway for 10.1.1.3, if that changes anything. 10.* are both running recent -currents. Out of curiousity, I checked the route table on my 4.2 box, which is on a different network and wasn't participating in the syn-fun whatsoever. Sure enough, it has more refcounts to its gateway than it should too: Destination Gateway Flags Refs Use Netif Expire default 24.183.3.1 UGSc 18 223 dc0 24.183.3.1 0:50:54:72:8c:54 UHLW 19 0 dc0 1197 So, two questions: 1. Are route entries refcounts only supposed to correspond to connections currently in existance, or do they get bumped by other network subsystems? 2. Does anyone have a guess as to where this leak is coming from in the cloning process? I'm not very familiar with the route table at this moment. Thanks, Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 10 14:17:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 7C73F37B401 for ; Sat, 10 Feb 2001 14:17:28 -0800 (PST) Received: (qmail 91350 invoked by uid 1000); 10 Feb 2001 22:17:27 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Feb 2001 22:17:27 -0000 Date: Sat, 10 Feb 2001 16:17:27 -0600 (CST) From: Mike Silbersack To: Subject: Re: Cloned routes and refcounts question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 10 Feb 2001, Mike Silbersack wrote: > Out of curiousity, I checked the route table on my 4.2 box, which is on a > different network and wasn't participating in the syn-fun whatsoever. > Sure enough, it has more refcounts to its gateway than it should too: > > > Destination Gateway Flags Refs Use Netif Expire > default 24.183.3.1 UGSc 18 223 dc0 > 24.183.3.1 0:50:54:72:8c:54 UHLW 19 0 dc0 1197 Ignore that part of the message, there are cloned routes pointing to 24.183.3.1 still in existance which, when counted, actually add up to that amount. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message