From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 00:39:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5773106564A for ; Mon, 28 Jul 2008 00:39:09 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by mx1.freebsd.org (Postfix) with ESMTP id 314E48FC14 for ; Mon, 28 Jul 2008 00:39:09 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so4118897fkk.11 for ; Sun, 27 Jul 2008 17:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=q7oWXnQdf6B5Q09qqs8jFN+ullHW85KiEzl7xdCkKeQ=; b=t4qJiulkTn2ISFWQ8PfWdJlSF14x5A7aIvHpd5MVU1eck7tb5JFJCFKc9RrAnOhqSC WSPSOrIu0uZsZAbRH9eeSTnx9RzMLTXaNVoldKGkM/OMdHWsMpzO97Wdy6d8dZX6NMhv OeKNlO5BOTwzlp/Ecr/ZOSnZjQIdyA6LazZ74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=G/1swvYm2BefFWVRCodBnKqZheSVhnB9Rz/Df6XU7ybDteawWOjVYpjkWqUT5RkGQf WtfkGsvqTKViHBloU1zeHIiyoOBhsGS0m8tGr03oFeoPmswR4+zO3/QHmne+EiIEOBsk +l0Y0Gt/SB1g14dZqK/+ZW8MutiXK2Atym85M= Received: by 10.125.111.14 with SMTP id o14mr253409mkm.3.1217205547376; Sun, 27 Jul 2008 17:39:07 -0700 (PDT) Received: by 10.125.139.12 with HTTP; Sun, 27 Jul 2008 17:39:07 -0700 (PDT) Message-ID: <3c1674c90807271739p3db39ca4r3ed176903f6dae2c@mail.gmail.com> Date: Sun, 27 Jul 2008 17:39:07 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Robert Watson" In-Reply-To: <20080724084240.C63347@fledge.watson.org> MIME-Version: 1.0 References: <3c1674c90807201514o5bafba72r6be84de6e37a5525@mail.gmail.com> <20080724084240.C63347@fledge.watson.org> X-Google-Sender-Auth: ec12eb25a3b63fa4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: moving sockbuf in to its own header X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2008 00:39:10 -0000 Hi Robert, I updated the patch to reflect your requested changes. Please confirm that your concerns have been addressed. Thanks, Kip On Thu, Jul 24, 2008 at 12:54 AM, Robert Watson wrote: > > On Sun, 20 Jul 2008, Kip Macy wrote: > > Actually, I'd like to re-factor multiple parts of socketvar in to separate >> files. >> >> Please provide feedback on the following: >> >> http://www.fsmware.com/socketvar_refactor.diff >> > > This seems like a fairly disruptive change from the perpective of managing > future MFCs, and likewise makes it quite a bit harder to diff branches and > make sure things haven't been missed. That said, I'm not entirely opposed > to it, since I think this decomposition is a fairly reasonable one. Do make > sure you've done a complete make universe to hit all the user consumers, > such as netstat, etc, that grub around in the kernel parts and make sure > there are no surprises. A few comments: > > - Please propagate the copyright/license from socketvar.h to all derived > new > files. > - You seem to have a lot of extra blank lines -- generally speaking, at > most > one blank line between pieces of code/comments/etc is required. > - The new include files seem not to have forward declarations of the > structs > referenced from other structures, so in practice you may find that > including > one requires including the others. Fixing this is easy and, at the very > least, non-harmful. It would also lay the way towards not doing nested > includes of various includes from socketvar.h in the future. > - One of the elements of the BSD style(9) I don't like is the tab between > "struct" and "structname" for fields in older structures. Perhaps this is > why I notice that it isn't there in the new struct sockbuf line in struct > socket, and likewise xsockbuf in xsocket :-) > > If you do make this change, check in with Peter about whether we now prefer > the use of svn copy. > > Robert N M Watson > Computer Laboratory > University of Cambridge > > > >> Thanks, >> Kip >> >> >> On Sun, Jul 20, 2008 at 3:14 PM, Kip Macy wrote: >> >>> TOE drivers need to be able to directly enqueue data in to a socket >>> buffer and thus benefit from having knowledge of sockbuf internals. >>> However, there is no need for them to know about other socket >>> definitions. Thus I would like to move sockbuf and accompanying >>> definitions to their own header. >>> >>> This is a fairly straightforward change so I don't really see the need >>> to wait more than a few days for feedback: >>> >>> http://www.fsmware.com/sockbuf.h.diff >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >>> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 11:07:01 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72AED106567A for ; Mon, 28 Jul 2008 11:07:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 064B58FC0A for ; Mon, 28 Jul 2008 11:07:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6SB701K078986 for ; Mon, 28 Jul 2008 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6SB70xp078982 for freebsd-net@FreeBSD.org; Mon, 28 Jul 2008 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Jul 2008 11:07:00 GMT Message-Id: <200807281107.m6SB70xp078982@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2008 11:07:01 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net [patch] changing interface ipaddress doesn't seem to w s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122685 net It is not visible passing packets in tcpdump o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f conf/122858 net [nsswitch.conf] nsswitch in 7.0 is f*cked up o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o bin/125922 net [patch] Deadlock in arp(8) 96 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123892 net [tap] [patch] No buffer space available p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125239 net [gre] kernel crash when using gre o kern/125258 net [socket] socket's SO_REUSEADDR option does not work f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125816 net [carp] [bridge] carp stuck in init when using bridge i o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard 59 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 28 21:44:16 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75660106567C; Mon, 28 Jul 2008 21:44:16 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0D7A68FC16; Mon, 28 Jul 2008 21:44:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6SLhwaA004973; Mon, 28 Jul 2008 17:44:09 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: bug-followup@FreeBSD.org, netch@netch.kiev.ua Date: Mon, 28 Jul 2008 16:25:57 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807281625.58108.jhb@FreeBSD.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 28 Jul 2008 17:44:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7868/Mon Jul 28 14:31:43 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: net@FreeBSD.org Subject: Re: bin/65258: [patch] [request] save /etc/rc.firewall from changing for standard firewall types X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2008 21:44:16 -0000 An updated patch is available at http://www.FreeBSD.org/~jhb/patches/firewall_rc_conf.patch. I'm not sure that we need to have the default values in /etc/rc.firewall anymore though with this patch. I think I'd rather make the script error out if any of the required values aren't supplied. Also, I updated the description of the other firewall toggles that are only for the "workstation" type to indicate as such in their comments. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jul 29 19:00:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DCBB106564A for ; Tue, 29 Jul 2008 19:00:50 +0000 (UTC) (envelope-from jtyocum@publicmx.com) Received: from homer.publicmx.com (homer.publicmx.com [204.14.95.242]) by mx1.freebsd.org (Postfix) with ESMTP id 36CB18FC12 for ; Tue, 29 Jul 2008 19:00:50 +0000 (UTC) (envelope-from jtyocum@publicmx.com) Received: by homer.publicmx.com (Postfix, from userid 99) id DBB871A6D72; Tue, 29 Jul 2008 11:42:37 -0700 (PDT) Received: from web0.fluidhosting.com (web0.fluidhosting.com [204.14.90.20]) by www.publicmx.com (Horde Framework) with HTTP; Tue, 29 Jul 2008 11:42:37 -0700 Message-ID: <20080729114237.45525xviqzjqf9nh@www.publicmx.com> Date: Tue, 29 Jul 2008 11:42:37 -0700 From: "John T. Yocum" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.2) Subject: ath using hostap sets MTU to 2290 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2008 19:00:50 -0000 Hello, I have a system running pfSense, which is built on top of FreeBSD 7.0-RELEASE-p3. In the system I have an Atheros wireless card, which when I enable hostap, changes it's MTU to 2290. If an explanation is listed on a man page, I apologize, I did try searching. Any ideas why this might happen? It doesn't appear to be a pfSense issue, as it appears their code actually tries to set the MTU to 1500. Only reason I ask here, is I noticed in my searching on Google, I noticed others that aren't running pfSense have their MTU set to 2290. Thank you, John From owner-freebsd-net@FreeBSD.ORG Tue Jul 29 20:20:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67AD81065678 for ; Tue, 29 Jul 2008 20:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4B4B28FC1C for ; Tue, 29 Jul 2008 20:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6TKK371041852 for ; Tue, 29 Jul 2008 20:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6TKK39c041851; Tue, 29 Jul 2008 20:20:03 GMT (envelope-from gnats) Date: Tue, 29 Jul 2008 20:20:03 GMT Message-Id: <200807292020.m6TKK39c041851@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: John Baldwin Cc: Subject: Re: kern/112179: [sis] [patch] sis driver for natsemi DP83815D autonegotiate failure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Baldwin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2008 20:20:03 -0000 The following reply was made to PR kern/112179; it has been noted by GNATS. From: John Baldwin To: bug-followup@freebsd.org, mark@hydrus.org.uk Cc: phk@freebsd.org Subject: Re: kern/112179: [sis] [patch] sis driver for natsemi DP83815D autonegotiate failure Date: Tue, 29 Jul 2008 11:56:38 -0400 How about the patch below. This makes the driver match the behavior of the Linux driver (and also fixes a harmless weirdness phk@ introduced.. I think because he thought SIS_SETBIT was CSR_WRITE_4 rather than a RMW op). Index: if_sis.c =================================================================== --- if_sis.c (revision 180877) +++ if_sis.c (working copy) @@ -1904,14 +1904,15 @@ if (sc->sis_type == SIS_TYPE_83815 && sc->sis_srr <= NS_SRR_15D) { CSR_WRITE_4(sc, NS_PHY_PAGE, 0x0001); CSR_WRITE_4(sc, NS_PHY_CR, 0x189C); - if (sc->sis_srr == NS_SRR_15C) { - /* set val for c2 */ - CSR_WRITE_4(sc, NS_PHY_TDATA, 0x0000); + /* set val for c2 */ + CSR_WRITE_4(sc, NS_PHY_TDATA, 0x0000); + if (sc->sis_srr <= NS_SRR_15C) /* load/kill c2 */ CSR_WRITE_4(sc, NS_PHY_DSPCFG, 0x5040); - /* rais SD off, from 4 to c */ - CSR_WRITE_4(sc, NS_PHY_SDCFG, 0x008C); - } + else + SIS_SETBIT(sc, NS_PHY_DSPCFG, 0x1000); + /* rais SD off, from 4 to c */ + CSR_WRITE_4(sc, NS_PHY_SDCFG, 0x008C); CSR_WRITE_4(sc, NS_PHY_PAGE, 0); } @@ -2011,12 +2012,11 @@ CSR_WRITE_4(sc, NS_PHY_DSPCFG, reg | 0x1000); DELAY(100000); reg = CSR_READ_4(sc, NS_PHY_TDATA) & 0xff; - if ((reg & 0x0080) == 0 || (reg > 0xd8 && reg <= 0xff)) { + if ((reg & 0x0080) == 0 || (reg >= 0xd8 && reg <= 0xff)) { device_printf(sc->sis_dev, "Applying short cable fix (reg=%x)\n", reg); CSR_WRITE_4(sc, NS_PHY_TDATA, 0x00e8); - reg = CSR_READ_4(sc, NS_PHY_DSPCFG); - SIS_SETBIT(sc, NS_PHY_DSPCFG, reg | 0x20); + SIS_SETBIT(sc, NS_PHY_DSPCFG, 0x20); } CSR_WRITE_4(sc, NS_PHY_PAGE, 0); } One other thing the Linux driver does differently than the FreeBSD driver is that it 1) doesn't set 0x1000 in DSPCFG when locking the coeffecient (since it sets it earlier) and 2), it locks the coefficient every time link is established and unlocks it when link is lost. Doing 2) would require pushing some logic down into the phy driver I think. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jul 29 20:31:30 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC7BA1065673; Tue, 29 Jul 2008 20:31:30 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9C98FC1B; Tue, 29 Jul 2008 20:31:30 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6TKVU33043549; Tue, 29 Jul 2008 20:31:30 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6TKVUGu043545; Tue, 29 Jul 2008 20:31:30 GMT (envelope-from gavin) Date: Tue, 29 Jul 2008 20:31:30 GMT Message-Id: <200807292031.m6TKVUGu043545@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/126075: [in] Network: internet control accesses beyond end of structure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2008 20:31:30 -0000 Old Synopsis: Network: internet control accesses beyond end of structure New Synopsis: [in] Network: internet control accesses beyond end of structure Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Tue Jul 29 20:30:36 UTC 2008 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=126075 From owner-freebsd-net@FreeBSD.ORG Tue Jul 29 20:41:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00064106564A for ; Tue, 29 Jul 2008 20:41:04 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id CB0E68FC18 for ; Tue, 29 Jul 2008 20:41:04 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m6TKf4hM091570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 13:41:04 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <488F8060.70600@freebsd.org> Date: Tue, 29 Jul 2008 13:41:04 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: "John T. Yocum" References: <20080729114237.45525xviqzjqf9nh@www.publicmx.com> In-Reply-To: <20080729114237.45525xviqzjqf9nh@www.publicmx.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org Subject: Re: ath using hostap sets MTU to 2290 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2008 20:41:05 -0000 John T. Yocum wrote: > Hello, > > I have a system running pfSense, which is built on top of FreeBSD > 7.0-RELEASE-p3. In the system I have an Atheros wireless card, which > when I enable hostap, changes it's MTU to 2290. If an explanation is > listed on a man page, I apologize, I did try searching. > > Any ideas why this might happen? It doesn't appear to be a pfSense > issue, as it appears their code actually tries to set the MTU to 1500. > > Only reason I ask here, is I noticed in my searching on Google, I > noticed others that aren't running pfSense have their MTU set to 2290. MTU on an 802.11 network is 2290. If you don't want the default then change it. If you cannot then please provide the exact steps you take that do not work. Sam From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 01:31:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABA5F106564A for ; Wed, 30 Jul 2008 01:31:19 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 3A1198FC08 for ; Wed, 30 Jul 2008 01:31:19 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so67401nfh.33 for ; Tue, 29 Jul 2008 18:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent :sender; bh=FkUX2vV4azVCj5C368qFjwzOrYfHne5Mz9NTNC8vyps=; b=hIaCbb7XE2lEhAJY8685V2McnBVR9aLy6IjJZpMENtuwUm/WlxI8rh0YHjIe5jHlQy gJYcmsZbavZHF7KQ7SiSkcL9HSYEGQc5/Rm1LzytAOcNoU8nbMjLvdpKMt4OFSO4zTio OH2RDlA0iaM8TZGGU9oZ9gkYzDCEjjYuFbTcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent:sender; b=JqSa5KWX69fmcIe//zGDkc9Cpjx8Laq+gd0a0fUArUAutwBhi7epjrWPFYyF4XmJ0m S5BjW8m8pQmXbA70Cd7dFzQDy9x2g3dXglSUEde0TFmoqV+CFJ5I/rcLwePLwYvcVXvf r1SL+EIeY9MMPpBDZ/LkfDMhdbmgBHAMjWlyA= Received: by 10.210.117.1 with SMTP id p1mr8486943ebc.53.1217379935808; Tue, 29 Jul 2008 18:05:35 -0700 (PDT) Received: from epsilon.local ( [77.54.25.93]) by mx.google.com with ESMTPS id g9sm733371gvc.0.2008.07.29.18.05.33 (version=SSLv3 cipher=RC4-MD5); Tue, 29 Jul 2008 18:05:35 -0700 (PDT) Date: Wed, 30 Jul 2008 02:04:52 +0100 From: Rui Paulo To: freebsd-net@freebsd.org Message-ID: <20080730010452.GA856@epsilon.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Sender: Rui Paulo Subject: TCP ECN patch to be committed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 01:31:19 -0000 Hi, After some chat with other TCP folks I'm going to commit the TCP ECN patch I asked for review a couple months ago with some changes. Most notably is the new padding fields added to the syncache struct. I plan to commit this after investigating the best padding of the syncache struct. So, maybe in the end of the week I'm done. If you feel that something is wrong, please speak up ASAP. The patch can be found at: http://people.freebsd.org/~rpaulo/tcp_ecn.diff Thanks, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 02:04:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56D281065674 for ; Wed, 30 Jul 2008 02:04:52 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 967928FC08 for ; Wed, 30 Jul 2008 02:04:51 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id m6U23rMV028632 for ; Wed, 30 Jul 2008 11:33:53 +0930 (CST) Received: from fmbex510.dsto.defence.gov.au (fmbex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Wed, 30 Jul 2008 11:34:49 +0930 Received: from stlex510.dsto.defence.gov.au ([203.6.60.184]) by fmbex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 12:04:49 +1000 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by stlex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 10:04:48 +0800 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.2/8.14.2) with ESMTP id m6U22sZu086354 for ; Wed, 30 Jul 2008 10:02:54 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.2/8.14.2/Submit) id m6U22sZ8086353 for freebsd-net@freebsd.org; Wed, 30 Jul 2008 10:02:54 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 30 Jul 2008 10:02:54 +0800 From: "Wilkinson, Alex" To: freebsd-net@freebsd.org Message-ID: <20080730020254.GT72093@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-net@freebsd.org References: <20080730010452.GA856@epsilon.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20080730010452.GA856@epsilon.local> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 30 Jul 2008 02:04:48.0727 (UTC) FILETIME=[A5410E70:01C8F1E8] Content-Transfer-Encoding: 7bit Subject: Re: TCP ECN patch to be committed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 02:04:52 -0000 0n Wed, Jul 30, 2008 at 02:04:52AM +0100, Rui Paulo wrote: >After some chat with other TCP folks I'm going to commit the TCP ECN patch >I asked for review a couple months ago with some changes. Most notably is >the new padding fields added to the syncache struct. Um, what is "TCP ECN" ? Nutshell summary please ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 02:31:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E33CF1065685 for ; Wed, 30 Jul 2008 02:31:54 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by mx1.freebsd.org (Postfix) with ESMTP id 73D568FC25 for ; Wed, 30 Jul 2008 02:31:54 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so250302fkk.11 for ; Tue, 29 Jul 2008 19:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=k/lztx2TDIckg/v/3ZFz8EdJQLefAc+5RbE1aZU3RRE=; b=duvryDfabu0jZ5kZHb//dF9n/Vp63801o8UqfgdWUxkExQaj7+HqTiM+htFumJ91zJ XYMOSCIZKeZEt7CuNK1oTJUfLy//mb3+bNuvY5uclxEpe+qtoMdfaot03LulhZ4CM25Y zXalAPlKk4ODmu7UUL79OUcdBry5eESkdIY3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=a/adCrNBko6BxSyLvfRpgIT1XZR/7lbQqk6/bnWHTevVHzl547Uihg2wB+BK7XyZZI Y0245P54YabSQe4n/6+TxJfHc3g8+iYwXghCoCvqnMf8xPrZ075Cpww0GQo0cAegsXVv VLYqVvAa/Rk+Jk4v0qkR2GUWzvU7xYO1G7yx8= Received: by 10.125.78.15 with SMTP id f15mr400028mkl.39.1217385113078; Tue, 29 Jul 2008 19:31:53 -0700 (PDT) Received: by 10.125.139.12 with HTTP; Tue, 29 Jul 2008 19:31:53 -0700 (PDT) Message-ID: <3c1674c90807291931s423bcd55yfb19e689a734974a@mail.gmail.com> Date: Tue, 29 Jul 2008 19:31:53 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: freebsd-net@freebsd.org In-Reply-To: <20080730020254.GT72093@stlux503.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080730010452.GA856@epsilon.local> <20080730020254.GT72093@stlux503.dsto.defence.gov.au> X-Google-Sender-Auth: 02031bfba18f309e Subject: Re: TCP ECN patch to be committed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 02:31:55 -0000 See RFC 3168 and 3540. In short it uses some of the options bits to provide "explicit congestion notification." -Kip On Tue, Jul 29, 2008 at 7:02 PM, Wilkinson, Alex wrote: > 0n Wed, Jul 30, 2008 at 02:04:52AM +0100, Rui Paulo wrote: > > >After some chat with other TCP folks I'm going to commit the TCP ECN patch > >I asked for review a couple months ago with some changes. Most notably is > >the new padding fields added to the syncache struct. > > Um, what is "TCP ECN" ? Nutshell summary please ? > > -aW > > > > IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 02:39:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE07A106566C for ; Wed, 30 Jul 2008 02:39:10 +0000 (UTC) (envelope-from chris@arnold.se) Received: from mailstore.infotropic.com (mailstore.infotropic.com [213.136.34.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3B3FC8FC17 for ; Wed, 30 Jul 2008 02:39:10 +0000 (UTC) (envelope-from chris@arnold.se) Received: (qmail 15054 invoked by uid 89); 30 Jul 2008 02:12:28 -0000 Received: from sql.infotropic.com (HELO sql) (213.136.34.28) by mailstore.infotropic.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Jul 2008 02:12:28 -0000 Date: Wed, 30 Jul 2008 04:12:27 +0200 (CEST) From: Chris Arnold X-X-Sender: chris@sql.infotropic.com To: "Wilkinson, Alex" In-Reply-To: <20080730020254.GT72093@stlux503.dsto.defence.gov.au> Message-ID: <20080730040811.T70776@sql.infotropic.com> References: <20080730010452.GA856@epsilon.local> <20080730020254.GT72093@stlux503.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: TCP ECN patch to be committed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 02:39:11 -0000 On Wed, 30 Jul 2008, Wilkinson, Alex wrote: > 0n Wed, Jul 30, 2008 at 02:04:52AM +0100, Rui Paulo wrote: > > >After some chat with other TCP folks I'm going to commit the TCP ECN patch > >I asked for review a couple months ago with some changes. Most notably is > >the new padding fields added to the syncache struct. > > Um, what is "TCP ECN" ? Nutshell summary please ? > "Explicit Congestion Notification", if negotiated the endpoints in a tcp session can notify eachother of congestion without waiting for dropped packets. This helps in reducing latency and jitter. Short enough? /Chris -- http://www.arnold.se/ http://www.mbit.us/ From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 03:28:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C7F6106566B for ; Wed, 30 Jul 2008 03:28:19 +0000 (UTC) (envelope-from jtyocum@publicmx.com) Received: from homer.publicmx.com (homer.publicmx.com [204.14.95.242]) by mx1.freebsd.org (Postfix) with ESMTP id 31DE08FC16 for ; Wed, 30 Jul 2008 03:28:19 +0000 (UTC) (envelope-from jtyocum@publicmx.com) Received: by homer.publicmx.com (Postfix, from userid 99) id AAA761A6D78; Tue, 29 Jul 2008 20:28:18 -0700 (PDT) Received: from web0.fluidhosting.com (web0.fluidhosting.com [204.14.90.20]) by www.publicmx.com (Horde Framework) with HTTP; Tue, 29 Jul 2008 20:28:18 -0700 Message-ID: <20080729202818.70074fchr6x67bgy@www.publicmx.com> Date: Tue, 29 Jul 2008 20:28:18 -0700 From: "John T. Yocum" To: Sam Leffler References: <20080729114237.45525xviqzjqf9nh@www.publicmx.com> <488F8060.70600@freebsd.org> In-Reply-To: <488F8060.70600@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.2) Cc: freebsd-net@freebsd.org Subject: Re: ath using hostap sets MTU to 2290 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 03:28:19 -0000 Quoting Sam Leffler : > John T. Yocum wrote: >> Hello, >> >> I have a system running pfSense, which is built on top of FreeBSD =20 >> 7.0-RELEASE-p3. In the system I have an Atheros wireless card, =20 >> which when I enable hostap, changes it's MTU to 2290. If an =20 >> explanation is listed on a man page, I apologize, I did try =20 >> searching. >> >> Any ideas why this might happen? It doesn't appear to be a pfSense =20 >> issue, as it appears their code actually tries to set the MTU to =20 >> 1500. >> >> Only reason I ask here, is I noticed in my searching on Google, I =20 >> noticed others that aren't running pfSense have their MTU set to =20 >> 2290. > MTU on an 802.11 network is 2290. If you don't want the default =20 > then change it. If you cannot then please provide the exact steps =20 > you take that do not work. > > Sam Thank you, I didn't realize that the default MTU was 2290. At the =20 moment, I am manually changing it to 1500, so I can setup a bridge =20 between wired, and wireless. I'm curious, are there some Atheros cards or chipsets that only =20 support an MTU of 1500? I only ask, as it seems that some people don't =20 need to manually set the MTU to 1500. Thank you, John From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 04:00:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC3D81065679 for ; Wed, 30 Jul 2008 04:00:06 +0000 (UTC) (envelope-from freebsd@chrisbuechler.com) Received: from mail.livebsd.com (mail.livebsd.com [69.64.6.14]) by mx1.freebsd.org (Postfix) with SMTP id 86BAB8FC0C for ; Wed, 30 Jul 2008 04:00:06 +0000 (UTC) (envelope-from freebsd@chrisbuechler.com) Received: (qmail 9449 invoked by uid 89); 30 Jul 2008 03:32:03 -0000 Received: from unknown (HELO ?10.0.64.15?) (74.130.92.110) by 172.29.29.14 with SMTP; 30 Jul 2008 03:32:03 -0000 Message-ID: <488FE0B3.4070400@chrisbuechler.com> Date: Tue, 29 Jul 2008 23:32:03 -0400 From: Chris Buechler User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20080729114237.45525xviqzjqf9nh@www.publicmx.com> <488F8060.70600@freebsd.org> In-Reply-To: <488F8060.70600@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ath using hostap sets MTU to 2290 / channel '0' no longer works X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 04:00:06 -0000 Sam Leffler wrote: > John T. Yocum wrote: >> Hello, >> >> I have a system running pfSense, which is built on top of FreeBSD >> 7.0-RELEASE-p3. In the system I have an Atheros wireless card, which >> when I enable hostap, changes it's MTU to 2290. If an explanation is >> listed on a man page, I apologize, I did try searching. >> >> Any ideas why this might happen? It doesn't appear to be a pfSense >> issue, as it appears their code actually tries to set the MTU to 1500. >> >> Only reason I ask here, is I noticed in my searching on Google, I >> noticed others that aren't running pfSense have their MTU set to 2290. > MTU on an 802.11 network is 2290. If you don't want the default then > change it. If you cannot then please provide the exact steps you take > that do not work. Thanks for the reply, Sam! I have an ath card I'm working with that sets its MTU to 1500 in hostap, so there seems to be inconsistent behavior here. This card, specifically: http://www.netgate.com/product_info.php?products_id=130 We added a forced MTU of 1500 to wireless cards in pfSense (as a stop gap testing measure since they're frequently bridged to Ethernet and the bridge won't work unless the wireless card is 1500), but it still appears to revert to 2290 for people. I haven't had time to fully quantify this, and I can't replicate it with the hardware I have at hand as it uses 1500 without specifying any MTU. If I can come up with better info and steps to replicate, I'll post back. While I have your attention, we have found one change in behavior between 6.x and 7.0. I'm not sure if it's a regression or intentional, any insight would be appreciated. "ifconfig ath0 channel '0'" used to work in 6.x with hostap mode. Now users are finding their AP does not show up unless they manually specify a channel. Running that command shows: # ifconfig ath0 channel '0' ifconfig: unknown/undefined channel number 0 flags 0x0 At boot time when the above is set, I get (dmesg|grep ath0): Jul 27 18:24:44 pfSense kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) Jul 27 18:24:44 pfSense kernel: ath0: mem 0x88010000-0x8801ffff irq 10 at device 0.0 on cardbus1 Jul 27 18:24:44 pfSense kernel: ath0: [ITHREAD] Jul 27 18:24:44 pfSense kernel: ath0: using obsoleted if_watchdog interface Jul 27 18:24:44 pfSense kernel: ath0: Ethernet address: 00:0b:6b:20:3a:4d Jul 27 18:24:44 pfSense kernel: ath0: mac 5.9 phy 4.3 radio 3.6 Jul 27 18:24:47 pfSense kernel: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal flags 0x150) Jul 27 18:24:47 pfSense kernel: ath0: unable to reset hardware; hal status 0 The above was also seen by a pfSense user with a different ath card, miniPCI I believe. Numerous people have reported that "auto" channel (what our GUI translates to channel 0 in ifconfig) no longer works with ath cards on 7.0-based versions when they were working fine previously on 6.2 and 6.3-based versions. The ifconfig man page mentions using channel - or any should do the same as 0. Both of those do not produce any error messages (they return no output), but the AP still isn't visible. I haven't confirmed this part, but I believe running ifconfig ath0 down / ifconfig ath0 up after running either channel - or channel 'any' will make it work. Not sure on behavior at boot time. I tested an old wi(4) card with channel '0' and it still works the same as in 6.x. I was waiting to post until I had time to gather more definitive information but since someone else brought it up, thought I'd add to it. If I can help gather any additional information please let me know. thanks, Chris From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 06:05:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5694A106567F for ; Wed, 30 Jul 2008 06:05:04 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by mx1.freebsd.org (Postfix) with ESMTP id E06AB8FC0A for ; Wed, 30 Jul 2008 06:05:03 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so357454fkk.11 for ; Tue, 29 Jul 2008 23:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=A5LJ5E0fMc3+znjy9DcRDfUoZ+PEAUu37aJY3JcAYwo=; b=CuqTF3qYZXyvO/6MMST08YeecRGCiy67/T1BAAvXwbelksHdznPWPaHRG02abv5KmW R/ZJWe5EqTd2Zc61VKnCXlcs+rUF6ymK9osMU36N9QRLX8u7nqWjHedQ+dHPdcc7eeo+ cJ1YH8kyQKC4K0aRfqyANSI5zU07iJzHrtwgM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=xNzRJGpLSR8UayRV15/1/0/pa0YCet4gXGPjtL7OUHDU65YrIsm0g57gXfUb0i1OKZ sPzX2QtmwlCcKzgNOyuLS6nH8S1tUifaeLWGjtWgUIyQ9+fTDQgSOIbl2FxDW067yaQS aiJAQ3uD4SNbnoyII4WteM2rrWTWaSzmNhKuk= Received: by 10.125.159.1 with SMTP id l1mr410857mko.139.1217397902167; Tue, 29 Jul 2008 23:05:02 -0700 (PDT) Received: by 10.125.139.12 with HTTP; Tue, 29 Jul 2008 23:05:02 -0700 (PDT) Message-ID: <3c1674c90807292305kd1b0413w16ca1542b7d1a95b@mail.gmail.com> Date: Tue, 29 Jul 2008 23:05:02 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: jfv@gmail.com, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 5088e29b01908ad5 Cc: Subject: fix for ixgbe to use non-power-of-2 number of rx queues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 06:05:04 -0000 Unless anyone complains I intend to commit the following change to HEAD. It makes it possible to use an arbitrary number of rx queues up to the maximum allowed by hardware. The current driver only allows 1, 2, 4, or 8. http://www.fsmware.com/ixgbe.diff From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 12:32:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DEDB106566C for ; Wed, 30 Jul 2008 12:32:55 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 315B18FC1D for ; Wed, 30 Jul 2008 12:32:55 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so54360ywe.13 for ; Wed, 30 Jul 2008 05:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:message-id :in-reply-to:references:date:subject:from:to:cc:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance:sender; bh=uEG+Cbbv5xDVrs6D0u966JeB7SiGB4EiO4LZRPVybcw=; b=mS9m+FiDY69JlhgF3BWDvCy+QXqK4kJ3Hfy3Dl3we8yFSuQdqzxZ46HEEwm2NLdNdH 4ENsvzPfeawsj5afQvBhqfGcApF0h/3tWbTf3aNBKWxEYAFW+l1C6tBs+tl1vrTI34dY CvqHC/kftB9VU8ss0pOKyvO1qqObVSOQdHo/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:in-reply-to:references:date:subject:from:to:cc :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance:sender; b=T/ztxnFzNCrZZtdfmIT9JprR2rCdfJDoewfJi52cdm3Rtd3ud8oVaT2jodOHqrBv/L mv8xwLvyuyPIjTttlgBfvd3a7rxq4mwb7TCssVZX4FpVeNGCz7HhpiEUCr8v3GHEleh/ pauQhbDscZNkmfRZ0WBuUQRaHnZJAFXPjLn4c= Received: by 10.114.193.1 with SMTP id q1mr8243027waf.70.1217419538961; Wed, 30 Jul 2008 05:05:38 -0700 (PDT) Received: from cygnus.homeunix.com ( [189.71.70.196]) by mx.google.com with ESMTPS id 6sm1718487ywi.1.2008.07.30.05.05.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 30 Jul 2008 05:05:38 -0700 (PDT) Received: by cygnus.homeunix.com (Postfix, from userid 80) id 7CC08141; Wed, 30 Jul 2008 09:05:33 -0300 (BRT) Received: from 200.252.157.118 (proxying for 10.12.1.211, 10.12.1.3) (SquirrelMail authenticated user matheus@eternamente.info) by cygnus.homeunix.com with HTTP; Wed, 30 Jul 2008 09:05:33 -0300 (BRT) Message-ID: In-Reply-To: <488FE0B3.4070400@chrisbuechler.com> References: <20080729114237.45525xviqzjqf9nh@www.publicmx.com> <488F8060.70600@freebsd.org> <488FE0B3.4070400@chrisbuechler.com> Date: Wed, 30 Jul 2008 09:05:33 -0300 (BRT) From: "Nenhum_de_Nos" To: "Chris Buechler" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: Nenhum_de_Nos Cc: freebsd-net@freebsd.org Subject: Re: ath using hostap sets MTU to 2290 / channel '0' no longer works X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 12:32:55 -0000 On Wed, July 30, 2008 00:32, Chris Buechler wrote: > Sam Leffler wrote: >> John T. Yocum wrote: >>> Hello, >>> >>> I have a system running pfSense, which is built on top of FreeBSD >>> 7.0-RELEASE-p3. In the system I have an Atheros wireless card, which >>> when I enable hostap, changes it's MTU to 2290. If an explanation is >>> listed on a man page, I apologize, I did try searching. >>> >>> Any ideas why this might happen? It doesn't appear to be a pfSense >>> issue, as it appears their code actually tries to set the MTU to 1500. >>> >>> Only reason I ask here, is I noticed in my searching on Google, I >>> noticed others that aren't running pfSense have their MTU set to 2290. >> MTU on an 802.11 network is 2290. If you don't want the default then >> change it. If you cannot then please provide the exact steps you take >> that do not work. > > Thanks for the reply, Sam! > > I have an ath card I'm working with that sets its MTU to 1500 in hostap, > so there seems to be inconsistent behavior here. This card, specifically: > http://www.netgate.com/product_info.php?products_id=130 > > We added a forced MTU of 1500 to wireless cards in pfSense (as a stop > gap testing measure since they're frequently bridged to Ethernet and the > bridge won't work unless the wireless card is 1500), but it still > appears to revert to 2290 for people. > > I haven't had time to fully quantify this, and I can't replicate it with > the hardware I have at hand as it uses 1500 without specifying any MTU. > If I can come up with better info and steps to replicate, I'll post back. > > While I have your attention, we have found one change in behavior > between 6.x and 7.0. I'm not sure if it's a regression or intentional, > any insight would be appreciated. "ifconfig ath0 channel '0'" used to > work in 6.x with hostap mode. Now users are finding their AP does not > show up unless they manually specify a channel. Running that command > shows: > > # ifconfig ath0 channel '0' > ifconfig: unknown/undefined channel number 0 flags 0x0 > > At boot time when the above is set, I get (dmesg|grep ath0): > Jul 27 18:24:44 pfSense kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, > AR5212, RF5111, RF5112, RF2413, RF5413) > Jul 27 18:24:44 pfSense kernel: ath0: mem > 0x88010000-0x8801ffff irq 10 at device 0.0 on cardbus1 > Jul 27 18:24:44 pfSense kernel: ath0: [ITHREAD] > Jul 27 18:24:44 pfSense kernel: ath0: using obsoleted if_watchdog > interface > Jul 27 18:24:44 pfSense kernel: ath0: Ethernet address: 00:0b:6b:20:3a:4d > Jul 27 18:24:44 pfSense kernel: ath0: mac 5.9 phy 4.3 radio 3.6 > Jul 27 18:24:47 pfSense kernel: ath0: ath_chan_set: unable to reset > channel 6 (2437 Mhz, flags 0x490 hal flags 0x150) > Jul 27 18:24:47 pfSense kernel: ath0: unable to reset hardware; hal status > 0 > > The above was also seen by a pfSense user with a different ath card, > miniPCI I believe. Numerous people have reported that "auto" channel > (what our GUI translates to channel 0 in ifconfig) no longer works with > ath cards on 7.0-based versions when they were working fine previously > on 6.2 and 6.3-based versions. > > The ifconfig man page mentions using channel - or any should do the same > as 0. Both of those do not produce any error messages (they return no > output), but the AP still isn't visible. I haven't confirmed this part, > but I believe running ifconfig ath0 down / ifconfig ath0 up after > running either channel - or channel 'any' will make it work. Not sure on > behavior at boot time. > > I tested an old wi(4) card with channel '0' and it still works the same > as in 6.x. > > I was waiting to post until I had time to gather more definitive > information but since someone else brought it up, thought I'd add to it. > If I can help gather any additional information please let me know. > > thanks, > Chris > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" [matheus@xxx /usr/home/matheus]$ dmesg | grep ath0 ath0: mem 0xec1f0000-0xec1fffff irq 16 at device 8.0 on pci0 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: xx:xx:xx:xx:xx:xx ath0: mac 7.9 phy 4.5 radio 5.6 [matheus@xxx /usr/home/matheus]$ and I need to make it use 1500, this is set on local.sh: /sbin/ifconfig ath0 mtu 1500 mediaopt hostap what I have in this box is: interrupt storm detected on "irq16:"; throttling interrupt source on the atheros card irq. every single reboot :( sometimes when heavily used the wlan dies, usually the atheros based freebsd-7 notebook kills this ap. need a hostapd restart to go back to normal. matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 12:40:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DBCE106567F for ; Wed, 30 Jul 2008 12:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 33E0A8FC1D for ; Wed, 30 Jul 2008 12:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6UCe3i1063650 for ; Wed, 30 Jul 2008 12:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6UCe3mM063649; Wed, 30 Jul 2008 12:40:03 GMT (envelope-from gnats) Date: Wed, 30 Jul 2008 12:40:03 GMT Message-Id: <200807301240.m6UCe3mM063649@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Mark Willson Cc: Subject: Re: kern/112179: [sis] [patch] sis driver for natsemi DP83815D autonegotiate failure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Willson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 12:40:04 -0000 The following reply was made to PR kern/112179; it has been noted by GNATS. From: Mark Willson To: bug-followup@FreeBSD.org, jhb@FreeBSD.org Cc: phk@FreeBSD.org Subject: Re: kern/112179: [sis] [patch] sis driver for natsemi DP83815D autonegotiate failure Date: Wed, 30 Jul 2008 13:04:59 +0100 (BST) > From: John Baldwin > Subject: Re: kern/112179: [sis] [patch] sis driver for natsemi DP83815D > autonegotiate failure > Date: Tue, 29 Jul 2008 11:56:38 -0400 > Cc: phk@FreeBSD.org > > How about the patch below. This makes the driver match the behavior of the > Linux driver (and also fixes a harmless weirdness phk@ introduced.. I think > because he thought SIS_SETBIT was CSR_WRITE_4 rather than a RMW op). > > Index: if_sis.c > =================================================================== > --- if_sis.c (revision 180877) > +++ if_sis.c (working copy) > @@ -1904,14 +1904,15 @@ > if (sc->sis_type == SIS_TYPE_83815 && sc->sis_srr <= NS_SRR_15D) { > CSR_WRITE_4(sc, NS_PHY_PAGE, 0x0001); > CSR_WRITE_4(sc, NS_PHY_CR, 0x189C); > - if (sc->sis_srr == NS_SRR_15C) { > - /* set val for c2 */ > - CSR_WRITE_4(sc, NS_PHY_TDATA, 0x0000); > + /* set val for c2 */ > + CSR_WRITE_4(sc, NS_PHY_TDATA, 0x0000); > + if (sc->sis_srr <= NS_SRR_15C) > /* load/kill c2 */ > CSR_WRITE_4(sc, NS_PHY_DSPCFG, 0x5040); > - /* rais SD off, from 4 to c */ > - CSR_WRITE_4(sc, NS_PHY_SDCFG, 0x008C); > - } > + else > + SIS_SETBIT(sc, NS_PHY_DSPCFG, 0x1000); > + /* rais SD off, from 4 to c */ > + CSR_WRITE_4(sc, NS_PHY_SDCFG, 0x008C); > CSR_WRITE_4(sc, NS_PHY_PAGE, 0); > } > > @@ -2011,12 +2012,11 @@ > CSR_WRITE_4(sc, NS_PHY_DSPCFG, reg | 0x1000); > DELAY(100000); > reg = CSR_READ_4(sc, NS_PHY_TDATA) & 0xff; > - if ((reg & 0x0080) == 0 || (reg > 0xd8 && reg <= 0xff)) { > + if ((reg & 0x0080) == 0 || (reg >= 0xd8 && reg <= 0xff)) { > device_printf(sc->sis_dev, > "Applying short cable fix (reg=%x)\n", reg); > CSR_WRITE_4(sc, NS_PHY_TDATA, 0x00e8); > - reg = CSR_READ_4(sc, NS_PHY_DSPCFG); > - SIS_SETBIT(sc, NS_PHY_DSPCFG, reg | 0x20); > + SIS_SETBIT(sc, NS_PHY_DSPCFG, 0x20); > } > CSR_WRITE_4(sc, NS_PHY_PAGE, 0); > } > John, Thanks for the patch. I tried it out on my system, but it did not fix the problem. However, if I make a small change, it works fine. It seems the call "CSR_WRITE_4(sc, NS_PHY_DSPCFG, 0x5040);" is necessary for the NS_SRR_15D revision of the card. Here's the modified patch: --- if_sis.c.orig 2008-07-30 11:04:53.000000000 +0100 +++ if_sis.c 2008-07-30 11:08:15.000000000 +0100 @@ -1904,14 +1904,14 @@ if (sc->sis_type == SIS_TYPE_83815 && sc->sis_srr <= NS_SRR_15D) { CSR_WRITE_4(sc, NS_PHY_PAGE, 0x0001); CSR_WRITE_4(sc, NS_PHY_CR, 0x189C); - if (sc->sis_srr == NS_SRR_15C) { - /* set val for c2 */ - CSR_WRITE_4(sc, NS_PHY_TDATA, 0x0000); - /* load/kill c2 */ - CSR_WRITE_4(sc, NS_PHY_DSPCFG, 0x5040); - /* rais SD off, from 4 to c */ - CSR_WRITE_4(sc, NS_PHY_SDCFG, 0x008C); - } + /* set val for c2 */ + CSR_WRITE_4(sc, NS_PHY_TDATA, 0x0000); + /* load/kill c2 */ + CSR_WRITE_4(sc, NS_PHY_DSPCFG, 0x5040); + if (sc->sis_srr > NS_SRR_15C) + SIS_SETBIT(sc, NS_PHY_DSPCFG, 0x1000); + /* rais SD off, from 4 to c */ + CSR_WRITE_4(sc, NS_PHY_SDCFG, 0x008C); CSR_WRITE_4(sc, NS_PHY_PAGE, 0); } @@ -2011,12 +2011,11 @@ CSR_WRITE_4(sc, NS_PHY_DSPCFG, reg | 0x1000); DELAY(100000); reg = CSR_READ_4(sc, NS_PHY_TDATA) & 0xff; - if ((reg & 0x0080) == 0 || (reg > 0xd8 && reg <= 0xff)) { + if ((reg & 0x0080) == 0 || (reg >= 0xd8 && reg <= 0xff)) { device_printf(sc->sis_dev, "Applying short cable fix (reg=%x)\n", reg); CSR_WRITE_4(sc, NS_PHY_TDATA, 0x00e8); - reg = CSR_READ_4(sc, NS_PHY_DSPCFG); - SIS_SETBIT(sc, NS_PHY_DSPCFG, reg | 0x20); + SIS_SETBIT(sc, NS_PHY_DSPCFG, 0x20); } CSR_WRITE_4(sc, NS_PHY_PAGE, 0); } -mark From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 16:14:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6FA81065671 for ; Wed, 30 Jul 2008 16:14:31 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 96A828FC18 for ; Wed, 30 Jul 2008 16:14:31 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m6UGEQPd099060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 09:14:26 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <48909361.2070406@freebsd.org> Date: Wed, 30 Jul 2008 09:14:25 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Chris Buechler References: <20080729114237.45525xviqzjqf9nh@www.publicmx.com> <488F8060.70600@freebsd.org> <488FE0B3.4070400@chrisbuechler.com> In-Reply-To: <488FE0B3.4070400@chrisbuechler.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org Subject: Re: ath using hostap sets MTU to 2290 / channel '0' no longer works X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 16:14:31 -0000 Chris Buechler wrote: > Sam Leffler wrote: >> John T. Yocum wrote: >>> Hello, >>> >>> I have a system running pfSense, which is built on top of FreeBSD >>> 7.0-RELEASE-p3. In the system I have an Atheros wireless card, which >>> when I enable hostap, changes it's MTU to 2290. If an explanation is >>> listed on a man page, I apologize, I did try searching. >>> >>> Any ideas why this might happen? It doesn't appear to be a pfSense >>> issue, as it appears their code actually tries to set the MTU to 1500. >>> >>> Only reason I ask here, is I noticed in my searching on Google, I >>> noticed others that aren't running pfSense have their MTU set to 2290. >> MTU on an 802.11 network is 2290. If you don't want the default then >> change it. If you cannot then please provide the exact steps you >> take that do not work. > > Thanks for the reply, Sam! > I have an ath card I'm working with that sets its MTU to 1500 in > hostap, so there seems to be inconsistent behavior here. This card, > specifically: > http://www.netgate.com/product_info.php?products_id=130 No ath card sets an mtu; this is done in s/w in the host. > > We added a forced MTU of 1500 to wireless cards in pfSense (as a stop > gap testing measure since they're frequently bridged to Ethernet and > the bridge won't work unless the wireless card is 1500), but it still > appears to revert to 2290 for people. I cannot help w/ an issue unless I can reproduce it. The above does not help me. As I said previously when a card is attached to the system (e.g. on boot or card insert) the default mtu setup is 2290. If it changes at a later then some program is doing it. This is on RELENG_7 and later. > > I haven't had time to fully quantify this, and I can't replicate it > with the hardware I have at hand as it uses 1500 without specifying > any MTU. If I can come up with better info and steps to replicate, > I'll post back. > > While I have your attention, we have found one change in behavior > between 6.x and 7.0. I'm not sure if it's a regression or intentional, > any insight would be appreciated. "ifconfig ath0 channel '0'" used to > work in 6.x with hostap mode. Now users are finding their AP does not > show up unless they manually specify a channel. Running that command > shows: > > # ifconfig ath0 channel '0' > ifconfig: unknown/undefined channel number 0 flags 0x0 > > At boot time when the above is set, I get (dmesg|grep ath0): > Jul 27 18:24:44 pfSense kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, > AR5212, RF5111, RF5112, RF2413, RF5413) > Jul 27 18:24:44 pfSense kernel: ath0: mem > 0x88010000-0x8801ffff irq 10 at device 0.0 on cardbus1 > Jul 27 18:24:44 pfSense kernel: ath0: [ITHREAD] > Jul 27 18:24:44 pfSense kernel: ath0: using obsoleted if_watchdog > interface > Jul 27 18:24:44 pfSense kernel: ath0: Ethernet address: 00:0b:6b:20:3a:4d > Jul 27 18:24:44 pfSense kernel: ath0: mac 5.9 phy 4.3 radio 3.6 > Jul 27 18:24:47 pfSense kernel: ath0: ath_chan_set: unable to reset > channel 6 (2437 Mhz, flags 0x490 hal flags 0x150) > Jul 27 18:24:47 pfSense kernel: ath0: unable to reset hardware; hal > status 0 > > The above was also seen by a pfSense user with a different ath card, > miniPCI I believe. Numerous people have reported that "auto" channel > (what our GUI translates to channel 0 in ifconfig) no longer works > with ath cards on 7.0-based versions when they were working fine > previously on 6.2 and 6.3-based versions. Use ifconfig ath0 channel - (or any) to clear any locked channel. This is in fact a change; never noticed before. I can either change the man page or try to hack ifconfig but I'd prefer to just deprecate the use of "0". > > The ifconfig man page mentions using channel - or any should do the > same as 0. Both of those do not produce any error messages (they > return no output), but the AP still isn't visible. I haven't confirmed > this part, but I believe running ifconfig ath0 down / ifconfig ath0 up > after running either channel - or channel 'any' will make it work. Not > sure on behavior at boot time. When you clear the locked down channel the device should scan. You can observe this by monitoring state w/ ifconfig or enable debug msgs with wlandebug scan+state. > > I tested an old wi(4) card with channel '0' and it still works the > same as in 6.x. 6.x and 7.x are very different systems and wi is not a good indicator of changes in the system. > > I was waiting to post until I had time to gather more definitive > information but since someone else brought it up, thought I'd add to > it. If I can help gather any additional information please let me know. I'll fix the man page at least right now; thanks. Sam From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 16:16:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B03A4106566B for ; Wed, 30 Jul 2008 16:16:27 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 7B4BA8FC0C for ; Wed, 30 Jul 2008 16:16:27 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from [172.16.151.53] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id 0C4E411BC48 for ; Wed, 30 Jul 2008 18:00:12 +0200 (CEST) Message-ID: <48909009.1070805@fsn.hu> Date: Wed, 30 Jul 2008 18:00:09 +0200 From: Attila Nagy User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: SO_BINDANY and pf divert X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 16:16:27 -0000 Hello, OpenBSD's relayd has grown a very useful transparent relay support, which means you can run a HTTP(S) reverse proxy transparently (maintaining the source IP, while you have a different TCP stream open from the proxy to the backend, even by terminating the SSL part and speaking clear text HTTP to the backends). For this (as far as I could figure out, while trying to make this newer relayd working on FreeBSD) two pieces are needed, which FreeBSD currently lacks: - the SO_BINDANY support (see http://marc.info/?l=openbsd-cvs&m=121030159009823&w=2 and http://www.openbsd.org/cgi-bin/man.cgi?query=setsockopt) - the pf part, which diverts the non-local packets to the given socket (see http://marc.info/?l=openbsd-cvs&m=121030115209292&w=2 and http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf) After having those said, the question is obvious. :) Does anybody feel the need for these two in FreeBSD and have the competence and time to port them? Thanks, From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 17:32:07 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20CDB10656DF; Wed, 30 Jul 2008 17:32:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F0B0B8FC1D; Wed, 30 Jul 2008 17:32:06 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (jhb@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6UHW6Q1093529; Wed, 30 Jul 2008 17:32:06 GMT (envelope-from jhb@freefall.freebsd.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6UHW6Np093525; Wed, 30 Jul 2008 17:32:06 GMT (envelope-from jhb) Date: Wed, 30 Jul 2008 17:32:06 GMT Message-Id: <200807301732.m6UHW6Np093525@freefall.freebsd.org> To: mark@hydrus.org.uk, jhb@FreeBSD.org, freebsd-net@FreeBSD.org, jhb@FreeBSD.org From: jhb@FreeBSD.org Cc: Subject: Re: kern/112179: [sis] [patch] sis driver for natsemi DP83815D autonegotiate failure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 17:32:07 -0000 Synopsis: [sis] [patch] sis driver for natsemi DP83815D autonegotiate failure State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Wed Jul 30 17:31:15 UTC 2008 State-Changed-Why: I've committed the original patch (more or less) and will MFC it in a week or so. Responsible-Changed-From-To: freebsd-net->jhb Responsible-Changed-By: jhb Responsible-Changed-When: Wed Jul 30 17:31:15 UTC 2008 Responsible-Changed-Why: I've committed the original patch (more or less) and will MFC it in a week or so. http://www.freebsd.org/cgi/query-pr.cgi?pr=112179 From owner-freebsd-net@FreeBSD.ORG Wed Jul 30 21:44:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B97C106567A for ; Wed, 30 Jul 2008 21:44:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 8ABF58FC1F for ; Wed, 30 Jul 2008 21:44:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 27295249F; Wed, 30 Jul 2008 14:44:13 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 3147C2D60F1; Wed, 30 Jul 2008 14:44:12 -0700 (PDT) Message-ID: <4890E0C0.1070208@elischer.org> Date: Wed, 30 Jul 2008 14:44:32 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Attila Nagy References: <48909009.1070805@fsn.hu> In-Reply-To: <48909009.1070805@fsn.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: SO_BINDANY and pf divert X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 21:44:12 -0000 Attila Nagy wrote: > Hello, > > OpenBSD's relayd has grown a very useful transparent relay support, > which means you can run a HTTP(S) reverse proxy transparently > (maintaining the source IP, while you have a different TCP stream open > from the proxy to the backend, even by terminating the SSL part and > speaking clear text HTTP to the backends). > > For this (as far as I could figure out, while trying to make this newer > relayd working on FreeBSD) two pieces are needed, which FreeBSD > currently lacks: > - the SO_BINDANY support (see > http://marc.info/?l=openbsd-cvs&m=121030159009823&w=2 and > http://www.openbsd.org/cgi-bin/man.cgi?query=setsockopt) > - the pf part, which diverts the non-local packets to the given socket > (see http://marc.info/?l=openbsd-cvs&m=121030115209292&w=2 and > http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf) well, ipfw can do that. > > After having those said, the question is obvious. :) > Does anybody feel the need for these two in FreeBSD and have the > competence and time to port them? > > Thanks, > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 09:56:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42BFE106564A for ; Thu, 31 Jul 2008 09:56:33 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from dire.wubethiopia.com (j071.v.rootbsd.net [208.79.82.223]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7278FC15 for ; Thu, 31 Jul 2008 09:56:32 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from rogue.mike.lan (unknown [213.55.88.225]) by dire.wubethiopia.com (Postfix) with ESMTPSA id A17FB4FD990C for ; Thu, 31 Jul 2008 09:56:29 +0000 (UTC) Message-ID: <48918DB5.7020201@wubethiopia.com> Date: Thu, 31 Jul 2008 13:02:29 +0300 From: Mike Makonnen User-Agent: Thunderbird 2.0.0.12 (X11/20080323) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2008 09:56:33 -0000 Hi, An Internet Cafe I do some work for was recently having problems with very slow internet access. It turns out customers were running P2P file sharing applications which were hogging all the bandwidth. I looked for programs that would allow me to shape traffic according to the application layer protocol, but couldn't find any for FreeBSD. I found a couple: l7-filter and ipp2p, but these are Linux specific. So, I decided to write one. The result is ipfw-classifyd : http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 As the name implies it uses ipfw(4) to implement a userland daemon that classifies TCP and UDP packets according to regular expression patterns for various protocols. It's intended to be used with divert(4) sockets and dummynet(4) so you can do traffic shaping depending on the application level protocol. The protocol patterns are from the l7-filter project. Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It reads its configuration file for a list of protocols and ipfw(8) rules. Then, when it detects a matching session it re-injects the packet back at the specified rule number. The tarball has a sample configuration file and firewall script to get you started. While I have not done extensive testing, preliminary tests are encouraging and it seems to work, so I thought I'd announce it to the rest of the world in case anyone else is interested in this kind of application. Comments and suggestions highly appreciated. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 10:49:18 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 533CC106568D for ; Thu, 31 Jul 2008 10:49:18 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.freebsd.org (Postfix) with ESMTP id 166FB8FC22 for ; Thu, 31 Jul 2008 10:49:18 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from southcross.wired.org (host-84-221-82-250.cust-adsl.tiscali.it [84.221.82.250]) by mail.oltrelinux.com (Postfix) with SMTP id 9B26111B1F5 for ; Thu, 31 Jul 2008 12:17:51 +0200 (CEST) Received: (qmail 32770 invoked by uid 1001); 31 Jul 2008 12:21:16 +0200 Date: Thu, 31 Jul 2008 12:21:16 +0200 From: Paolo Pisati To: Mike Makonnen Message-ID: <20080731102116.GA32671@tin.it> References: <48918DB5.7020201@wubethiopia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48918DB5.7020201@wubethiopia.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: freebsd-net@FreeBSD.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2008 10:49:18 -0000 On Thu, Jul 31, 2008 at 01:02:29PM +0300, Mike Makonnen wrote: > > While I have not done extensive testing, preliminary tests are encouraging > and it seems to work, so I thought I'd announce it to the rest of the world > in case anyone else is interested in this kind of application. That's a much needed addition to ipfw and FreeBSD in general, thanks for the hard work. -- bye, P. From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 11:19:24 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D3C9106566C for ; Thu, 31 Jul 2008 11:19:24 +0000 (UTC) (envelope-from lstewart@room52.net) Received: from outbound.icp-qv1-irony-out2.iinet.net.au (outbound.icp-qv1-irony-out2.iinet.net.au [203.59.1.107]) by mx1.freebsd.org (Postfix) with ESMTP id BEB698FC12 for ; Thu, 31 Jul 2008 11:19:23 +0000 (UTC) (envelope-from lstewart@room52.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAFY1kUh8qG0B/2dsb2JhbACLHqYq X-IronPort-AV: E=Sophos;i="4.31,285,1215360000"; d="scan'208";a="348552249" Received: from unknown (HELO lawrence1.loshell.room52.net) ([124.168.109.1]) by outbound.icp-qv1-irony-out2.iinet.net.au with ESMTP; 31 Jul 2008 18:49:43 +0800 Message-ID: <489198C6.9060409@room52.net> Date: Thu, 31 Jul 2008 20:49:42 +1000 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.14 (X11/20080703) MIME-Version: 1.0 To: Mike Makonnen References: <48918DB5.7020201@wubethiopia.com> In-Reply-To: <48918DB5.7020201@wubethiopia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2008 11:19:24 -0000 Hi Mike, Mike Makonnen wrote: [snip] > sharing applications which were hogging all the bandwidth. I looked for > programs that would allow me to shape traffic according to the > application layer protocol, but couldn't find any for FreeBSD. I found a > couple: l7-filter and ipp2p, but these are Linux specific. So, I decided > to write one. The result is ipfw-classifyd : > http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 [snip] Unfortunately, I suspect you should have looked a bit harder: Bro (http://www.bro-ids.org/) or Snort (http://www.snort.org/), both of which are in the FreeBSD ports tree, would have saved you from reinventing the wheel. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 12:30:08 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 872101065674 for ; Thu, 31 Jul 2008 12:30:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7B0C48FC1F for ; Thu, 31 Jul 2008 12:30:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6VCU8ZS032014 for ; Thu, 31 Jul 2008 12:30:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6VCU8mi032011; Thu, 31 Jul 2008 12:30:08 GMT (envelope-from gnats) Date: Thu, 31 Jul 2008 12:30:08 GMT Message-Id: <200807311230.m6VCU8mi032011@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: sam Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sam List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2008 12:30:08 -0000 The following reply was made to PR kern/124127; it has been noted by GNATS. From: sam To: bug-followup@FreeBSD.org, skylord@linkline.ru Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Thu, 31 Jul 2008 16:00:19 +0400 ----------------------------------------------- Jul 30 11:13:47 moon3 kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering Jul 30 11:14:44 moon3 kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering ----------------------------------------------- ----------------------------------------------- Jul 29 23:18:28 moon3 kernel: mskc0: port 0xdf00-0xdfff mem 0xdeefc000-0xdeefffff irq 16 at device 0.0 on pci2 Jul 29 23:18:28 moon3 kernel: msk0: on mskc0 Jul 29 23:18:28 moon3 kernel: miibus0: on msk0 ----------------------------------------------- ----------------------------------------------- FreeBSD moon3 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #5: Wed Jul 27 15:00:14 MSD 2008 root@moon3:/usr/src/sys/i386/compile/MOON3 i386 ----------------------------------------------- I confirm this problem. /Vladimir Ermakov From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 13:04:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6B32106567F for ; Thu, 31 Jul 2008 13:04:58 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from dire.wubethiopia.com (j071.v.rootbsd.net [208.79.82.223]) by mx1.freebsd.org (Postfix) with ESMTP id B421D8FC12 for ; Thu, 31 Jul 2008 13:04:58 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from rogue.mike.lan (unknown [213.55.86.59]) by dire.wubethiopia.com (Postfix) with ESMTPSA id 06EF24FD990C; Thu, 31 Jul 2008 13:04:32 +0000 (UTC) Message-ID: <4891B992.3040204@wubethiopia.com> Date: Thu, 31 Jul 2008 16:09:38 +0300 From: Mike Makonnen User-Agent: Thunderbird 2.0.0.12 (X11/20080323) MIME-Version: 1.0 To: Lawrence Stewart References: <48918DB5.7020201@wubethiopia.com> <489198C6.9060409@room52.net> In-Reply-To: <489198C6.9060409@room52.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2008 13:04:58 -0000 Lawrence Stewart wrote: > Hi Mike, > > Mike Makonnen wrote: > > [snip] > >> sharing applications which were hogging all the bandwidth. I looked >> for programs that would allow me to shape traffic according to the >> application layer protocol, but couldn't find any for FreeBSD. I >> found a couple: l7-filter and ipp2p, but these are Linux specific. >> So, I decided to write one. The result is ipfw-classifyd : >> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 > > [snip] > > Unfortunately, I suspect you should have looked a bit harder: Bro > (http://www.bro-ids.org/) or Snort (http://www.snort.org/), both of > which are in the FreeBSD ports tree, would have saved you from > reinventing the wheel. > I'm not sure they have the exact type of wheel I'm looking for :-). My understanding is that their primary function is Intrusion Detection, not traffic shaping. To use them as traffic shapers would require extra work on the sysadmin's part (scripts and other types of scotch tape). Am I wrong? The ipfw-classifyd daemon, on the other hand, works directly with ipfw(4). I suspect that for traffic shaping using ipfw-classifyd would require a lot less effort than using either of the above solutions. At the very least it's an additional tool in the FreeBSD sysadmin's arsenal. BTW, my motivation for writing this program wasn't because there were no other tools that did this (as I mentioned I had already found Linux tools that would do this), but because I wanted a solution that uses FreeBSD and is BSD licensed :-) Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 13:45:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7452C106567F for ; Thu, 31 Jul 2008 13:45:42 +0000 (UTC) (envelope-from lstewart@room52.net) Received: from outbound.icp-qv1-irony-out3.iinet.net.au (outbound.icp-qv1-irony-out3.iinet.net.au [203.59.1.148]) by mx1.freebsd.org (Postfix) with ESMTP id F13DD8FC17 for ; Thu, 31 Jul 2008 13:45:41 +0000 (UTC) (envelope-from lstewart@room52.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEABZckUh8qG0B/2dsb2JhbACLHqZC X-IronPort-AV: E=Sophos;i="4.31,286,1215360000"; d="scan'208";a="296328939" Received: from unknown (HELO lawrence1.loshell.room52.net) ([124.168.109.1]) by outbound.icp-qv1-irony-out3.iinet.net.au with ESMTP; 31 Jul 2008 21:35:35 +0800 Message-ID: <4891BFA7.4000405@room52.net> Date: Thu, 31 Jul 2008 23:35:35 +1000 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.14 (X11/20080703) MIME-Version: 1.0 To: Mike Makonnen References: <48918DB5.7020201@wubethiopia.com> <489198C6.9060409@room52.net> <4891B992.3040204@wubethiopia.com> In-Reply-To: <4891B992.3040204@wubethiopia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2008 13:45:42 -0000 Mike Makonnen wrote: > Lawrence Stewart wrote: >> Hi Mike, >> >> Mike Makonnen wrote: >> >> [snip] >> >>> sharing applications which were hogging all the bandwidth. I looked >>> for programs that would allow me to shape traffic according to the >>> application layer protocol, but couldn't find any for FreeBSD. I >>> found a couple: l7-filter and ipp2p, but these are Linux specific. >>> So, I decided to write one. The result is ipfw-classifyd : >>> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 >> >> [snip] >> >> Unfortunately, I suspect you should have looked a bit harder: Bro >> (http://www.bro-ids.org/) or Snort (http://www.snort.org/), both of >> which are in the FreeBSD ports tree, would have saved you from >> reinventing the wheel. >> > I'm not sure they have the exact type of wheel I'm looking for :-). My > understanding is that their primary function is Intrusion Detection, not > traffic shaping. To use them as traffic shapers would require extra work > on the sysadmin's part (scripts and other types of scotch tape). Am I > wrong? The ipfw-classifyd daemon, on the other hand, works directly with > ipfw(4). I suspect that for traffic shaping using ipfw-classifyd would > require a lot less effort than using either of the above solutions. At > the very least it's an additional tool in the FreeBSD sysadmin's arsenal. Yes, the IDS solutions would need to trigger some sort of script to implement the shaping once P2P traffic was detected... but I'd argue that writing those scripts would be the easy bit. The tricky thing is doing all the application layer protocol parsing and identification. This is where leveraging one of these IDS solutions makes a lot of sense... a classifier is only going to be as good as its training data and IDSs are all about good training data. All of that said, I think what you've done is neat. Perhaps you could find a way to hand off the classification decision to something like Bro so that you can utilise the existing training data and avoid having to maintain that sort of information yourself. Just thinking out loud though :) > > BTW, my motivation for writing this program wasn't because there were no > other tools that did this (as I mentioned I had already found Linux > tools that would do this), but because I wanted a solution that uses > FreeBSD and is BSD licensed :-) For the record, Bro is BSD licenced. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 15:02:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C80601065674 for ; Thu, 31 Jul 2008 15:02:14 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [201.48.151.3]) by mx1.freebsd.org (Postfix) with SMTP id 19BC18FC08 for ; Thu, 31 Jul 2008 15:02:13 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 23533 invoked from network); 31 Jul 2008 11:34:10 -0300 Received: by simscan 1.1.0 ppid: 23489, pid: 23492, t: 17.3996s scanners: clamav: 0.91.1/m: spam: 3.1.1 X-Spam-Checker-Version: SpamAssassin: -last, FreeBSD Brasil LTDA rulesets: Yes X-Spam-Status: No, hits=-1.9 required=3.7 Received: from unknown (HELO claire.bh.freebsdbrasil.com.br) (201.48.151.226) by capeta.freebsdbrasil.com.br with SMTP; 31 Jul 2008 11:33:52 -0300 Message-ID: <4891CD13.20600@freebsdbrasil.com.br> Date: Thu, 31 Jul 2008 11:32:51 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Thunderbird 2.0.0.0 (X11/20070612) MIME-Version: 1.0 To: Mike Makonnen References: <48918DB5.7020201@wubethiopia.com> In-Reply-To: <48918DB5.7020201@wubethiopia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2008 15:02:14 -0000 Mike Makonnen escreveu: > Hi, > > An Internet Cafe I do some work for was recently having problems with > very slow internet access. It turns out customers were running P2P file > sharing applications which were hogging all the bandwidth. I looked for > programs that would allow me to shape traffic according to the > application layer protocol, but couldn't find any for FreeBSD. I found a > couple: l7-filter and ipp2p, but these are Linux specific. So, I decided > to write one. The result is ipfw-classifyd : > http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 > > As the name implies it uses ipfw(4) to implement a userland daemon that > classifies TCP and UDP packets according to regular expression patterns > for various protocols. It's intended to be used with divert(4) sockets > and dummynet(4) so you can do traffic shaping depending on the > application level protocol. The protocol patterns are from the l7-filter > project. > > Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It > reads its configuration file for a list of protocols and ipfw(8) rules. > Then, when it detects a matching session it re-injects the packet back > at the specified rule number. The tarball has a sample configuration > file and firewall script to get you started. > > While I have not done extensive testing, preliminary tests are > encouraging and it seems to work, so I thought I'd announce it to the > rest of the world in case anyone else is interested in this kind of > application. > > Comments and suggestions highly appreciated. > > Cheers. Wont compile on RELENG_6 but is working perfectly on REL_7. I am trying hard with ssh, soulseek and msn. Its working like a charm with the suggested rc.firewall. I have configured ipfw-classfyd.conf changing the rules, for a number of L7 patterns, and now I try to understand why the "diverted" rules only match if the rule number is 1 after the configured, ie, I put soulseek to 65530 and a rule wont match there, but the very same rule matches 65531. I will read the code, but it seems that reinjection of the packet is made +1, correct? -- Patrick Tracanelli From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 21:09:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55C60106567D for ; Thu, 31 Jul 2008 21:09:27 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by mx1.freebsd.org (Postfix) with ESMTP id 237DF8FC19 for ; Thu, 31 Jul 2008 21:09:26 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so989184rvf.43 for ; Thu, 31 Jul 2008 14:09:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=8ikMoFcSDmvgHGRuWdtyHTc23v4+X75d4L/n5NVFfe4=; b=kelmSR4B3d0ZW2VoKV4uzqOwxRefhSNl6Y3LI+QgZlLT95ultOG1QRquDxuTAKPhrS wBcuGlbZl0niKj5NCqhLpTQ0qlKiP9nEtt+MFCJHaQOJZpqvYvR1fQnfTZ2EVXmJvG0G 5NZLhYKa+0hUugcSBsbhjxKd6u1tak0dyPDO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ulDQpSxghcOaSgzQd6yYZS6wNyixCF5OE+owM0KvJJsTzZQ6vg7y6xzMav/HD5AZ+T +IwPejlX+zESoeUL2mRP+Ls47GLYNRGiiSvUafsAJkvmiZy6lZKbkv0nufnYQs1/x/ac NtHDFcTdu0z38F9hF6lNYjzUlwsvRdI8MTMfU= Received: by 10.141.162.1 with SMTP id p1mr5521890rvo.161.1217537067458; Thu, 31 Jul 2008 13:44:27 -0700 (PDT) Received: by 10.141.128.2 with HTTP; Thu, 31 Jul 2008 13:44:27 -0700 (PDT) Message-ID: <9a542da30807311344u34422adauade5c2b62b71804a@mail.gmail.com> Date: Thu, 31 Jul 2008 22:44:27 +0200 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" To: mtm@wubethiopia.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2008 21:09:27 -0000 > Hi, > > An Internet Cafe I do some work for was recently having problems with > very slow internet access. It turns out customers were running P2P file > sharing applications which were hogging all the bandwidth. I looked for > programs that would allow me to shape traffic according to the > application layer protocol, but couldn't find any for FreeBSD. I found a > couple: l7-filter and ipp2p, but these are Linux specific. So, I decided > to write one. The result is ipfw-classifyd : > http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 > > As the name implies it uses ipfw(4) to implement a userland daemon that > classifies TCP and UDP packets according to regular expression patterns > for various protocols. It's intended to be used with divert(4) sockets > and dummynet(4) so you can do traffic shaping depending on the > application level protocol. The protocol patterns are from the l7-filter > project. > > Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It > reads its configuration file for a list of protocols and ipfw(8) rules. > Then, when it detects a matching session it re-injects the packet back > at the specified rule number. The tarball has a sample configuration > file and firewall script to get you started. > > While I have not done extensive testing, preliminary tests are > encouraging and it seems to work, so I thought I'd announce it to the > rest of the world in case anyone else is interested in this kind of > application. > > Comments and suggestions highly appreciated. Thanks for this. I have a question, you remove a flow from if you see a FIN for the TCP case and only on overlapping flow for either TCP/UDP how do the other flows expire i am missing that part? > > Cheers. > -- > Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc > mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 > FreeBSD | http://www.freebsd.org > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > -- Ermal From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 21:14:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F06D1065680 for ; Thu, 31 Jul 2008 21:14:34 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: from mail.mastercabo.com.br (mail.mastercabo.com.br [200.179.179.14]) by mx1.freebsd.org (Postfix) with SMTP id 10CE88FC17 for ; Thu, 31 Jul 2008 21:14:32 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: (qmail 46181 invoked by uid 1008); 31 Jul 2008 20:47:51 -0000 Received: from unknown (HELO ?192.168.0.169?) (200.251.26.17) by mail.mastercabo.com.br with SMTP; 31 Jul 2008 20:47:51 -0000 Message-ID: <489224F2.3050508@yan.com.br> Date: Thu, 31 Jul 2008 17:47:46 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <48918DB5.7020201@wubethiopia.com> In-Reply-To: <48918DB5.7020201@wubethiopia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ddg@yan.com.br List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2008 21:14:34 -0000 You will go to develop a version to work with PF ? Mike Makonnen escreveu: > Hi, > > An Internet Cafe I do some work for was recently having problems with > very slow internet access. It turns out customers were running P2P > file sharing applications which were hogging all the bandwidth. I > looked for programs that would allow me to shape traffic according to > the application layer protocol, but couldn't find any for FreeBSD. I > found a couple: l7-filter and ipp2p, but these are Linux specific. So, > I decided to write one. The result is ipfw-classifyd : > http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 > > As the name implies it uses ipfw(4) to implement a userland daemon > that classifies TCP and UDP packets according to regular expression > patterns for various protocols. It's intended to be used with > divert(4) sockets and dummynet(4) so you can do traffic shaping > depending on the application level protocol. The protocol patterns are > from the l7-filter project. > > Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It > reads its configuration file for a list of protocols and ipfw(8) > rules. Then, when it detects a matching session it re-injects the > packet back at the specified rule number. The tarball has a sample > configuration file and firewall script to get you started. > > While I have not done extensive testing, preliminary tests are > encouraging and it seems to work, so I thought I'd announce it to the > rest of the world in case anyone else is interested in this kind of > application. > > Comments and suggestions highly appreciated. > > Cheers. From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 21:18:11 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3ED74106567A for ; Thu, 31 Jul 2008 21:18:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outl.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id 256C98FC42 for ; Thu, 31 Jul 2008 21:18:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 991DA24DF; Thu, 31 Jul 2008 14:18:43 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 772172D605A; Thu, 31 Jul 2008 14:18:09 -0700 (PDT) Message-ID: <48922C27.8090005@elischer.org> Date: Thu, 31 Jul 2008 14:18:31 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Paolo Pisati References: <48918DB5.7020201@wubethiopia.com> <20080731102116.GA32671@tin.it> In-Reply-To: <20080731102116.GA32671@tin.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Makonnen , freebsd-net@FreeBSD.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2008 21:18:11 -0000 Paolo Pisati wrote: > On Thu, Jul 31, 2008 at 01:02:29PM +0300, Mike Makonnen wrote: >> While I have not done extensive testing, preliminary tests are encouraging >> and it seems to work, so I thought I'd announce it to the rest of the world >> in case anyone else is interested in this kind of application. > > That's a much needed addition to ipfw and FreeBSD in general, thanks > for the hard work. I wonder how it would go as a netgraph node? From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 21:28:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 718091065685 for ; Thu, 31 Jul 2008 21:28:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outd.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 5536D8FC17 for ; Thu, 31 Jul 2008 21:28:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 717DF24BB; Thu, 31 Jul 2008 14:29:07 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id D449F2D60C6; Thu, 31 Jul 2008 14:28:39 -0700 (PDT) Message-ID: <48922E9D.1020507@elischer.org> Date: Thu, 31 Jul 2008 14:29:01 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Patrick Tracanelli References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> In-Reply-To: <4891CD13.20600@freebsdbrasil.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Makonnen , freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2008 21:28:40 -0000 Patrick Tracanelli wrote: > Mike Makonnen escreveu: >> Hi, >> >> An Internet Cafe I do some work for was recently having problems with >> very slow internet access. It turns out customers were running P2P >> file sharing applications which were hogging all the bandwidth. I >> looked for programs that would allow me to shape traffic according to >> the application layer protocol, but couldn't find any for FreeBSD. I >> found a couple: l7-filter and ipp2p, but these are Linux specific. So, >> I decided to write one. The result is ipfw-classifyd : >> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 >> >> As the name implies it uses ipfw(4) to implement a userland daemon >> that classifies TCP and UDP packets according to regular expression >> patterns for various protocols. It's intended to be used with >> divert(4) sockets and dummynet(4) so you can do traffic shaping >> depending on the application level protocol. The protocol patterns are >> from the l7-filter project. >> >> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It >> reads its configuration file for a list of protocols and ipfw(8) >> rules. Then, when it detects a matching session it re-injects the >> packet back at the specified rule number. The tarball has a sample >> configuration file and firewall script to get you started. >> >> While I have not done extensive testing, preliminary tests are >> encouraging and it seems to work, so I thought I'd announce it to the >> rest of the world in case anyone else is interested in this kind of >> application. >> >> Comments and suggestions highly appreciated. >> >> Cheers. > > Wont compile on RELENG_6 but is working perfectly on REL_7. I am trying > hard with ssh, soulseek and msn. Its working like a charm with the > suggested rc.firewall. > > I have configured ipfw-classfyd.conf changing the rules, for a number of > L7 patterns, and now I try to understand why the "diverted" rules only > match if the rule number is 1 after the configured, ie, I put soulseek > to 65530 and a rule wont match there, but the very same rule matches > 65531. I will read the code, but it seems that reinjection of the packet > is made +1, correct? yes, the idea is: If you get the sockaddr for the received packet, and use it unmodified when reinjecting the packet, then it will continue on at the next rule. so since the rule number is "unchanged" we need to add 1 to it to say where to start from.. hope that helps.. > > > > > > From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 21:50:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0586106566B for ; Thu, 31 Jul 2008 21:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DC12D8FC15 for ; Thu, 31 Jul 2008 21:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6VLo3ha087738 for ; Thu, 31 Jul 2008 21:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6VLo3ET087737; Thu, 31 Jul 2008 21:50:03 GMT (envelope-from gnats) Date: Thu, 31 Jul 2008 21:50:03 GMT Message-Id: <200807312150.m6VLo3ET087737@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Wooseog Choi Cc: Subject: Re: kern/114714: [gre][patch] gre(4) is not MPSAFE and does not support keys X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Wooseog Choi List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2008 21:50:04 -0000 The following reply was made to PR kern/114714; it has been noted by GNATS. From: Wooseog Choi To: , Cc: Subject: Re: kern/114714: [gre][patch] gre(4) is not MPSAFE and does not support keys Date: Thu, 31 Jul 2008 14:28:13 -0700 --_6b0f6d37-847d-4140-98e8-949ced352c50_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=2C =20 My name is Ben Choi=2C working for Sandvine=2C Waterloo=2C ON=2C Canada. I had experienced similar issue=2C which was displaying many gre_out() cons= ole messages. At that moment=2C I could not access console at all. After applying the fix of MPSAFE codes only=2C it works fine.=20 No error messages on console at all. The benefit of this fix is two-fold. One=2C By removing all annoying messages=2C the console becomes accessible. Two=2C no gre packets are dropped by this incorrect error messages. =20 As the result=2C I think this code is worth to merge into official build. =20 Kind regards=2C =20 Ben Choi _________________________________________________________________ Keep your kids safer online with Windows Live Family Safety. http://www.windowslive.com/family_safety/overview.html?ocid=3DTXT_TAGLM_WL_= family_safety_072008= --_6b0f6d37-847d-4140-98e8-949ced352c50_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=2C
 =3B
My name is Ben Choi=2C working for Sandvine=2C Waterloo=2C ON=2C Canada. I had experienced similar issue=2C which was displaying many gre_out() cons= ole messages.
At that moment=2C I could not access console at all.
After applying the fix of MPSAFE codes only=2C it works fine.
No error messages on console at all.
The benefit of this fix is two-fold.
One=2C By removing all annoying messages=2C the console becomes accessible.=
Two=2C no gre packets are dropped by this incorrect error messages.
 =3B
As the result=2C I think this code is worth to merge into official build.  =3B
Kind regards=2C
 =3B
Ben Choi

Keep your kids safer online with Windows Live Famil= y Safety. Help protect you= r kids. = --_6b0f6d37-847d-4140-98e8-949ced352c50_-- From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 01:50:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46C581065673 for ; Fri, 1 Aug 2008 01:50:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outw.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id 2BA468FC0C for ; Fri, 1 Aug 2008 01:50:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id E3DB424AF; Thu, 31 Jul 2008 18:50:41 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 8EA492D601B; Thu, 31 Jul 2008 18:50:41 -0700 (PDT) Message-ID: <48926C02.6030308@elischer.org> Date: Thu, 31 Jul 2008 18:50:58 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: FreeBSD Net , ipfw@freebsd.org Content-Type: multipart/mixed; boundary="------------080502070707020107000209" Cc: Subject: ipfw add skipto tablearg.... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 01:50:42 -0000 This is a multi-part message in MIME format. --------------080502070707020107000209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit looking int he code I noticed that the following command gave no error but didn't work.. ipfw add 1000 skipto tablearg ip from any to table(31) and as I have a use for that, I implemented it.. see attached patch... (hopefully not stripped) Of course it is hoped that the rules you are skipping to are nearby as it iterates through the rules following the skipto to find the target, but.... if you had a thousand table entries and wanted to sort them into 20 buckets, it could save you puting them into 20 different tables and doing 20 table lookups on them. here I sort into two categories.. possibly already a win.. julian@trafmon2:cat ipfw-test.sh #!/bin/sh ipfw add 100 skipto 10000 ip from any to not 1.1.1.0/24 ipfw add 1000 skipto tablearg ip from any to "table(31)" ipfw add 2000 drop ip from any to any ipfw add 2001 drop ip from any to any ipfw add 3000 drop ip from any to any ipfw add 3001 drop ip from any to any ipfw add 10000 count ip from any to any ipfw table 31 add 1.1.1.1 2000 ipfw table 31 add 1.1.1.2 3000 julian@trafmon2: ping 1.1.1.1 [...] (2 packets bounced) julian@trafmon2: ping 1.1.1.2 [...] (12 packets bounced) julian@trafmon2: ipfw show 00100 220 19633 skipto 10000 ip from any to not 1.1.1.0/24 01000 14 1176 skipto tablearg ip from any to table(31) 02000 2 168 deny ip from any to any 02001 0 0 deny ip from any to any 03000 12 1008 deny ip from any to any 03001 0 0 deny ip from any to any 10000 209 18549 count ip from any to any 65535 1751 153792 allow ip from any to any comments? --------------080502070707020107000209 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="ipfw-skipto-current.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipfw-skipto-current.diff" Index: ip_fw2.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/netinet/ip_fw2.c,v retrieving revision 1.186 diff -u -r1.186 ip_fw2.c --- ip_fw2.c 9 May 2008 23:02:57 -0000 1.186 +++ ip_fw2.c 1 Aug 2008 01:15:06 -0000 @@ -1738,10 +1738,11 @@ */ static struct ip_fw * -lookup_next_rule(struct ip_fw *me) +lookup_next_rule(struct ip_fw *me, u_int32_t tablearg) { struct ip_fw *rule = NULL; ipfw_insn *cmd; + u_int16_t rulenum; /* look for action, in case it is a skipto */ cmd = ACTION_PTR(me); @@ -1751,10 +1752,18 @@ cmd += F_LEN(cmd); if (cmd->opcode == O_TAG) cmd += F_LEN(cmd); - if ( cmd->opcode == O_SKIPTO ) - for (rule = me->next; rule ; rule = rule->next) - if (rule->rulenum >= cmd->arg1) + if (cmd->opcode == O_SKIPTO ) { + if (tablearg != 0) { + rulenum = (u_int16_t)tablearg; + } else { + rulenum = cmd->arg1; + } + for (rule = me->next; rule ; rule = rule->next) { + if (rule->rulenum >= rulenum) { break; + } + } + } if (rule == NULL) /* failure or not a skipto */ rule = me->next; me->next_rule = rule; @@ -2475,7 +2484,7 @@ f = args->rule->next_rule; if (f == NULL) - f = lookup_next_rule(args->rule); + f = lookup_next_rule(args->rule, 0); } else { /* * Find the starting rule. It can be either the first @@ -3226,9 +3235,13 @@ if (cmd->opcode == O_COUNT) goto next_rule; /* handle skipto */ - if (f->next_rule == NULL) - lookup_next_rule(f); - f = f->next_rule; + if (cmd->arg1 == IP_FW_TABLEARG) { + f = lookup_next_rule(f, tablearg); + } else { + if (f->next_rule == NULL) + lookup_next_rule(f, 0); + f = f->next_rule; + } goto again; case O_REJECT: --------------080502070707020107000209-- From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 05:35:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09E9210656BF for ; Fri, 1 Aug 2008 05:35:28 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id 9637B8FC15 for ; Fri, 1 Aug 2008 05:35:27 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 13539 invoked from network); 1 Aug 2008 05:08:46 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 1 Aug 2008 05:08:46 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 1 Aug 2008 00:08:38 -0500 (CDT) From: Mike Silbersack To: ticso@cicely.de In-Reply-To: <20080718135931.GA48087@cicely7.cicely.de> Message-ID: References: <20080718135931.GA48087@cicely7.cicely.de> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: TCP zombie connections with 7-RELEASE and STABLE from 15th june X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 05:35:28 -0000 On Fri, 18 Jul 2008, Bernd Walter wrote: > 443 is a self written server, but it also happens with port 80 and > sslproxy. > The client is a telnet, which disconnects directly after connecting, > so the disconnect is initiated from the client, which seems to be > important for this problem to trigger. > > You can see that the FIN handshake completes and netstat on the > client box shows the connection in TIME_WAIT. > The server however has the connection still in ESTABLISHED state. Well, syncookies allow the ack of the 3WHS to establish a connection. Just a quick look at your tcpdump shows that since you aren't sending any data you are not advancing the sequence number. As a result, it looks like one of the ACKs the client sends during connection shutdown may actually be causing the server to re-establish the connection. You might want to file a PR with exact instructions (and code) that'll easily reproduce this so that it can be solved at some point in the future. I don't have time to look into it now, although I'd be happy to code review a fix! -Mike From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 06:50:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D302D1065679 for ; Fri, 1 Aug 2008 06:50:56 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id 8F7958FC15 for ; Fri, 1 Aug 2008 06:50:56 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 23523 invoked from network); 1 Aug 2008 01:24:17 -0500 Received: from 203-166-248-146.dyn.iinet.net.au (HELO ayiin) (203.166.248.146) by sigma.octantis.com.au with (DHE-RSA-AES128-SHA encrypted) SMTP; 1 Aug 2008 01:24:17 -0500 Date: Fri, 1 Aug 2008 16:24:11 +1000 From: Norberto Meijome To: freebsd-net@freebsd.org Message-ID: <20080801162411.0bb87b55@ayiin> In-Reply-To: <48922C27.8090005@elischer.org> References: <48918DB5.7020201@wubethiopia.com> <20080731102116.GA32671@tin.it> <48922C27.8090005@elischer.org> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 06:50:56 -0000 On Thu, 31 Jul 2008 14:18:31 -0700 Julian Elischer wrote: > Paolo Pisati wrote: > > On Thu, Jul 31, 2008 at 01:02:29PM +0300, Mike Makonnen wrote: > >> While I have not done extensive testing, preliminary tests are encouraging > >> and it seems to work, so I thought I'd announce it to the rest of the world > >> in case anyone else is interested in this kind of application. > > > > That's a much needed addition to ipfw and FreeBSD in general, thanks > > for the hard work. > > I wonder how it would go as a netgraph node? +1 :) _________________________ {Beto|Norberto|Numard} Meijome "Life is just what happens to you, While your busy making other plans..." John Lennon I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 09:30:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4420106566C for ; Fri, 1 Aug 2008 09:30:41 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6FA498FC16 for ; Fri, 1 Aug 2008 09:30:41 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KOqxz-0005Dw-Rs for freebsd-net@freebsd.org; Fri, 01 Aug 2008 09:30:31 +0000 Received: from firewall.andxor.it ([195.223.2.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Aug 2008 09:30:31 +0000 Received: from lapo by firewall.andxor.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Aug 2008 09:30:31 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Lapo Luchini Date: Fri, 01 Aug 2008 11:30:22 +0200 Lines: 10 Message-ID: References: <484E0C08.1060800@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: firewall.andxor.it User-Agent: Thunderbird 2.0.0.16 (X11/20080728) In-Reply-To: <484E0C08.1060800@FreeBSD.org> X-Enigmail-Version: 0.95.6 OpenPGP: id=C8F252FB Sender: news Subject: Re: Proposal: Enable IPv6 Privacy Extensions (RFCs 3041/4941) by default X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 09:30:41 -0000 Doug Barton wrote: > The "normal" EUI-64-based address will still be configured, but there > will also be a random identifier added to the interface as an alias, > and outgoing traffic will go out from that address. Be prepared to question about it, though ;-) http://www.sixxs.net/faq/connectivity/?faq=rfc3041 -- Lapo Luchini - http://lapo.it/ From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 10:16:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24D3C1065670 for ; Fri, 1 Aug 2008 10:16:00 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from dire.wubethiopia.com (j071.v.rootbsd.net [208.79.82.223]) by mx1.freebsd.org (Postfix) with ESMTP id F31758FC1D for ; Fri, 1 Aug 2008 10:15:59 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from rogue.mike.lan (unknown [213.55.82.136]) by dire.wubethiopia.com (Postfix) with ESMTPSA id 0ACE24FDA772; Fri, 1 Aug 2008 10:15:55 +0000 (UTC) Message-ID: <4892E3BE.2030900@wubethiopia.com> Date: Fri, 01 Aug 2008 13:21:50 +0300 From: Mike Makonnen User-Agent: Thunderbird 2.0.0.12 (X11/20080323) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= References: <9a542da30807311344u34422adauade5c2b62b71804a@mail.gmail.com> In-Reply-To: <9a542da30807311344u34422adauade5c2b62b71804a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 10:16:00 -0000 Ermal Luçi wrote: >> Hi, >> >> An Internet Cafe I do some work for was recently having problems with >> very slow internet access. It turns out customers were running P2P file >> sharing applications which were hogging all the bandwidth. I looked for >> programs that would allow me to shape traffic according to the >> application layer protocol, but couldn't find any for FreeBSD. I found a >> couple: l7-filter and ipp2p, but these are Linux specific. So, I decided >> to write one. The result is ipfw-classifyd : >> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 >> >> As the name implies it uses ipfw(4) to implement a userland daemon that >> classifies TCP and UDP packets according to regular expression patterns >> for various protocols. It's intended to be used with divert(4) sockets >> and dummynet(4) so you can do traffic shaping depending on the >> application level protocol. The protocol patterns are from the l7-filter >> project. >> >> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It >> reads its configuration file for a list of protocols and ipfw(8) rules. >> Then, when it detects a matching session it re-injects the packet back >> at the specified rule number. The tarball has a sample configuration >> file and firewall script to get you started. >> >> While I have not done extensive testing, preliminary tests are >> encouraging and it seems to work, so I thought I'd announce it to the >> rest of the world in case anyone else is interested in this kind of >> application. >> >> Comments and suggestions highly appreciated. >> > > Thanks for this. > I have a question, you remove a flow from if you see a FIN for the TCP > case and only on overlapping flow for either TCP/UDP how do the other > flows expire i am missing that part? > > No, you're not missing anything. It's on my TODO list. I wanted to get this out and get feedback as early as possible, so I released it as soon as I had it basically working. I'm thinking of storing some session information for the flow (like a timestamp for the last packet seen) and implementing a garbage collector thread that removes sessions that have been idle for some period of time. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 10:18:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A4C0106566C for ; Fri, 1 Aug 2008 10:18:21 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from dire.wubethiopia.com (j071.v.rootbsd.net [208.79.82.223]) by mx1.freebsd.org (Postfix) with ESMTP id 37B808FC13 for ; Fri, 1 Aug 2008 10:18:21 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from rogue.mike.lan (unknown [213.55.82.136]) by dire.wubethiopia.com (Postfix) with ESMTPSA id 714F24FDA772; Fri, 1 Aug 2008 10:18:17 +0000 (UTC) Message-ID: <4892E456.5080408@wubethiopia.com> Date: Fri, 01 Aug 2008 13:24:22 +0300 From: Mike Makonnen User-Agent: Thunderbird 2.0.0.12 (X11/20080323) MIME-Version: 1.0 To: ddg@yan.com.br References: <48918DB5.7020201@wubethiopia.com> <489224F2.3050508@yan.com.br> In-Reply-To: <489224F2.3050508@yan.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 10:18:21 -0000 Daniel Dias Gonçalves wrote: > You will go to develop a version to work with PF ? > I don't know what's needed to get it to work with pf, but if it's not too much work, sure. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 10:30:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D662106567F for ; Fri, 1 Aug 2008 10:30:51 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from dire.wubethiopia.com (j071.v.rootbsd.net [208.79.82.223]) by mx1.freebsd.org (Postfix) with ESMTP id DED418FC12 for ; Fri, 1 Aug 2008 10:30:50 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from rogue.mike.lan (unknown [213.55.82.136]) by dire.wubethiopia.com (Postfix) with ESMTPSA id 45EEE4FDA772; Fri, 1 Aug 2008 10:30:46 +0000 (UTC) Message-ID: <4892E735.1000105@wubethiopia.com> Date: Fri, 01 Aug 2008 13:36:37 +0300 From: Mike Makonnen User-Agent: Thunderbird 2.0.0.12 (X11/20080323) MIME-Version: 1.0 To: Patrick Tracanelli References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> In-Reply-To: <4891CD13.20600@freebsdbrasil.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 10:30:51 -0000 Patrick Tracanelli wrote: > Mike Makonnen escreveu: >> Hi, >> >> An Internet Cafe I do some work for was recently having problems with >> very slow internet access. It turns out customers were running P2P >> file sharing applications which were hogging all the bandwidth. I >> looked for programs that would allow me to shape traffic according >> to the application layer protocol, but couldn't find any for FreeBSD. >> I found a couple: l7-filter and ipp2p, but these are Linux specific. >> So, I decided to write one. The result is ipfw-classifyd : >> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 >> >> As the name implies it uses ipfw(4) to implement a userland daemon >> that classifies TCP and UDP packets according to regular expression >> patterns for various protocols. It's intended to be used with >> divert(4) sockets and dummynet(4) so you can do traffic shaping >> depending on the application level protocol. The protocol patterns >> are from the l7-filter project. >> >> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It >> reads its configuration file for a list of protocols and ipfw(8) >> rules. Then, when it detects a matching session it re-injects the >> packet back at the specified rule number. The tarball has a sample >> configuration file and firewall script to get you started. >> >> While I have not done extensive testing, preliminary tests are >> encouraging and it seems to work, so I thought I'd announce it to the >> rest of the world in case anyone else is interested in this kind of >> application. >> >> Comments and suggestions highly appreciated. >> >> Cheers. > > Wont compile on RELENG_6 but is working perfectly on REL_7. I am > trying hard with ssh, soulseek and msn. Its working like a charm with > the suggested rc.firewall. Can you email me the compile error? > > I have configured ipfw-classfyd.conf changing the rules, for a number > of L7 patterns, and now I try to understand why the "diverted" rules > only match if the rule number is 1 after the configured, ie, I put > soulseek to 65530 and a rule wont match there, but the very same rule > matches 65531. I will read the code, but it seems that reinjection of > the packet is made +1, correct? > The application doesn't do that, it's the firewall that does that. Basically, when ipfw(4) diverts a packet to the application it includes the rule that caused the packet to be diverted (so that when it gets it back it knows where to continue processing from). When it gets the packet back it continues processing the packet at the rule *after* the one that caused it to be diverted (otherwise the packet would get diverted in an endless loop). In the sample script rule 1000 is the rule that passes the packets that do not get diverted, so I configured ipfw-classifyd to modify the information that comes with the packet to point to rule 1000 (in classifyd.conf). So, when ipfw(4) gets the packet back it continues processing it at the next rule after 1000, which is the rule that sends all diverted packets through the pipe. Hope that helps. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 11:50:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44F55106569C for ; Fri, 1 Aug 2008 11:50:16 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id A569F8FC12 for ; Fri, 1 Aug 2008 11:50:15 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m71BoC0i044816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Aug 2008 13:50:13 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m71Bo8nN002777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2008 13:50:09 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m71Bo8wt076589; Fri, 1 Aug 2008 13:50:08 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m71Bo7B0076588; Fri, 1 Aug 2008 13:50:07 +0200 (CEST) (envelope-from ticso) Date: Fri, 1 Aug 2008 13:50:07 +0200 From: Bernd Walter To: Mike Silbersack Message-ID: <20080801115007.GA76575@cicely7.cicely.de> References: <20080718135931.GA48087@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.120, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-net@freebsd.org, ticso@cicely.de Subject: Re: TCP zombie connections with 7-RELEASE and STABLE from 15th june X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 11:50:16 -0000 On Fri, Aug 01, 2008 at 12:08:38AM -0500, Mike Silbersack wrote: > > > On Fri, 18 Jul 2008, Bernd Walter wrote: > > >443 is a self written server, but it also happens with port 80 and > >sslproxy. > >The client is a telnet, which disconnects directly after connecting, > >so the disconnect is initiated from the client, which seems to be > >important for this problem to trigger. > > > >You can see that the FIN handshake completes and netstat on the > >client box shows the connection in TIME_WAIT. > >The server however has the connection still in ESTABLISHED state. > > Well, syncookies allow the ack of the 3WHS to establish a connection. > Just a quick look at your tcpdump shows that since you aren't sending any > data you are not advancing the sequence number. As a result, it looks > like one of the ACKs the client sends during connection shutdown may > actually be causing the server to re-establish the connection. Ah - that makes sense. > You might want to file a PR with exact instructions (and code) that'll > easily reproduce this so that it can be solved at some point in the > future. I don't have time to look into it now, although I'd be happy to > code review a fix! Thank you - I will file a PR. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 14:31:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2962106566C for ; Fri, 1 Aug 2008 14:31:36 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [201.48.151.3]) by mx1.freebsd.org (Postfix) with SMTP id 163668FC16 for ; Fri, 1 Aug 2008 14:31:35 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 14356 invoked from network); 1 Aug 2008 11:31:34 -0300 Received: by simscan 1.1.0 ppid: 14348, pid: 14349, t: 0.3869s scanners: clamav: 0.91.1/m: spam: 3.1.1 X-Spam-Checker-Version: SpamAssassin: -last, FreeBSD Brasil LTDA rulesets: Yes X-Spam-Status: No, hits=-2.1 required=3.7 Received: from unknown (HELO claire.bh.freebsdbrasil.com.br) (201.48.151.226) by capeta.freebsdbrasil.com.br with SMTP; 1 Aug 2008 11:31:34 -0300 Message-ID: <48931E09.70407@freebsdbrasil.com.br> Date: Fri, 01 Aug 2008 11:30:33 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Thunderbird 2.0.0.0 (X11/20070612) MIME-Version: 1.0 To: Mike Makonnen References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> In-Reply-To: <48922E9D.1020507@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 14:31:37 -0000 I guess I need some help here. How can I increase (and what should I be aware) the input queue? Under 20Mbit/s of load, I have the following problem: Aug 1 11:14:45 ourofino last message repeated 5828 times Aug 1 11:14:45 ourofino ipfw-classifyd: MATCH edonkey(50000): 88.165.54.165:50286 -> 88.165.54.165:42074 Aug 1 11:14:45 ourofino ipfw-classifyd: packet dropped: input queue full Where should I start from? -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 15:08:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C333E1065673 for ; Fri, 1 Aug 2008 15:08:33 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [201.48.151.3]) by mx1.freebsd.org (Postfix) with SMTP id EE8E38FC1B for ; Fri, 1 Aug 2008 15:08:32 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 19530 invoked from network); 1 Aug 2008 12:08:31 -0300 Received: by simscan 1.1.0 ppid: 19522, pid: 19523, t: 0.3543s scanners: clamav: 0.91.1/m: spam: 3.1.1 X-Spam-Checker-Version: SpamAssassin: -last, FreeBSD Brasil LTDA rulesets: Yes X-Spam-Status: No, hits=-2.1 required=3.7 Received: from unknown (HELO claire.bh.freebsdbrasil.com.br) (201.48.151.226) by capeta.freebsdbrasil.com.br with SMTP; 1 Aug 2008 12:08:31 -0300 Message-ID: <489326B3.4030306@freebsdbrasil.com.br> Date: Fri, 01 Aug 2008 12:07:31 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Thunderbird 2.0.0.0 (X11/20070612) MIME-Version: 1.0 To: Mike Makonnen References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <48931E09.70407@freebsdbrasil.com.br> In-Reply-To: <48931E09.70407@freebsdbrasil.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 15:08:33 -0000 Patrick Tracanelli escreveu: > I guess I need some help here. How can I increase (and what should I be > aware) the input queue? > > Under 20Mbit/s of load, I have the following problem: > > Aug 1 11:14:45 ourofino last message repeated 5828 times > Aug 1 11:14:45 ourofino ipfw-classifyd: MATCH edonkey(50000): > 88.165.54.165:50286 -> 88.165.54.165:42074 > Aug 1 11:14:45 ourofino ipfw-classifyd: packet dropped: input queue full > > Where should I start from? > I have raised the queue lenght a lot, up to 40960, and the behavior was the same. Ill keep trying and let you know if any success. -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 15:14:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADFD110656D2 for ; Fri, 1 Aug 2008 15:14:39 +0000 (UTC) (envelope-from petri@helenius.fi) Received: from silver.he.iki.fi (mx.helenius.fi [IPv6:2001:1bc8:1018::42]) by mx1.freebsd.org (Postfix) with ESMTP id 375F48FC17 for ; Fri, 1 Aug 2008 15:14:39 +0000 (UTC) (envelope-from petri@helenius.fi) Received: from localhost (localhost [127.0.0.1]) by silver.he.iki.fi (Postfix) with ESMTP id B8C12BBF2; Fri, 1 Aug 2008 18:14:36 +0300 (EEST) Received: from silver.he.iki.fi ([127.0.0.1]) by localhost (silver.he.iki.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7SSsNZesCDd; Fri, 1 Aug 2008 18:14:32 +0300 (EEST) Received: from [83.150.107.196] (d196.helenius.fi [83.150.107.196]) by silver.he.iki.fi (Postfix) with ESMTP; Fri, 1 Aug 2008 18:14:32 +0300 (EEST) Message-ID: <48932850.9090104@helenius.fi> Date: Fri, 01 Aug 2008 18:14:24 +0300 From: Petri Helenius User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Patrick Tracanelli References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <48931E09.70407@freebsdbrasil.com.br> <489326B3.4030306@freebsdbrasil.com.br> In-Reply-To: <489326B3.4030306@freebsdbrasil.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Makonnen , freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 15:14:39 -0000 Patrick Tracanelli wrote: > > I have raised the queue lenght a lot, up to 40960, and the behavior > was the same. Ill keep trying and let you know if any success. > No queue depth is going to help you if you receive more data than you can process. Pete From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 15:19:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05D45106564A for ; Fri, 1 Aug 2008 15:19:00 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [201.48.151.3]) by mx1.freebsd.org (Postfix) with SMTP id 300AB8FC0C for ; Fri, 1 Aug 2008 15:18:58 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 20958 invoked from network); 1 Aug 2008 12:18:57 -0300 Received: by simscan 1.1.0 ppid: 20950, pid: 20951, t: 0.3348s scanners: clamav: 0.91.1/m: spam: 3.1.1 X-Spam-Checker-Version: SpamAssassin: -last, FreeBSD Brasil LTDA rulesets: Yes X-Spam-Status: No, hits=-2.1 required=3.7 Received: from unknown (HELO claire.bh.freebsdbrasil.com.br) (201.48.151.226) by capeta.freebsdbrasil.com.br with SMTP; 1 Aug 2008 12:18:57 -0300 Message-ID: <48932924.2070102@freebsdbrasil.com.br> Date: Fri, 01 Aug 2008 12:17:56 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Thunderbird 2.0.0.0 (X11/20070612) MIME-Version: 1.0 To: Petri Helenius References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <48931E09.70407@freebsdbrasil.com.br> <489326B3.4030306@freebsdbrasil.com.br> <48932850.9090104@helenius.fi> In-Reply-To: <48932850.9090104@helenius.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Makonnen , freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 15:19:00 -0000 Petri Helenius escreveu: > Patrick Tracanelli wrote: >> >> I have raised the queue lenght a lot, up to 40960, and the behavior >> was the same. Ill keep trying and let you know if any success. >> > No queue depth is going to help you if you receive more data than you > can process. > > Pete From here, where I see (userland perspective) CPU usage is not an issue (yet?). classifyd is demanding low CPU: 6386 root 2 108 0 7496K 6668K RUN 0:11 0.04% ipfw-classifyd But maybe you mean something else. -- Patrick Tracanelli From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 15:27:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B2C01065675 for ; Fri, 1 Aug 2008 15:27:04 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from ns2.bafirst.com (72-12-2-19.static.networktel.net [72.12.2.19]) by mx1.freebsd.org (Postfix) with ESMTP id 099568FC17 for ; Fri, 1 Aug 2008 15:27:03 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from HOME.encontacto.net ([189.190.8.164]) by ns2.bafirst.com with esmtp; Fri, 01 Aug 2008 09:46:27 -0500 id 000D53A8.489321C3.0000F0FC Received: from localhost (localhost [127.0.0.1]) (uid 80) by HOME.encontacto.net with local; Fri, 01 Aug 2008 09:46:26 -0500 id 0004AC22.489321C2.00012220 Received: from local65.local.net.mx (local65.local.net.mx [192.168.1.65]) by econet.encontacto.net (Horde Framework) with HTTP; Fri, 01 Aug 2008 09:46:26 -0500 Message-ID: <20080801094626.18943vxiypbkcts0@econet.encontacto.net> Date: Fri, 01 Aug 2008 09:46:26 -0500 From: eculp To: freebsd-net@freebsd.org References: <48918DB5.7020201@wubethiopia.com> <489224F2.3050508@yan.com.br> <4892E456.5080408@wubethiopia.com> In-Reply-To: <4892E456.5080408@wubethiopia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (5.0-cvs) X-Remote-Browser: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.16) Gecko/20080725 Firefox/2.0.0.16 X-IMP-Server: 189.190.8.164 X-Originating-IP: 192.168.1.65 X-Originating-User: eculp@encontacto.net Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 15:27:04 -0000 Quoting Mike Makonnen : > Daniel Dias Gon=E7alves wrote: >> You will go to develop a version to work with PF ? >> > I don't know what's needed to get it to work with pf, but if it's not too > much work, sure. That would be great, Mike. I'm seeing more and more bandwidth being =20 used with p2p that I haven't been able to control with pf. The =20 thought has entered my mind to change back to ipfw that I used for =20 many years before changing to pf maybe 3 years ago. I also found =20 dummynet to be easy and practical to set up for both incoming and =20 outgoing connections. Something else I haven't figured out how to do =20 the same with altq, if even possible. In fact, if I am able to =20 control p2p with pf I may not even need bidirectional bandwidth limits. Thanks for sharing your very practical solution to a real world =20 problem. Have a great weekend. ed > > Cheers. > > --=20 > Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc > mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 > FreeBSD | http://www.freebsd.org > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 15:30:06 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A4C31065670 for ; Fri, 1 Aug 2008 15:30:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EB6B28FC0A for ; Fri, 1 Aug 2008 15:30:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m71FU52W015819 for ; Fri, 1 Aug 2008 15:30:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m71FU5et015816; Fri, 1 Aug 2008 15:30:05 GMT (envelope-from gnats) Date: Fri, 1 Aug 2008 15:30:05 GMT Message-Id: <200808011530.m71FU5et015816@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Oliver Cc: Subject: Re: kern/123881: [tcp] Turning on TCP blackholing causes slow localhost connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oliver List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 15:30:06 -0000 The following reply was made to PR kern/123881; it has been noted by GNATS. From: Oliver To: bug-followup@FreeBSD.org, tom@tomkarpik.com Cc: Subject: Re: kern/123881: [tcp] Turning on TCP blackholing causes slow localhost connections Date: Fri, 01 Aug 2008 17:05:10 +0200 I tried to reproduce this. You can log this issue when you also set net.inet.tcp.log_in_vain=2 the dmesg output shows for each connection attempt to sendmail TCP: [127.0.0.1]:58148 to [127.0.0.1]:113 tcpflags 0x2; tcp_input: Connection attempt on closed port if you start inetd/auth (113) the sendmail deamon answers the same speed it does with net.inet.tcp.blackhole=0 If you don't want to use auth, sendmail can be configured to set the timeout for ident to 0s which results in ident checking disabled or you can reduce the default value of 5 seconds. O Timeout.ident=0s so tcp.blackhole works as expected and perhaps this can be closed. Greetings, Oliver From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 15:36:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED1CC1065684 for ; Fri, 1 Aug 2008 15:36:29 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [201.48.151.3]) by mx1.freebsd.org (Postfix) with SMTP id 40FC48FC14 for ; Fri, 1 Aug 2008 15:36:28 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 23420 invoked from network); 1 Aug 2008 12:36:27 -0300 Received: by simscan 1.1.0 ppid: 23414, pid: 23415, t: 0.4314s scanners: clamav: 0.91.1/m: spam: 3.1.1 X-Spam-Checker-Version: SpamAssassin: -last, FreeBSD Brasil LTDA rulesets: Yes X-Spam-Status: No, hits=-2.1 required=3.7 Received: from unknown (HELO claire.bh.freebsdbrasil.com.br) (201.48.151.226) by capeta.freebsdbrasil.com.br with SMTP; 1 Aug 2008 12:36:27 -0300 Message-ID: <48932D3E.7090709@freebsdbrasil.com.br> Date: Fri, 01 Aug 2008 12:35:26 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Thunderbird 2.0.0.0 (X11/20070612) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <48918DB5.7020201@wubethiopia.com> <489224F2.3050508@yan.com.br> <4892E456.5080408@wubethiopia.com> <20080801094626.18943vxiypbkcts0@econet.encontacto.net> In-Reply-To: <20080801094626.18943vxiypbkcts0@econet.encontacto.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 15:36:30 -0000 eculp escreveu: > Quoting Mike Makonnen : > >> Daniel Dias Gonçalves wrote: >>> You will go to develop a version to work with PF ? >>> >> I don't know what's needed to get it to work with pf, but if it's not too >> much work, sure. > > That would be great, Mike. I'm seeing more and more bandwidth being > used with p2p that I haven't been able to control with pf. The thought > has entered my mind to change back to ipfw that I used for many years > before changing to pf maybe 3 years ago. I also found dummynet to be > easy and practical to set up for both incoming and outgoing > connections. Something else I haven't figured out how to do the same > with altq, if even possible. In fact, if I am able to control p2p with > pf I may not even need bidirectional bandwidth limits. > > Thanks for sharing your very practical solution to a real world > problem. Have a great weekend. If it could be rewritten as a netgaph node, maybe it could tag the classified packets, and tagging be compatible with both pf and ipfw (under discretionary user choice with configuration switchs), so both ipfw or pf could be used. However a lot of work has to be done before. It works better on i386 than amd64 right now, wont compile on RELENG_6 without modifying some gcc tweaks, etc. I hope enhacing it can be a GSoC project in the future, or we (community) can raise some funds to make it happen faster. It is really a long-time needed feature to FreeBSD. -- Patrick Tracanelli From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 15:50:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 861D5106566B for ; Fri, 1 Aug 2008 15:50:18 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id 55B4D8FC1E for ; Fri, 1 Aug 2008 15:50:18 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1480992rvf.43 for ; Fri, 01 Aug 2008 08:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=jWjSTD/A5EDTp2XgaPrB+D4Y6tPKz3groDfrnBo53+k=; b=q/In9/5AFlQOhM/4RlDm4p0eFzNpouexFEGU7mXRAfezGviMtY3L9DQKDLTKa4Cn4B 6gw1+suXmZqx2v9AXc3R8VnO6+lF8r8Y1UXdclvdv/np1F+1br0uaNqacjhLJ2BXyoHW T+ZNgE0h9AwyNGnG91q9YMSSbHZR7RBJ02xcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=yHKAQVLeTGOmz4p03ZjMz1CFl9sLr4gnoEMMrRtHEuerCZaA97cW684pylk/OBvqY5 QKw2clioOtLPOnFsEgDs9RIzmmxDNkUfJUU0tTAqFykTXAUOAbJxD2StbNxZDS13Uuf6 XnOi4dGTTAZYf67pjx1pIVifXHhYVIFWA+if8= Received: by 10.140.128.11 with SMTP id a11mr6022228rvd.232.1217605817727; Fri, 01 Aug 2008 08:50:17 -0700 (PDT) Received: by 10.141.128.2 with HTTP; Fri, 1 Aug 2008 08:50:17 -0700 (PDT) Message-ID: <9a542da30808010850o22ebbe4er4e56e6f700a37c5e@mail.gmail.com> Date: Fri, 1 Aug 2008 17:50:17 +0200 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" To: "Mike Makonnen" In-Reply-To: <4892E3BE.2030900@wubethiopia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9a542da30807311344u34422adauade5c2b62b71804a@mail.gmail.com> <4892E3BE.2030900@wubethiopia.com> Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 15:50:18 -0000 On Fri, Aug 1, 2008 at 12:21 PM, Mike Makonnen wrote: > Ermal Lu=E7i wrote: >>> >>> Hi, >>> >>> An Internet Cafe I do some work for was recently having problems with >>> very slow internet access. It turns out customers were running P2P file >>> sharing applications which were hogging all the bandwidth. I looked for >>> programs that would allow me to shape traffic according to the >>> application layer protocol, but couldn't find any for FreeBSD. I found = a >>> couple: l7-filter and ipp2p, but these are Linux specific. So, I decide= d >>> to write one. The result is ipfw-classifyd : >>> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 >>> >>> As the name implies it uses ipfw(4) to implement a userland daemon that >>> classifies TCP and UDP packets according to regular expression patterns >>> for various protocols. It's intended to be used with divert(4) sockets >>> and dummynet(4) so you can do traffic shaping depending on the >>> application level protocol. The protocol patterns are from the l7-filte= r >>> project. >>> >>> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It >>> reads its configuration file for a list of protocols and ipfw(8) rules. >>> Then, when it detects a matching session it re-injects the packet back >>> at the specified rule number. The tarball has a sample configuration >>> file and firewall script to get you started. >>> >>> While I have not done extensive testing, preliminary tests are >>> encouraging and it seems to work, so I thought I'd announce it to the >>> rest of the world in case anyone else is interested in this kind of >>> application. >>> >>> Comments and suggestions highly appreciated. >>> >> >> Thanks for this. >> I have a question, you remove a flow from if you see a FIN for the TCP >> case and only on overlapping flow for either TCP/UDP how do the other >> flows expire i am missing that part? >> >> > > No, you're not missing anything. It's on my TODO list. I wanted to get > this out and get feedback as early as possible, so I released it as soon = as > I had it basically working. I'm thinking of storing some session > information > for the flow (like a timestamp for the last packet seen) and implementing > a garbage collector thread that removes sessions that have been idle for > some period of time. > BTW, why not make it a port?! --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 15:59:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79B80106564A for ; Fri, 1 Aug 2008 15:59:07 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [201.48.151.3]) by mx1.freebsd.org (Postfix) with SMTP id BB9058FC1B for ; Fri, 1 Aug 2008 15:59:06 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 25841 invoked from network); 1 Aug 2008 12:59:05 -0300 Received: by simscan 1.1.0 ppid: 25833, pid: 25834, t: 0.4594s scanners: clamav: 0.91.1/m: spam: 3.1.1 X-Spam-Checker-Version: SpamAssassin: -last, FreeBSD Brasil LTDA rulesets: Yes X-Spam-Status: No, hits=-2.0 required=3.7 Received: from unknown (HELO claire.bh.freebsdbrasil.com.br) (201.48.151.226) by capeta.freebsdbrasil.com.br with SMTP; 1 Aug 2008 12:59:05 -0300 Message-ID: <4893328C.2040105@freebsdbrasil.com.br> Date: Fri, 01 Aug 2008 12:58:04 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Thunderbird 2.0.0.0 (X11/20070612) MIME-Version: 1.0 To: Julian Elischer References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> In-Reply-To: <48922E9D.1020507@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Makonnen , freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 15:59:07 -0000 Julian Elischer escreveu: > Patrick Tracanelli wrote: >> Mike Makonnen escreveu: >>> Hi, >>> >>> An Internet Cafe I do some work for was recently having problems with >>> very slow internet access. It turns out customers were running P2P >>> file sharing applications which were hogging all the bandwidth. I >>> looked for programs that would allow me to shape traffic according >>> to the application layer protocol, but couldn't find any for FreeBSD. >>> I found a couple: l7-filter and ipp2p, but these are Linux specific. >>> So, I decided to write one. The result is ipfw-classifyd : >>> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 >>> >>> As the name implies it uses ipfw(4) to implement a userland daemon >>> that classifies TCP and UDP packets according to regular expression >>> patterns for various protocols. It's intended to be used with >>> divert(4) sockets and dummynet(4) so you can do traffic shaping >>> depending on the application level protocol. The protocol patterns >>> are from the l7-filter project. >>> >>> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It >>> reads its configuration file for a list of protocols and ipfw(8) >>> rules. Then, when it detects a matching session it re-injects the >>> packet back at the specified rule number. The tarball has a sample >>> configuration file and firewall script to get you started. >>> >>> While I have not done extensive testing, preliminary tests are >>> encouraging and it seems to work, so I thought I'd announce it to the >>> rest of the world in case anyone else is interested in this kind of >>> application. >>> >>> Comments and suggestions highly appreciated. >>> >>> Cheers. >> >> Wont compile on RELENG_6 but is working perfectly on REL_7. I am >> trying hard with ssh, soulseek and msn. Its working like a charm with >> the suggested rc.firewall. >> >> I have configured ipfw-classfyd.conf changing the rules, for a number >> of L7 patterns, and now I try to understand why the "diverted" rules >> only match if the rule number is 1 after the configured, ie, I put >> soulseek to 65530 and a rule wont match there, but the very same rule >> matches 65531. I will read the code, but it seems that reinjection of >> the packet is made +1, correct? > > > yes, > the idea is: > If you get the sockaddr for the received packet, and use it unmodified > when reinjecting the packet, > then it will continue on at the next rule. > so since the rule number is "unchanged" we need to add 1 to it > to say where to start from.. > > hope that helps.. Perfect. Thanks. To let you know of my current (real world) tests: - Wireless Internet Provider 1: - 4Mbit/s of Internet Traffic - Classifying default protocols + soulseek + ssh - Classifying 100Mbit/s of dump over ssh Results in: No latency added, very low CPU usage, no packets dropping. - Wireless ISP 2: - 21 Mbit/s of Internet Traffic - Classifying default protocols + soulseek + ssh Results in: No tcp or udp traffic at all; everything that gets diverted never comes out of the divert socket, and ipfw-classifyd logs Aug 1 12:07:35 ourofino last message repeated 58 times Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent (rule 50000) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule 50000) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack (rule 50000) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella (rule 1000) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek (rule 50000) Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule 50000) Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert socket: Operation not permitted Aug 1 12:18:50 ourofino last message repeated 90 times Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue full Aug 1 12:19:11 ourofino last message repeated 94 times Raised queue len a lot (up to 40960), when the application starts it uses up to 25% CPU and a second after that, CPU usage gets lower the 0.1%. So far, this is what I have in real world enviroments. -- Patrick Tracanelli From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 17:53:43 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 800C9106566B; Fri, 1 Aug 2008 17:53:43 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 550A28FC22; Fri, 1 Aug 2008 17:53:43 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m71Hrhmq028806; Fri, 1 Aug 2008 17:53:43 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m71Hrhuf028802; Fri, 1 Aug 2008 17:53:43 GMT (envelope-from gavin) Date: Fri, 1 Aug 2008 17:53:43 GMT Message-Id: <200808011753.m71Hrhuf028802@freefall.freebsd.org> To: gavin@FreeBSD.org, gavin@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/123256: [wpi] panic: blockable sleep lock with wpi(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 17:53:43 -0000 Synopsis: [wpi] panic: blockable sleep lock with wpi(4) Responsible-Changed-From-To: gavin->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Fri Aug 1 17:42:56 UTC 2008 Responsible-Changed-Why: Over to maintainers. Hopefully the backtrace is enough to understand what is happening here. http://www.freebsd.org/cgi/query-pr.cgi?pr=123256 From owner-freebsd-net@FreeBSD.ORG Sat Aug 2 11:21:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CE44106564A for ; Sat, 2 Aug 2008 11:21:57 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from dire.wubethiopia.com (j071.v.rootbsd.net [208.79.82.223]) by mx1.freebsd.org (Postfix) with ESMTP id B69B88FC08 for ; Sat, 2 Aug 2008 11:21:56 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from rogue.mike.lan (unknown [213.55.65.29]) by dire.wubethiopia.com (Postfix) with ESMTPSA id 46C9C4FDA214; Sat, 2 Aug 2008 11:21:20 +0000 (UTC) Message-ID: <4894447C.3000800@wubethiopia.com> Date: Sat, 02 Aug 2008 14:26:52 +0300 From: Mike Makonnen User-Agent: Thunderbird 2.0.0.12 (X11/20080323) MIME-Version: 1.0 To: Patrick Tracanelli References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <4893328C.2040105@freebsdbrasil.com.br> In-Reply-To: <4893328C.2040105@freebsdbrasil.com.br> Content-Type: multipart/mixed; boundary="------------030903020905070706010308" Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2008 11:21:57 -0000 This is a multi-part message in MIME format. --------------030903020905070706010308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Patrick Tracanelli wrote: > > To let you know of my current (real world) tests: > > - Wireless Internet Provider 1: > - 4Mbit/s of Internet Traffic > - Classifying default protocols + soulseek + ssh > - Classifying 100Mbit/s of dump over ssh > > Results in: > No latency added, very low CPU usage, no packets dropping. > > - Wireless ISP 2: > - 21 Mbit/s of Internet Traffic > - Classifying default protocols + soulseek + ssh > > Results in: > No tcp or udp traffic at all; everything that gets diverted never > comes out of the divert socket, and ipfw-classifyd logs > > Aug 1 12:07:35 ourofino last message repeated 58 times > Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent > (rule 50000) > Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey > (rule 50000) > Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack > (rule 50000) > Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella > (rule 1000) > Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek > (rule 50000) > Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule > 50000) > Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert > socket: Operation not permitted > Aug 1 12:18:50 ourofino last message repeated 90 times Hmmm... this part means that the call to sendto(2) to write the packet back into network stack failed. This explains why you are not seein g any traffic comming back out of the divert socket, but I don't see why it would suddenly fail with a permission error. Could this be a kernel bug? > Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue full > Aug 1 12:19:11 ourofino last message repeated 94 times > > Raised queue len a lot (up to 40960), when the application starts it > uses up to 25% CPU and a second after that, CPU usage gets lower the > 0.1%. This looks like a deadlock. If it weren't able to process packets fast enough the cpu usage should be high even as it's spewing "packet dropped" messages. Can you send me some more information like memory usage and the firewall script you are using? How much of the 21Mbits/s of traffic is P2P? If you reduce the number of protocols you are trying to match against does the behavior change? Using netstat -w1 -I can you tell me how many packets per second we're talking about for 4Mbits/s and 21Mbit/s? Also, the timestamps from the log file seem to show that the daemon is running for approx. 34 sec. before the first "unable to write to write to divert socket" message. Is it passing traffic during this time? Thanks. I've uploaded a newer version. Can you try that also please. It includes: o SIGHUP forces it to re-read its configuration file o rc.d script o minor optimization (calls pthread_cond_signal with the mutex unlocked) o code cleanup Also, for your convenience I have attached a patch against the earlier version that removes a debugging printf that should remove spammage to your log files (the current version has it removed already). Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org --------------030903020905070706010308 Content-Type: text/plain; name="ipfw-classifyd-remove-match-printf.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipfw-classifyd-remove-match-printf.patch" --- classifyd.c.orig 2008-08-02 11:11:33.000000000 +0300 +++ classifyd.c 2008-08-02 11:10:52.000000000 +0300 @@ -334,10 +334,6 @@ if ((error) == 0) { \ (flow)->if_fwrule = (proto)->p_fwrule; \ (pkt)->fp_saddr.sin_port = (flow)->if_fwrule; \ - syslog(LOG_NOTICE, "MATCH %s(%d): %s:%d -> %s:%d\n", \ - (proto)->p_name, (flow)->if_fwrule, \ - inet_ntoa((key)->ik_src), ntohs((key)->ik_sport), \ - inet_ntoa((key)->ik_dst), ntohs((key)->ik_dport)); \ } else if ((error) != REG_NOMATCH) { \ regerror((error), &(proto)->p_preg, (regerr), sizeof((regerr))); \ syslog(LOG_WARNING, "error matching %s:%d -> %s:%d against %s: %s", \ --------------030903020905070706010308-- From owner-freebsd-net@FreeBSD.ORG Sat Aug 2 11:25:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7374106566C for ; Sat, 2 Aug 2008 11:25:06 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from dire.wubethiopia.com (j071.v.rootbsd.net [208.79.82.223]) by mx1.freebsd.org (Postfix) with ESMTP id AC9AE8FC08 for ; Sat, 2 Aug 2008 11:25:06 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from rogue.mike.lan (unknown [213.55.65.29]) by dire.wubethiopia.com (Postfix) with ESMTPSA id DF8954FDA214; Sat, 2 Aug 2008 11:24:54 +0000 (UTC) Message-ID: <4894456F.6060607@wubethiopia.com> Date: Sat, 02 Aug 2008 14:30:55 +0300 From: Mike Makonnen User-Agent: Thunderbird 2.0.0.12 (X11/20080323) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= References: <9a542da30807311344u34422adauade5c2b62b71804a@mail.gmail.com> <4892E3BE.2030900@wubethiopia.com> <9a542da30808010850o22ebbe4er4e56e6f700a37c5e@mail.gmail.com> In-Reply-To: <9a542da30808010850o22ebbe4er4e56e6f700a37c5e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2008 11:25:06 -0000 Ermal Luçi wrote: > On Fri, Aug 1, 2008 at 12:21 PM, Mike Makonnen wrote: > >> Ermal Luçi wrote: >> >>> Thanks for this. >>> I have a question, you remove a flow from if you see a FIN for the TCP >>> case and only on overlapping flow for either TCP/UDP how do the other >>> flows expire i am missing that part? >>> >>> >>> >> No, you're not missing anything. It's on my TODO list. I wanted to get >> this out and get feedback as early as possible, so I released it as soon as >> I had it basically working. I'm thinking of storing some session >> information >> for the flow (like a timestamp for the last packet seen) and implementing >> a garbage collector thread that removes sessions that have been idle for >> some period of time. >> >> > > BTW, why not make it a port?! > That's the plan as soon as I'm happy with it. I've created a sourceforge project (I just haven't had time to set it up yet), and in a few weeks I'll submit a port for it. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Sat Aug 2 11:27:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00CB9106567B for ; Sat, 2 Aug 2008 11:27:18 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from dire.wubethiopia.com (j071.v.rootbsd.net [208.79.82.223]) by mx1.freebsd.org (Postfix) with ESMTP id CBAC78FC12 for ; Sat, 2 Aug 2008 11:27:17 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from rogue.mike.lan (unknown [213.55.65.29]) by dire.wubethiopia.com (Postfix) with ESMTPSA id 967254FDA214; Sat, 2 Aug 2008 11:27:05 +0000 (UTC) Message-ID: <489445F8.3080100@wubethiopia.com> Date: Sat, 02 Aug 2008 14:33:12 +0300 From: Mike Makonnen User-Agent: Thunderbird 2.0.0.12 (X11/20080323) MIME-Version: 1.0 To: Patrick Tracanelli References: <48918DB5.7020201@wubethiopia.com> <489224F2.3050508@yan.com.br> <4892E456.5080408@wubethiopia.com> <20080801094626.18943vxiypbkcts0@econet.encontacto.net> <48932D3E.7090709@freebsdbrasil.com.br> In-Reply-To: <48932D3E.7090709@freebsdbrasil.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2008 11:27:18 -0000 Patrick Tracanelli wrote: > eculp escreveu: >> Quoting Mike Makonnen : >> >>> Daniel Dias Gonçalves wrote: >>>> You will go to develop a version to work with PF ? >>>> >>> I don't know what's needed to get it to work with pf, but if it's >>> not too >>> much work, sure. >> >> That would be great, Mike. I'm seeing more and more bandwidth being >> used with p2p that I haven't been able to control with pf. The >> thought has entered my mind to change back to ipfw that I used for >> many years before changing to pf maybe 3 years ago. I also found >> dummynet to be easy and practical to set up for both incoming and >> outgoing connections. Something else I haven't figured out how to do >> the same with altq, if even possible. In fact, if I am able to >> control p2p with pf I may not even need bidirectional bandwidth limits. >> >> Thanks for sharing your very practical solution to a real world >> problem. Have a great weekend. > > If it could be rewritten as a netgaph node, maybe it could tag the > classified packets, and tagging be compatible with both pf and ipfw > (under discretionary user choice with configuration switchs), so both > ipfw or pf could be used. I'll look into this when I have time. > > However a lot of work has to be done before. It works better on i386 > than amd64 right now, wont compile on RELENG_6 without modifying some > gcc tweaks, etc. Do you have a patch :-) ? Barring that, can you email me a copy of the build output? > > I hope enhacing it can be a GSoC project in the future, or we > (community) can raise some funds to make it happen faster. It is > really a long-time needed feature to FreeBSD. > Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Sat Aug 2 11:34:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D787E1065676 for ; Sat, 2 Aug 2008 11:34:09 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.181]) by mx1.freebsd.org (Postfix) with ESMTP id 6A3A28FC12 for ; Sat, 2 Aug 2008 11:34:07 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by ik-out-1112.google.com with SMTP id c30so2654274ika.3 for ; Sat, 02 Aug 2008 04:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ohHNjznX582X2+Vw3hW3BzYS39R3d+pD+YpkXZTgGys=; b=O8fIV01wjYuJQZyY4PSJ7AFr6NTiLc86bo69K3/OOofC1zz/vgtcDJVj/C/hG5hg5i ndmlD43CzZHRnaLK+7hSv2R5ecaUXiMxeOihYWmLi80/GnIBdzCGxWCl+7BLm5tVNQMd 8LDl1BDAjvUBEKdaGIL+WzhppSaCLl1Oc0AY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=o4/EsCDDQMDhRWx80lFXiZaCgUn/D5X9Xd40DD8eOS9QOzcoVoYvhiPJmaIp4fMWMV TFHaR16+c00BMIP0Mv0LS9joVXOanzvlaxetCoAXZOtFZUoqkGGkYmaUjZfGHFkYdaje fvCj0SPC6a9B2mh7YIgfEKTEEHWBkakX53+xQ= Received: by 10.210.75.6 with SMTP id x6mr14090204eba.120.1217676846369; Sat, 02 Aug 2008 04:34:06 -0700 (PDT) Received: by 10.210.116.17 with HTTP; Sat, 2 Aug 2008 04:34:06 -0700 (PDT) Message-ID: <9a542da30808020434w4954924dued75202ad34d44ba@mail.gmail.com> Date: Sat, 2 Aug 2008 13:34:06 +0200 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" To: "Mike Makonnen" In-Reply-To: <489445F8.3080100@wubethiopia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <48918DB5.7020201@wubethiopia.com> <489224F2.3050508@yan.com.br> <4892E456.5080408@wubethiopia.com> <20080801094626.18943vxiypbkcts0@econet.encontacto.net> <48932D3E.7090709@freebsdbrasil.com.br> <489445F8.3080100@wubethiopia.com> Cc: Patrick Tracanelli , freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2008 11:34:10 -0000 On Sat, Aug 2, 2008 at 1:33 PM, Mike Makonnen wrote: > Patrick Tracanelli wrote: >> >> eculp escreveu: >>> >>> Quoting Mike Makonnen : >>> >>>> Daniel Dias Gon=E7alves wrote: >>>>> >>>>> You will go to develop a version to work with PF ? >>>>> >>>> I don't know what's needed to get it to work with pf, but if it's not >>>> too >>>> much work, sure. >>> >>> That would be great, Mike. I'm seeing more and more bandwidth being us= ed >>> with p2p that I haven't been able to control with pf. The thought has >>> entered my mind to change back to ipfw that I used for many years befor= e >>> changing to pf maybe 3 years ago. I also found dummynet to be easy and >>> practical to set up for both incoming and outgoing connections. Someth= ing >>> else I haven't figured out how to do the same with altq, if even possib= le. >>> In fact, if I am able to control p2p with pf I may not even need >>> bidirectional bandwidth limits. As for pf(4) i have mostly finished divert support on pf. The number on the protocol means a dummynet queue/pipe instead of a rule number for ipfw. Surely with dummynet(4) support into pf(4) too. I will polish the patch and post it later on. >>> >>> Thanks for sharing your very practical solution to a real world problem= . >>> Have a great weekend. >> >> If it could be rewritten as a netgaph node, maybe it could tag the >> classified packets, and tagging be compatible with both pf and ipfw (und= er >> discretionary user choice with configuration switchs), so both ipfw or p= f >> could be used. > This means doing regex in kernel or just a daemon as mpd on top of netgraph= ? > I'll look into this when I have time. >> >> However a lot of work has to be done before. It works better on i386 tha= n >> amd64 right now, wont compile on RELENG_6 without modifying some gcc twe= aks, >> etc. > > Do you have a patch :-) ? Barring that, can you email me a copy of the bu= ild > output? >> >> I hope enhacing it can be a GSoC project in the future, or we (community= ) >> can raise some funds to make it happen faster. It is really a long-time >> needed feature to FreeBSD. >> > > Cheers. > > -- > Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc > mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 > FreeBSD | http://www.freebsd.org > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Sat Aug 2 11:41:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B536A1065672 for ; Sat, 2 Aug 2008 11:41:45 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 3BF6F8FC08 for ; Sat, 2 Aug 2008 11:41:45 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so694512nfh.33 for ; Sat, 02 Aug 2008 04:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=UwzT2Qh+dLvPEHktJuiidW7pdKZDx0TRulpKMu+T7vk=; b=DlV17qgyTzzuxusmS4Xwr6cGpo7sQ+KmRtvH/jBvvY5xV7rPxi4vFKPdVxUwFErM12 1Se6DiKGbpc97mnV7jDyP+XTZRN+oU8uGidODvj5rQYMAgcUDjQTY1jiM11kwugRcgML TPSxOUn7c0pBWUeQKc6F/rr0rAImRc+JzIxqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=aGFENQjRG7gw3+9ab+aQfaolrdB5VpWFDJDgFJRloahUPbLV3dIt9uZGO1Ccnfpz6t 4+y9ZJh4BNd3EIgWoPpzseufYoX2a14hqUtyECNVwSC4V1ONvrTHOy+KMK6CllCkY1xD Ce+810ycT4f2DZvMJIO447UcLuUGFFJOO7TcY= Received: by 10.210.43.10 with SMTP id q10mr12703415ebq.168.1217677303886; Sat, 02 Aug 2008 04:41:43 -0700 (PDT) Received: by 10.210.116.17 with HTTP; Sat, 2 Aug 2008 04:41:43 -0700 (PDT) Message-ID: <9a542da30808020441k300ce778kdb84f9d4914b6891@mail.gmail.com> Date: Sat, 2 Aug 2008 13:41:43 +0200 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" To: "Mike Makonnen" In-Reply-To: <9a542da30808020434w4954924dued75202ad34d44ba@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <48918DB5.7020201@wubethiopia.com> <489224F2.3050508@yan.com.br> <4892E456.5080408@wubethiopia.com> <20080801094626.18943vxiypbkcts0@econet.encontacto.net> <48932D3E.7090709@freebsdbrasil.com.br> <489445F8.3080100@wubethiopia.com> <9a542da30808020434w4954924dued75202ad34d44ba@mail.gmail.com> Cc: Patrick Tracanelli , freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2008 11:41:45 -0000 One thing, can you please make the SYN/ACK table optional since on pf(4) you have the info from the state table when a tcp connection is established. On Sat, Aug 2, 2008 at 1:34 PM, Ermal Lu=E7i wrote: > On Sat, Aug 2, 2008 at 1:33 PM, Mike Makonnen wrote= : >> Patrick Tracanelli wrote: >>> >>> eculp escreveu: >>>> >>>> Quoting Mike Makonnen : >>>> >>>>> Daniel Dias Gon=E7alves wrote: >>>>>> >>>>>> You will go to develop a version to work with PF ? >>>>>> >>>>> I don't know what's needed to get it to work with pf, but if it's not >>>>> too >>>>> much work, sure. >>>> >>>> That would be great, Mike. I'm seeing more and more bandwidth being u= sed >>>> with p2p that I haven't been able to control with pf. The thought has >>>> entered my mind to change back to ipfw that I used for many years befo= re >>>> changing to pf maybe 3 years ago. I also found dummynet to be easy an= d >>>> practical to set up for both incoming and outgoing connections. Somet= hing >>>> else I haven't figured out how to do the same with altq, if even possi= ble. >>>> In fact, if I am able to control p2p with pf I may not even need >>>> bidirectional bandwidth limits. > > As for pf(4) i have mostly finished divert support on pf. The number > on the protocol means a dummynet queue/pipe instead of a rule number > for ipfw. > Surely with dummynet(4) support into pf(4) too. I will polish the > patch and post it later on. > >>>> >>>> Thanks for sharing your very practical solution to a real world proble= m. >>>> Have a great weekend. >>> >>> If it could be rewritten as a netgaph node, maybe it could tag the >>> classified packets, and tagging be compatible with both pf and ipfw (un= der >>> discretionary user choice with configuration switchs), so both ipfw or = pf >>> could be used. >> > > This means doing regex in kernel or just a daemon as mpd on top of netgra= ph? > >> I'll look into this when I have time. >>> >>> However a lot of work has to be done before. It works better on i386 th= an >>> amd64 right now, wont compile on RELENG_6 without modifying some gcc tw= eaks, >>> etc. >> >> Do you have a patch :-) ? Barring that, can you email me a copy of the b= uild >> output? >>> >>> I hope enhacing it can be a GSoC project in the future, or we (communit= y) >>> can raise some funds to make it happen faster. It is really a long-time >>> needed feature to FreeBSD. >>> >> >> Cheers. >> >> -- >> Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc >> mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 >> FreeBSD | http://www.freebsd.org >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > > -- > Ermal > --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Sat Aug 2 12:55:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0891E1065670 for ; Sat, 2 Aug 2008 12:55:11 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id CD2FB8FC16 for ; Sat, 2 Aug 2008 12:55:07 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id WAA11611; Sat, 2 Aug 2008 22:54:38 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 2 Aug 2008 22:54:37 +1000 (EST) From: Ian Smith To: Mike Makonnen In-Reply-To: <4892E735.1000105@wubethiopia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Patrick Tracanelli , freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2008 12:55:11 -0000 On Fri, 1 Aug 2008, Mike Makonnen wrote: > Patrick Tracanelli wrote: > > Mike Makonnen escreveu: > >> Hi, > >> > >> An Internet Cafe I do some work for was recently having problems with > >> very slow internet access. It turns out customers were running P2P > >> file sharing applications which were hogging all the bandwidth. I > >> looked for programs that would allow me to shape traffic according > >> to the application layer protocol, but couldn't find any for FreeBSD. > >> I found a couple: l7-filter and ipp2p, but these are Linux specific. > >> So, I decided to write one. The result is ipfw-classifyd : > >> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2 This is great, Mike. I've been 'waiting for this' for a very similar situation for months now, getting by with dummynet bandwidth limiting and wondering about weighted queuing, but this is a much sharper tool. > >> As the name implies it uses ipfw(4) to implement a userland daemon > >> that classifies TCP and UDP packets according to regular expression > >> patterns for various protocols. It's intended to be used with > >> divert(4) sockets and dummynet(4) so you can do traffic shaping > >> depending on the application level protocol. The protocol patterns > >> are from the l7-filter project. Any GPL issues with using these patterns? > >> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It > >> reads its configuration file for a list of protocols and ipfw(8) > >> rules. Then, when it detects a matching session it re-injects the > >> packet back at the specified rule number. The tarball has a sample > >> configuration file and firewall script to get you started. I was confused by 'back at the specified rule number' too, especially as you used a rule 1000 in the example, being the rule handling NON matched packets. So I had a browse through the code, finding: /* * Inform divert(4) what rule to send it to by * modifying the port number of the associated sockaddr_in * structure. Note: we subtract one from the ipfw(4) rule * number because processing in ipfw(4) will start with * the next rule *after* the supplied rule number. */ if (flow->if_fwrule != 0) { pkt->fp_saddr.sin_port = flow->if_fwrule; goto enqueue; } and noticed that we weren't subtracting one .. I don't believe it's quite correct to say 'ipfw will start with the next rule after the supplied rule number'. If there were (legitimately) multiple rules having the same number (either divert rules themselves or at the target rule), the ipfw divert-return code skips past duplicates to the next rule that has a higher rule number, which may not amount to the same thing. (Sorry, Julian made me study ipfw execution behaviour months ago :) I thought at first that this behaviour is fine, and just needed a bit better describing. But I'm starting to wonder if subtracting one isn't really a better idea? > >> While I have not done extensive testing, preliminary tests are > >> encouraging and it seems to work, so I thought I'd announce it to the > >> rest of the world in case anyone else is interested in this kind of > >> application. > >> > >> Comments and suggestions highly appreciated. > >> > >> Cheers. > > > > Wont compile on RELENG_6 but is working perfectly on REL_7. I am > > trying hard with ssh, soulseek and msn. Its working like a charm with > > the suggested rc.firewall. > Can you email me the compile error? I'd like to run it on a 4.8 filtering bridge .. ah, never mind :) > > I have configured ipfw-classfyd.conf changing the rules, for a number > > of L7 patterns, and now I try to understand why the "diverted" rules > > only match if the rule number is 1 after the configured, ie, I put > > soulseek to 65530 and a rule wont match there, but the very same rule > > matches 65531. I will read the code, but it seems that reinjection of > > the packet is made +1, correct? > > > The application doesn't do that, it's the firewall that does that. > Basically, when > ipfw(4) diverts a packet to the application it includes the rule > that caused the packet to be diverted (so that when it gets it back it knows > where to continue processing from). When it gets the packet back it > continues > processing the packet at the rule *after* the one that caused it to be > diverted Rather, 'at the first rule having a higher rule number than the one ..' > (otherwise the packet would get diverted in an endless loop). In the sample > script rule 1000 is the rule that passes the packets that do not get > diverted, so > I configured ipfw-classifyd to modify the information that comes with the > packet to point to rule 1000 (in classifyd.conf). So, when ipfw(4) gets the > packet back it continues processing it at the next rule after 1000, which is > the rule that sends all diverted packets through the pipe. Yeah figuring out how rule 1000 had anything to do with it confused me at first, when any number after the divert rule/s would do. I think it may need stating really explicitly, something perhaps better put than: The rule number configured for the specified traffic type is that of the last rule number *before* the target ipfw rule for a match. Which is still harder to describe (or get one's head around) than being able to specify the desired target rule number in the config file? As long as you don't subtract one for the non-match packets reinjected normally, and do subtract one from the matching packet's config rule, so directly skipping to the specified rule, it would need an awful lot less explaining to users .. > Hope that helps. Oh yes :) Might even have to upgrade that bridge at long last. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sat Aug 2 12:55:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E18A106570D for ; Sat, 2 Aug 2008 12:55:20 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from dire.wubethiopia.com (j071.v.rootbsd.net [208.79.82.223]) by mx1.freebsd.org (Postfix) with ESMTP id DA1118FC18 for ; Sat, 2 Aug 2008 12:55:19 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from rogue.mike.lan (unknown [213.55.65.29]) by dire.wubethiopia.com (Postfix) with ESMTPSA id 301E94FDA22A; Sat, 2 Aug 2008 12:54:54 +0000 (UTC) Message-ID: <48945A79.50300@wubethiopia.com> Date: Sat, 02 Aug 2008 16:00:41 +0300 From: Mike Makonnen User-Agent: Thunderbird 2.0.0.12 (X11/20080323) MIME-Version: 1.0 To: Patrick Tracanelli References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <4893328C.2040105@freebsdbrasil.com.br> <4894447C.3000800@wubethiopia.com> In-Reply-To: <4894447C.3000800@wubethiopia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2008 12:55:20 -0000 Mike Makonnen wrote: > Patrick Tracanelli wrote: >> >> To let you know of my current (real world) tests: >> >> - Wireless Internet Provider 1: >> - 4Mbit/s of Internet Traffic >> - Classifying default protocols + soulseek + ssh >> - Classifying 100Mbit/s of dump over ssh >> >> Results in: >> No latency added, very low CPU usage, no packets dropping. >> >> - Wireless ISP 2: >> - 21 Mbit/s of Internet Traffic >> - Classifying default protocols + soulseek + ssh >> >> Results in: >> No tcp or udp traffic at all; everything that gets diverted never >> comes out of the divert socket, and ipfw-classifyd logs >> >> Aug 1 12:07:35 ourofino last message repeated 58 times >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent >> (rule 50000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey >> (rule 50000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack >> (rule 50000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella >> (rule 1000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek >> (rule 50000) >> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule >> 50000) >> Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert >> socket: Operation not permitted >> Aug 1 12:18:50 ourofino last message repeated 90 times > > Hmmm... this part means that the call to sendto(2) to write the packet > back into network stack failed. This explains why you are not seein g > any traffic comming back out of the divert socket, but I don't see why > it would suddenly fail with a permission error. Could this be a kernel > bug? >> Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue >> full >> Aug 1 12:19:11 ourofino last message repeated 94 times >> >> Raised queue len a lot (up to 40960), when the application starts it >> uses up to 25% CPU and a second after that, CPU usage gets lower the >> 0.1%. > > This looks like a deadlock. If it weren't able to process packets fast > enough the cpu usage should be high even as it's spewing "packet > dropped" messages. Can you send me some more information like memory > usage and the firewall script you are using? How much of the 21Mbits/s > of traffic is P2P? If you reduce the number of protocols you are > trying to match against does the behavior change? Using netstat -w1 > -I can you tell me how many packets per second we're > talking about for 4Mbits/s and 21Mbit/s? Also, the timestamps from the > log file seem to show that the daemon is running for approx. 34 sec. > before the first "unable to write to write to divert socket" message. > Is it passing traffic during this time? Thanks. > > I've uploaded a newer version. Can you try that also please. It includes: > o SIGHUP forces it to re-read its configuration file > o rc.d script > o minor optimization (calls pthread_cond_signal with the mutex > unlocked) > o code cleanup > > Also, for your convenience I have attached a patch against the earlier > version that removes a debugging printf that should remove spammage to > your log files (the current version has it removed already). > Ooops, a few minutes after I sent this email I found a couple of bugs (one major, and one minor). They were in the original tarball as well as the newer one I uploaded earlier today. I've uploaded a fixed version of the code. Can you try that instead please. Also, to help track down performance issues I've modified the Makefile to build a profiled version of the application so you can use gprof(1) to figure out where any problems lie. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org