From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 01:00:02 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A3E016A41F; Sun, 27 Nov 2005 01:00:02 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 715A743D7F; Sun, 27 Nov 2005 00:59:47 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jAR0xid3078418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Nov 2005 03:59:45 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jAR0ximR078417; Sun, 27 Nov 2005 03:59:44 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 27 Nov 2005 03:59:43 +0300 From: Gleb Smirnoff To: ru@FreeBSD.org, Vsevolod Lobko , rwatson@FreeBSD.org Message-ID: <20051127005943.GR25711@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="7LkOrbQMr4cezO2T" Content-Disposition: inline User-Agent: Mutt/1.5.6i Cc: net@FreeBSD.org Subject: parallelizing ipfw table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 01:00:02 -0000 --7LkOrbQMr4cezO2T Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Colleagues, in ipfw(4) we've got a reader/writer locking semantics. The ipfw lookups performed on packet forwarding obtain reader lock on ipfw chain, while altering the chain requires writer access on chain. So, in multiprocessor multiinterface box we achieve a parallizm almost without any contention. However, ipfw tables lock the RADIX trie on every lookup. At the first glance the radix.c:rn_lookup() function is reenterable. This means that we can do two parallel RADIX lookups. So, I suggest to eliminate the RADIX trie locking in ipfw, and utilize the locking that is already present in ipfw. This will: - reduce number of mutex operations for each packer - remove contention from parallel ipfw_chk() lookups A patch displaying the idea is attached. Not tested yet, read below. The patch moves the tables array into the ip_fw_chain structure. This is not necessary now, but in future we can have multiple independent chains in ipfw, that's why I try to avoid usage of &layer3_chain in the functions that are deeper in the call graph. I try to supply chain pointer from the caller. The only problem is the caching in table lookup. This "hack" makes the lookup function modify the table structure. We need to remove caching to make the lookup_table() function fully lockless and reenterable at the same time. The attached patch doesn't removes caching, since it only displays the original idea. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --7LkOrbQMr4cezO2T Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ip_fw.table.unlock" RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v Working file: ip_fw2.c head: 1.115 branch: locks: strict access list: symbolic names: RELENG_6_0_0_RELEASE: 1.106.2.3 RELENG_6_0: 1.106.2.3.0.2 RELENG_6_0_BP: 1.106.2.3 RELENG_6: 1.106.0.2 RELENG_6_BP: 1.106 RELENG_5_4_0_RELEASE: 1.70.2.10 RELENG_5_4: 1.70.2.10.0.2 RELENG_5_4_BP: 1.70.2.10 RELENG_4_11_0_RELEASE: 1.6.2.23 RELENG_4_11: 1.6.2.23.0.2 RELENG_4_11_BP: 1.6.2.23 RELENG_5_3_0_RELEASE: 1.70.2.7 RELENG_5_3: 1.70.2.7.0.2 RELENG_5_3_BP: 1.70.2.7 RELENG_5: 1.70.0.2 RELENG_5_BP: 1.70 RELENG_4_10_0_RELEASE: 1.6.2.21 RELENG_4_10: 1.6.2.21.0.2 RELENG_4_10_BP: 1.6.2.21 RELENG_5_2_1_RELEASE: 1.51.2.1 RELENG_5_2_0_RELEASE: 1.51.2.1 RELENG_5_2: 1.51.0.2 RELENG_5_2_BP: 1.51 RELENG_4_9_0_RELEASE: 1.6.2.18 RELENG_4_9: 1.6.2.18.0.2 RELENG_4_9_BP: 1.6.2.18 RELENG_5_1_0_RELEASE: 1.28.2.1 RELENG_5_1: 1.28.0.2 RELENG_5_1_BP: 1.28 RELENG_4_8_0_RELEASE: 1.6.2.11 RELENG_4_8: 1.6.2.11.0.2 RELENG_4_8_BP: 1.6.2.11 RELENG_5_0_0_RELEASE: 1.19.2.1 RELENG_5_0: 1.19.0.2 RELENG_5_0_BP: 1.19 RELENG_4_7_0_RELEASE: 1.6.2.3 RELENG_4_7: 1.6.2.3.0.2 RELENG_4_7_BP: 1.6.2.3 RELENG_4: 1.6.0.2 keyword substitution: kv total revisions: 161; selected revisions: 161 description: ---------------------------- revision 1.115 date: 2005/11/10 22:10:39; author: suz; state: Exp; lines: +8 -2 fixed a bug that uRPF does not work properly for an IPv6 packet bound for the sending machine itself (this is a bug introduced due to a change in ip6_input.c:Rev.1.83) Pointed out by: Sean McNeil and J.R.Oldroyd MFC after: 3 days ---------------------------- revision 1.114 date: 2005/11/02 13:46:31; author: andre; state: Exp; lines: +1 -1 Retire MT_HEADER mbuf type and change its users to use MT_DATA. Having an additional MT_HEADER mbuf type is superfluous and redundant as nothing depends on it. It only adds a layer of confusion. The distinction between header mbuf's and data mbuf's is solely done through the m->m_flags M_PKTHDR flag. Non-native code is not changed in this commit. For compatibility MT_HEADER is mapped to MT_DATA. Sponsored by: TCP/IP Optimization Fundraise 2005 ---------------------------- revision 1.113 date: 2005/09/27 18:10:42; author: mlaier; state: Exp; lines: +1 -1 Remove bridge(4) from the tree. if_bridge(4) is a full functional replacement and has additional features which make it superior. Discussed on: -arch Reviewed by: thompsa X-MFC-after: never (RELENG_6 as transition period) ---------------------------- revision 1.112 date: 2005/09/19 22:29:21; author: andre; state: Exp; lines: +24 -24 Use monotonic 'time_uptime' instead of 'time_second' as timebase for timeouts. ---------------------------- revision 1.111 date: 2005/09/14 07:53:54; author: bz; state: Exp; lines: +30 -6 Fix panic when kernel compiled without INET6 by rejecting IPv6 opcodes which are behind #if(n)def INET6 now. PR: kern/85826 MFC after: 3 days ---------------------------- revision 1.110 date: 2005/09/04 17:33:40; author: sam; state: Exp; lines: +1 -0 clear lock on error in O_LIMIT case of install_state Submitted by: Ted Unangst MFC after: 3 days ---------------------------- revision 1.109 date: 2005/08/14 18:20:33; author: bz; state: Exp; lines: +7 -1 Fix broken build of rev. 1.108 in case of no INET6 and IPFIREWALL compiled into kernel. Spotted and tested by: Michal Mertl ---------------------------- revision 1.108 date: 2005/08/13 11:02:33; author: bz; state: Exp; lines: +283 -67 * Add dynamic sysctl for net.inet6.ip6.fw. * Correct handling of IPv6 Extension Headers. * Add unreach6 code. * Add logging for IPv6. Submitted by: sysctl handling derived from patch from ume needed for ip6fw Obtained from: is_icmp6_query and send_reject6 derived from similar functions of netinet6,ip6fw Reviewed by: ume, gnn; silence on ipfw@ Test setup provided by: CK Software GmbH MFC after: 6 days ---------------------------- revision 1.107 date: 2005/07/26 00:19:58; author: ume; state: Exp; lines: +3 -0 include scope6_var.h for in6_clearscope(). ---------------------------- revision 1.106 date: 2005/07/03 15:42:22; author: mlaier; state: Exp; lines: +17 -20 branches: 1.106.2; Remove ambiguity from hlen. IPv4 is now indicated by is_ipv4 and we need a proper hlen value for IPv6 to implement O_REJECT and O_LOG. Reviewed by: glebius, brooks, gnn Approved by: re (scottl) ---------------------------- revision 1.105 date: 2005/06/29 21:36:49; author: simon; state: Exp; lines: +20 -17 Fix ipfw packet matching errors with address tables. The ipfw tables lookup code caches the result of the last query. The kernel may process multiple packets concurrently, performing several concurrent table lookups. Due to an insufficient locking, a cached result can become corrupted that could cause some addresses to be incorrectly matched against a lookup table. Submitted by: ru Reviewed by: csjp, mlaier Security: CAN-2005-2019 Security: FreeBSD-SA-05:13.ipfw Correct bzip2 permission race condition vulnerability. Obtained from: Steve Grubb via RedHat Security: CAN-2005-0953 Security: FreeBSD-SA-05:14.bzip2 Approved by: obrien Correct TCP connection stall denial of service vulnerability. A TCP packets with the SYN flag set is accepted for established connections, allowing an attacker to overwrite certain TCP options. Submitted by: Noritoshi Demizu Reviewed by: andre, Mohan Srinivasan Security: CAN-2005-2068 Security: FreeBSD-SA-05:15.tcp Approved by: re (security blanket), cperciva ---------------------------- revision 1.104 date: 2005/06/16 14:55:58; author: mlaier; state: Exp; lines: +52 -18 In verify_rev_path6(): - do not use static memory as we are under a shared lock only - properly rtfree routes allocated with rtalloc - rename to verify_path6() - implement the full functionality of the IPv4 version Also make O_ANTISPOOF work with IPv6. Reviewed by: gnn Approved by: re (blanket) ---------------------------- revision 1.103 date: 2005/06/16 13:20:36; author: mlaier; state: Exp; lines: +47 -47 Fix indentation in INET6 section in preperation of more serious work. Approved by: re (blanket ip6fw removal) ---------------------------- revision 1.102 date: 2005/06/12 16:27:10; author: mlaier; state: Exp; lines: +13 -10 When doing matching based on dst_ip/src_ip make sure we are really looking on an IPv4 packet as these variables are uninitialized if not. This used to allow arbitrary IPv6 packets depending on the value in the uninitialized variables. Some opcodes (most noteably O_REJECT) do not support IPv6 at all right now. Reviewed by: brooks, glebius Security: IPFW might pass IPv6 packets depending on stack contents. Approved by: re (blanket) ---------------------------- revision 1.101 date: 2005/06/10 12:28:17; author: green; state: Exp; lines: +32 -8 Modify send_pkt() to return the generated packet and have the caller do the subsequent ip_output() in IPFW. In ipfw_tick(), the keep-alive packets must be generated from the data that resides under the stateful lock, but they must not be sent at that time, as this would cause a lock order reversal with the normal ordering (interface's lock, then locks belonging to the pfil hooks). In practice, this caused deadlocks when using IPFW and if_bridge(4) together to do stateful transparent filtering. MFC after: 1 week ---------------------------- revision 1.100 date: 2005/06/04 19:04:31; author: green; state: Exp; lines: +3 -0 Better explain, then actually implement the IPFW ALTQ-rule first-match policy. It may be used to provide more detailed classification of traffic without actually having to decide its fate at the time of classification. MFC after: 1 week ---------------------------- revision 1.99 date: 2005/06/03 01:10:28; author: mlaier; state: Exp; lines: +7 -0 Add support for IPv4 only rules to IPFW2 now that it supports IPv6 as well. This is the last requirement before we can retire ip6fw. Reviewed by: dwhite, brooks(earlier version) Submitted by: dwhite (manpage) Silence from: -ipfw ---------------------------- revision 1.98 date: 2005/05/28 07:46:44; author: tanimura; state: Exp; lines: +5 -0 Let OSPFv3 go through ipfw. Some more additional checks would be desirable, though. ---------------------------- revision 1.97 date: 2005/05/04 13:12:52; author: glebius; state: Exp; lines: +0 -4 IPFW version 2 is the only option in HEAD and RELENG_5. Thus, cleanup unnecessary now ifdefs. ---------------------------- revision 1.96 date: 2005/04/26 18:10:21; author: brooks; state: Exp; lines: +5 -9 Introduce a struct icmphdr which contains the type, code, and cksum fields of an ICMP packet. Use this to allow ipfw to pullup only these values since it does not use the rest of the packet and it was failed on ICMP packets because they were not long enough. struct icmp should probably be modified to use these at some point, but that will break a fair bit of code so it can wait for another day. On the off chance that adding this struct breaks something in ports, bump __FreeBSD_version. Reported by: Randy Bush Tested by: Randy Bush ---------------------------- revision 1.95 date: 2005/04/19 10:04:38; author: phk; state: Exp; lines: +1 -1 typo ---------------------------- revision 1.94 date: 2005/04/19 09:56:14; author: phk; state: Exp; lines: +18 -3 Make IPFIREWALL compile without INET6 ---------------------------- revision 1.93 date: 2005/04/18 18:35:05; author: brooks; state: Exp; lines: +333 -32 Add IPv6 support to IPFW and Dummynet. Submitted by: Mariano Tortoriello and Raffaele De Lorenzo (via luigi) ---------------------------- revision 1.92 date: 2005/04/15 00:47:44; author: brooks; state: Exp; lines: +107 -90 Centralized finding the protocol header in IP packets in preperation for IPv6 support. The header in IPv6 is more complex then in IPv4 so we want to handle skipping over it in one location. Submitted by: Mariano Tortoriello and Raffaele De Lorenzo (via luigi) ---------------------------- revision 1.91 date: 2005/03/01 12:01:17; author: glebius; state: Exp; lines: +1 -1 Use NET_CALLOUT_MPSAFE macro. ---------------------------- revision 1.90 date: 2005/02/06 11:13:59; author: glebius; state: Exp; lines: +5 -0 Jump to common action checks after doing specific once. This fixes adding of divert rules, which I break in previous commit. Pointy hat to: glebius ---------------------------- revision 1.89 date: 2005/02/05 12:06:33; author: glebius; state: Exp; lines: +23 -0 Add a ng_ipfw node, implementing a quick and simple interface between ipfw(4) and netgraph(4) facilities. Reviewed by: andre, brooks, julian ---------------------------- revision 1.88 date: 2005/01/31 00:48:39; author: csjp; state: Exp; lines: +7 -2 Change the state allocator from using regular malloc to using a UMA zone instead. This should eliminate a bit of the locking overhead associated with with malloc and reduce the memory consumption associated with each new state. Reviewed by: rwatson, andre Silence on: ipfw@ MFC after: 1 week ---------------------------- revision 1.87 date: 2005/01/14 09:00:46; author: glebius; state: Exp; lines: +23 -26 o Clean up interface between ip_fw_chk() and its callers: - ip_fw_chk() returns action as function return value. Field retval is removed from args structure. Action is not flag any more. It is one of integer constants. - Any action-specific cookies are returned either in new "cookie" field in args structure (dummynet, future netgraph glue), or in mbuf tag attached to packet (divert, tee, some future action). o Convert parsing of return value from ip_fw_chk() in ipfw_check_{in,out}() to a switch structure, so that the functions are more readable, and a future actions can be added with less modifications. Approved by: andre MFC after: 2 months ---------------------------- revision 1.86 date: 2005/01/07 01:45:44; author: imp; state: Exp; lines: +1 -1 /* -> /*- for license, minor formatting changes ---------------------------- revision 1.85 date: 2004/12/10 02:17:18; author: csjp; state: Exp; lines: +69 -29 This commit adds a shared locking mechanism very similar to the mechanism used by pfil. This shared locking mechanism will remove a nasty lock order reversal which occurs when ucred based rules are used which results in hard locks while mpsafenet=1. So this removes the debug.mpsafenet=0 requirement when using ucred based rules with IPFW. It should be noted that this locking mechanism does not guarantee fairness between read and write locks, and that it will favor firewall chain readers over writers. This seemed acceptable since write operations to firewall chains protected by this lock tend to be less frequent than reads. Reviewed by: andre, rwatson Tested by: myself, seanc Silence on: ipfw@ MFC after: 1 month ---------------------------- revision 1.84 date: 2004/11/02 22:22:21; author: andre; state: Exp; lines: +0 -5 Remove RFC1644 T/TCP support from the TCP side of the network stack. A complete rationale and discussion is given in this message and the resulting discussion: http://docs.freebsd.org/cgi/mid.cgi?4177C8AD.6060706 Note that this commit removes only the functional part of T/TCP from the tcp_* related functions in the kernel. Other features introduced with RFC1644 are left intact (socket layer changes, sendmsg(2) on connection oriented protocols) and are meant to be reused by a simpler and less intrusive reimplemention of the previous T/TCP functionality. Discussed on: -arch ---------------------------- revision 1.83 date: 2004/10/22 19:18:06; author: andre; state: Exp; lines: +1 -1 When printing the initialization string and IPDIVERT is not compiled into the kernel refer to it as "loadable" instead of "disabled". ---------------------------- revision 1.82 date: 2004/10/19 21:14:57; author: andre; state: Exp; lines: +2 -4 Convert IPDIVERT into a loadable module. This makes use of the dynamic loadability of protocols. The call to divert_packet() is done through a function pointer. All semantics of IPDIVERT remain intact. If IPDIVERT is not loaded ipfw will refuse to install divert rules and natd will complain about 'protocol not supported'. Once it is loaded both will work and accept rules and open the divert socket. The module can only be unloaded if no divert sockets are open. It does not close any divert sockets when an unload is requested but will return EBUSY instead. ---------------------------- revision 1.81 date: 2004/10/03 00:47:15; author: green; state: Exp; lines: +23 -0 Add support to IPFW for matching by TCP data length. ---------------------------- revision 1.80 date: 2004/10/03 00:26:35; author: green; state: Exp; lines: +20 -1 Add support to IPFW for classification based on "diverted" status (that is, input via a divert socket). ---------------------------- revision 1.79 date: 2004/10/03 00:17:46; author: green; state: Exp; lines: +44 -0 Add to IPFW the ability to do ALTQ classification/tagging. ---------------------------- revision 1.78 date: 2004/09/30 17:42:00; author: green; state: Exp; lines: +5 -0 Validate the action pointer to be within the rule size, so that trying to add corrupt ipfw rules would not potentially panic the system or worse. ---------------------------- revision 1.77 date: 2004/09/29 04:54:33; author: mlaier; state: Exp; lines: +32 -11 Add an additional struct inpcb * argument to pfil(9) in order to enable passing along socket information. This is required to work around a LOR with the socket code which results in an easy reproducible hard lockup with debug.mpsafenet=1. This commit does *not* fix the LOR, but enables us to do so later. The missing piece is to turn the filter locking into a leaf lock and will follow in a seperate (later) commit. This will hopefully be MT5'ed in order to fix the problem for RELENG_5 in forseeable future. Suggested by: rwatson A lot of work by: csjp (he'd be even more helpful w/o mentor-reviews ;) Reviewed by: rwatson, csjp Tested by: -pf, -ipfw, LINT, csjp and myself MFC after: 3 days LOR IDs: 14 - 17 (not fixed yet) ---------------------------- revision 1.76 date: 2004/09/13 19:27:23; author: andre; state: Exp; lines: +4 -0 Do not allow 'ipfw fwd' command when IPFIREWALL_FORWARD is not compiled into the kernel. Return EINVAL instead. ---------------------------- revision 1.75 date: 2004/09/05 20:06:50; author: glebius; state: Exp; lines: +5 -2 Recover normal behavior: return EINVAL to attempt to add a divert rule when module is built without IPDIVERT. Silence from: andre Approved by: julian (mentor) ---------------------------- revision 1.74 date: 2004/08/26 14:18:30; author: ru; state: Exp; lines: +2 -0 Revert the last change to sys/modules/ipfw/Makefile and fix a standalone module build in a better way. Silence from: andre MFC after: 3 days ---------------------------- revision 1.73 date: 2004/08/19 23:31:40; author: andre; state: Exp; lines: +1 -1 When unloading ipfw module use callout_drain() to make absolutely sure that all callouts are stopped and finished. Move it before IPFW_LOCK() to avoid deadlocking when draining callouts. ---------------------------- revision 1.72 date: 2004/08/19 17:59:26; author: andre; state: Exp; lines: +0 -2 Do not unconditionally ignore IPDIVERT and IPFIREWALL_FORWARD when building the ipfw KLD. For IPFIREWALL_FORWARD this does not have any side effects. If the module has it but not the kernel it just doesn't do anything. For IPDIVERT the KLD will be unloadable if the kernel doesn't have IPDIVERT compiled in too. However this is the least disturbing behaviour. The user can just recompile either module or the kernel to match the other one. The access to the machine is not denied if ipfw refuses to load. ---------------------------- revision 1.71 date: 2004/08/19 17:38:47; author: andre; state: Exp; lines: +3 -0 Bring back the sysctl 'net.inet.ip.fw.enable' to unbreak the startup scripts and to be able to disable ipfw if it was compiled directly into the kernel. ---------------------------- revision 1.70 date: 2004/08/17 22:05:54; author: andre; state: Exp; lines: +14 -51 branches: 1.70.2; Convert ipfw to use PFIL_HOOKS. This is change is transparent to userland and preserves the ipfw ABI. The ipfw core packet inspection and filtering functions have not been changed, only how ipfw is invoked is different. However there are many changes how ipfw is and its add-on's are handled: In general ipfw is now called through the PFIL_HOOKS and most associated magic, that was in ip_input() or ip_output() previously, is now done in ipfw_check_[in|out]() in the ipfw PFIL handler. IPDIVERT is entirely handled within the ipfw PFIL handlers. A packet to be diverted is checked if it is fragmented, if yes, ip_reass() gets in for reassembly. If not, or all fragments arrived and the packet is complete, divert_packet is called directly. For 'tee' no reassembly attempt is made and a copy of the packet is sent to the divert socket unmodified. The original packet continues its way through ip_input/output(). ipfw 'forward' is done via m_tag's. The ipfw PFIL handlers tag the packet with the new destination sockaddr_in. A check if the new destination is a local IP address is made and the m_flags are set appropriately. ip_input() and ip_output() have some more work to do here. For ip_input() the m_flags are checked and a packet for us is directly sent to the 'ours' section for further processing. Destination changes on the input path are only tagged and the 'srcrt' flag to ip_forward() is set to disable destination checks and ICMP replies at this stage. The tag is going to be handled on output. ip_output() again checks for m_flags and the 'ours' tag. If found, the packet will be dropped back to the IP netisr where it is going to be picked up by ip_input() again and the directly sent to the 'ours' section. When only the destination changes, the route's 'dst' is overwritten with the new destination from the forward m_tag. Then it jumps back at the route lookup again and skips the firewall check because it has been marked with M_SKIP_FIREWALL. ipfw 'forward' has to be compiled into the kernel with 'option IPFIREWALL_FORWARD' to enable it. DUMMYNET is entirely handled within the ipfw PFIL handlers. A packet for a dummynet pipe or queue is directly sent to dummynet_io(). Dummynet will then inject it back into ip_input/ip_output() after it has served its time. Dummynet packets are tagged and will continue from the next rule when they hit the ipfw PFIL handlers again after re-injection. BRIDGING and IPFW_ETHER are not changed yet and use ipfw_chk() directly as they did before. Later this will be changed to dedicated ETHER PFIL_HOOKS. More detailed changes to the code: conf/files Add netinet/ip_fw_pfil.c. conf/options Add IPFIREWALL_FORWARD option. modules/ipfw/Makefile Add ip_fw_pfil.c. net/bridge.c Disable PFIL_HOOKS if ipfw for bridging is active. Bridging ipfw is still directly invoked to handle layer2 headers and packets would get a double ipfw when run through PFIL_HOOKS as well. netinet/ip_divert.c Removed divert_clone() function. It is no longer used. netinet/ip_dummynet.[ch] Neither the route 'ro' nor the destination 'dst' need to be stored while in dummynet transit. Structure members and associated macros are removed. netinet/ip_fastfwd.c Removed all direct ipfw handling code and replace it with the new 'ipfw forward' handling code. netinet/ip_fw.h Removed 'ro' and 'dst' from struct ip_fw_args. netinet/ip_fw2.c (Re)moved some global variables and the module handling. netinet/ip_fw_pfil.c New file containing the ipfw PFIL handlers and module initialization. netinet/ip_input.c Removed all direct ipfw handling code and replace it with the new 'ipfw forward' handling code. ip_forward() does not longer require the 'next_hop' struct sockaddr_in argument. Disable early checks if 'srcrt' is set. netinet/ip_output.c Removed all direct ipfw handling code and replace it with the new 'ipfw forward' handling code. netinet/ip_var.h Add ip_reass() as general function. (Used from ipfw PFIL handlers for IPDIVERT.) netinet/raw_ip.c Directly check if ipfw and dummynet control pointers are active. netinet/tcp_input.c Rework the 'ipfw forward' to local code to work with the new way of forward tags. netinet/tcp_sack.c Remove include 'opt_ipfw.h' which is not needed here. sys/mbuf.h Remove m_claim_next() macro which was exclusively for ipfw 'forward' and is no longer needed. Approved by: re (scottl) ---------------------------- revision 1.69 date: 2004/08/12 22:05:47; author: csjp; state: Exp; lines: +9 -1 Add the ability to associate ipfw rules with a specific prison ID. Since the only thing truly unique about a prison is it's ID, I figured this would be the most granular way of handling this. This commit makes the following changes: - Adds tokenizing and parsing for the ``jail'' command line option to the ipfw(8) userspace utility. - Append the ipfw opcode list with O_JAIL. - While Iam here, add a comment informing others that if they want to add additional opcodes, they should append them to the end of the list to avoid ABI breakage. - Add ``fw_prid'' to the ipfw ucred cache structure. - When initializing ucred cache, if the process is jailed, set fw_prid to the prison ID, otherwise set it to -1. - Update man page to reflect these changes. This change was a strong motivator behind the ucred caching mechanism in ipfw. A sample usage of this new functionality could be: ipfw add count ip from any to any jail 2 It should be noted that because ucred based constraints are only implemented for TCP and UDP packets, the same applies for jail associations. Conceptual head nod by: pjd Reviewed by: rwatson Approved by: bmilekic (mentor) ---------------------------- revision 1.68 date: 2004/08/11 11:41:11; author: andre; state: Exp; lines: +4 -4 Only invoke verify_path() for verrevpath and versrcreach when we have an IP packet. ---------------------------- revision 1.67 date: 2004/08/09 16:12:10; author: andre; state: Exp; lines: +11 -0 New ipfw option "antispoof": For incoming packets, the packet's source address is checked if it belongs to a directly connected network. If the network is directly connected, then the interface the packet came on in is compared to the interface the network is connected to. When incoming interface and directly connected interface are not the same, the packet does not match. Usage example: ipfw add deny ip from any to any not antispoof in Manpage education by: ru ---------------------------- revision 1.66 date: 2004/07/21 19:55:14; author: andre; state: Exp; lines: +6 -0 Extend versrcreach by checking against the rt_flags for RTF_REJECT and RTF_BLACKHOLE as well. To quote the submitter: The uRPF loose-check implementation by the industry vendors, at least on Cisco and possibly Juniper, will fail the check if the route of the source address is pointed to Null0 (on Juniper, discard or reject route). What this means is, even if uRPF Loose-check finds the route, if the route is pointed to blackhole, uRPF loose-check must fail. This allows people to utilize uRPF loose-check mode as a pseudo-packet-firewall without using any manual filtering configuration -- one can simply inject a IGP or BGP prefix with next-hop set to a static route that directs to null/discard facility. This results in uRPF Loose-check failing on all packets with source addresses that are within the range of the nullroute. Submitted by: James Jun ---------------------------- revision 1.65 date: 2004/07/17 02:40:13; author: jmallett; state: Exp; lines: +0 -12 Make M_SKIP_FIREWALL a global (and semantic) flag, preventing anything from using M_PROTO6 and possibly shooting someone's foot, as well as allowing the firewall to be used in multiple passes, or with a packet classifier frontend, that may need to explicitly allow a certain packet. Presently this is handled in the ipfw_chk code as before, though I have run with it moved to upper layers, and possibly it should apply to ipfilter and pf as well, though this has not been investigated. Discussed with: luigi, rwatson ---------------------------- revision 1.64 date: 2004/07/15 08:26:07; author: phk; state: Exp; lines: +1 -0 Do a pass over all modules in the kernel and make them return EOPNOTSUPP for unknown events. A number of modules return EINVAL in this instance, and I have left those alone for now and instead taught MOD_QUIESCE to accept this as "didn't do anything". ---------------------------- revision 1.63 date: 2004/06/24 02:01:48; author: rwatson; state: Exp; lines: +4 -1 When asserting non-Giant locks in the network stack, also assert Giant if debug.mpsafenet=0, as any points that require synchronization in the SMPng world also required it in the Giant-world: - inpcb locks (including IPv6) - inpcbinfo locks (including IPv6) - dummynet subsystem lock - ipfw2 subsystem lock ---------------------------- revision 1.62 date: 2004/06/11 22:17:14; author: csjp; state: Exp; lines: +77 -30 Modify ip fw so that whenever UID or GID constraints exist in a ruleset, the pcb is looked up once per ipfw_chk() activation. This is done by extracting the required information out of the PCB and caching it to the ipfw_chk() stack. This should greatly reduce PCB looking contention and speed up the processing of UID/GID based firewall rules (especially with large UID/GID rulesets). Some very basic benchmarks were taken which compares the number of in_pcblookup_hash(9) activations to the number of firewall rules containing UID/GID based contraints before and after this patch. The results can be viewed here: o http://people.freebsd.org/~csjp/ip_fw_pcb.png Reviewed by: andre, luigi, rwatson Approved by: bmilekic (mentor) ---------------------------- revision 1.61 date: 2004/06/10 20:20:37; author: ru; state: Exp; lines: +4 -1 init_tables() must be run after sys/net/route.c:route_init(). ---------------------------- revision 1.60 date: 2004/06/09 20:10:38; author: ru; state: Exp; lines: +324 -1 Introduce a new feature to IPFW2: lookup tables. These are useful for handling large sparse address sets. Initial implementation by Vsevolod Lobko , refined by me. MFC after: 1 week ---------------------------- revision 1.59 date: 2004/05/30 17:57:45; author: phk; state: Exp; lines: +1 -0 Add some missing includes which are masked by the one on death-row in ---------------------------- revision 1.58 date: 2004/05/25 15:02:12; author: csjp; state: Exp; lines: +4 -0 Add a super-user check to ipfw_ctl() to make sure that the calling process is a non-prison root. The security.jail.allow_raw_sockets sysctl variable is disabled by default, however if the user enables raw sockets in prisons, prison-root should not be able to interact with firewall rule sets. Approved by: rwatson, bmilekic (mentor) ---------------------------- revision 1.57 date: 2004/04/23 14:27:27; author: andre; state: Exp; lines: +31 -7 Add the option versrcreach to verify that a valid route to the source address of a packet exists in the routing table. The default route is ignored because it would match everything and render the check pointless. This option is very useful for routers with a complete view of the Internet (BGP) in the routing table to reject packets with spoofed or unrouteable source addresses. Example: ipfw add 1000 deny ip from any to any not versrcreach also known in Cisco-speak as: ip verify unicast source reachable-via any Reviewed by: luigi ---------------------------- revision 1.56 date: 2004/02/25 19:55:28; author: mlaier; state: Exp; lines: +25 -5 Re-remove MT_TAGs. The problems with dummynet have been fixed now. Tested by: -current, bms(mentor), me Approved by: bms(mentor), sam ---------------------------- revision 1.55 date: 2004/02/18 00:04:51; author: mlaier; state: Exp; lines: +5 -25 Backout MT_TAG removal (i.e. bring back MT_TAGs) for now, as dummynet is not working properly with the patch in place. Approved by: bms(mentor) ---------------------------- revision 1.54 date: 2004/02/13 19:14:15; author: mlaier; state: Exp; lines: +25 -5 This set of changes eliminates the use of MT_TAG "pseudo mbufs", replacing them mostly with packet tags (one case is handled by using an mbuf flag since the linkage between "caller" and "callee" is direct and there's no need to incur the overhead of a packet tag). This is (mostly) work from: sam Silence from: -arch Approved by: bms(mentor), sam, rwatson ---------------------------- revision 1.53 date: 2003/12/24 18:22:04; author: ume; state: Exp; lines: +1 -1 NULL is not 0. Submitted by: "Bjoern A. Zeeb" ---------------------------- revision 1.52 date: 2003/12/16 18:21:47; author: maxim; state: Exp; lines: +1 -1 o IN_MULTICAST wants an address in host byte order. PR: kern/60304 Submitted by: demon MFC after: 1 week ---------------------------- revision 1.51 date: 2003/12/02 00:23:45; author: sam; state: Exp; lines: +1 -0 branches: 1.51.2; Include opt_ipsec.h so IPSEC/FAST_IPSEC is defined and the appropriate code is compiled in to support the O_IPSEC operator. Previously no support was included and ipsec rules were always matching. Note that we do not return an error when an ipsec rule is added and the kernel does not have IPsec support compiled in; this is done intentionally but we may want to revisit this (document this in the man page). PR: 58899 Submitted by: Bjoern A. Zeeb Approved by: re (rwatson) ---------------------------- revision 1.50 date: 2003/11/27 09:40:13; author: andre; state: Exp; lines: +7 -13 Fix verify_rev_path() function. The author of this function tried to cut corners which completely broke down when the routing table locking was introduced. Reviewed by: sam (mentor) Approved by: re (rwatson) ---------------------------- revision 1.49 date: 2003/11/24 03:57:03; author: sam; state: Exp; lines: +9 -5 Correct a problem where ipfw-generated packets were being returned for ipfw processing w/o an indication the packets were generated by ipfw--and so should not be processed (this manifested itself as a LOR.) The flag bit in the mbuf that was used to mark the packets was not listed in M_COPYFLAGS so if a packet had a header prepended (as done by IPsec) the flag was lost. Correct this by defining a new M_PROTO6 flag and use it to mark packets that need this processing. Reviewed by: bms Approved by: re (rwatson) MFC after: 2 weeks ---------------------------- revision 1.48 date: 2003/11/23 18:13:41; author: sam; state: Exp; lines: +1 -1 Use MPSAFE callouts only when debug.mpsafenet is 1. Both timer routines potentially transmit packets that may enter KAME IPsec w/o Giant if the callouts are marked MPSAFE. Reviewed by: ume Approved by: re (rwatson) ---------------------------- revision 1.47 date: 2003/11/20 20:07:37; author: andre; state: Exp; lines: +6 -3 Introduce tcp_hostcache and remove the tcp specific metrics from the routing table. Move all usage and references in the tcp stack from the routing table metrics to the tcp hostcache. It caches measured parameters of past tcp sessions to provide better initial start values for following connections from or to the same source or destination. Depending on the network parameters to/from the remote host this can lead to significant speedups for new tcp connections after the first one because they inherit and shortcut the learning curve. tcp_hostcache is designed for multiple concurrent access in SMP environments with high contention and is hash indexed by remote ip address. It removes significant locking requirements from the tcp stack with regard to the routing table. Reviewed by: sam (mentor), bms Reviewed by: -net, -current, core@kame.net (IPv6 parts) Approved by: re (scottl) ---------------------------- revision 1.46 date: 2003/11/20 19:47:30; author: andre; state: Exp; lines: +1 -1 Remove RTF_PRCLONING from routing table and adjust users of it accordingly. The define is left intact for ABI compatibility with userland. This is a pre-step for the introduction of tcp_hostcache. The network stack remains fully useable with this change. Reviewed by: sam (mentor), bms Reviewed by: -net, -current, core@kame.net (IPv6 parts) Approved by: re (scottl) ---------------------------- revision 1.45 date: 2003/11/20 10:28:33; author: maxim; state: Exp; lines: +2 -2 Fix an arguments order in check_uidgid() call. PR: kern/59314 Submitted by: Andrey V. Shytov Approved by: re (rwatson, jhb) ---------------------------- revision 1.44 date: 2003/11/14 21:48:56; author: andre; state: Exp; lines: +1 -6 Remove the global one-level rtcache variable and associated complex locking and rework ip_rtaddr() to do its own rtlookup. Adopt all its callers to this and make ip_output() callable with NULL rt pointer. Reviewed by: sam (mentor) ---------------------------- revision 1.43 date: 2003/11/07 23:26:57; author: sam; state: Exp; lines: +60 -40 Move uid/gid checking logic out of line and lock inpcb usage. This has a LOR between IPFW inpcb locks but I'm committing it now as the lesser of two evils (the other being unlocked use of in_pcblookup). Supported by: FreeBSD Foundation ---------------------------- revision 1.42 date: 2003/11/07 20:25:47; author: ume; state: Exp; lines: +1 -1 use ipsec_getnhist() instead of obsoleted ipsec_gethist(). Submitted by: "Bjoern A. Zeeb" Reviewed by: Ari Suutari (ipfw@) ---------------------------- revision 1.41 date: 2003/10/31 18:32:11; author: brooks; state: Exp; lines: +9 -8 Replace the if_name and if_unit members of struct ifnet with new members if_xname, if_dname, and if_dunit. if_xname is the name of the interface and if_dname/unit are the driver name and instance. This change paves the way for interface renaming and enhanced pseudo device creation and configuration symantics. Approved By: re (in principle) Reviewed By: njl, imp Tested On: i386, amd64, sparc64 Obtained From: NetBSD (if_xname) ---------------------------- revision 1.40 date: 2003/10/16 02:00:12; author: mckusick; state: Exp; lines: +7 -4 Malloc buckets of size 128 have been having their 64-byte offset trashed after being freed. This has caused several panics including kern/42277 related to soft updates. Jim Kuhn tracked the problem down to ipfw limit rule processing. In the expiry of dynamic rules, it is possible for an O_LIMIT_PARENT rule to be removed when it still has live children. When the children eventually do expire, a pointer to the (long gone) parent is dereferenced and a count decremented. Since this memory can, and is, allocated for other purposes (in the case of kern/42277 an inodedep structure), chaos ensues. The offset in question in inodedep is the offset of the 16 bit count field in the ipfw2 ipfw_dyn_rule. Submitted by: Jim Kuhn Reviewed by: "Evgueni V. Gavrilov" Reviewed by: Ben Pfountz MFC after: 1 week ---------------------------- revision 1.39 date: 2003/09/17 22:06:47; author: sam; state: Exp; lines: +2 -1 Bandaid locking change: mark static rule mutex recursive so re-entry when sending an ICMP packet doesn't cause a panic. A better solution is needed; possibly defering the transmit to a dedicated thread. Observed by: "Aaron Wohl" ---------------------------- revision 1.38 date: 2003/09/17 00:56:50; author: sam; state: Exp; lines: +309 -164 Add locking. o change timeout to MPSAFE callout o restructure rule deletion to deal with locking requirements o replace static buffer used for ipfw control operations with malloc'd storage Sponsored by: FreeBSD Foundation ---------------------------- revision 1.37 date: 2003/07/15 23:07:34; author: luigi; state: Exp; lines: +27 -23 Allow set 31 to be used for rules other than 65535. Set 31 is still special because rules belonging to it are not deleted by the "ipfw flush" command, but must be deleted explicitly with "ipfw delete set 31" or by individual rule numbers. This implement a flexible form of "persistent rules" which you might want to have available even after an "ipfw flush". Note that this change does not violate POLA, because you could not use set 31 in a ruleset before this change. sbin/ipfw changes to allow manipulation of set 31 will follow shortly. Suggested by: Paul Richards ---------------------------- revision 1.36 date: 2003/07/12 05:54:17; author: luigi; state: Exp; lines: +1 -1 Implement comments embedded into ipfw2 instructions. Since we already had 'O_NOP' instructions which always match, all I needed to do is allow the NOP command to have arbitrary length (i.e. move its label in a different part of the switch() which validates instructions). The kernel must know nothing about comments, everything else is done in userland (which will be described in the upcoming ipfw2.c commit). ---------------------------- revision 1.35 date: 2003/07/08 07:44:42; author: luigi; state: Exp; lines: +13 -17 Merge the handlers of O_IP_SRC_MASK and O_IP_DST_MASK opcodes, and support matching a list of addr/mask pairs so one can write more efficient rulesets which were not possible before e.g. add 100 skipto 1000 not src-ip 10.0.0.0/8,127.0.0.1/8,192.168.0.0/16 The change is fully backward compatible. ipfw2 and manpage commit to follow. MFC after: 3 days ---------------------------- revision 1.34 date: 2003/07/04 21:42:32; author: luigi; state: Exp; lines: +16 -0 Implement the 'ipsec' option to match packets coming out of an ipsec tunnel. Should work with both regular and fast ipsec (mutually exclusive). See manpage for more details. Submitted by: Ari Suutari (ari.suutari@syncrontech.com) Revised by: sam MFC after: 1 week ---------------------------- revision 1.33 date: 2003/06/28 14:16:53; author: luigi; state: Exp; lines: +1 -1 whitespace fix ---------------------------- revision 1.32 date: 2003/06/23 21:18:56; author: luigi; state: Exp; lines: +4 -4 Remove whitespace at end of line. ---------------------------- revision 1.31 date: 2003/06/22 17:33:19; author: luigi; state: Exp; lines: +29 -12 Add support for multiple values and ranges for the "iplen", "ipttl", "ipid" options. This feature has been requested by several users. On passing, fix some minor bugs in the parser. This change is fully backward compatible so if you have an old /sbin/ipfw and a new kernel you are not in trouble (but you need to update /sbin/ipfw if you want to use the new features). Document the changes in the manpage. Now you can write things like ipfw add skipto 1000 iplen 0-500 which some people were asking to give preferential treatment to short packets. The 'MFC after' is just set as a reminder, because I still need to merge the Alpha/Sparc64 fixes for ipfw2 (which unfortunately change the size of certain kernel structures; not that it matters a lot since ipfw2 is entirely optional and not the default...) PR: bin/48015 MFC after: 1 week ---------------------------- revision 1.30 date: 2003/06/04 01:17:37; author: ticso; state: Exp; lines: +15 -6 Change handling to support strong alignment architectures such as alpha and sparc64. PR: alpha/50658 Submitted by: rizzo Tested on: alpha ---------------------------- revision 1.29 date: 2003/06/02 23:54:09; author: kbyanc; state: Exp; lines: +6 -3 Account for packets processed at layer-2 (i.e. net.link.ether.ipfw=1). MFC after: 2 weeks ---------------------------- revision 1.28 date: 2003/03/15 01:13:00; author: cjc; state: Exp; lines: +50 -0 branches: 1.28.2; Add a 'verrevpath' option that verifies the interface that a packet comes in on is the same interface that we would route out of to get to the packet's source address. Essentially automates an anti-spoofing check using the information in the routing table. Experimental. The usage and rule format for the feature may still be subject to change. ---------------------------- revision 1.27 date: 2003/02/19 05:47:34; author: imp; state: Exp; lines: +2 -2 Back out M_* changes, per decision of the TRB. Approved by: trb ---------------------------- revision 1.26 date: 2003/02/17 13:39:57; author: maxim; state: Exp; lines: +2 -2 o Fix ipfw uid rules: socheckuid() returns 0 when uid matches a socket cr_uid. Note: we do not have socheckuid() in RELENG_4, ip_fw2.c uses its own macro for a similar purpose that is why ipfw2 in RELENG_4 processes uid rules correctly. I will MFC the diff for code consistency. Reported by: Oleg Baranov Reviewed by: luigi MFC after: 1 month ---------------------------- revision 1.25 date: 2003/01/21 08:56:03; author: alfred; state: Exp; lines: +2 -2 Remove M_TRYWAIT/M_WAITOK/M_WAIT. Callers should use 0. Merge M_NOWAIT/M_DONTWAIT into a single flag M_NOWAIT. ---------------------------- revision 1.24 date: 2003/01/20 11:58:34; author: maxim; state: Exp; lines: +2 -0 If the first action is O_LOG adjust a pointer to the real one, unbreaks skipto + log rules. Reported by: Wiktor Niesiobedzki MFC after: 1 week ---------------------------- revision 1.23 date: 2003/01/14 19:35:33; author: dillon; state: Exp; lines: +3 -3 Introduce the ability to flag a sysctl for operation at secure level 2 or 3 in addition to secure level 1. The mask supports up to a secure level of 8 but only add defines through CTLFLAG_SECURE3 for now. As per the missif in the log entry for 1.11 of ip_fw2.c which added the secure flag to the IPFW sysctl's in the first place, change the secure level requirement from 1 to 3 now that we have support for it. Reviewed by: imp With Design Suggestions by: imp ---------------------------- revision 1.22 date: 2002/12/27 17:43:25; author: iedowse; state: Exp; lines: +8 -2 Bridged packets are supplied to the firewall with their IP header in network byte order, but icmp_error() expects the IP header to be in host order and the code here did not perform the necessary swapping for the bridged case. This bug causes an "icmp_error: bad length" panic when certain length IP packets (e.g. ip_len == 0x100) are rejected by the firewall with an ICMP response. MFC after: 3 days ---------------------------- revision 1.21 date: 2002/12/24 13:45:23; author: maxim; state: Exp; lines: +16 -15 o De-anonymity dummynet(4) and ipfw(4) messages, prepend them by 'dummynet: ' and 'ipfw: ' prefixes. PR: kern/41609 ---------------------------- revision 1.20 date: 2002/12/15 09:44:02; author: maxim; state: Exp; lines: +1 -1 o Fix byte order logging issue: sa.sin_port is already in host byte order. PR: kern/45964 Submitted by: Sascha Blank Reviewed by: luigi MFC after: 1 week ---------------------------- revision 1.19 date: 2002/11/20 19:07:27; author: luigi; state: Exp; lines: +0 -1 branches: 1.19.2; Move fw_one_pass from ip_fw2.c to ip_input.c so that neither bridge.c nor if_ethersubr.c depend on IPFIREWALL. Restore the use of fw_one_pass in if_ethersubr.c ipfw.8 will be updated with a separate commit. Approved by: re ---------------------------- revision 1.18 date: 2002/10/29 08:53:14; author: maxim; state: Exp; lines: +1 -1 Lower a priority of "session drop" messages. Requested by: Eugene Grosbein MFC after: 3 days ---------------------------- revision 1.17 date: 2002/10/24 18:04:44; author: mux; state: Exp; lines: +2 -6 Fix ipfw2 panics on 64-bit platforms. Quoting luigi: In order to make the userland code fully 64-bit clean it may be necessary to commit other changes that may or may not cause a minor change in the ABI. Reviewed by: luigi ---------------------------- revision 1.16 date: 2002/10/24 18:01:53; author: luigi; state: Exp; lines: +2 -2 src and dst address were erroneously swapped in SRC_SET and DST_SET commands. Use the correct one. Also affects ipfw2 in -stable. ---------------------------- revision 1.15 date: 2002/10/23 10:07:55; author: maxim; state: Exp; lines: +23 -24 Kill EOL spaces. Approved by: luigi MFC after: 1 week ---------------------------- revision 1.14 date: 2002/10/23 10:05:19; author: maxim; state: Exp; lines: +1 -1 Use syslog for messages about dropped sessions, do not flood a console. Suggested by: Eugene Grosbein Approved by: luigi MFC after: 1 week ---------------------------- revision 1.13 date: 2002/10/19 11:31:50; author: mux; state: Exp; lines: +3 -3 Several malloc() calls were passing the M_DONTWAIT flag which is an mbuf allocation flag. Use the correct M_NOWAIT malloc() flag. Fortunately, both were defined to 1, so this commit is a no-op. ---------------------------- revision 1.12 date: 2002/10/16 01:54:44; author: sam; state: Exp; lines: +1 -1 Replace aux mbufs with packet tags: o instead of a list of mbufs use a list of m_tag structures a la openbsd o for netgraph et. al. extend the stock openbsd m_tag to include a 32-bit ABI/module number cookie o for openbsd compatibility define a well-known cookie MTAG_ABI_COMPAT and use this in defining openbsd-compatible m_tag_find and m_tag_get routines o rewrite KAME use of aux mbufs in terms of packet tags o eliminate the most heavily used aux mbufs by adding an additional struct inpcb parameter to ip_output and ip6_output to allow the IPsec code to locate the security policy to apply to outbound packets o bump __FreeBSD_version so code can be conditionalized o fixup ipfilter's call to ip_output based on __FreeBSD_version Reviewed by: julian, luigi (silent), -arch, -net, darren Approved by: julian, silence from everyone else Obtained from: openbsd (mostly) MFC after: 1 month ---------------------------- revision 1.11 date: 2002/08/25 03:50:17; author: cjc; state: Exp; lines: +6 -3 Lock the sysctl(8) knobs that turn ip{,6}fw(8) firewalling and firewall logging on and off when at elevated securelevel(8). It would be nice to be able to only lock these at securelevel >= 3, like rules are, but there is no such functionality at present. I don't see reason to be adding features to securelevel(8) with MAC being merged into 5.0. PR: kern/39396 Reviewed by: luigi MFC after: 1 week ---------------------------- revision 1.10 date: 2002/08/19 04:45:01; author: luigi; state: Exp; lines: +4 -6 Raise limit for port lists to 30 entries/ranges. Remove a duplicate "logging" message, and identify the firewall as ipfw2 in the boot message. ---------------------------- revision 1.9 date: 2002/08/16 10:31:47; author: luigi; state: Exp; lines: +116 -47 sys/netinet/ip_fw2.c: Implement the M_SKIP_FIREWALL bit in m_flags to avoid loops for firewall-generated packets (the constant has to go in sys/mbuf.h). Better comments on keepalive generation, and enforce dyn_rst_lifetime and dyn_fin_lifetime to be less than dyn_keepalive_period. Enforce limits (up to 64k) on the number of dynamic buckets, and retry allocation with smaller sizes. Raise default number of dynamic rules to 4096. Improved handling of set of rules -- now you can atomically enable/disable multiple sets, move rules from one set to another, and swap sets. sbin/ipfw/ipfw2.c: userland support for "noerror" pipe attribute. userland support for sets of rules. minor improvements on rule parsing and printing. sbin/ipfw/ipfw.8: more documentation on ipfw2 extensions, differences from ipfw1 (so we can use the same manpage for both), stateful rules, and some additional examples. Feedback and more examples needed here. ---------------------------- revision 1.8 date: 2002/08/13 19:13:23; author: phk; state: Exp; lines: +1 -1 remove spurious printf ---------------------------- revision 1.7 date: 2002/08/10 04:37:32; author: luigi; state: Exp; lines: +95 -18 One bugfix and one new feature. The bugfix (ipfw2.c) makes the handling of port numbers with a dash in the name, e.g. ftp-data, consistent with old ipfw: use \\ before the - to consider it as part of the name and not a range separator. The new feature (all this description will go in the manpage): each rule now belongs to one of 32 different sets, which can be optionally specified in the following form: ipfw add 100 set 23 allow ip from any to any If "set N" is not specified, the rule belongs to set 0. Individual sets can be disabled, enabled, and deleted with the commands: ipfw disable set N ipfw enable set N ipfw delete set N Enabling/disabling of a set is atomic. Rules belonging to a disabled set are skipped during packet matching, and they are not listed unless you use the '-S' flag in the show/list commands. Note that dynamic rules, once created, are always active until they expire or their parent rule is deleted. Set 31 is reserved for the default rule and cannot be disabled. All sets are enabled by default. The enable/disable status of the sets can be shown with the command ipfw show sets Hopefully, this feature will make life easier to those who want to have atomic ruleset addition/deletion/tests. Examples: To add a set of rules atomically: ipfw disable set 18 ipfw add ... set 18 ... # repeat as needed ipfw enable set 18 To delete a set of rules atomically ipfw disable set 18 ipfw delete set 18 ipfw enable set 18 To test a ruleset and disable it and regain control if something goes wrong: ipfw disable set 18 ipfw add ... set 18 ... # repeat as needed ipfw enable set 18 ; echo "done "; sleep 30 && ipfw disable set 18 here if everything goes well, you press control-C before the "sleep" terminates, and your ruleset will be left active. Otherwise, e.g. if you cannot access your box, the ruleset will be disabled after the sleep terminates. I think there is only one more thing that one might want, namely a command to assign all rules in set X to set Y, so one can test a ruleset using the above mechanisms, and once it is considered acceptable, make it part of an existing ruleset. ---------------------------- revision 1.6 date: 2002/07/24 02:41:19; author: luigi; state: Exp; lines: +2 -1 branches: 1.6.2; Only log things net.inet.ip.fw.verbose is set ---------------------------- revision 1.5 date: 2002/07/14 23:47:18; author: luigi; state: Exp; lines: +145 -104 Implement keepalives for dynamic rules, so they will not expire just because you leave your session idle. Also, put in a fix for 64-bit architectures (to be revised). In detail: ip_fw.h * Reorder fields in struct ip_fw to avoid alignment problems on 64-bit machines. This only masks the problem, I am still not sure whether I am doing something wrong in the code or there is a problem elsewhere (e.g. different aligmnent of structures between userland and kernel because of pragmas etc.) * added fields in dyn_rule to store ack numbers, so we can generate keepalives when the dynamic rule is about to expire ip_fw2.c * use a local function, send_pkt(), to generate TCP RST for Reset rules; * save about 250 bytes by cleaning up the various snprintf() in ipfw_log() ... * ... and use twice as many bytes to implement keepalives (this seems to be working, but i have not tested it extensively). Keepalives are generated once every 5 seconds for the last 20 seconds of the lifetime of a dynamic rule for an established TCP flow. The packets are sent to both sides, so if at least one of the endpoints is responding, the timeout is refreshed and the rule will not expire. You can disable this feature with sysctl net.inet.ip.fw.dyn_keepalive=0 (the default is 1, to have them enabled). MFC after: 1 day (just kidding... I will supply an updated version of ipfw2 for RELENG_4 tomorrow). ---------------------------- revision 1.4 date: 2002/07/08 22:46:01; author: luigi; state: Exp; lines: +266 -278 No functional changes, but: Following Darren's suggestion, make Dijkstra happy and rewrite the ipfw_chk() main loop removing a lot of goto's and using instead a variable to store match status. Add a lot of comments to explain what instructions are supposed to do and how -- this should ease auditing of the code and make people more confident with it. In terms of code size: the entire file takes about 12700 bytes of text, about 3K of which are for the main function, ipfw_chk(), and 2K (ouch!) for ipfw_log(). ---------------------------- revision 1.3 date: 2002/07/05 22:43:06; author: luigi; state: Exp; lines: +110 -36 Implement the last 2-3 missing instructions for ipfw, now it should support all the instructions of the old ipfw. Fix some bugs in the user interface, /sbin/ipfw. Please check this code against your rulesets, so i can fix the remaining bugs (if any, i think they will be mostly in /sbin/ipfw). Once we have done a bit of testing, this code is ready to be MFC'ed, together with a bunch of other changes (glue to ipfw, and also the removal of some global variables) which have been in -current for a couple of weeks now. MFC after: 7 days ---------------------------- revision 1.2 date: 2002/06/28 08:36:26; author: dfr; state: Exp; lines: +1 -1 Fix warning. Reviewed by: luigi ---------------------------- revision 1.1 date: 2002/06/27 23:02:17; author: luigi; state: Exp; The new ipfw code. This code makes use of variable-size kernel representation of rules (exactly the same concept of BPF instructions, as used in the BSDI's firewall), which makes firewall operation a lot faster, and the code more readable and easier to extend and debug. The interface with the rest of the system is unchanged, as witnessed by this commit. The only extra kernel files that I am touching are if_fw.h and ip_dummynet.c, which is quite tied to ipfw. In userland I only had to touch those programs which manipulate the internal representation of firewall rules). The code is almost entirely new (and I believe I have written the vast majority of those sections which were taken from the former ip_fw.c), so rather than modifying the old ip_fw.c I decided to create a new file, sys/netinet/ip_fw2.c . Same for the user interface, which is in sbin/ipfw/ipfw2.c (it still compiles to /sbin/ipfw). The old files are still there, and will be removed in due time. I have not renamed the header file because it would have required touching a one-line change to a number of kernel files. In terms of user interface, the new "ipfw" is supposed to accepts the old syntax for ipfw rules (and produce the same output with "ipfw show". Only a couple of the old options (out of some 30 of them) has not been implemented, but they will be soon. On the other hand, the new code has some very powerful extensions. First, you can put "or" connectives between match fields (and soon also between options), and write things like ipfw add allow ip from { 1.2.3.4/27 or 5.6.7.8/30 } 10-23,25,1024-3000 to any This should make rulesets slightly more compact (and lines longer!), by condensing 2 or more of the old rules into single ones. Also, as an example of how easy the rules can be extended, I have implemented an 'address set' match pattern, where you can specify an IP address in a format like this: 10.20.30.0/26{18,44,33,22,9} which will match the set of hosts listed in braces belonging to the subnet 10.20.30.0/26 . The match is done using a bitmap, so it is essentially a constant time operation requiring a handful of CPU instructions (and a very small amount of memmory -- for a full /24 subnet, the instruction only consumes 40 bytes). Again, in this commit I have focused on functionality and tried to minimize changes to the other parts of the system. Some performance improvement can be achieved with minor changes to the interface of ip_fw_chk_t. This will be done later when this code is settled. The code is meant to compile unmodified on RELENG_4 (once the PACKET_TAG_* changes have been merged), for this reason you will see #ifdef __FreeBSD_version in a couple of places. This should minimize errors when (hopefully soon) it will be time to do the MFC. ---------------------------- revision 1.6.2.23 date: 2004/09/13 07:21:17; author: maxim; state: Exp; lines: +5 -2 MFC rev.1.75: recover normal behavior: return EINVAL to attempt to add a divert rule when module is built without IPDIVERT. ---------------------------- revision 1.6.2.22 date: 2004/06/16 06:57:49; author: ru; state: Exp; lines: +335 -0 MFC: IPFW2 lookup tables. ---------------------------- revision 1.6.2.21 date: 2004/04/02 17:15:44; author: andre; state: Exp; lines: +13 -16 MFC of rev 1.50, fix refcount leak in verify_rev_path() function. Reviewed by: sam ---------------------------- revision 1.6.2.20 date: 2004/01/22 08:50:26; author: maxim; state: Exp; lines: +1 -0 MFC rev. 1.51: include opt_ipsec.h so IPSEC/FAST_IPSEC is defined and the appropriate code is compiled in to support the O_IPSEC operator. ---------------------------- revision 1.6.2.19 date: 2003/12/23 12:23:57; author: maxim; state: Exp; lines: +1 -1 MFC rev. 1.52: IN_MULTICAST wants an address in host byte order. ---------------------------- revision 1.6.2.18 date: 2003/10/17 11:01:03; author: scottl; state: Exp; lines: +7 -4 MFC Rev 1.40 to fix use-after-free problems with dynamic rules. Submitted by: mckusick Approved by: re (murray> ---------------------------- revision 1.6.2.17 date: 2003/10/01 07:07:07; author: bms; state: Exp; lines: +3 -3 MFC: The knobs controlling ipfw2 and ip6fw were not protected when running at an elevated securelevel. Fix this behaviour and function as documented. PR: kern/39396 Approved by: re (rwatson) ---------------------------- revision 1.6.2.16 date: 2003/07/17 06:03:39; author: luigi; state: Exp; lines: +66 -45 MFC: sync ipfw2 with the version in -current, including: * implement a '-n' option to do a syntax-check only of ipfw2 rules; * allow spaces after commas in ipfw rules; * support for comma-separated address lists e.g. ipfw add allow ip from not 10.0.0.0/8, 192.168.0.0/16, 1.2.3.4 to me (note the possibility to put a 'not' in front of the entire list, which was not possible with "or blocks"); * allow comments in ipfw rules which are stored together with rules and appear upon an 'ipfw show': ipfw add allow udp from any to any 53 // nameserver * allow set 31 to be used for ordinary (non-default) rules, but with the special feature that rules in set 31 cannot be disabled and are not affected by a 'flush' command (so they must be deleted explicitly). This permits a flexible form of "persistent" rules which should survive across firewall reloads. * allow ranges to be specified in the "ipfw show" and "ipfw list" commands (the same ought to be done for ""ipfw delete"): ipfw show 100-1000 2000 3000-5500 I believe the kernel side of these changes is entirely backward compatible with the old /sbin/ipfw[2], though of course you need to update the userland command to use the new features. ---------------------------- revision 1.6.2.15 date: 2003/06/28 16:12:13; author: luigi; state: Exp; lines: +94 -23 MFC: sync ipfw2 (kernel, userland, manpage) with the version in -current. Among other things, this includes the following: + pass to the preprocessor all command-line options after -p (except the last one, the ruleset file) + add the "verrevpath" option + support strong alignment architectures such as alpha and sparc64; + support multiple values and ranges for "iplen", "ipttl", "ipid" options. + support range notations such as 1.2.3.4/24{5,6,7,10-20,60-90} for sets of IP addresses The changes (also those in sys/netinet/ip_dummynet.c) are all IPFW2-specific, which is entirely optional in RELENG_4 so there are no ABI issues for those using the standard ipfw[1]. Note, however, that ipfw2 users MUST REBUILD /sbin/ipfw together with the new kernel. ---------------------------- revision 1.6.2.14 date: 2003/06/23 22:00:21; author: luigi; state: Exp; lines: +16 -15 MFC: add subsystem names in front of the messages generated by ipfw[2] and dummynet. There ought to be a better way to do this, something similar to device_printf() which automatically generates the subsystem names! ---------------------------- revision 1.6.2.13 date: 2003/06/18 02:55:08; author: kbyanc; state: Exp; lines: +6 -3 MFC revision 1.29: Account for packets processed at layer-2 (i.e. net.link.ether.ipfw=1). ---------------------------- revision 1.6.2.12 date: 2003/04/08 10:42:32; author: maxim; state: Exp; lines: +2 -2 MFC rev. 1.26: make socheckuid() consistent across branches. ---------------------------- revision 1.6.2.11 date: 2003/01/27 13:45:20; author: maxim; state: Exp; lines: +2 -0 MFC rev. 1.24: if the first action is O_LOG adjust a pointer to the real one, unbreaks skipto + log rules. ---------------------------- revision 1.6.2.10 date: 2003/01/23 21:06:45; author: sam; state: Exp; lines: +1 -1 MFC: m_tag support Replace aux mbufs with packet tags: o instead of a list of mbufs use a list of m_tag structures a la openbsd o for netgraph et. al. extend the stock openbsd m_tag to include a 32-bit ABI/module number cookie o for openbsd compatibility define a well-known cookie MTAG_ABI_COMPAT and use this in defining openbsd-compatible m_tag_find and m_tag_get routines o rewrite KAME use of aux mbufs in terms of packet tags o eliminate the most heavily used aux mbufs by adding an additional struct inpcb parameter to ip_output and ip6_output to allow the IPsec code to locate the security policy to apply to outbound packets o bump __FreeBSD_version so code can be conditionalized o fixup ipfilter's call to ip_output based on __FreeBSD_version ---------------------------- revision 1.6.2.9 date: 2003/01/20 02:23:08; author: iedowse; state: Exp; lines: +8 -2 MFC: Bridged packets need to have their IP header converted to host byte order before being passed to icmp_error(). ---------------------------- revision 1.6.2.8 date: 2002/12/23 10:02:40; author: maxim; state: Exp; lines: +1 -1 MFC rev. 1.20: fix byte order logging issue: sa.sin_port is already in host byte order. ---------------------------- revision 1.6.2.7 date: 2002/11/21 01:27:30; author: luigi; state: Exp; lines: +0 -1 MFC: obey to fw_one_pass in bridge and layer 2 firewalling (the latter only affects ipfw2 users). Move fw_one_pass from ip_fw[2].c to ip_input.c to avoid depending on IPFIREWALL. ---------------------------- revision 1.6.2.6 date: 2002/11/18 21:32:37; author: luigi; state: Exp; lines: +3 -3 MFC 1.12: replace incorrect usage of M_DONTWAIT with M_NOWAIT ---------------------------- revision 1.6.2.5 date: 2002/11/04 15:57:21; author: maxim; state: Exp; lines: +24 -25 MFC revs. 1.14, 1.15, 1.18: o Use syslog for messages about dropped sessions, do not flood a console. o Kill EOL spaces. ---------------------------- revision 1.6.2.4 date: 2002/10/24 18:24:13; author: luigi; state: Exp; lines: +2 -2 MFC: use correct address in DST_SET and SRC_SET rules. ---------------------------- revision 1.6.2.3 date: 2002/08/21 05:34:07; author: luigi; state: Exp; lines: +4 -6 Sync the file with the one in -current: allow up to 30 ports/ranges in port specifications, clean up formatting of the boot string. No functional or ABI changes. ---------------------------- revision 1.6.2.2 date: 2002/08/16 11:03:11; author: luigi; state: Exp; lines: +181 -35 Synchronize ipfw2 with the version in -current (adding sets of rules, prevention of loops in keepalive generation, better defaults on size of dynamic rule table). For documentation, please refer to the ipfw manpage in -current (which I am going to MFC as soon as I have completed the section listing differences between ipfw1-stable and ipfw2). In particular have a look at the sections "PACKET FLOW", "IPFW2 ENHANCEMENTS" and "EXAMPLES" to see if your ruleset can be simplified with the new commands. ---------------------------- revision 1.6.2.1 date: 2002/07/24 03:21:23; author: luigi; state: Exp; lines: +0 -1 Bring ipfw2 into the -stable tree. This will give more people a chance to test it, and hopefully accelerate the transition from the old to the new ipfw code. NOTE: THIS COMMIT WILL NOT CHANGE THE FIREWALL YOU USE, NOR A SINGLE BIT IN YOUR KERNEL AND BINARIES. YOU WILL KEEP USING YOUR OLD "ipfw" UNLESS YOU: + add "options IPFW2" (undocumented) to your kernel config file; + compile and install sbin/ipfw and lib/libalias with make -DIPFW2 in other words, you must really want it. On the other hand, i believe you do really want to use this new code. In addition to being twice as fast in processing individual rules, you can use more powerful match patterns such as ... ip from 1.2.3.0/24{50,6,27,158} to ... ... ip from { 1.2.3.4/26 or 5.6.7.8/22 } to ... ... ip from any 5-7,9-66,1020-3000,4000-5000 to ... i.e. match sparse sets of IP addresses in constant time; use "or" connectives between match patterns; have multiple port ranges; etc. which I believe will dramatically reduce your ruleset size. As an additional bonus, "keep-state" rules will now send keepalives when the rule is about to expire, so you will not have your remote login sessions die while you are idle. The syntax is backward compatible with the old ipfw. A manual page documenting the extensions has yet to be completed. ---------------------------- revision 1.19.2.1 date: 2002/12/15 13:57:43; author: maxim; state: Exp; lines: +1 -1 MFC rev. 1.20: fix byte order logging issue: sa.sin_port is already in host byte order. Approved by: re (rwatson) ---------------------------- revision 1.28.2.1 date: 2003/06/04 02:19:36; author: ticso; state: Exp; lines: +15 -6 MFC: Change handling to support strong alignment architectures such as alpha and sparc64. src/sbin/ipfw/ipfw2.c (1.24) src/sys/netinet/ip_dummynet.c (1.64) src/sys/netinet/ip_fw.h (1.77) src/sys/netinet/ip_fw2.c (1.30) Approved by: re (scottl) ---------------------------- revision 1.51.2.1 date: 2003/12/23 12:25:56; author: maxim; state: Exp; lines: +1 -1 MFC rev. 1.52: IN_MULTICAST wants an address in host byte order. Approved by: re (scottl) ---------------------------- revision 1.70.2.14 date: 2005/06/29 21:38:48; author: simon; state: Exp; lines: +20 -17 Correct ipfw packet matching errors with address tables. Security: CAN-2005-2019 Security: FreeBSD-SA-05:13.ipfw Correct bzip2 denial of service and permission race vulnerabilities. Obtained from: Redhat, Steve Grubb via RedHat Security: CAN-2005-0953, CAN-2005-1260 Security: FreeBSD-SA-05:14.bzip2 Approved by: obrien Correct TCP connection stall denial of service vulnerability. A TCP packets with the SYN flag set is accepted for established connections, allowing an attacker to overwrite certain TCP options. Security: CAN-2005-2068 Security: FreeBSD-SA-05:15.tcp Approved by: cperciva ---------------------------- revision 1.70.2.13 date: 2005/06/17 23:56:59; author: green; state: Exp; lines: +32 -8 MFC: r1.101 Invoke the transmission of IPFW's stateful keep-alives once the locks have been dropped, thus preventing a deadlock between IPFW and the ifnet. ---------------------------- revision 1.70.2.12 date: 2005/06/17 23:30:32; author: green; state: Exp; lines: +3 -0 MFC: ipfw.8 r.1.172, ip_fw2.c r.1.100 Properly document the IPFW ALTQ first-match behavior that was intended, as well as actually implementing it. ---------------------------- revision 1.70.2.11 date: 2005/05/12 15:11:30; author: green; state: Exp; lines: +92 -1 MFC: IPFW ALTQ(4) classification support, diverted traffic match rules, and the TCP packet data length match rule. ---------------------------- revision 1.70.2.10 date: 2005/02/06 16:16:20; author: csjp; state: Exp; lines: +7 -2 branches: 1.70.2.10.2; MFC v1.88 FreeBSD src repository Modified files: sys/netinet ip_fw2.c Log: Change the state allocator from using regular malloc to using a UMA zone instead. This should eliminate a bit of the locking overhead associated with with malloc and reduce the memory consumption associated with each new state. Reviewed by: rwatson, andre Silence on: ipfw@ MFC after: 1 week ---------------------------- revision 1.70.2.9 date: 2005/01/31 23:26:35; author: imp; state: Exp; lines: +1 -1 MFC: /*- and related license changes ---------------------------- revision 1.70.2.8 date: 2005/01/07 23:09:39; author: csjp; state: Exp; lines: +69 -29 MFC v1.85 Log: This commit adds a shared locking mechanism very similar to the mechanism used by pfil. This shared locking mechanism will remove a nasty lock order reversal which occurs when ucred based rules are used which results in hard locks while mpsafenet=1. So this removes the debug.mpsafenet=0 requirement when using ucred based rules with IPFW. It should be noted that this locking mechanism does not guarantee fairness between read and write locks, and that it will favor firewall chain readers over writers. This seemed acceptable since write operations to firewall chains protected by this lock tend to be less frequent than reads. Reviewed by: andre, rwatson Tested by: myself, seanc Silence on: ipfw@ MFC after: 1 month ---------------------------- revision 1.70.2.7 date: 2004/10/13 22:07:05; author: green; state: Exp; lines: +5 -0 MFC r1.78: further rule verification (against corrupt rules added by root). Approved by: re ---------------------------- revision 1.70.2.6 date: 2004/10/03 17:04:40; author: mlaier; state: Exp; lines: +32 -11 MFC pfil API change: Add an additional struct inpcb * argument to pfil(9) in order to enable passing along socket information. This is required to work around a LOR with the socket code which results in an easy reproducible hard lockup with debug.mpsafenet=1. This commit does *not* fix the LOR, but enables us to do so later. The missing piece is to turn the filter locking into a leaf lock and will follow in a seperate (later) commit. Suggested by: rwatson A lot of work by: csjp LOR IDs: 14 - 17 (not fixed yet) Approved by: re (scottl) ---------------------------- revision 1.70.2.5 date: 2004/09/16 18:02:22; author: andre; state: Exp; lines: +4 -0 MFC 1.76: Return EINVAL when IPFIREWALL_FORWARD is not compiled into the kernel. Approved by: re (scottl) ---------------------------- revision 1.70.2.4 date: 2004/09/13 07:19:55; author: maxim; state: Exp; lines: +5 -2 MFC rev.1.75: recover normal behavior: return EINVAL to attempt to add a divert rule when module is built without IPDIVERT. Approved by: re (kensmith) ---------------------------- revision 1.70.2.3 date: 2004/08/26 14:41:43; author: ru; state: Exp; lines: +2 -0 Fix a standalone module build. Approved by: re (scottl) ---------------------------- revision 1.70.2.2 date: 2004/08/20 02:02:05; author: kensmith; state: Exp; lines: +1 -1 Almost an oops, local mirror hadn't caught up with the last version of this file yet... MFC of rev. 1.73 - definitely stop callout. Work done by: andre Noticed my oops: andre Approved by: re ---------------------------- revision 1.70.2.1 date: 2004/08/20 01:40:42; author: kensmith; state: Exp; lines: +3 -2 MFC balance of ipfw fixes. Revs being MFC-ed: ip_fw.h rev 1.90 ip_fw2.c rev 1.71-1.73 ip_fw_pfil.c rev 1.2-1.3 ip_input.c rev 1.285 tcp_subr.c rev 1.202 Work done by: andre Approved by: re ---------------------------- revision 1.70.2.10.2.1 date: 2005/06/29 21:41:03; author: simon; state: Exp; lines: +20 -17 Correct ipfw packet matching errors with address tables. Security: CAN-2005-2019 Security: FreeBSD-SA-05:13.ipfw Correct bzip2 denial of service and permission race vulnerabilities. Obtained from: Redhat, Steve Grubb via RedHat Security: CAN-2005-0953, CAN-2005-1260 Security: FreeBSD-SA-05:14.bzip2 Approved by: obrien Correct TCP connection stall denial-of-service vulnerabilities. MFC: rev 1.270 of tcp_input.c, rev 1.25 of tcp_seq.h by ps: When a TCP packets containing a timestamp is received, inadequate checking of sequence numbers is performed, allowing an attacker to artificially increase the internal "recent" timestamp for a connection. A TCP packets with the SYN flag set is accepted for established connections, allowing an attacker to overwrite certain TCP options. Security: CAN-2005-0356, CAN-2005-2068 Security: FreeBSD-SA-05:15.tcp Approved by: so (cperciva) ---------------------------- revision 1.106.2.5 date: 2005/11/14 22:33:35; author: suz; state: Exp; lines: +8 -2 MFC 1.115 fixed a bug that uRPF does not work properly for an IPv6 packet bound for the sending machine itself (this is a bug introduced due to a change in ip6_input.c:Rev.1.81.2.2) ---------------------------- revision 1.106.2.4 date: 2005/11/04 20:26:14; author: ume; state: Exp; lines: +3 -0 MFC: scope cleanup. with this change - most of the kernel code will not care about the actual encoding of scope zone IDs and won't touch "s6_addr16[1]" directly. - similarly, most of the kernel code will not care about link-local scoped addresses as a special case. - scope boundary check will be stricter. For example, the current *BSD code allows a packet with src=::1 and dst=(some global IPv6 address) to be sent outside of the node, if the application do: s = socket(AF_INET6); bind(s, "::1"); sendto(s, some_global_IPv6_addr); This is clearly wrong, since ::1 is only meaningful within a single node, but the current implementation of the *BSD kernel cannot reject this attempt. sys/net/if_gif.c: 1.53 sys/net/if_spppsubr.c: 1.120 sys/netinet/icmp6.h: 1.19 sys/netinet/ip_carp.c: 1.28,1.29 sys/netinet/ip_fw2.c: 1.107 sys/netinet/tcp_subr.c: 1.230,1.231,1.235 sys/netinet/tcp_usrreq.c: 1.125 sys/netinet6/ah_core.c: 1.26 sys/netinet6/icmp6.c: 1.63,1.64 sys/netinet6/in6.c: 1.52 sys/netinet6/in6.h: 1.38 sys/netinet6/in6_cksum.c: 1.11 sys/netinet6/in6_ifattach.c: 1.27 sys/netinet6/in6_pcb.c: 1.63 sys/netinet6/in6_proto.c: 1.33 sys/netinet6/in6_src.c: 1.31,1.32 sys/netinet6/in6_var.h: 1.22 sys/netinet6/ip6_forward.c: 1.29 sys/netinet6/ip6_input.c: 1.83 sys/netinet6/ip6_mroute.c: 1.30 sys/netinet6/ip6_output.c: 1.95 sys/netinet6/ip6_var.h: 1.33 sys/netinet6/ipsec.c: 1.43 sys/netinet6/mld6.c: 1.21 sys/netinet6/nd6.c: 1.50 sys/netinet6/nd6_nbr.c: 1.30 sys/netinet6/nd6_rtr.c: 1.27 sys/netinet6/raw_ip6.c: 1.54 sys/netinet6/route6.c: 1.12 sys/netinet6/scope6.c: 1.13,1.14,1.15 sys/netinet6/scope6_var.h: 1.5 sys/netinet6/udp6_output.c: 1.23 sys/netinet6/udp6_usrreq.c: 1.55 sys/netkey/key.c: 1.72,1.73 ---------------------------- revision 1.106.2.3 date: 2005/09/17 13:43:36; author: bz; state: Exp; lines: +30 -6 MFC: rev. 1.111 Fix panic when kernel compiled without INET6 by rejecting IPv6 opcodes which are behind #if(n)def INET6 now. PR: kern/85826 Approved by: re (scottl) ---------------------------- revision 1.106.2.2 date: 2005/09/08 22:49:23; author: sam; state: Exp; lines: +1 -0 MFC 1.110: clear lock on error in O_LIMIT case of install_state Approved by: re (scottl) ---------------------------- revision 1.106.2.1 date: 2005/08/20 08:36:57; author: bz; state: Exp; lines: +289 -67 MFC: rev. 1.108, 1.109 src/sys/netinet/ip_fw2.c rev. 1.101 src/sys/netinet/ip_fw.h rev. 1.77 src/sbin/ipfw/ipfw2.c rev. 1.176 src/sbin/ipfw/ipfw.8 * Add dynamic sysctl for net.inet6.ip6.fw. * Correct handling of IPv6 Extension Headers. * Add unreach6 code. * Add logging for IPv6. * Fix build without INET6 and IPFIREWALL compiled into kernel.[1] Submitted by: sysctl handling derived from patch from ume needed for ip6fw Obtained from: is_icmp6_query and send_reject6 derived from similar functions of netinet6,ip6fw Reviewed by: ume, gnn; silence on ipfw@ Spotted and tested by: Michal Mertl [1] Approved by: re (kensmith) ============================================================================= --7LkOrbQMr4cezO2T-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 02:53:55 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6917516A41F; Sun, 27 Nov 2005 02:53:55 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C236243D9C; Sun, 27 Nov 2005 02:53:23 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jAR2r9bn079240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Nov 2005 05:53:09 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jAR2r9IK079239; Sun, 27 Nov 2005 05:53:09 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 27 Nov 2005 05:53:08 +0300 From: Gleb Smirnoff To: ru@FreeBSD.org, Vsevolod Lobko , rwatson@FreeBSD.org Message-ID: <20051127025308.GV25711@cell.sick.ru> References: <20051127005943.GR25711@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AqCDj3hiknadvR6t" Content-Disposition: inline In-Reply-To: <20051127005943.GR25711@cell.sick.ru> User-Agent: Mutt/1.5.6i Cc: net@FreeBSD.org Subject: Re: parallelizing ipfw table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 02:53:55 -0000 --AqCDj3hiknadvR6t Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Sun, Nov 27, 2005 at 03:59:43AM +0300, Gleb Smirnoff wrote: T> Colleagues, T> T> in ipfw(4) we've got a reader/writer locking semantics. The ipfw T> lookups performed on packet forwarding obtain reader lock on ipfw T> chain, while altering the chain requires writer access on chain. T> T> So, in multiprocessor multiinterface box we achieve a parallizm T> almost without any contention. T> T> However, ipfw tables lock the RADIX trie on every lookup. At the T> first glance the radix.c:rn_lookup() function is reenterable. This T> means that we can do two parallel RADIX lookups. So, I suggest T> to eliminate the RADIX trie locking in ipfw, and utilize the T> locking that is already present in ipfw. This will: T> T> - reduce number of mutex operations for each packer T> - remove contention from parallel ipfw_chk() lookups T> T> A patch displaying the idea is attached. Not tested yet, read T> below. The patch moves the tables array into the ip_fw_chain T> structure. This is not necessary now, but in future we can T> have multiple independent chains in ipfw, that's why I try T> to avoid usage of &layer3_chain in the functions that are T> deeper in the call graph. I try to supply chain pointer T> from the caller. T> T> The only problem is the caching in table lookup. This "hack" T> makes the lookup function modify the table structure. We need T> to remove caching to make the lookup_table() function fully T> lockless and reenterable at the same time. The attached patch T> doesn't removes caching, since it only displays the original T> idea. I'm sorry to send 'cvs log' instead of 'cvs diff'. :( Here is the patch. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --AqCDj3hiknadvR6t Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ip_fw.table.unlock" Index: ip_fw2.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v retrieving revision 1.115 diff -u -r1.115 ip_fw2.c --- ip_fw2.c 10 Nov 2005 22:10:39 -0000 1.115 +++ ip_fw2.c 27 Nov 2005 00:11:46 -0000 @@ -126,9 +126,19 @@ int fw_prid; }; +#define IPFW_TABLES_MAX 128 +struct ip_fw_table { + struct radix_node_head *rnh; + int modified; + in_addr_t last_addr; + int last_match; + u_int32_t last_value; +}; + struct ip_fw_chain { struct ip_fw *rules; /* list of rules */ struct ip_fw *reap; /* list of rules to reap */ + struct ip_fw_table tables[IPFW_TABLES_MAX]; struct mtx mtx; /* lock guarding rule list */ int busy_count; /* busy count for rw locks */ int want_write; @@ -192,15 +202,6 @@ u_int32_t value; }; -#define IPFW_TABLES_MAX 128 -static struct ip_fw_table { - struct radix_node_head *rnh; - int modified; - in_addr_t last_addr; - int last_match; - u_int32_t last_value; -} ipfw_tables[IPFW_TABLES_MAX]; - static int fw_debug = 1; static int autoinc_step = 100; /* bounded to 1..1000 in add_rule() */ @@ -1703,25 +1704,26 @@ } static void -init_tables(void) +init_tables(struct ip_fw_chain *ch) { int i; for (i = 0; i < IPFW_TABLES_MAX; i++) { - rn_inithead((void **)&ipfw_tables[i].rnh, 32); - ipfw_tables[i].modified = 1; + rn_inithead((void **)&ch->tables[i].rnh, 32); + ch->tables[i].modified = 1; } } static int -add_table_entry(u_int16_t tbl, in_addr_t addr, u_int8_t mlen, u_int32_t value) +add_table_entry(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t addr, + uint8_t mlen, uint32_t value) { struct radix_node_head *rnh; struct table_entry *ent; if (tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl].rnh; + rnh = ch->tables[tbl].rnh; ent = malloc(sizeof(*ent), M_IPFW_TBL, M_NOWAIT | M_ZERO); if (ent == NULL) return (ENOMEM); @@ -1729,20 +1731,21 @@ ent->addr.sin_len = ent->mask.sin_len = 8; ent->mask.sin_addr.s_addr = htonl(mlen ? ~((1 << (32 - mlen)) - 1) : 0); ent->addr.sin_addr.s_addr = addr & ent->mask.sin_addr.s_addr; - RADIX_NODE_HEAD_LOCK(rnh); + IPFW_WLOCK(&layer3_chain); if (rnh->rnh_addaddr(&ent->addr, &ent->mask, rnh, (void *)ent) == NULL) { - RADIX_NODE_HEAD_UNLOCK(rnh); + IPFW_WUNLOCK(&layer3_chain); free(ent, M_IPFW_TBL); return (EEXIST); } - ipfw_tables[tbl].modified = 1; - RADIX_NODE_HEAD_UNLOCK(rnh); + ch->tables[tbl].modified = 1; + IPFW_WUNLOCK(&layer3_chain); return (0); } static int -del_table_entry(u_int16_t tbl, in_addr_t addr, u_int8_t mlen) +del_table_entry(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t addr, + uint8_t mlen) { struct radix_node_head *rnh; struct table_entry *ent; @@ -1750,18 +1753,18 @@ if (tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl].rnh; + rnh = ch->tables[tbl].rnh; sa.sin_len = mask.sin_len = 8; mask.sin_addr.s_addr = htonl(mlen ? ~((1 << (32 - mlen)) - 1) : 0); sa.sin_addr.s_addr = addr & mask.sin_addr.s_addr; - RADIX_NODE_HEAD_LOCK(rnh); + IPFW_WLOCK(ch); ent = (struct table_entry *)rnh->rnh_deladdr(&sa, &mask, rnh); if (ent == NULL) { - RADIX_NODE_HEAD_UNLOCK(rnh); + IPFW_WUNLOCK(ch); return (ESRCH); } - ipfw_tables[tbl].modified = 1; - RADIX_NODE_HEAD_UNLOCK(rnh); + ch->tables[tbl].modified = 1; + IPFW_WUNLOCK(ch); free(ent, M_IPFW_TBL); return (0); } @@ -1780,31 +1783,34 @@ } static int -flush_table(u_int16_t tbl) +flush_table(struct ip_fw_chain *ch, uint16_t tbl) { struct radix_node_head *rnh; + IPFW_WLOCK_ASSERT(ch); + if (tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl].rnh; - RADIX_NODE_HEAD_LOCK(rnh); + rnh = ch->tables[tbl].rnh; rnh->rnh_walktree(rnh, flush_table_entry, rnh); - ipfw_tables[tbl].modified = 1; - RADIX_NODE_HEAD_UNLOCK(rnh); + ch->tables[tbl].modified = 1; return (0); } static void -flush_tables(void) +flush_tables(struct ip_fw_chain *ch) { - u_int16_t tbl; + uint16_t tbl; + + IPFW_WLOCK_ASSERT(ch); for (tbl = 0; tbl < IPFW_TABLES_MAX; tbl++) - flush_table(tbl); + flush_table(ch, tbl); } static int -lookup_table(u_int16_t tbl, in_addr_t addr, u_int32_t *val) +lookup_table(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t addr, + uint32_t *val) { struct radix_node_head *rnh; struct ip_fw_table *table; @@ -1814,14 +1820,12 @@ if (tbl >= IPFW_TABLES_MAX) return (0); - table = &ipfw_tables[tbl]; + table = &ch->tables[tbl]; rnh = table->rnh; - RADIX_NODE_HEAD_LOCK(rnh); if (addr == table->last_addr && !table->modified) { last_match = table->last_match; if (last_match) *val = table->last_value; - RADIX_NODE_HEAD_UNLOCK(rnh); return (last_match); } table->modified = 0; @@ -1832,11 +1836,9 @@ if (ent != NULL) { table->last_value = *val = ent->value; table->last_match = 1; - RADIX_NODE_HEAD_UNLOCK(rnh); return (1); } table->last_match = 0; - RADIX_NODE_HEAD_UNLOCK(rnh); return (0); } @@ -1850,17 +1852,15 @@ } static int -count_table(u_int32_t tbl, u_int32_t *cnt) +count_table(struct ip_fw_chain *ch, uint32_t tbl, uint32_t *cnt) { struct radix_node_head *rnh; if (tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl].rnh; + rnh = ch->tables[tbl].rnh; *cnt = 0; - RADIX_NODE_HEAD_LOCK(rnh); rnh->rnh_walktree(rnh, count_table_entry, cnt); - RADIX_NODE_HEAD_UNLOCK(rnh); return (0); } @@ -1886,17 +1886,17 @@ } static int -dump_table(ipfw_table *tbl) +dump_table(struct ip_fw_chain *ch, ipfw_table *tbl) { struct radix_node_head *rnh; + IPFW_WLOCK_ASSERT(ch); + if (tbl->tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl->tbl].rnh; + rnh = ch->tables[tbl->tbl].rnh; tbl->cnt = 0; - RADIX_NODE_HEAD_LOCK(rnh); rnh->rnh_walktree(rnh, dump_table_entry, tbl); - RADIX_NODE_HEAD_UNLOCK(rnh); return (0); } @@ -2567,7 +2567,8 @@ dst_ip.s_addr : src_ip.s_addr; uint32_t v; - match = lookup_table(cmd->arg1, a, &v); + match = lookup_table(chain, cmd->arg1, a, + &v); if (!match) break; if (cmdlen == F_INSN_SIZE(ipfw_insn_u32)) @@ -4012,8 +4013,8 @@ sizeof(ent), sizeof(ent)); if (error) break; - error = add_table_entry(ent.tbl, ent.addr, - ent.masklen, ent.value); + error = add_table_entry(&layer3_chain, ent.tbl, + ent.addr, ent.masklen, ent.value); } break; @@ -4025,7 +4026,8 @@ sizeof(ent), sizeof(ent)); if (error) break; - error = del_table_entry(ent.tbl, ent.addr, ent.masklen); + error = del_table_entry(&layer3_chain, ent.tbl, + ent.addr, ent.masklen); } break; @@ -4037,7 +4039,9 @@ sizeof(tbl), sizeof(tbl)); if (error) break; - error = flush_table(tbl); + IPFW_WLOCK(&layer3_chain); + error = flush_table(&layer3_chain, tbl); + IPFW_WUNLOCK(&layer3_chain); } break; @@ -4048,8 +4052,10 @@ if ((error = sooptcopyin(sopt, &tbl, sizeof(tbl), sizeof(tbl)))) break; - if ((error = count_table(tbl, &cnt))) + IPFW_RLOCK(&layer3_chain); + if ((error = count_table(&layer3_chain, tbl, &cnt))) break; + IPFW_RUNLOCK(&layer3_chain); error = sooptcopyout(sopt, &cnt, sizeof(cnt)); } break; @@ -4075,11 +4081,14 @@ } tbl->size = (size - sizeof(*tbl)) / sizeof(ipfw_table_entry); - error = dump_table(tbl); + IPFW_WLOCK(&layer3_chain); + error = dump_table(&layer3_chain, tbl); if (error) { + IPFW_WUNLOCK(&layer3_chain); free(tbl, M_TEMP); break; } + IPFW_WUNLOCK(&layer3_chain); error = sooptcopyout(sopt, tbl, size); free(tbl, M_TEMP); } @@ -4242,7 +4251,7 @@ printf("limited to %d packets/entry by default\n", verbose_limit); - init_tables(); + init_tables(&layer3_chain); ip_fw_ctl_ptr = ipfw_ctl; ip_fw_chk_ptr = ipfw_chk; callout_reset(&ipfw_timeout, hz, ipfw_tick, NULL); @@ -4259,13 +4268,13 @@ ip_fw_ctl_ptr = NULL; callout_drain(&ipfw_timeout); IPFW_WLOCK(&layer3_chain); + flush_tables(&layer3_chain); layer3_chain.reap = NULL; free_chain(&layer3_chain, 1 /* kill default rule */); reap = layer3_chain.reap, layer3_chain.reap = NULL; IPFW_WUNLOCK(&layer3_chain); if (reap != NULL) reap_rules(reap); - flush_tables(); IPFW_DYN_LOCK_DESTROY(); uma_zdestroy(ipfw_dyn_rule_zone); IPFW_LOCK_DESTROY(&layer3_chain); --AqCDj3hiknadvR6t-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 06:18:53 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30A2516A420 for ; Sun, 27 Nov 2005 06:18:53 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (outbound.idiom.com [216.240.47.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7F7B43D49 for ; Sun, 27 Nov 2005 06:18:50 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 84DC2226FDC for ; Sat, 26 Nov 2005 22:18:50 -0800 (PST) Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id jAR6In4R050999 for ; Sat, 26 Nov 2005 22:18:50 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <43894FC9.6040205@elischer.org> Date: Sat, 26 Nov 2005 22:18:49 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: proposal: TCP rendevous X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 06:18:53 -0000 In this world of P2P apps it would be neat to have a way that two P2P apps could attach to each other even though each is through a firewall. Most firewalls only allow "outgoing" connections. It would of course be possible via a 3rd party relaying but that is inneffieient and the throughput would be limited by throughput limits on the 3rd party link. It must be possible, with the connivance of a 3rd party both parties could be able to make suitable 'OUTGOING' connections. The 3rd party would spoof needed packets using information supplied by the two parties. if this were to be done, there would be two modes In the first, the application can be modified so special socket options could be used but for application binaries that can't be modified, one would need an external way of 'interfering' with the sessions. You could probably do it with netgraph. I'm still thinking about connecting systems separated by NAT however. that's a trickier problem. you still need to use outgoing connections but no-one who is not in the path can not tell what the NAT'd packets looke like. julian From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 06:46:12 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 881C316A41F for ; Sun, 27 Nov 2005 06:46:12 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 311F343D4C for ; Sun, 27 Nov 2005 06:46:11 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 48610 invoked from network); 27 Nov 2005 06:46:10 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 27 Nov 2005 06:46:10 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 27 Nov 2005 00:46:09 -0600 (CST) From: Mike Silbersack To: Julian Elischer In-Reply-To: <43894FC9.6040205@elischer.org> Message-ID: <20051127004535.U2443@odysseus.silby.com> References: <43894FC9.6040205@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@freebsd.org Subject: Re: proposal: TCP rendevous X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 06:46:12 -0000 On Sat, 26 Nov 2005, Julian Elischer wrote: > In this world of P2P apps it would be neat to have a way that two P2P apps > could attach to each other even though each is through a firewall. Most > firewalls only allow > "outgoing" connections. Go research Microsoft's uPnP firewall support. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 07:58:31 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2A3A16A41F for ; Sun, 27 Nov 2005 07:58:31 +0000 (GMT) (envelope-from priarifire@yahoo.com) Received: from web60016.mail.yahoo.com (web60016.mail.yahoo.com [209.73.178.64]) by mx1.FreeBSD.org (Postfix) with SMTP id 15BE643D45 for ; Sun, 27 Nov 2005 07:58:30 +0000 (GMT) (envelope-from priarifire@yahoo.com) Received: (qmail 35056 invoked by uid 60001); 27 Nov 2005 07:58:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=s32Ij0UA76BDCl/2+1PlL264a46k9DgKFFQ0K61WDBspvHX+mAytQEoU7D6Nie9xLlGj+zu2YeQudYPiwcp/zVfZS1UMMeg+Q0MSayYxegP/yMKVlT9SkFmAg7TyRaTjT3XX5Gqramb1lsmybjrLmC3t3nBpSuYy7coI1XbqLSQ= ; Message-ID: <20051127075830.35054.qmail@web60016.mail.yahoo.com> Received: from [65.26.195.25] by web60016.mail.yahoo.com via HTTP; Sat, 26 Nov 2005 23:58:30 PST Date: Sat, 26 Nov 2005 23:58:30 -0800 (PST) From: Imrani To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Configure wireless connection using Cisco aironet 350 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 07:58:31 -0000 Hi, I am trying to configure Cisco Aironet 350 wireless PCI card but I get an error which I am unable to find much details for that. Following is description of ifconfing: > ifconfig an0 an0: flags=8843 mtu 1500 inet6 fe80::209:7cff:fe22:6eab%an0 prefixlen 64 scopeid 0x2 ether 00:09:7c:22:6e:ab media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid 1:myhome channel 9 stationname FreeBSD ano: record length mismatch -- expected 194, got 196 for Rid ff10 authmode OPEN privacy ON deftxkey 2 txpowmax 0 rtsthreshold 0 fragthreshold 0 roaming DEVICE As you can see the wireless card is detected and status is "associated' but my wireless connection doesn't work. I cannot even ping the router. Can you please help me configure wireless connection with my router. Also, here are more details: WEP on, encryption is 128 bits, BSD 6.0, PCI card is Cisco Aironet 350, AMD athalon. Thanks again. --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free. From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 10:18:28 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 122D916A41F for ; Sun, 27 Nov 2005 10:18:28 +0000 (GMT) (envelope-from pawmal@freebsd.lublin.pl) Received: from mailhost.freebsd.lublin.pl (mailhost.freebsd.lublin.pl [193.138.118.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B56A43D55 for ; Sun, 27 Nov 2005 10:18:26 +0000 (GMT) (envelope-from pawmal@freebsd.lublin.pl) Received: from lagoon.freebsd.lublin.pl (qmailr@lagoon.freebsd.lublin.pl [193.138.118.3]) by mailhost.freebsd.lublin.pl (8.13.3/8.13.1) with SMTP id jARAIPo7063123 for ; Sun, 27 Nov 2005 11:18:25 +0100 (CET) (envelope-from pawmal@freebsd.lublin.pl) Received: (qmail 63033 invoked by uid 1033); 27 Nov 2005 10:18:24 -0000 Date: Sun, 27 Nov 2005 11:18:24 +0100 From: =?iso-8859-2?Q?Pawe=B3_Ma=B3achowski?= To: net@freebsd.org Message-ID: <20051127101824.GA3606@lagoon.freebsd.lublin.pl> References: <43894FC9.6040205@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <43894FC9.6040205@elischer.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.86.1/1195/Fri Nov 25 10:29:55 2005 on mailhost.freebsd.lublin.pl X-Virus-Status: Clean Cc: Subject: Re: proposal: TCP rendevous X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 10:18:28 -0000 On Sat, Nov 26, 2005 at 10:18:49PM -0800, Julian Elischer wrote: > I'm still thinking about connecting systems separated by NAT however. > that's a trickier problem. you still need to use outgoing connections but > no-one who is not in the path can not tell what the NAT'd packets looke > like. BTW, I've heared Windows-behind-NAT-people ;) are using http://hamachi.cc trick, however, I've never tried. -- Pawe³ Ma³achowski From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 13:53:59 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C82816A41F for ; Sun, 27 Nov 2005 13:53:59 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4302B43D60 for ; Sun, 27 Nov 2005 13:53:56 +0000 (GMT) (envelope-from keramida@linux.gr) Received: (qmail 5697 invoked by uid 207); 27 Nov 2005 13:53:54 -0000 Received: from keramida@linux.gr by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.30/3.97. Clear:RC:1(81.186.70.193):. Processed in 0.699104 secs); 27 Nov 2005 13:53:54 -0000 Received: from dialup193.ach.sch.gr (HELO flame.pc) ([81.186.70.193]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 27 Nov 2005 13:53:53 -0000 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id jARDrHOo017644; Sun, 27 Nov 2005 15:53:17 +0200 (EET) (envelope-from keramida@linux.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id jARDrFA1017643; Sun, 27 Nov 2005 15:53:15 +0200 (EET) (envelope-from keramida@linux.gr) Date: Sun, 27 Nov 2005 15:53:15 +0200 From: Giorgos Keramidas To: Imrani Message-ID: <20051127135315.GA17605@flame.pc> References: <20051127075830.35054.qmail@web60016.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051127075830.35054.qmail@web60016.mail.yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: Configure wireless connection using Cisco aironet 350 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 13:53:59 -0000 On 2005-11-26 23:58, Imrani wrote: > Hi, > I am trying to configure Cisco Aironet 350 wireless PCI card but I get > an error which I am unable to find much details for that. Following is > description of ifconfing: > > > ifconfig an0 > an0: flags=8843 mtu 1500 > inet6 fe80::209:7cff:fe22:6eab%an0 prefixlen 64 scopeid 0x2 > ether 00:09:7c:22:6e:ab > media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) > status: associated > ssid 1:myhome channel 9 > stationname FreeBSD > ano: record length mismatch -- expected 194, got 196 for Rid ff10 > authmode OPEN privacy ON deftxkey 2 txpowmax 0 rtsthreshold 0 > fragthreshold 0 roaming DEVICE > > As you can see the wireless card is detected and status is > "associated' but my wireless connection doesn't work. I cannot even > ping the router. Your interface only has an IPv6 address. Is that expected? How are you bringing up the an0 interface? For instance, my /root/netstart-home.sh script contains (among a few other things): # Default setup for my bge0 interface. export ifconfig_ath0="DHCP ssid 'XXXX' \ wepmode on weptxkey 1 wepkey '1:0xXXXXXXXXXXXXXXXXXXXXXXXXXX'" /etc/rc.d/netif stop bge0 /etc/rc.d/netif stop ath0 /etc/rc.d/netif start ath0 This seems to take care of everything here. From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 13:55:33 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B427F16A41F; Sun, 27 Nov 2005 13:55:33 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 012E143D49; Sun, 27 Nov 2005 13:55:32 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jARDtURm083552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Nov 2005 16:55:30 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jARDtTDQ083551; Sun, 27 Nov 2005 16:55:29 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 27 Nov 2005 16:55:29 +0300 From: Gleb Smirnoff To: ru@FreeBSD.org, Vsevolod Lobko , rwatson@FreeBSD.org Message-ID: <20051127135529.GF25711@cell.sick.ru> References: <20051127005943.GR25711@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="rCb8EA+9TsBVtA92" Content-Disposition: inline In-Reply-To: <20051127005943.GR25711@cell.sick.ru> User-Agent: Mutt/1.5.6i Cc: net@FreeBSD.org Subject: Re: parallelizing ipfw table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 13:55:33 -0000 --rCb8EA+9TsBVtA92 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Sun, Nov 27, 2005 at 03:59:43AM +0300, Gleb Smirnoff wrote: T> A patch displaying the idea is attached. Not tested yet, read T> below. The patch moves the tables array into the ip_fw_chain T> structure. This is not necessary now, but in future we can T> have multiple independent chains in ipfw, that's why I try T> to avoid usage of &layer3_chain in the functions that are T> deeper in the call graph. I try to supply chain pointer T> from the caller. T> T> The only problem is the caching in table lookup. This "hack" T> makes the lookup function modify the table structure. We need T> to remove caching to make the lookup_table() function fully T> lockless and reenterable at the same time. The attached patch T> doesn't removes caching, since it only displays the original T> idea. Okay, I have made a working patch, that is now undergoing testing on SMP. I have axed all the caching from ipfw tables, to make lookup_table() lockless and reenterable. This axing simplified things much. I believe that the caching gives a benefit only when we serve a small number of clients, and is only additional workload when we are routing hundreds and thousands of simultaneous IP flows. The patch attached. I'm going to put it into production testing as soon as I can reboot the prod box. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --rCb8EA+9TsBVtA92 Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ip_fw.table.unlock.2" Index: ip_fw2.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v retrieving revision 1.115 diff -u -r1.115 ip_fw2.c --- ip_fw2.c 10 Nov 2005 22:10:39 -0000 1.115 +++ ip_fw2.c 27 Nov 2005 12:40:08 -0000 @@ -126,9 +126,11 @@ int fw_prid; }; +#define IPFW_TABLES_MAX 128 struct ip_fw_chain { struct ip_fw *rules; /* list of rules */ struct ip_fw *reap; /* list of rules to reap */ + struct radix_node_head *tables[IPFW_TABLES_MAX]; struct mtx mtx; /* lock guarding rule list */ int busy_count; /* busy count for rw locks */ int want_write; @@ -192,15 +194,6 @@ u_int32_t value; }; -#define IPFW_TABLES_MAX 128 -static struct ip_fw_table { - struct radix_node_head *rnh; - int modified; - in_addr_t last_addr; - int last_match; - u_int32_t last_value; -} ipfw_tables[IPFW_TABLES_MAX]; - static int fw_debug = 1; static int autoinc_step = 100; /* bounded to 1..1000 in add_rule() */ @@ -1703,25 +1696,24 @@ } static void -init_tables(void) +init_tables(struct ip_fw_chain *ch) { int i; - for (i = 0; i < IPFW_TABLES_MAX; i++) { - rn_inithead((void **)&ipfw_tables[i].rnh, 32); - ipfw_tables[i].modified = 1; - } + for (i = 0; i < IPFW_TABLES_MAX; i++) + rn_inithead((void **)&ch->tables[i], 32); } static int -add_table_entry(u_int16_t tbl, in_addr_t addr, u_int8_t mlen, u_int32_t value) +add_table_entry(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t addr, + uint8_t mlen, uint32_t value) { struct radix_node_head *rnh; struct table_entry *ent; if (tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl].rnh; + rnh = ch->tables[tbl]; ent = malloc(sizeof(*ent), M_IPFW_TBL, M_NOWAIT | M_ZERO); if (ent == NULL) return (ENOMEM); @@ -1729,20 +1721,20 @@ ent->addr.sin_len = ent->mask.sin_len = 8; ent->mask.sin_addr.s_addr = htonl(mlen ? ~((1 << (32 - mlen)) - 1) : 0); ent->addr.sin_addr.s_addr = addr & ent->mask.sin_addr.s_addr; - RADIX_NODE_HEAD_LOCK(rnh); + IPFW_WLOCK(&layer3_chain); if (rnh->rnh_addaddr(&ent->addr, &ent->mask, rnh, (void *)ent) == NULL) { - RADIX_NODE_HEAD_UNLOCK(rnh); + IPFW_WUNLOCK(&layer3_chain); free(ent, M_IPFW_TBL); return (EEXIST); } - ipfw_tables[tbl].modified = 1; - RADIX_NODE_HEAD_UNLOCK(rnh); + IPFW_WUNLOCK(&layer3_chain); return (0); } static int -del_table_entry(u_int16_t tbl, in_addr_t addr, u_int8_t mlen) +del_table_entry(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t addr, + uint8_t mlen) { struct radix_node_head *rnh; struct table_entry *ent; @@ -1750,18 +1742,17 @@ if (tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl].rnh; + rnh = ch->tables[tbl]; sa.sin_len = mask.sin_len = 8; mask.sin_addr.s_addr = htonl(mlen ? ~((1 << (32 - mlen)) - 1) : 0); sa.sin_addr.s_addr = addr & mask.sin_addr.s_addr; - RADIX_NODE_HEAD_LOCK(rnh); + IPFW_WLOCK(ch); ent = (struct table_entry *)rnh->rnh_deladdr(&sa, &mask, rnh); if (ent == NULL) { - RADIX_NODE_HEAD_UNLOCK(rnh); + IPFW_WUNLOCK(ch); return (ESRCH); } - ipfw_tables[tbl].modified = 1; - RADIX_NODE_HEAD_UNLOCK(rnh); + IPFW_WUNLOCK(ch); free(ent, M_IPFW_TBL); return (0); } @@ -1780,63 +1771,48 @@ } static int -flush_table(u_int16_t tbl) +flush_table(struct ip_fw_chain *ch, uint16_t tbl) { struct radix_node_head *rnh; + IPFW_WLOCK_ASSERT(ch); + if (tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl].rnh; - RADIX_NODE_HEAD_LOCK(rnh); + rnh = ch->tables[tbl]; rnh->rnh_walktree(rnh, flush_table_entry, rnh); - ipfw_tables[tbl].modified = 1; - RADIX_NODE_HEAD_UNLOCK(rnh); return (0); } static void -flush_tables(void) +flush_tables(struct ip_fw_chain *ch) { - u_int16_t tbl; + uint16_t tbl; + + IPFW_WLOCK_ASSERT(ch); for (tbl = 0; tbl < IPFW_TABLES_MAX; tbl++) - flush_table(tbl); + flush_table(ch, tbl); } static int -lookup_table(u_int16_t tbl, in_addr_t addr, u_int32_t *val) +lookup_table(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t addr, + uint32_t *val) { struct radix_node_head *rnh; - struct ip_fw_table *table; struct table_entry *ent; struct sockaddr_in sa; - int last_match; if (tbl >= IPFW_TABLES_MAX) return (0); - table = &ipfw_tables[tbl]; - rnh = table->rnh; - RADIX_NODE_HEAD_LOCK(rnh); - if (addr == table->last_addr && !table->modified) { - last_match = table->last_match; - if (last_match) - *val = table->last_value; - RADIX_NODE_HEAD_UNLOCK(rnh); - return (last_match); - } - table->modified = 0; + rnh = ch->tables[tbl]; sa.sin_len = 8; sa.sin_addr.s_addr = addr; ent = (struct table_entry *)(rnh->rnh_lookup(&sa, NULL, rnh)); - table->last_addr = addr; if (ent != NULL) { - table->last_value = *val = ent->value; - table->last_match = 1; - RADIX_NODE_HEAD_UNLOCK(rnh); + *val = ent->value; return (1); } - table->last_match = 0; - RADIX_NODE_HEAD_UNLOCK(rnh); return (0); } @@ -1850,17 +1826,15 @@ } static int -count_table(u_int32_t tbl, u_int32_t *cnt) +count_table(struct ip_fw_chain *ch, uint32_t tbl, uint32_t *cnt) { struct radix_node_head *rnh; if (tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl].rnh; + rnh = ch->tables[tbl]; *cnt = 0; - RADIX_NODE_HEAD_LOCK(rnh); rnh->rnh_walktree(rnh, count_table_entry, cnt); - RADIX_NODE_HEAD_UNLOCK(rnh); return (0); } @@ -1886,17 +1860,17 @@ } static int -dump_table(ipfw_table *tbl) +dump_table(struct ip_fw_chain *ch, ipfw_table *tbl) { struct radix_node_head *rnh; + IPFW_WLOCK_ASSERT(ch); + if (tbl->tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl->tbl].rnh; + rnh = ch->tables[tbl->tbl]; tbl->cnt = 0; - RADIX_NODE_HEAD_LOCK(rnh); rnh->rnh_walktree(rnh, dump_table_entry, tbl); - RADIX_NODE_HEAD_UNLOCK(rnh); return (0); } @@ -2567,7 +2541,8 @@ dst_ip.s_addr : src_ip.s_addr; uint32_t v; - match = lookup_table(cmd->arg1, a, &v); + match = lookup_table(chain, cmd->arg1, a, + &v); if (!match) break; if (cmdlen == F_INSN_SIZE(ipfw_insn_u32)) @@ -4012,8 +3987,8 @@ sizeof(ent), sizeof(ent)); if (error) break; - error = add_table_entry(ent.tbl, ent.addr, - ent.masklen, ent.value); + error = add_table_entry(&layer3_chain, ent.tbl, + ent.addr, ent.masklen, ent.value); } break; @@ -4025,7 +4000,8 @@ sizeof(ent), sizeof(ent)); if (error) break; - error = del_table_entry(ent.tbl, ent.addr, ent.masklen); + error = del_table_entry(&layer3_chain, ent.tbl, + ent.addr, ent.masklen); } break; @@ -4037,7 +4013,9 @@ sizeof(tbl), sizeof(tbl)); if (error) break; - error = flush_table(tbl); + IPFW_WLOCK(&layer3_chain); + error = flush_table(&layer3_chain, tbl); + IPFW_WUNLOCK(&layer3_chain); } break; @@ -4048,8 +4026,10 @@ if ((error = sooptcopyin(sopt, &tbl, sizeof(tbl), sizeof(tbl)))) break; - if ((error = count_table(tbl, &cnt))) + IPFW_RLOCK(&layer3_chain); + if ((error = count_table(&layer3_chain, tbl, &cnt))) break; + IPFW_RUNLOCK(&layer3_chain); error = sooptcopyout(sopt, &cnt, sizeof(cnt)); } break; @@ -4075,11 +4055,14 @@ } tbl->size = (size - sizeof(*tbl)) / sizeof(ipfw_table_entry); - error = dump_table(tbl); + IPFW_WLOCK(&layer3_chain); + error = dump_table(&layer3_chain, tbl); if (error) { + IPFW_WUNLOCK(&layer3_chain); free(tbl, M_TEMP); break; } + IPFW_WUNLOCK(&layer3_chain); error = sooptcopyout(sopt, tbl, size); free(tbl, M_TEMP); } @@ -4242,7 +4225,7 @@ printf("limited to %d packets/entry by default\n", verbose_limit); - init_tables(); + init_tables(&layer3_chain); ip_fw_ctl_ptr = ipfw_ctl; ip_fw_chk_ptr = ipfw_chk; callout_reset(&ipfw_timeout, hz, ipfw_tick, NULL); @@ -4259,13 +4242,13 @@ ip_fw_ctl_ptr = NULL; callout_drain(&ipfw_timeout); IPFW_WLOCK(&layer3_chain); + flush_tables(&layer3_chain); layer3_chain.reap = NULL; free_chain(&layer3_chain, 1 /* kill default rule */); reap = layer3_chain.reap, layer3_chain.reap = NULL; IPFW_WUNLOCK(&layer3_chain); if (reap != NULL) reap_rules(reap); - flush_tables(); IPFW_DYN_LOCK_DESTROY(); uma_zdestroy(ipfw_dyn_rule_zone); IPFW_LOCK_DESTROY(&layer3_chain); --rCb8EA+9TsBVtA92-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 16:03:52 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0E8016A41F for ; Sun, 27 Nov 2005 16:03:52 +0000 (GMT) (envelope-from ozkan@mersin.edu.tr) Received: from mail.mersin.edu.tr (mail.mersin.edu.tr [193.255.128.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D09A43D46 for ; Sun, 27 Nov 2005 16:03:51 +0000 (GMT) (envelope-from ozkan@mersin.edu.tr) Received: from localhost (localhost.mersin.edu.tr [127.0.0.1]) by mail.mersin.edu.tr (Postfix) with ESMTP id CC11B45374 for ; Sun, 27 Nov 2005 18:03:48 +0200 (EET) Received: from mail.mersin.edu.tr ([127.0.0.1]) by localhost (mail.mersin.edu.tr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11019-41 for ; Sun, 27 Nov 2005 18:03:37 +0200 (EET) Received: from [10.0.50.20] (unknown [81.213.166.209]) by mail.mersin.edu.tr (Postfix) with ESMTP id E15274536B for ; Sun, 27 Nov 2005 18:03:36 +0200 (EET) Message-ID: <4389D8D7.7000809@mersin.edu.tr> Date: Sun, 27 Nov 2005 18:03:35 +0200 From: =?ISO-8859-9?Q?=D6zkan_KIRIK?= User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050927) X-Accept-Language: tr-TR, tr, en-US, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mersin.edu.tr Subject: if_bridge not working with second interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 16:03:52 -0000 Hi, i am trying to bridge two interfaces via if_bridge. i built a new kernel that includes "device if_bridge" line. my physical interfaces are fxp0 and fxp1 bridge0 works with fxp0, but it doesnt work with fxp1 i tried configurations below: Note: fxp0 and fxp1 doesnt have ip adress # ifconfig bridge0 create # ifconfig bridge0 addm fxp0 # ifconfig bridge0 inet 10.0.0.1/24 # ping 10.0.0.2 PING 10.0.0.2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.50.1: icmp_seq=0 ttl=64 time=1.847 ms ... it works. Then, I removed cable from fxp0 and plugged to fxp1. # ifconfig bridge0 destroy # ifconfig bridge0 create # ifconfig bridge0 addm fxp1 # ifconfig bridge0 inet 10.0.0.1/24 # ping 10.0.0.2 PING 10.0.0.2 (10.0.0.2): 56 data bytes ping: sendto: Host is down ... After this result, i removed fxp0 from my pc. Now the old fxp1 becomes fxp0. And now i can ping via bridge member fxp0. All NICs are working , but as you see if_bridge doesnt work with the second interface. How can i solve problem? ( OS is: FreeBSD 6.0 - RELEASE ) thanks for your interests From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 16:19:13 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BA5E16A41F for ; Sun, 27 Nov 2005 16:19:13 +0000 (GMT) (envelope-from priarifire@yahoo.com) Received: from web60022.mail.yahoo.com (web60022.mail.yahoo.com [209.73.178.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 7F6BE43D7C for ; Sun, 27 Nov 2005 16:19:00 +0000 (GMT) (envelope-from priarifire@yahoo.com) Received: (qmail 96905 invoked by uid 60001); 27 Nov 2005 16:18:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oKQStwnEIOcl0EnD3zN7/sBb1jK+lp1rGy5u02HHAn8HIusnNUONAJHe/K36PJMETz2zulINiHP6ziqb5L8lEKEnDR4/GA0KJx5gUu/6QaEH7/p/eJt/zAEERKWejcUTNzxL36iq6aHEO98Bq3SczHzjOgQ9MdB2zEfa09q7eX8= ; Message-ID: <20051127161859.96903.qmail@web60022.mail.yahoo.com> Received: from [65.26.195.25] by web60022.mail.yahoo.com via HTTP; Sun, 27 Nov 2005 08:18:59 PST Date: Sun, 27 Nov 2005 08:18:59 -0800 (PST) From: Imrani To: freebsd-net@freebsd.org In-Reply-To: <20051127135315.GA17605@flame.pc> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Configure wireless connection using Cisco aironet 350 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 16:19:13 -0000 I don't have any netstart-home.sh under /root directory. Moreover I dont' want IPv6 and its not something I expect. With regards to bringing up network, problem is network doesn't work and this is what I did: 1) edited /etc/rc.conf and add following line: ifconfig_an0="DHCP" 2) Then I run following command: ifconfig an0 inet 192.168.2.110 netmask 255.255.255.0 wepmode on wepkey 0x00000000000000000000654321 ssid myhome Once I run this.. ifconfig an0 status shows "associated" but unfortunately i cannot use this network for any connection. Even ping 192.168.2.1 doesn't work (thats my router IP). but I get this problem: "an0: record length mismatch -- expected 194, got 196 for Rid ff10" can u please suggest something? Thanks Giorgos Keramidas wrote: On 2005-11-26 23:58, Imrani wrote: > Hi, > I am trying to configure Cisco Aironet 350 wireless PCI card but I get > an error which I am unable to find much details for that. Following is > description of ifconfing: > > > ifconfig an0 > an0: flags=8843 mtu 1500 > inet6 fe80::209:7cff:fe22:6eab%an0 prefixlen 64 scopeid 0x2 > ether 00:09:7c:22:6e:ab > media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) > status: associated > ssid 1:myhome channel 9 > stationname FreeBSD > ano: record length mismatch -- expected 194, got 196 for Rid ff10 > authmode OPEN privacy ON deftxkey 2 txpowmax 0 rtsthreshold 0 > fragthreshold 0 roaming DEVICE > > As you can see the wireless card is detected and status is > "associated' but my wireless connection doesn't work. I cannot even > ping the router. Your interface only has an IPv6 address. Is that expected? How are you bringing up the an0 interface? For instance, my /root/netstart-home.sh script contains (among a few other things): # Default setup for my bge0 interface. export ifconfig_ath0="DHCP ssid 'XXXX' \ wepmode on weptxkey 1 wepkey '1:0xXXXXXXXXXXXXXXXXXXXXXXXXXX'" /etc/rc.d/netif stop bge0 /etc/rc.d/netif stop ath0 /etc/rc.d/netif start ath0 This seems to take care of everything here. _______________________________________________ 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" --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free. From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 19:46:15 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A45816A41F; Sun, 27 Nov 2005 19:46:15 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 035F143D55; Sun, 27 Nov 2005 19:46:13 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jARJkBG7089805; Sun, 27 Nov 2005 21:46:11 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 10420-06; Sun, 27 Nov 2005 21:46:10 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jARJjn9r089791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Nov 2005 21:45:49 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jARJjojQ076221; Sun, 27 Nov 2005 21:45:50 +0200 (EET) (envelope-from ru) Date: Sun, 27 Nov 2005 21:45:45 +0200 From: Ruslan Ermilov To: Gleb Smirnoff Message-ID: <20051127194545.GA76200@ip.net.ua> References: <20051127005943.GR25711@cell.sick.ru> <20051127135529.GF25711@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051127135529.GF25711@cell.sick.ru> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: Vsevolod Lobko , rwatson@FreeBSD.org, net@FreeBSD.org Subject: Re: parallelizing ipfw table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 19:46:15 -0000 On Sun, Nov 27, 2005 at 04:55:29PM +0300, Gleb Smirnoff wrote: > On Sun, Nov 27, 2005 at 03:59:43AM +0300, Gleb Smirnoff wrote: > T> A patch displaying the idea is attached. Not tested yet, read > T> below. The patch moves the tables array into the ip_fw_chain > T> structure. This is not necessary now, but in future we can > T> have multiple independent chains in ipfw, that's why I try > T> to avoid usage of &layer3_chain in the functions that are > T> deeper in the call graph. I try to supply chain pointer > T> from the caller. > T> > T> The only problem is the caching in table lookup. This "hack" > T> makes the lookup function modify the table structure. We need > T> to remove caching to make the lookup_table() function fully > T> lockless and reenterable at the same time. The attached patch > T> doesn't removes caching, since it only displays the original > T> idea. > > Okay, I have made a working patch, that is now undergoing testing > on SMP. I have axed all the caching from ipfw tables, to make > lookup_table() lockless and reenterable. This axing simplified > things much. I believe that the caching gives a benefit only > when we serve a small number of clients, and is only additional > workload when we are routing hundreds and thousands of simultaneous > IP flows. > > The patch attached. I'm going to put it into production testing as > soon as I can reboot the prod box. > Nope, I need this caching. It's for looking up the same table several times in a row but with various values. For example, we use ipfw tables to route the traffic to the correct dummynet pipe, where value is the bandwidth, and this caching helps a lot. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 19:59:18 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E19D16A41F; Sun, 27 Nov 2005 19:59:18 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C3D243D66; Sun, 27 Nov 2005 19:59:17 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jARJxEgB086607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Nov 2005 22:59:15 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jARJxEOl086606; Sun, 27 Nov 2005 22:59:14 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 27 Nov 2005 22:59:14 +0300 From: Gleb Smirnoff To: Ruslan Ermilov Message-ID: <20051127195914.GI25711@cell.sick.ru> References: <20051127005943.GR25711@cell.sick.ru> <20051127135529.GF25711@cell.sick.ru> <20051127194545.GA76200@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051127194545.GA76200@ip.net.ua> User-Agent: Mutt/1.5.6i Cc: Vsevolod Lobko , rwatson@FreeBSD.org, net@FreeBSD.org Subject: Re: parallelizing ipfw table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 19:59:18 -0000 Ruslan, On Sun, Nov 27, 2005 at 09:45:45PM +0200, Ruslan Ermilov wrote: R> Nope, I need this caching. It's for looking up the same table R> several times in a row but with various values. For example, R> we use ipfw tables to route the traffic to the correct dummynet R> pipe, where value is the bandwidth, and this caching helps a lot. Have you benchmarked that this caching is important? On a router that serves a lot of parallel traffic flows the caching is not a benefit, but additional processing. I think we should optimize the code for more loaded environments, since we don't care about CPU consumption in a less loaded setup - whether it is 0.1% or 0.11%. In general such kind of caching in network code is an old fashion, that causes a problems when we attempt to make code more parallelizable. We alreade removed rtcache in ip_output.c rev. 1.201 and we will soon remove route caching in gif(4), because it causes problems on SMP. Can you try my patch? Since it reduces the total number of mutex operations it should be a win on UP, too. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 20:00:16 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B45B16A41F for ; Sun, 27 Nov 2005 20:00:16 +0000 (GMT) (envelope-from misho@interbgc.com) Received: from mail.interbgc.com (mx02.interbgc.com [217.9.224.227]) by mx1.FreeBSD.org (Postfix) with SMTP id 250FC43D6A for ; Sun, 27 Nov 2005 20:00:10 +0000 (GMT) (envelope-from misho@interbgc.com) Received: (qmail 18744 invoked from network); 27 Nov 2005 20:00:07 -0000 Received: from misho@interbgc.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(-2.6/8.0):. Processed in 2.735015 secs); 27 Nov 2005 20:00:07 -0000 X-Spam-Status: No, hits=-2.6 required=8.0 Received: from topilapi-wlan.ddns.cablebg.net (HELO misho) (213.240.221.12) by mx02.interbgc.com with SMTP; 27 Nov 2005 20:00:04 -0000 Message-ID: <002801c5f38d$2885c1c0$0cddf0d5@misho> From: "Mihail Balikov" To: References: <20051127005943.GR25711@cell.sick.ru><20051127135529.GF25711@cell.sick.ru> <20051127194545.GA76200@ip.net.ua> Date: Sun, 27 Nov 2005 22:00:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Cc: Subject: Re: parallelizing ipfw table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mihail Balikov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 20:00:16 -0000 I have made small patch to cache results per "table" and this caching gives me about 92% hit ratio with a lot of session. ----- Original Message ----- From: "Ruslan Ermilov" To: "Gleb Smirnoff" Cc: "Vsevolod Lobko" ; ; Sent: Sunday, November 27, 2005 9:45 PM Subject: Re: parallelizing ipfw table > On Sun, Nov 27, 2005 at 04:55:29PM +0300, Gleb Smirnoff wrote: > > On Sun, Nov 27, 2005 at 03:59:43AM +0300, Gleb Smirnoff wrote: > > T> A patch displaying the idea is attached. Not tested yet, read > > T> below. The patch moves the tables array into the ip_fw_chain > > T> structure. This is not necessary now, but in future we can > > T> have multiple independent chains in ipfw, that's why I try > > T> to avoid usage of &layer3_chain in the functions that are > > T> deeper in the call graph. I try to supply chain pointer > > T> from the caller. > > T> > > T> The only problem is the caching in table lookup. This "hack" > > T> makes the lookup function modify the table structure. We need > > T> to remove caching to make the lookup_table() function fully > > T> lockless and reenterable at the same time. The attached patch > > T> doesn't removes caching, since it only displays the original > > T> idea. > > > > Okay, I have made a working patch, that is now undergoing testing > > on SMP. I have axed all the caching from ipfw tables, to make > > lookup_table() lockless and reenterable. This axing simplified > > things much. I believe that the caching gives a benefit only > > when we serve a small number of clients, and is only additional > > workload when we are routing hundreds and thousands of simultaneous > > IP flows. > > > > The patch attached. I'm going to put it into production testing as > > soon as I can reboot the prod box. > > > Nope, I need this caching. It's for looking up the same table > several times in a row but with various values. For example, > we use ipfw tables to route the traffic to the correct dummynet > pipe, where value is the bandwidth, and this caching helps a lot. > > > Cheers, > -- > Ruslan Ermilov > ru@FreeBSD.org > FreeBSD committer > _______________________________________________ > 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 Sun Nov 27 20:35:02 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D99116A41F; Sun, 27 Nov 2005 20:35:02 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (outbound.idiom.com [216.240.47.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F28F43D68; Sun, 27 Nov 2005 20:34:51 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 6C28622737C; Sun, 27 Nov 2005 12:34:51 -0800 (PST) Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id jARKYlhq028069; Sun, 27 Nov 2005 12:34:48 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <438A1867.1030009@elischer.org> Date: Sun, 27 Nov 2005 12:34:47 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <20051127005943.GR25711@cell.sick.ru> <20051127135529.GF25711@cell.sick.ru> In-Reply-To: <20051127135529.GF25711@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: rwatson@freebsd.org, Vsevolod Lobko , net@freebsd.org Subject: Re: parallelizing ipfw table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 20:35:02 -0000 Gleb Smirnoff wrote: >On Sun, Nov 27, 2005 at 03:59:43AM +0300, Gleb Smirnoff wrote: >T> A patch displaying the idea is attached. Not tested yet, read >T> below. The patch moves the tables array into the ip_fw_chain >T> structure. This is not necessary now, but in future we can >T> have multiple independent chains in ipfw, that's why I try >T> to avoid usage of &layer3_chain in the functions that are >T> deeper in the call graph. I try to supply chain pointer >T> from the caller. >T> >T> The only problem is the caching in table lookup. This "hack" >T> makes the lookup function modify the table structure. We need >T> to remove caching to make the lookup_table() function fully >T> lockless and reenterable at the same time. The attached patch >T> doesn't removes caching, since it only displays the original >T> idea. > >Okay, I have made a working patch, that is now undergoing testing >on SMP. I have axed all the caching from ipfw tables, to make >lookup_table() lockless and reenterable. This axing simplified >things much. I believe that the caching gives a benefit only >when we serve a small number of clients, and is only additional >workload when we are routing hundreds and thousands of simultaneous >IP flows. > >The patch attached. I'm going to put it into production testing as >soon as I can reboot the prod box. > > > would caching help when there are two successive packets of the same flow? That is not that uncommon, even though larger groupings are less common. From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 21:10:32 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2EF316A41F for ; Sun, 27 Nov 2005 21:10:32 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81F9A43D76 for ; Sun, 27 Nov 2005 21:10:30 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id E288A108; Sun, 27 Nov 2005 16:10:39 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 9902C836; Sun, 27 Nov 2005 16:10:38 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.54 (FreeBSD)) id 1EgTmo-0008I7-Nd; Sun, 27 Nov 2005 21:10:14 +0000 Date: Sun, 27 Nov 2005 21:10:14 +0000 From: Brian Candler To: Julian Elischer Message-ID: <20051127211014.GA31851@uk.tiscali.com> References: <43894FC9.6040205@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43894FC9.6040205@elischer.org> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: proposal: TCP rendevous X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 21:10:32 -0000 On Sat, Nov 26, 2005 at 10:18:49PM -0800, Julian Elischer wrote: > In this world of P2P apps it would be neat to have a way that two P2P apps > could attach to each other even though each is through a firewall. Most > firewalls only allow > "outgoing" connections. > > It would of course be possible via a 3rd party relaying but that is > inneffieient and the throughput > would be limited by throughput limits on the 3rd party link. > > It must be possible, with the connivance of a 3rd party both parties > could be able > to make suitable 'OUTGOING' connections. > The 3rd party would spoof needed packets using information supplied > by the two parties. See this: http://samy.pl/chownat/ (Haven't tried it myself, but came across it on Freshmeat a while ago. I imagine it must rely on the NAT firewalls not changing the source UDP port unless they have to) From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 22:21:05 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8956416A41F for ; Sun, 27 Nov 2005 22:21:05 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (outbound.idiom.com [216.240.47.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B36A43D5C for ; Sun, 27 Nov 2005 22:21:04 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 40517223C86; Sun, 27 Nov 2005 14:21:04 -0800 (PST) Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id jARML3nH066017; Sun, 27 Nov 2005 14:21:04 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <438A314E.2090403@elischer.org> Date: Sun, 27 Nov 2005 14:21:02 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Candler References: <43894FC9.6040205@elischer.org> <20051127211014.GA31851@uk.tiscali.com> In-Reply-To: <20051127211014.GA31851@uk.tiscali.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: proposal: TCP rendevous X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 22:21:05 -0000 Brian Candler wrote: >On Sat, Nov 26, 2005 at 10:18:49PM -0800, Julian Elischer wrote: > > >>In this world of P2P apps it would be neat to have a way that two P2P apps >>could attach to each other even though each is through a firewall. Most >>firewalls only allow >>"outgoing" connections. >> >>It would of course be possible via a 3rd party relaying but that is >>inneffieient and the throughput >>would be limited by throughput limits on the 3rd party link. >> >>It must be possible, with the connivance of a 3rd party both parties >>could be able >>to make suitable 'OUTGOING' connections. >>The 3rd party would spoof needed packets using information supplied >>by the two parties. >> >> > >See this: http://samy.pl/chownat/ > >(Haven't tried it myself, but came across it on Freshmeat a while ago. I >imagine it must rely on the NAT firewalls not changing the source UDP port >unless they have to) > > yes, which means it might unexpectedly fail. From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 23:38:01 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0937F16A41F for ; Sun, 27 Nov 2005 23:38:01 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 250D443D49 for ; Sun, 27 Nov 2005 23:37:59 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.12.11) with ESMTP id jARNbqjc017941 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 28 Nov 2005 00:37:52 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id jARNbmrv012760; Mon, 28 Nov 2005 00:37:48 +0100 (MET) Date: Mon, 28 Nov 2005 00:37:48 +0100 From: Daniel Hartmeier To: Julian Elischer Message-ID: <20051127233748.GA7212@insomnia.benzedrine.cx> References: <43894FC9.6040205@elischer.org> <20051127211014.GA31851@uk.tiscali.com> <438A314E.2090403@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438A314E.2090403@elischer.org> User-Agent: Mutt/1.5.10i Cc: net@freebsd.org, Brian Candler Subject: Re: proposal: TCP rendevous X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 23:38:01 -0000 On Sun, Nov 27, 2005 at 02:21:02PM -0800, Julian Elischer wrote: > yes, which means it might unexpectedly fail. I don't see how it can be done with TCP, assuming both peers are behind NATing firewalls (like pf). Some tricks to consider are: Let one peer send a SYN through the firewall towards the other peer, but set the TTL low, so the firewall creates a state entry but there will be no RST from the peer tearing down the state entry (the TTL-exceeded ICMP error is not a problem). The NATing firewall will pick a random source port as replacement and might even randomize the sequence numbers (as in pf's "modulate state"). Can the first peer find out what source port and ISN was chosen, so it can relay the information to an external third party? One idea would be to craft an ICMP error sent by the first peer, say a fake TTL-excceded message. In the inner IP and TCP header (the one in the ICMP payload), pretend that the first peer received a SYN+ACK from the second peer, and that the second peer chose the very same ISN as the first peer. But in the outer IP header, set the destination address to the external third party. This would pass pf's state engine and pf would demodulate the sequence number quoted in the payload. Hence, the external third party would receive both the random source part and the externally visible ISN of the first peer. It could then relay that information to the second peer. But here comes the problem. The second peer could similarly send a low-TTL SYN to create a state entry on his firewall, and then pass out a SYN+ACK to the first peer's port and ack'ing the proper ISN. But the firewall would similarly pick a random source port replacement for the second peer, which wouldn't match what the first peer picked as initial destination port. In short, the random NAT source ports are only decided when the first packet is sent. But the first packet already needs to contain the other peer's port. Which puts us back to square one ;) Daniel From owner-freebsd-net@FreeBSD.ORG Mon Nov 28 06:29:32 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2BDE16A41F; Mon, 28 Nov 2005 06:29:32 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8E8343D75; Mon, 28 Nov 2005 06:29:29 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jAS6TRv9015688; Mon, 28 Nov 2005 08:29:27 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 18813-03-2; Mon, 28 Nov 2005 08:29:25 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jAS6RabX015618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Nov 2005 08:27:37 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jAS6RbkM058802; Mon, 28 Nov 2005 08:27:37 +0200 (EET) (envelope-from ru) Date: Mon, 28 Nov 2005 08:27:32 +0200 From: Ruslan Ermilov To: Gleb Smirnoff Message-ID: <20051128062732.GA58778@ip.net.ua> References: <20051127005943.GR25711@cell.sick.ru> <20051127135529.GF25711@cell.sick.ru> <20051127194545.GA76200@ip.net.ua> <20051127195914.GI25711@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051127195914.GI25711@cell.sick.ru> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: Vsevolod Lobko , rwatson@freebsd.org, net@freebsd.org Subject: Re: parallelizing ipfw table 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 Nov 2005 06:29:33 -0000 On Sun, Nov 27, 2005 at 10:59:14PM +0300, Gleb Smirnoff wrote: > Ruslan, > > On Sun, Nov 27, 2005 at 09:45:45PM +0200, Ruslan Ermilov wrote: > R> Nope, I need this caching. It's for looking up the same table > R> several times in a row but with various values. For example, > R> we use ipfw tables to route the traffic to the correct dummynet > R> pipe, where value is the bandwidth, and this caching helps a lot. > > Have you benchmarked that this caching is important? On a router > that serves a lot of parallel traffic flows the caching is not > a benefit, but additional processing. I think we should optimize > the code for more loaded environments, since we don't care about > CPU consumption in a less loaded setup - whether it is 0.1% or 0.11%. > I'm talking about the following case: the same packet is processed by a firewall ruleset that has N rules that look up the same ipfw table but with different "values", to select a correct dummynet pipe. > In general such kind of caching in network code is an old fashion, > that causes a problems when we attempt to make code more > parallelizable. We alreade removed rtcache in ip_output.c rev. 1.201 > and we will soon remove route caching in gif(4), because it causes > problems on SMP. > > Can you try my patch? Since it reduces the total number of mutex > operations it should be a win on UP, too. > We're currently based on 4.x. You can try it yourself: create a table with 10000 entries and with value 13. Then write a ruleset with 13 rules that look up this table so that the last rule looks it up with value 13, and do a benchmark. Let me know what are results with and without caching. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-net@FreeBSD.ORG Mon Nov 28 09:47:31 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEEAB16A41F; Mon, 28 Nov 2005 09:47:31 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C372343D5D; Mon, 28 Nov 2005 09:47:30 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jAS9lSO1097800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Nov 2005 12:47:28 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jAS9lRdF097799; Mon, 28 Nov 2005 12:47:27 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 28 Nov 2005 12:47:27 +0300 From: Gleb Smirnoff To: Ruslan Ermilov Message-ID: <20051128094727.GK25711@cell.sick.ru> References: <20051127005943.GR25711@cell.sick.ru> <20051127135529.GF25711@cell.sick.ru> <20051127194545.GA76200@ip.net.ua> <20051127195914.GI25711@cell.sick.ru> <20051128062732.GA58778@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051128062732.GA58778@ip.net.ua> User-Agent: Mutt/1.5.6i Cc: Vsevolod Lobko , rwatson@FreeBSD.org, net@FreeBSD.org Subject: Re: parallelizing ipfw table 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 Nov 2005 09:47:31 -0000 On Mon, Nov 28, 2005 at 08:27:32AM +0200, Ruslan Ermilov wrote: R> > On Sun, Nov 27, 2005 at 09:45:45PM +0200, Ruslan Ermilov wrote: R> > R> Nope, I need this caching. It's for looking up the same table R> > R> several times in a row but with various values. For example, R> > R> we use ipfw tables to route the traffic to the correct dummynet R> > R> pipe, where value is the bandwidth, and this caching helps a lot. R> > R> > Have you benchmarked that this caching is important? On a router R> > that serves a lot of parallel traffic flows the caching is not R> > a benefit, but additional processing. I think we should optimize R> > the code for more loaded environments, since we don't care about R> > CPU consumption in a less loaded setup - whether it is 0.1% or 0.11%. R> > R> I'm talking about the following case: the same packet is R> processed by a firewall ruleset that has N rules that R> look up the same ipfw table but with different "values", R> to select a correct dummynet pipe. I understand this case. But wouldn't it be better to optimise this case by storing the last match on stack in ipfw_chk()? Can you please show me how this ruleset looks like? R> > In general such kind of caching in network code is an old fashion, R> > that causes a problems when we attempt to make code more R> > parallelizable. We alreade removed rtcache in ip_output.c rev. 1.201 R> > and we will soon remove route caching in gif(4), because it causes R> > problems on SMP. R> > R> > Can you try my patch? Since it reduces the total number of mutex R> > operations it should be a win on UP, too. R> > R> We're currently based on 4.x. You can try it yourself: create R> a table with 10000 entries and with value 13. Then write a R> ruleset with 13 rules that look up this table so that the last R> rule looks it up with value 13, and do a benchmark. Let me R> know what are results with and without caching. Such kind of firewall looks like unoptimized. Why should we optimize the code for non-optimized setups. Can't we avoid looking into one table 13 times each packet? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Nov 28 10:38:35 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1430616A420 for ; Mon, 28 Nov 2005 10:38:35 +0000 (GMT) (envelope-from babolo@cicuta.babolo.ru) Received: from ints.mail.pike.ru (ints.mail.pike.ru [85.30.199.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1FFF43D5E for ; Mon, 28 Nov 2005 10:38:32 +0000 (GMT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 5191 invoked from network); 28 Nov 2005 10:38:30 -0000 Received: from cicuta.babolo.ru (85.30.224.245) by ints.mail.pike.ru with SMTP; 28 Nov 2005 10:38:30 -0000 Received: (nullmailer pid 16076 invoked by uid 136); Mon, 28 Nov 2005 10:42:41 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20051128094727.GK25711@cell.sick.ru> To: Gleb Smirnoff Date: Mon, 28 Nov 2005 13:42:41 +0300 (MSK) From: .@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1133174561.369095.16075.nullmailer@cicuta.babolo.ru> Cc: Vsevolod Lobko , rwatson@FreeBSD.org, Ruslan Ermilov , net@FreeBSD.org Subject: Re: parallelizing ipfw table 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 Nov 2005 10:38:35 -0000 > On Mon, Nov 28, 2005 at 08:27:32AM +0200, Ruslan Ermilov wrote: > R> > Can you try my patch? Since it reduces the total number of mutex > R> > operations it should be a win on UP, too. > R> We're currently based on 4.x. You can try it yourself: create > R> a table with 10000 entries and with value 13. Then write a > R> ruleset with 13 rules that look up this table so that the last > R> rule looks it up with value 13, and do a benchmark. Let me > R> know what are results with and without caching. > Such kind of firewall looks like unoptimized. Why should we optimize the > code for non-optimized setups. Can't we avoid looking into one table > 13 times each packet? add 47400 pipe 47400 ip from table(0, 0) to any add 47401 pipe 47401 ip from table(0, 1) to any add 47402 pipe 47402 ip from table(0, 2) to any add 47403 pipe 47403 ip from table(0, 3) to any add 47404 pipe 47404 ip from table(0, 4) to any add 47405 pipe 47405 ip from table(0, 5) to any add 47406 pipe 47406 ip from table(0, 6) to any add 47407 pipe 47407 ip from table(0, 7) to any add 47408 pipe 47408 ip from table(0, 8) to any add 47409 pipe 47409 ip from table(0, 9) to any for different traffic consumers listed in table(0) From owner-freebsd-net@FreeBSD.ORG Mon Nov 28 10:52:55 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E96CA16A41F; Mon, 28 Nov 2005 10:52:55 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1658B43D55; Mon, 28 Nov 2005 10:52:54 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jASAqot1099127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Nov 2005 13:52:51 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jASAqo3v099126; Mon, 28 Nov 2005 13:52:50 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 28 Nov 2005 13:52:50 +0300 From: Gleb Smirnoff To: .@babolo.ru Message-ID: <20051128105250.GP25711@cell.sick.ru> References: <20051128094727.GK25711@cell.sick.ru> <1133174561.369095.16075.nullmailer@cicuta.babolo.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1133174561.369095.16075.nullmailer@cicuta.babolo.ru> User-Agent: Mutt/1.5.6i Cc: Vsevolod Lobko , rwatson@FreeBSD.org, Ruslan Ermilov , net@FreeBSD.org Subject: Re: parallelizing ipfw table 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 Nov 2005 10:52:56 -0000 On Mon, Nov 28, 2005 at 01:42:41PM +0300, .@babolo.ru wrote: .> > On Mon, Nov 28, 2005 at 08:27:32AM +0200, Ruslan Ermilov wrote: .> > R> > Can you try my patch? Since it reduces the total number of mutex .> > R> > operations it should be a win on UP, too. .> > R> We're currently based on 4.x. You can try it yourself: create .> > R> a table with 10000 entries and with value 13. Then write a .> > R> ruleset with 13 rules that look up this table so that the last .> > R> rule looks it up with value 13, and do a benchmark. Let me .> > R> know what are results with and without caching. .> > Such kind of firewall looks like unoptimized. Why should we optimize the .> > code for non-optimized setups. Can't we avoid looking into one table .> > 13 times each packet? .> .> add 47400 pipe 47400 ip from table(0, 0) to any .> add 47401 pipe 47401 ip from table(0, 1) to any .> add 47402 pipe 47402 ip from table(0, 2) to any .> add 47403 pipe 47403 ip from table(0, 3) to any .> add 47404 pipe 47404 ip from table(0, 4) to any .> add 47405 pipe 47405 ip from table(0, 5) to any .> add 47406 pipe 47406 ip from table(0, 6) to any .> add 47407 pipe 47407 ip from table(0, 7) to any .> add 47408 pipe 47408 ip from table(0, 8) to any .> add 47409 pipe 47409 ip from table(0, 9) to any .> .> for different traffic consumers listed in table(0) I understand now. Ruslan has sent me a sample setup, too. Anyway, the current optimization is broken on SMP, because it stores the cache in the table itself. Parallel processing of the different packets on SMP breaks the optimization, since different instances of ipfw_chk() trash the cached addr one after another. I have two ideas about this. First, store the cache on stack. Second, utilize the table entry value in the rule. In this case your block can be converted to: add N pipe \$val ip from table(0) to any \$val means the value of the entry in the table. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Nov 28 11:02:19 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AF6816A41F for ; Mon, 28 Nov 2005 11:02:19 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E296B43D45 for ; Mon, 28 Nov 2005 11:02:13 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id jASB285q088240 for ; Mon, 28 Nov 2005 11:02:08 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id jASB28du088234 for freebsd-net@freebsd.org; Mon, 28 Nov 2005 11:02:08 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 28 Nov 2005 11:02:08 GMT Message-Id: <200511281102.jASB28du088234@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2005 11:02:19 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit o [2005/11/03] kern/88450 net SYN+ACK reports strange size of window 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 28 12:48:25 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD05C16A424 for ; Mon, 28 Nov 2005 12:48:25 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CE2A43DA1 for ; Mon, 28 Nov 2005 12:48:06 +0000 (GMT) (envelope-from keramida@linux.gr) Received: (qmail 6138 invoked by uid 207); 28 Nov 2005 12:48:02 -0000 Received: from keramida@linux.gr by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.30/3.97. Clear:RC:1(81.186.70.128):. Processed in 2.57942 secs); 28 Nov 2005 12:48:02 -0000 Received: from dialup128.ach.sch.gr (HELO flame.pc) ([81.186.70.128]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 28 Nov 2005 12:47:59 -0000 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id jASClLFo001025 for ; Mon, 28 Nov 2005 14:47:21 +0200 (EET) (envelope-from keramida@linux.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id jAS90fOr001719; Mon, 28 Nov 2005 11:00:41 +0200 (EET) (envelope-from keramida@linux.gr) Date: Mon, 28 Nov 2005 11:00:41 +0200 From: Giorgos Keramidas To: Imrani Message-ID: <20051128090041.GA1623@flame.pc> References: <20051127135315.GA17605@flame.pc> <20051127161859.96903.qmail@web60022.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051127161859.96903.qmail@web60022.mail.yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: Configure wireless connection using Cisco aironet 350 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 Nov 2005 12:48:25 -0000 Please *don't* post a reply on top of the original, quoting the entire original message. Top-posting is a bit annoying and quoting all the text of the original message when it's unnecessary is usually a waste of bandwidth and reader's time. On 2005-11-27 08:18, Imrani wrote: > Giorgos Keramidas wrote: > > Your interface only has an IPv6 address. Is that expected? How > > are you bringing up the an0 interface? > > > > For instance, my /root/netstart-home.sh script contains (among a > > few other things): > > > > # Default setup for my bge0 interface. > > export ifconfig_ath0="DHCP ssid 'XXXX' \ > > wepmode on weptxkey 1 wepkey '1:0xXXXXXXXXXXXXXXXXXXXXXXXXXX'" > > > > /etc/rc.d/netif stop bge0 > > /etc/rc.d/netif stop ath0 > > /etc/rc.d/netif start ath0 > > > > This seems to take care of everything here. > > I don't have any netstart-home.sh under /root directory. Moreover I > dont' want IPv6 and its not something I expect. That's not a "default" script of FreeBSD. It's just a wrapper around /etc/rc.d/netif that I use here, because my wireless connection is not always necessary. I don't want my wireless interface to be brought up automatically *every* time I boot, so I wrote the netstart-home.sh script to fire up the wireless interface only when I need to do so. This works because the /etc/rc.d scripts use /etc/rc.conf as a "persistent storage" of options that they look up in the environment of the current process. This way, by setting things in the current environment, before a script from /etc/rc.d runs (the 'netif' script in this case), I don't have to edit my /etc/rc.conf file manually every time I want to tweak just one option (the ifconfig_ath0 option here). > With regards to bringing up network, problem is network doesn't work > and this is what I did: > > 1) edited /etc/rc.conf and add following line: > ifconfig_an0="DHCP" That's probably ok, if your wireless interface is supposed to obtain an IP address automatically. Then you'll have to run: /etc/rc.d/netif start an0 to let the system startup script 'netif' bring up the interface. This will take care of running 'dhclient an0', which in turn will set up routing, the gateway, the DNS servers and all the other options your /etc/dhclient.conf is configured to use for the 'an0' interface. You didn't use 'netif' though. > 2) Then I run following command: > ifconfig an0 inet 192.168.2.110 netmask 255.255.255.0 wepmode on wepkey 0x00000000000000000000654321 ssid myhome Why? You don't need this. Just use /etc/rc.d/netif as described above to bring up the 'an0' interface with whatever options your /etc/rc.conf specifies (DHCP in this case). You haven't specified any "up" ifconfig option too, so this will set the parameters of the an0 interface but will *NOT* bring it up automatically. This is probably one of the reasons why you're having problems later on. > Once I run this.. ifconfig an0 status shows "associated" but > unfortunately i cannot use this network for any connection. > Even ping 192.168.2.1 doesn't work (thats my router IP). Is the an0 interface "up"? It's very likely that it isn't. > but I get this problem: > > "an0: record length mismatch -- expected 194, got 196 for Rid ff10" > > can u please suggest something? Ok, this sounds like a problem. But before we try to troubleshoot this one, you should use the process I described above to bring the interface up. To summarize: 1. Edit /etc/rc.conf and add: ifconfig_an0="DHCP ssid myhome wepmode on weptxkey 1 wepkey 1:0x00000000000000000000654321" This should be all in one line and you should edit ssid and the wepkey to match your local settings. 2. Bring up the interface using /etc/rc.d/netif: # /etc/rc.d/netif start an0 3. Wait until it's associated: # while true; do status=$( ifconfig an0 2>&1 | grep status: | \ awk '{print $2}' ) if [ "$status" = 'associated' ]; then echo "an0 associated" fi done 4. Check your routing table and the IP address of your an0 interface: # ifconfig an0 # netstat -rn Then, if you are still having problems with the an0 interface, we can start looking for a real bug. - Giorgos From owner-freebsd-net@FreeBSD.ORG Mon Nov 28 16:19:40 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 751DD16A42B; Mon, 28 Nov 2005 16:19:40 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3064843D60; Mon, 28 Nov 2005 16:19:38 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jASGJaTn005095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Nov 2005 19:19:36 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jASGJYtQ005094; Mon, 28 Nov 2005 19:19:34 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 28 Nov 2005 19:19:34 +0300 From: Gleb Smirnoff To: Ruslan Ermilov Message-ID: <20051128161934.GY25711@cell.sick.ru> References: <20051127005943.GR25711@cell.sick.ru> <20051127135529.GF25711@cell.sick.ru> <20051127194545.GA76200@ip.net.ua> <20051127195914.GI25711@cell.sick.ru> <20051128062732.GA58778@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1y1tiN5hVw5cPBDe" Content-Disposition: inline In-Reply-To: <20051128062732.GA58778@ip.net.ua> User-Agent: Mutt/1.5.6i Cc: Vsevolod Lobko , rwatson@FreeBSD.org, net@FreeBSD.org Subject: Re: parallelizing ipfw table 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 Nov 2005 16:19:40 -0000 --1y1tiN5hVw5cPBDe Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Ruslan, okay, I have implemented a feature that allows to merge your ruleset into one rule. Look how it works: root@behemoth:~:|>kldload dummynet root@behemoth:~:|>ipfw pipe 2 config root@behemoth:~:|>ipfw pipe 3 config root@behemoth:~:|>ipfw add 1000 pipe 65535 ip from any to table\(1\) 01000 pipe 65535 ip from any to table(1) root@behemoth:~:|>ipfw table 1 add 217.72.144.35 2 root@behemoth:~:|>ipfw table 1 add 217.72.144.68 3 root@behemoth:~:|>ipfw table 1 list 217.72.144.35/32 2 217.72.144.68/32 3 root@behemoth:~:|>ping cell.sick.ru PING cell.sick.ru (217.72.144.68): 56 data bytes 64 bytes from 217.72.144.68: icmp_seq=0 ttl=60 time=2.653 ms ^C --- cell.sick.ru ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.653/2.653/2.653/0.000 ms root@behemoth:~:|>ping unixfaq.ru PING unixfaq.ru (217.72.144.35): 56 data bytes 64 bytes from 217.72.144.35: icmp_seq=0 ttl=60 time=2.563 ms ^C --- unixfaq.ru ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.563/2.563/2.563/0.000 ms root@behemoth:~:|>ipfw pipe 2 show 00002: unlimited 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 icmp 81.19.64.118/0 217.72.144.35/0 1 84 0 0 0 root@behemoth:~:|>ipfw pipe 3 show 00003: unlimited 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 icmp 81.19.64.118/0 217.72.144.68/0 1 84 0 0 0 The number 65535 is some magic number, which means "take argument from table". I will make ipfw display some word instead of 65535, for example "tablearg". So, the rule will be looking like: pipe tablearg ip from any to table(1) Implementing this feature I have encountered a problem, that I have encountered before - the locate_flowset() function in ip_dummynet.c. The problem is that dummynet and ipfw are so welded together. The rule itself points into a pipe, and this puts a design limit that a packet from a rule can go only into one pipe. So, I removed this limitation removing the pointer from rule to pipe. This change also garbage-collected several XXX in the code. Yes, I've made a regression here for the time for pipe/queue lookup. But this is a proof-of-concept patch. Before checking in I will make a hash for pipes/queues in dummynet. This change also is a step forward in divorcing dummynet and ipfw, and thus a step closer to ng_dummynet node :). The proof-of-concept patch attached. Before committing it will be divided into three parts: 1) unlock the tables and remove caching 2) remove the rule->pipe pointer and implement hash for pipes/queues 3) introduce the tablearg feature -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --1y1tiN5hVw5cPBDe Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ip_fw.table_unlock.pipe_tablearg.diff" Index: ip_dummynet.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_dummynet.c,v retrieving revision 1.95 diff -u -r1.95 ip_dummynet.c --- ip_dummynet.c 27 Sep 2005 18:10:42 -0000 1.95 +++ ip_dummynet.c 28 Nov 2005 15:30:31 -0000 @@ -1111,19 +1111,11 @@ struct dn_flow_set * locate_flowset(int pipe_nr, struct ip_fw *rule) { - struct dn_flow_set *fs; + struct dn_flow_set *fs = NULL; ipfw_insn *cmd = ACTION_PTR(rule); if (cmd->opcode == O_LOG) cmd += F_LEN(cmd); -#ifdef __i386__ - fs = ((ipfw_insn_pipe *)cmd)->pipe_ptr; -#else - bcopy(& ((ipfw_insn_pipe *)cmd)->pipe_ptr, &fs, sizeof(fs)); -#endif - - if (fs != NULL) - return fs; if (cmd->opcode == O_QUEUE) for (fs=all_flow_sets; fs && fs->fs_nr != pipe_nr; fs=fs->next) @@ -1135,12 +1127,6 @@ if (p1 != NULL) fs = &(p1->fs) ; } - /* record for the future */ -#ifdef __i386__ - ((ipfw_insn_pipe *)cmd)->pipe_ptr = fs; -#else - bcopy(&fs, & ((ipfw_insn_pipe *)cmd)->pipe_ptr, sizeof(fs)); -#endif return fs ; } @@ -1407,8 +1393,6 @@ struct dn_flow_set *fs, *curr_fs; DUMMYNET_LOCK(); - /* remove all references to pipes ...*/ - flush_pipe_ptrs(NULL); /* prevent future matches... */ p = all_pipes ; all_pipes = NULL ; @@ -1811,8 +1795,6 @@ all_pipes = b->next ; else a->next = b->next ; - /* remove references to this pipe from the ip_fw rules. */ - flush_pipe_ptrs(&(b->fs)); /* remove all references to this pipe from flow_sets */ for (fs = all_flow_sets; fs; fs= fs->next ) @@ -1846,8 +1828,6 @@ all_flow_sets = b->next ; else a->next = b->next ; - /* remove references to this flow_set from the ip_fw rules. */ - flush_pipe_ptrs(b); if (b->pipe != NULL) { /* Update total weight on parent pipe and cleanup parent heaps */ Index: ip_fw.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.h,v retrieving revision 1.101 diff -u -r1.101 ip_fw.h --- ip_fw.h 13 Aug 2005 11:02:33 -0000 1.101 +++ ip_fw.h 28 Nov 2005 15:37:05 -0000 @@ -271,19 +271,6 @@ } ipfw_insn_if; /* - * This is used for pipe and queue actions, which need to store - * a single pointer (which can have different size on different - * architectures. - * Note that, because of previous instructions, pipe_ptr might - * be unaligned in the overall structure, so it needs to be - * manipulated with care. - */ -typedef struct _ipfw_insn_pipe { - ipfw_insn o; - void *pipe_ptr; /* XXX */ -} ipfw_insn_pipe; - -/* * This is used for storing an altq queue id number. */ typedef struct _ipfw_insn_altq { @@ -474,6 +461,8 @@ ipfw_table_entry ent[0]; /* entries */ } ipfw_table; +#define IP_FW_TABLECOOKIE USHRT_MAX + /* * Main firewall chains definitions and global var's definitions. */ @@ -546,8 +535,6 @@ int ipfw_init(void); void ipfw_destroy(void); -void flush_pipe_ptrs(struct dn_flow_set *match); /* used by dummynet */ - typedef int ip_fw_ctl_t(struct sockopt *); extern ip_fw_ctl_t *ip_fw_ctl_ptr; extern int fw_one_pass; Index: ip_fw2.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v retrieving revision 1.115 diff -u -r1.115 ip_fw2.c --- ip_fw2.c 10 Nov 2005 22:10:39 -0000 1.115 +++ ip_fw2.c 28 Nov 2005 15:30:05 -0000 @@ -51,6 +51,7 @@ #include #include #include +#include #include #include #include @@ -126,9 +127,11 @@ int fw_prid; }; +#define IPFW_TABLES_MAX 128 struct ip_fw_chain { struct ip_fw *rules; /* list of rules */ struct ip_fw *reap; /* list of rules to reap */ + struct radix_node_head *tables[IPFW_TABLES_MAX]; struct mtx mtx; /* lock guarding rule list */ int busy_count; /* busy count for rw locks */ int want_write; @@ -192,15 +195,6 @@ u_int32_t value; }; -#define IPFW_TABLES_MAX 128 -static struct ip_fw_table { - struct radix_node_head *rnh; - int modified; - in_addr_t last_addr; - int last_match; - u_int32_t last_value; -} ipfw_tables[IPFW_TABLES_MAX]; - static int fw_debug = 1; static int autoinc_step = 100; /* bounded to 1..1000 in add_rule() */ @@ -1703,25 +1697,24 @@ } static void -init_tables(void) +init_tables(struct ip_fw_chain *ch) { int i; - for (i = 0; i < IPFW_TABLES_MAX; i++) { - rn_inithead((void **)&ipfw_tables[i].rnh, 32); - ipfw_tables[i].modified = 1; - } + for (i = 0; i < IPFW_TABLES_MAX; i++) + rn_inithead((void **)&ch->tables[i], 32); } static int -add_table_entry(u_int16_t tbl, in_addr_t addr, u_int8_t mlen, u_int32_t value) +add_table_entry(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t addr, + uint8_t mlen, uint32_t value) { struct radix_node_head *rnh; struct table_entry *ent; if (tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl].rnh; + rnh = ch->tables[tbl]; ent = malloc(sizeof(*ent), M_IPFW_TBL, M_NOWAIT | M_ZERO); if (ent == NULL) return (ENOMEM); @@ -1729,20 +1722,20 @@ ent->addr.sin_len = ent->mask.sin_len = 8; ent->mask.sin_addr.s_addr = htonl(mlen ? ~((1 << (32 - mlen)) - 1) : 0); ent->addr.sin_addr.s_addr = addr & ent->mask.sin_addr.s_addr; - RADIX_NODE_HEAD_LOCK(rnh); + IPFW_WLOCK(&layer3_chain); if (rnh->rnh_addaddr(&ent->addr, &ent->mask, rnh, (void *)ent) == NULL) { - RADIX_NODE_HEAD_UNLOCK(rnh); + IPFW_WUNLOCK(&layer3_chain); free(ent, M_IPFW_TBL); return (EEXIST); } - ipfw_tables[tbl].modified = 1; - RADIX_NODE_HEAD_UNLOCK(rnh); + IPFW_WUNLOCK(&layer3_chain); return (0); } static int -del_table_entry(u_int16_t tbl, in_addr_t addr, u_int8_t mlen) +del_table_entry(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t addr, + uint8_t mlen) { struct radix_node_head *rnh; struct table_entry *ent; @@ -1750,18 +1743,17 @@ if (tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl].rnh; + rnh = ch->tables[tbl]; sa.sin_len = mask.sin_len = 8; mask.sin_addr.s_addr = htonl(mlen ? ~((1 << (32 - mlen)) - 1) : 0); sa.sin_addr.s_addr = addr & mask.sin_addr.s_addr; - RADIX_NODE_HEAD_LOCK(rnh); + IPFW_WLOCK(ch); ent = (struct table_entry *)rnh->rnh_deladdr(&sa, &mask, rnh); if (ent == NULL) { - RADIX_NODE_HEAD_UNLOCK(rnh); + IPFW_WUNLOCK(ch); return (ESRCH); } - ipfw_tables[tbl].modified = 1; - RADIX_NODE_HEAD_UNLOCK(rnh); + IPFW_WUNLOCK(ch); free(ent, M_IPFW_TBL); return (0); } @@ -1780,63 +1772,48 @@ } static int -flush_table(u_int16_t tbl) +flush_table(struct ip_fw_chain *ch, uint16_t tbl) { struct radix_node_head *rnh; + IPFW_WLOCK_ASSERT(ch); + if (tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl].rnh; - RADIX_NODE_HEAD_LOCK(rnh); + rnh = ch->tables[tbl]; rnh->rnh_walktree(rnh, flush_table_entry, rnh); - ipfw_tables[tbl].modified = 1; - RADIX_NODE_HEAD_UNLOCK(rnh); return (0); } static void -flush_tables(void) +flush_tables(struct ip_fw_chain *ch) { - u_int16_t tbl; + uint16_t tbl; + + IPFW_WLOCK_ASSERT(ch); for (tbl = 0; tbl < IPFW_TABLES_MAX; tbl++) - flush_table(tbl); + flush_table(ch, tbl); } static int -lookup_table(u_int16_t tbl, in_addr_t addr, u_int32_t *val) +lookup_table(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t addr, + uint32_t *val) { struct radix_node_head *rnh; - struct ip_fw_table *table; struct table_entry *ent; struct sockaddr_in sa; - int last_match; if (tbl >= IPFW_TABLES_MAX) return (0); - table = &ipfw_tables[tbl]; - rnh = table->rnh; - RADIX_NODE_HEAD_LOCK(rnh); - if (addr == table->last_addr && !table->modified) { - last_match = table->last_match; - if (last_match) - *val = table->last_value; - RADIX_NODE_HEAD_UNLOCK(rnh); - return (last_match); - } - table->modified = 0; + rnh = ch->tables[tbl]; sa.sin_len = 8; sa.sin_addr.s_addr = addr; ent = (struct table_entry *)(rnh->rnh_lookup(&sa, NULL, rnh)); - table->last_addr = addr; if (ent != NULL) { - table->last_value = *val = ent->value; - table->last_match = 1; - RADIX_NODE_HEAD_UNLOCK(rnh); + *val = ent->value; return (1); } - table->last_match = 0; - RADIX_NODE_HEAD_UNLOCK(rnh); return (0); } @@ -1850,17 +1827,15 @@ } static int -count_table(u_int32_t tbl, u_int32_t *cnt) +count_table(struct ip_fw_chain *ch, uint32_t tbl, uint32_t *cnt) { struct radix_node_head *rnh; if (tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl].rnh; + rnh = ch->tables[tbl]; *cnt = 0; - RADIX_NODE_HEAD_LOCK(rnh); rnh->rnh_walktree(rnh, count_table_entry, cnt); - RADIX_NODE_HEAD_UNLOCK(rnh); return (0); } @@ -1886,17 +1861,17 @@ } static int -dump_table(ipfw_table *tbl) +dump_table(struct ip_fw_chain *ch, ipfw_table *tbl) { struct radix_node_head *rnh; + IPFW_WLOCK_ASSERT(ch); + if (tbl->tbl >= IPFW_TABLES_MAX) return (EINVAL); - rnh = ipfw_tables[tbl->tbl].rnh; + rnh = ch->tables[tbl->tbl]; tbl->cnt = 0; - RADIX_NODE_HEAD_LOCK(rnh); rnh->rnh_walktree(rnh, dump_table_entry, tbl); - RADIX_NODE_HEAD_UNLOCK(rnh); return (0); } @@ -2409,9 +2384,9 @@ * Now scan the rules, and parse microinstructions for each rule. */ for (; f; f = f->next) { - int l, cmdlen; ipfw_insn *cmd; - int skip_or; /* skip rest of OR block */ + uint32_t tablearg = 0; + int l, cmdlen, skip_or; /* skip rest of OR block */ again: if (set_disable & (1 << f->set) ) @@ -2567,12 +2542,15 @@ dst_ip.s_addr : src_ip.s_addr; uint32_t v; - match = lookup_table(cmd->arg1, a, &v); + match = lookup_table(chain, cmd->arg1, a, + &v); if (!match) break; if (cmdlen == F_INSN_SIZE(ipfw_insn_u32)) match = ((ipfw_insn_u32 *)cmd)->d[0] == v; + else + tablearg = v; } break; @@ -3024,7 +3002,10 @@ case O_PIPE: case O_QUEUE: args->rule = f; /* report matching rule */ - args->cookie = cmd->arg1; + if (cmd->arg1 == IP_FW_TABLECOOKIE) + args->cookie = tablearg; + else + args->cookie = cmd->arg1; retval = IP_FW_DUMMYNET; goto done; @@ -3045,7 +3026,10 @@ } dt = (struct divert_tag *)(mtag+1); dt->cookie = f->rulenum; - dt->info = cmd->arg1; + if (cmd->arg1 == IP_FW_TABLECOOKIE) + dt->info = tablearg; + else + dt->info = cmd->arg1; m_tag_prepend(m, mtag); retval = (cmd->opcode == O_DIVERT) ? IP_FW_DIVERT : IP_FW_TEE; @@ -3110,7 +3094,10 @@ case O_NETGRAPH: case O_NGTEE: args->rule = f; /* report matching rule */ - args->cookie = cmd->arg1; + if (cmd->arg1 == IP_FW_TABLECOOKIE) + args->cookie = tablearg; + else + args->cookie = cmd->arg1; retval = (cmd->opcode == O_NETGRAPH) ? IP_FW_NETGRAPH : IP_FW_NGTEE; goto done; @@ -3169,34 +3156,6 @@ } /* - * When pipes/queues are deleted, clear the "pipe_ptr" pointer to a given - * pipe/queue, or to all of them (match == NULL). - */ -void -flush_pipe_ptrs(struct dn_flow_set *match) -{ - struct ip_fw *rule; - - IPFW_WLOCK(&layer3_chain); - for (rule = layer3_chain.rules; rule; rule = rule->next) { - ipfw_insn_pipe *cmd = (ipfw_insn_pipe *)ACTION_PTR(rule); - - if (cmd->o.opcode != O_PIPE && cmd->o.opcode != O_QUEUE) - continue; - /* - * XXX Use bcmp/bzero to handle pipe_ptr to overcome - * possible alignment problems on 64-bit architectures. - * This code is seldom used so we do not worry too - * much about efficiency. - */ - if (match == NULL || - !bcmp(&cmd->pipe_ptr, &match, sizeof(match)) ) - bzero(&cmd->pipe_ptr, sizeof(cmd->pipe_ptr)); - } - IPFW_WUNLOCK(&layer3_chain); -} - -/* * Add a new rule to the list. Copy the rule into a malloc'ed area, then * possibly create a rule number and add the rule to the list. * Update the rule_number in the input struct so the caller knows it as well. @@ -3685,7 +3644,7 @@ case O_PIPE: case O_QUEUE: - if (cmdlen != F_INSN_SIZE(ipfw_insn_pipe)) + if (cmdlen != F_INSN_SIZE(ipfw_insn)) goto bad_size; goto check_action; @@ -4012,8 +3971,8 @@ sizeof(ent), sizeof(ent)); if (error) break; - error = add_table_entry(ent.tbl, ent.addr, - ent.masklen, ent.value); + error = add_table_entry(&layer3_chain, ent.tbl, + ent.addr, ent.masklen, ent.value); } break; @@ -4025,7 +3984,8 @@ sizeof(ent), sizeof(ent)); if (error) break; - error = del_table_entry(ent.tbl, ent.addr, ent.masklen); + error = del_table_entry(&layer3_chain, ent.tbl, + ent.addr, ent.masklen); } break; @@ -4037,7 +3997,9 @@ sizeof(tbl), sizeof(tbl)); if (error) break; - error = flush_table(tbl); + IPFW_WLOCK(&layer3_chain); + error = flush_table(&layer3_chain, tbl); + IPFW_WUNLOCK(&layer3_chain); } break; @@ -4048,8 +4010,10 @@ if ((error = sooptcopyin(sopt, &tbl, sizeof(tbl), sizeof(tbl)))) break; - if ((error = count_table(tbl, &cnt))) + IPFW_RLOCK(&layer3_chain); + if ((error = count_table(&layer3_chain, tbl, &cnt))) break; + IPFW_RUNLOCK(&layer3_chain); error = sooptcopyout(sopt, &cnt, sizeof(cnt)); } break; @@ -4075,11 +4039,14 @@ } tbl->size = (size - sizeof(*tbl)) / sizeof(ipfw_table_entry); - error = dump_table(tbl); + IPFW_WLOCK(&layer3_chain); + error = dump_table(&layer3_chain, tbl); if (error) { + IPFW_WUNLOCK(&layer3_chain); free(tbl, M_TEMP); break; } + IPFW_WUNLOCK(&layer3_chain); error = sooptcopyout(sopt, tbl, size); free(tbl, M_TEMP); } @@ -4242,7 +4209,7 @@ printf("limited to %d packets/entry by default\n", verbose_limit); - init_tables(); + init_tables(&layer3_chain); ip_fw_ctl_ptr = ipfw_ctl; ip_fw_chk_ptr = ipfw_chk; callout_reset(&ipfw_timeout, hz, ipfw_tick, NULL); @@ -4259,13 +4226,13 @@ ip_fw_ctl_ptr = NULL; callout_drain(&ipfw_timeout); IPFW_WLOCK(&layer3_chain); + flush_tables(&layer3_chain); layer3_chain.reap = NULL; free_chain(&layer3_chain, 1 /* kill default rule */); reap = layer3_chain.reap, layer3_chain.reap = NULL; IPFW_WUNLOCK(&layer3_chain); if (reap != NULL) reap_rules(reap); - flush_tables(); IPFW_DYN_LOCK_DESTROY(); uma_zdestroy(ipfw_dyn_rule_zone); IPFW_LOCK_DESTROY(&layer3_chain); --1y1tiN5hVw5cPBDe-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 28 16:33:19 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54BBA16A41F; Mon, 28 Nov 2005 16:33:19 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61F0543D67; Mon, 28 Nov 2005 16:32:49 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id jASGWa53065922; Mon, 28 Nov 2005 08:32:36 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id jASGWanJ065921; Mon, 28 Nov 2005 08:32:36 -0800 (PST) (envelope-from rizzo) Date: Mon, 28 Nov 2005 08:32:36 -0800 From: Luigi Rizzo To: Gleb Smirnoff Message-ID: <20051128083236.A65831@xorpc.icir.org> References: <20051127005943.GR25711@cell.sick.ru> <20051127135529.GF25711@cell.sick.ru> <20051127194545.GA76200@ip.net.ua> <20051127195914.GI25711@cell.sick.ru> <20051128062732.GA58778@ip.net.ua> <20051128161934.GY25711@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20051128161934.GY25711@cell.sick.ru>; from glebius@freebsd.org on Mon, Nov 28, 2005 at 07:19:34PM +0300 Cc: rwatson@freebsd.org, Vsevolod Lobko , net@freebsd.org Subject: Re: parallelizing ipfw table 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 Nov 2005 16:33:19 -0000 the pipe-pointer within an ipfw rule is just for optimizing the lookup. Surely there is a better way to do this e.g. looking up pipes through a hash table. In fact, the same might be done for rule lookups. Given that hash tables are already implemented in both ipfw and dummynet for the dynamic rules and masked-pipes respectively, i suspect the relevant code would be rather trivial to implement, and efficiency should not be a concern given that we already pay that cost for address lookups. Given that you (Gleb) are putting in some new features, I would suggest a variant to your tablearg thing, i.e. + a 'setvar index value' which can be put as an always-true option within a rule e.g. to store partial evaluation results. 'index' could be a small integer e.g. 0-9, value a 32-bit value which is either a constant or a packet field (src-ip...) or your tablearg. + allow a 'varN' arguments everywhere you can have a rule or pipe or queue number. This way you can easily implement your proposal, and a lot more. One should remember that variables are not meant to be staved with the packet's state (e.g. when a packet goes back and forth to dummynet) but other than that i think it is a useful feature and a simple one to implement. cheers luigi On Mon, Nov 28, 2005 at 07:19:34PM +0300, Gleb Smirnoff wrote: > Ruslan, > > okay, I have implemented a feature that allows to merge your ruleset > into one rule. Look how it works: > > root@behemoth:~:|>kldload dummynet > root@behemoth:~:|>ipfw pipe 2 config > root@behemoth:~:|>ipfw pipe 3 config > root@behemoth:~:|>ipfw add 1000 pipe 65535 ip from any to table\(1\) > 01000 pipe 65535 ip from any to table(1) > root@behemoth:~:|>ipfw table 1 add 217.72.144.35 2 > root@behemoth:~:|>ipfw table 1 add 217.72.144.68 3 > root@behemoth:~:|>ipfw table 1 list > 217.72.144.35/32 2 > 217.72.144.68/32 3 > root@behemoth:~:|>ping cell.sick.ru > PING cell.sick.ru (217.72.144.68): 56 data bytes > 64 bytes from 217.72.144.68: icmp_seq=0 ttl=60 time=2.653 ms > ^C > --- cell.sick.ru ping statistics --- > 1 packets transmitted, 1 packets received, 0% packet loss > round-trip min/avg/max/stddev = 2.653/2.653/2.653/0.000 ms > root@behemoth:~:|>ping unixfaq.ru > PING unixfaq.ru (217.72.144.35): 56 data bytes > 64 bytes from 217.72.144.35: icmp_seq=0 ttl=60 time=2.563 ms > ^C > --- unixfaq.ru ping statistics --- > 1 packets transmitted, 1 packets received, 0% packet loss > round-trip min/avg/max/stddev = 2.563/2.563/2.563/0.000 ms > root@behemoth:~:|>ipfw pipe 2 show > 00002: unlimited 0 ms 50 sl. 1 queues (1 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp > 0 icmp 81.19.64.118/0 217.72.144.35/0 1 84 0 0 0 > root@behemoth:~:|>ipfw pipe 3 show > 00003: unlimited 0 ms 50 sl. 1 queues (1 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp > 0 icmp 81.19.64.118/0 217.72.144.68/0 1 84 0 0 0 > > The number 65535 is some magic number, which means "take argument from table". I > will make ipfw display some word instead of 65535, for example "tablearg". So, the > rule will be looking like: > > pipe tablearg ip from any to table(1) > > Implementing this feature I have encountered a problem, that I have encountered > before - the locate_flowset() function in ip_dummynet.c. The problem is that > dummynet and ipfw are so welded together. The rule itself points into a pipe, > and this puts a design limit that a packet from a rule can go only into one > pipe. So, I removed this limitation removing the pointer from rule to pipe. This > change also garbage-collected several XXX in the code. Yes, I've made a regression > here for the time for pipe/queue lookup. But this is a proof-of-concept patch. > Before checking in I will make a hash for pipes/queues in dummynet. This change > also is a step forward in divorcing dummynet and ipfw, and thus a step closer > to ng_dummynet node :). > > The proof-of-concept patch attached. > > Before committing it will be divided into three parts: > > 1) unlock the tables and remove caching > 2) remove the rule->pipe pointer and implement hash for pipes/queues > 3) introduce the tablearg feature > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > Index: ip_dummynet.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_dummynet.c,v > retrieving revision 1.95 > diff -u -r1.95 ip_dummynet.c > --- ip_dummynet.c 27 Sep 2005 18:10:42 -0000 1.95 > +++ ip_dummynet.c 28 Nov 2005 15:30:31 -0000 > @@ -1111,19 +1111,11 @@ > struct dn_flow_set * > locate_flowset(int pipe_nr, struct ip_fw *rule) > { > - struct dn_flow_set *fs; > + struct dn_flow_set *fs = NULL; > ipfw_insn *cmd = ACTION_PTR(rule); > > if (cmd->opcode == O_LOG) > cmd += F_LEN(cmd); > -#ifdef __i386__ > - fs = ((ipfw_insn_pipe *)cmd)->pipe_ptr; > -#else > - bcopy(& ((ipfw_insn_pipe *)cmd)->pipe_ptr, &fs, sizeof(fs)); > -#endif > - > - if (fs != NULL) > - return fs; > > if (cmd->opcode == O_QUEUE) > for (fs=all_flow_sets; fs && fs->fs_nr != pipe_nr; fs=fs->next) > @@ -1135,12 +1127,6 @@ > if (p1 != NULL) > fs = &(p1->fs) ; > } > - /* record for the future */ > -#ifdef __i386__ > - ((ipfw_insn_pipe *)cmd)->pipe_ptr = fs; > -#else > - bcopy(&fs, & ((ipfw_insn_pipe *)cmd)->pipe_ptr, sizeof(fs)); > -#endif > return fs ; > } > > @@ -1407,8 +1393,6 @@ > struct dn_flow_set *fs, *curr_fs; > > DUMMYNET_LOCK(); > - /* remove all references to pipes ...*/ > - flush_pipe_ptrs(NULL); > /* prevent future matches... */ > p = all_pipes ; > all_pipes = NULL ; > @@ -1811,8 +1795,6 @@ > all_pipes = b->next ; > else > a->next = b->next ; > - /* remove references to this pipe from the ip_fw rules. */ > - flush_pipe_ptrs(&(b->fs)); > > /* remove all references to this pipe from flow_sets */ > for (fs = all_flow_sets; fs; fs= fs->next ) > @@ -1846,8 +1828,6 @@ > all_flow_sets = b->next ; > else > a->next = b->next ; > - /* remove references to this flow_set from the ip_fw rules. */ > - flush_pipe_ptrs(b); > > if (b->pipe != NULL) { > /* Update total weight on parent pipe and cleanup parent heaps */ > Index: ip_fw.h > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_fw.h,v > retrieving revision 1.101 > diff -u -r1.101 ip_fw.h > --- ip_fw.h 13 Aug 2005 11:02:33 -0000 1.101 > +++ ip_fw.h 28 Nov 2005 15:37:05 -0000 > @@ -271,19 +271,6 @@ > } ipfw_insn_if; > > /* > - * This is used for pipe and queue actions, which need to store > - * a single pointer (which can have different size on different > - * architectures. > - * Note that, because of previous instructions, pipe_ptr might > - * be unaligned in the overall structure, so it needs to be > - * manipulated with care. > - */ > -typedef struct _ipfw_insn_pipe { > - ipfw_insn o; > - void *pipe_ptr; /* XXX */ > -} ipfw_insn_pipe; > - > -/* > * This is used for storing an altq queue id number. > */ > typedef struct _ipfw_insn_altq { > @@ -474,6 +461,8 @@ > ipfw_table_entry ent[0]; /* entries */ > } ipfw_table; > > +#define IP_FW_TABLECOOKIE USHRT_MAX > + > /* > * Main firewall chains definitions and global var's definitions. > */ > @@ -546,8 +535,6 @@ > int ipfw_init(void); > void ipfw_destroy(void); > > -void flush_pipe_ptrs(struct dn_flow_set *match); /* used by dummynet */ > - > typedef int ip_fw_ctl_t(struct sockopt *); > extern ip_fw_ctl_t *ip_fw_ctl_ptr; > extern int fw_one_pass; > Index: ip_fw2.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v > retrieving revision 1.115 > diff -u -r1.115 ip_fw2.c > --- ip_fw2.c 10 Nov 2005 22:10:39 -0000 1.115 > +++ ip_fw2.c 28 Nov 2005 15:30:05 -0000 > @@ -51,6 +51,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -126,9 +127,11 @@ > int fw_prid; > }; > > +#define IPFW_TABLES_MAX 128 > struct ip_fw_chain { > struct ip_fw *rules; /* list of rules */ > struct ip_fw *reap; /* list of rules to reap */ > + struct radix_node_head *tables[IPFW_TABLES_MAX]; > struct mtx mtx; /* lock guarding rule list */ > int busy_count; /* busy count for rw locks */ > int want_write; > @@ -192,15 +195,6 @@ > u_int32_t value; > }; > > -#define IPFW_TABLES_MAX 128 > -static struct ip_fw_table { > - struct radix_node_head *rnh; > - int modified; > - in_addr_t last_addr; > - int last_match; > - u_int32_t last_value; > -} ipfw_tables[IPFW_TABLES_MAX]; > - > static int fw_debug = 1; > static int autoinc_step = 100; /* bounded to 1..1000 in add_rule() */ > > @@ -1703,25 +1697,24 @@ > } > > static void > -init_tables(void) > +init_tables(struct ip_fw_chain *ch) > { > int i; > > - for (i = 0; i < IPFW_TABLES_MAX; i++) { > - rn_inithead((void **)&ipfw_tables[i].rnh, 32); > - ipfw_tables[i].modified = 1; > - } > + for (i = 0; i < IPFW_TABLES_MAX; i++) > + rn_inithead((void **)&ch->tables[i], 32); > } > > static int > -add_table_entry(u_int16_t tbl, in_addr_t addr, u_int8_t mlen, u_int32_t value) > +add_table_entry(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t addr, > + uint8_t mlen, uint32_t value) > { > struct radix_node_head *rnh; > struct table_entry *ent; > > if (tbl >= IPFW_TABLES_MAX) > return (EINVAL); > - rnh = ipfw_tables[tbl].rnh; > + rnh = ch->tables[tbl]; > ent = malloc(sizeof(*ent), M_IPFW_TBL, M_NOWAIT | M_ZERO); > if (ent == NULL) > return (ENOMEM); > @@ -1729,20 +1722,20 @@ > ent->addr.sin_len = ent->mask.sin_len = 8; > ent->mask.sin_addr.s_addr = htonl(mlen ? ~((1 << (32 - mlen)) - 1) : 0); > ent->addr.sin_addr.s_addr = addr & ent->mask.sin_addr.s_addr; > - RADIX_NODE_HEAD_LOCK(rnh); > + IPFW_WLOCK(&layer3_chain); > if (rnh->rnh_addaddr(&ent->addr, &ent->mask, rnh, (void *)ent) == > NULL) { > - RADIX_NODE_HEAD_UNLOCK(rnh); > + IPFW_WUNLOCK(&layer3_chain); > free(ent, M_IPFW_TBL); > return (EEXIST); > } > - ipfw_tables[tbl].modified = 1; > - RADIX_NODE_HEAD_UNLOCK(rnh); > + IPFW_WUNLOCK(&layer3_chain); > return (0); > } > > static int > -del_table_entry(u_int16_t tbl, in_addr_t addr, u_int8_t mlen) > +del_table_entry(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t addr, > + uint8_t mlen) > { > struct radix_node_head *rnh; > struct table_entry *ent; > @@ -1750,18 +1743,17 @@ > > if (tbl >= IPFW_TABLES_MAX) > return (EINVAL); > - rnh = ipfw_tables[tbl].rnh; > + rnh = ch->tables[tbl]; > sa.sin_len = mask.sin_len = 8; > mask.sin_addr.s_addr = htonl(mlen ? ~((1 << (32 - mlen)) - 1) : 0); > sa.sin_addr.s_addr = addr & mask.sin_addr.s_addr; > - RADIX_NODE_HEAD_LOCK(rnh); > + IPFW_WLOCK(ch); > ent = (struct table_entry *)rnh->rnh_deladdr(&sa, &mask, rnh); > if (ent == NULL) { > - RADIX_NODE_HEAD_UNLOCK(rnh); > + IPFW_WUNLOCK(ch); > return (ESRCH); > } > - ipfw_tables[tbl].modified = 1; > - RADIX_NODE_HEAD_UNLOCK(rnh); > + IPFW_WUNLOCK(ch); > free(ent, M_IPFW_TBL); > return (0); > } > @@ -1780,63 +1772,48 @@ > } > > static int > -flush_table(u_int16_t tbl) > +flush_table(struct ip_fw_chain *ch, uint16_t tbl) > { > struct radix_node_head *rnh; > > + IPFW_WLOCK_ASSERT(ch); > + > if (tbl >= IPFW_TABLES_MAX) > return (EINVAL); > - rnh = ipfw_tables[tbl].rnh; > - RADIX_NODE_HEAD_LOCK(rnh); > + rnh = ch->tables[tbl]; > rnh->rnh_walktree(rnh, flush_table_entry, rnh); > - ipfw_tables[tbl].modified = 1; > - RADIX_NODE_HEAD_UNLOCK(rnh); > return (0); > } > > static void > -flush_tables(void) > +flush_tables(struct ip_fw_chain *ch) > { > - u_int16_t tbl; > + uint16_t tbl; > + > + IPFW_WLOCK_ASSERT(ch); > > for (tbl = 0; tbl < IPFW_TABLES_MAX; tbl++) > - flush_table(tbl); > + flush_table(ch, tbl); > } > > static int > -lookup_table(u_int16_t tbl, in_addr_t addr, u_int32_t *val) > +lookup_table(struct ip_fw_chain *ch, uint16_t tbl, in_addr_t addr, > + uint32_t *val) > { > struct radix_node_head *rnh; > - struct ip_fw_table *table; > struct table_entry *ent; > struct sockaddr_in sa; > - int last_match; > > if (tbl >= IPFW_TABLES_MAX) > return (0); > - table = &ipfw_tables[tbl]; > - rnh = table->rnh; > - RADIX_NODE_HEAD_LOCK(rnh); > - if (addr == table->last_addr && !table->modified) { > - last_match = table->last_match; > - if (last_match) > - *val = table->last_value; > - RADIX_NODE_HEAD_UNLOCK(rnh); > - return (last_match); > - } > - table->modified = 0; > + rnh = ch->tables[tbl]; > sa.sin_len = 8; > sa.sin_addr.s_addr = addr; > ent = (struct table_entry *)(rnh->rnh_lookup(&sa, NULL, rnh)); > - table->last_addr = addr; > if (ent != NULL) { > - table->last_value = *val = ent->value; > - table->last_match = 1; > - RADIX_NODE_HEAD_UNLOCK(rnh); > + *val = ent->value; > return (1); > } > - table->last_match = 0; > - RADIX_NODE_HEAD_UNLOCK(rnh); > return (0); > } > > @@ -1850,17 +1827,15 @@ > } > > static int > -count_table(u_int32_t tbl, u_int32_t *cnt) > +count_table(struct ip_fw_chain *ch, uint32_t tbl, uint32_t *cnt) > { > struct radix_node_head *rnh; > > if (tbl >= IPFW_TABLES_MAX) > return (EINVAL); > - rnh = ipfw_tables[tbl].rnh; > + rnh = ch->tables[tbl]; > *cnt = 0; > - RADIX_NODE_HEAD_LOCK(rnh); > rnh->rnh_walktree(rnh, count_table_entry, cnt); > - RADIX_NODE_HEAD_UNLOCK(rnh); > return (0); > } > > @@ -1886,17 +1861,17 @@ > } > > static int > -dump_table(ipfw_table *tbl) > +dump_table(struct ip_fw_chain *ch, ipfw_table *tbl) > { > struct radix_node_head *rnh; > > + IPFW_WLOCK_ASSERT(ch); > + > if (tbl->tbl >= IPFW_TABLES_MAX) > return (EINVAL); > - rnh = ipfw_tables[tbl->tbl].rnh; > + rnh = ch->tables[tbl->tbl]; > tbl->cnt = 0; > - RADIX_NODE_HEAD_LOCK(rnh); > rnh->rnh_walktree(rnh, dump_table_entry, tbl); > - RADIX_NODE_HEAD_UNLOCK(rnh); > return (0); > } > > @@ -2409,9 +2384,9 @@ > * Now scan the rules, and parse microinstructions for each rule. > */ > for (; f; f = f->next) { > - int l, cmdlen; > ipfw_insn *cmd; > - int skip_or; /* skip rest of OR block */ > + uint32_t tablearg = 0; > + int l, cmdlen, skip_or; /* skip rest of OR block */ > > again: > if (set_disable & (1 << f->set) ) > @@ -2567,12 +2542,15 @@ > dst_ip.s_addr : src_ip.s_addr; > uint32_t v; > > - match = lookup_table(cmd->arg1, a, &v); > + match = lookup_table(chain, cmd->arg1, a, > + &v); > if (!match) > break; > if (cmdlen == F_INSN_SIZE(ipfw_insn_u32)) > match = > ((ipfw_insn_u32 *)cmd)->d[0] == v; > + else > + tablearg = v; > } > break; > > @@ -3024,7 +3002,10 @@ > case O_PIPE: > case O_QUEUE: > args->rule = f; /* report matching rule */ > - args->cookie = cmd->arg1; > + if (cmd->arg1 == IP_FW_TABLECOOKIE) > + args->cookie = tablearg; > + else > + args->cookie = cmd->arg1; > retval = IP_FW_DUMMYNET; > goto done; > > @@ -3045,7 +3026,10 @@ > } > dt = (struct divert_tag *)(mtag+1); > dt->cookie = f->rulenum; > - dt->info = cmd->arg1; > + if (cmd->arg1 == IP_FW_TABLECOOKIE) > + dt->info = tablearg; > + else > + dt->info = cmd->arg1; > m_tag_prepend(m, mtag); > retval = (cmd->opcode == O_DIVERT) ? > IP_FW_DIVERT : IP_FW_TEE; > @@ -3110,7 +3094,10 @@ > case O_NETGRAPH: > case O_NGTEE: > args->rule = f; /* report matching rule */ > - args->cookie = cmd->arg1; > + if (cmd->arg1 == IP_FW_TABLECOOKIE) > + args->cookie = tablearg; > + else > + args->cookie = cmd->arg1; > retval = (cmd->opcode == O_NETGRAPH) ? > IP_FW_NETGRAPH : IP_FW_NGTEE; > goto done; > @@ -3169,34 +3156,6 @@ > } > > /* > - * When pipes/queues are deleted, clear the "pipe_ptr" pointer to a given > - * pipe/queue, or to all of them (match == NULL). > - */ > -void > -flush_pipe_ptrs(struct dn_flow_set *match) > -{ > - struct ip_fw *rule; > - > - IPFW_WLOCK(&layer3_chain); > - for (rule = layer3_chain.rules; rule; rule = rule->next) { > - ipfw_insn_pipe *cmd = (ipfw_insn_pipe *)ACTION_PTR(rule); > - > - if (cmd->o.opcode != O_PIPE && cmd->o.opcode != O_QUEUE) > - continue; > - /* > - * XXX Use bcmp/bzero to handle pipe_ptr to overcome > - * possible alignment problems on 64-bit architectures. > - * This code is seldom used so we do not worry too > - * much about efficiency. > - */ > - if (match == NULL || > - !bcmp(&cmd->pipe_ptr, &match, sizeof(match)) ) > - bzero(&cmd->pipe_ptr, sizeof(cmd->pipe_ptr)); > - } > - IPFW_WUNLOCK(&layer3_chain); > -} > - > -/* > * Add a new rule to the list. Copy the rule into a malloc'ed area, then > * possibly create a rule number and add the rule to the list. > * Update the rule_number in the input struct so the caller knows it as well. > @@ -3685,7 +3644,7 @@ > > case O_PIPE: > case O_QUEUE: > - if (cmdlen != F_INSN_SIZE(ipfw_insn_pipe)) > + if (cmdlen != F_INSN_SIZE(ipfw_insn)) > goto bad_size; > goto check_action; > > @@ -4012,8 +3971,8 @@ > sizeof(ent), sizeof(ent)); > if (error) > break; > - error = add_table_entry(ent.tbl, ent.addr, > - ent.masklen, ent.value); > + error = add_table_entry(&layer3_chain, ent.tbl, > + ent.addr, ent.masklen, ent.value); > } > break; > > @@ -4025,7 +3984,8 @@ > sizeof(ent), sizeof(ent)); > if (error) > break; > - error = del_table_entry(ent.tbl, ent.addr, ent.masklen); > + error = del_table_entry(&layer3_chain, ent.tbl, > + ent.addr, ent.masklen); > } > break; > > @@ -4037,7 +3997,9 @@ > sizeof(tbl), sizeof(tbl)); > if (error) > break; > - error = flush_table(tbl); > + IPFW_WLOCK(&layer3_chain); > + error = flush_table(&layer3_chain, tbl); > + IPFW_WUNLOCK(&layer3_chain); > } > break; > > @@ -4048,8 +4010,10 @@ > if ((error = sooptcopyin(sopt, &tbl, sizeof(tbl), > sizeof(tbl)))) > break; > - if ((error = count_table(tbl, &cnt))) > + IPFW_RLOCK(&layer3_chain); > + if ((error = count_table(&layer3_chain, tbl, &cnt))) > break; > + IPFW_RUNLOCK(&layer3_chain); > error = sooptcopyout(sopt, &cnt, sizeof(cnt)); > } > break; > @@ -4075,11 +4039,14 @@ > } > tbl->size = (size - sizeof(*tbl)) / > sizeof(ipfw_table_entry); > - error = dump_table(tbl); > + IPFW_WLOCK(&layer3_chain); > + error = dump_table(&layer3_chain, tbl); > if (error) { > + IPFW_WUNLOCK(&layer3_chain); > free(tbl, M_TEMP); > break; > } > + IPFW_WUNLOCK(&layer3_chain); > error = sooptcopyout(sopt, tbl, size); > free(tbl, M_TEMP); > } > @@ -4242,7 +4209,7 @@ > printf("limited to %d packets/entry by default\n", > verbose_limit); > > - init_tables(); > + init_tables(&layer3_chain); > ip_fw_ctl_ptr = ipfw_ctl; > ip_fw_chk_ptr = ipfw_chk; > callout_reset(&ipfw_timeout, hz, ipfw_tick, NULL); > @@ -4259,13 +4226,13 @@ > ip_fw_ctl_ptr = NULL; > callout_drain(&ipfw_timeout); > IPFW_WLOCK(&layer3_chain); > + flush_tables(&layer3_chain); > layer3_chain.reap = NULL; > free_chain(&layer3_chain, 1 /* kill default rule */); > reap = layer3_chain.reap, layer3_chain.reap = NULL; > IPFW_WUNLOCK(&layer3_chain); > if (reap != NULL) > reap_rules(reap); > - flush_tables(); > IPFW_DYN_LOCK_DESTROY(); > uma_zdestroy(ipfw_dyn_rule_zone); > IPFW_LOCK_DESTROY(&layer3_chain); > _______________________________________________ > 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 Nov 28 17:05:20 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D645016A4D7; Mon, 28 Nov 2005 17:05:20 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1531D43D60; Mon, 28 Nov 2005 17:05:14 +0000 (GMT) (envelope-from max@love2party.net) Received: from [84.163.211.253] (helo=donor.laier.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1EgmRF0teb-0003BU; Mon, 28 Nov 2005 18:05:13 +0100 From: Max Laier To: freebsd-net@freebsd.org Date: Mon, 28 Nov 2005 18:04:50 +0100 User-Agent: KMail/1.8.2 References: <20051127005943.GR25711@cell.sick.ru> <20051128062732.GA58778@ip.net.ua> <20051128161934.GY25711@cell.sick.ru> In-Reply-To: <20051128161934.GY25711@cell.sick.ru> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1303273.XKahMyehc9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200511281805.11952.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: rwatson@freebsd.org, Vsevolod Lobko Subject: Re: parallelizing ipfw table 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 Nov 2005 17:05:21 -0000 --nextPart1303273.XKahMyehc9 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 28 November 2005 17:19, Gleb Smirnoff wrote: > The number 65535 is some magic number, which means "take argument from > table". I will make ipfw display some word instead of 65535, for example > "tablearg". So, the rule will be looking like: > > pipe tablearg ip from any to table(1) This is not a good idea - IMHO. The problem is twofold: First, it adds a=20 special handling for a special case and is not a general sollution to the=20 problem (i.e. what if I want to use altq instead?). Second, it adds=20 complexity to the already painfully complex ipfw-grammar. In my opinion we= =20 need a cleanup here first. I remember that we had an extensive discussion about this around=20 =46reeBSD-SA-05:13.ipfw - the bottom line seems to be: either parallel or=20 cacheing. Stack storage should work as well. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1303273.XKahMyehc9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDizjHXyyEoT62BG0RAn4dAJ9vpPkhRUDj+mJA4C6G9KrK4scBPACeJ42+ ZROEbq3SDhk81rcLjLkVhdQ= =6D6I -----END PGP SIGNATURE----- --nextPart1303273.XKahMyehc9-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 28 18:47:15 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7832E16A41F; Mon, 28 Nov 2005 18:47:15 +0000 (GMT) (envelope-from drgnut@hotmail.com) Received: from hotmail.com (bay107-f18.bay107.hotmail.com [64.4.51.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4034143D70; Mon, 28 Nov 2005 18:46:42 +0000 (GMT) (envelope-from drgnut@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 28 Nov 2005 10:46:38 -0800 Message-ID: Received: from 64.4.51.220 by by107fd.bay107.hotmail.msn.com with HTTP; Mon, 28 Nov 2005 18:46:38 GMT X-Originating-IP: [130.107.15.110] X-Originating-Email: [drgnut@hotmail.com] X-Sender: drgnut@hotmail.com From: "John Palmer" To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Date: Mon, 28 Nov 2005 10:46:38 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Nov 2005 18:46:38.0405 (UTC) FILETIME=[10A7C750:01C5F44C] Cc: Subject: bad udp cksum 26ff! 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 Nov 2005 18:47:15 -0000 I am running FreeBSD 5.4 p8. I did a tcpdump -vv -i em0. The output produced a "bad udp cksum" with my DNS server. Does anyone know what it means? Or, how I can correct the problem? Thanks JP _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar – get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ From owner-freebsd-net@FreeBSD.ORG Mon Nov 28 19:17:56 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37A3A16A41F; Mon, 28 Nov 2005 19:17:56 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0808643D64; Mon, 28 Nov 2005 19:17:54 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jASJHqpq007273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Nov 2005 22:17:52 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jASJHpwX007272; Mon, 28 Nov 2005 22:17:51 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 28 Nov 2005 22:17:51 +0300 From: Gleb Smirnoff To: Max Laier Message-ID: <20051128191751.GZ25711@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Max Laier , freebsd-net@freebsd.org, Ruslan Ermilov , Vsevolod Lobko , rwatson@freebsd.org References: <20051127005943.GR25711@cell.sick.ru> <20051128062732.GA58778@ip.net.ua> <20051128161934.GY25711@cell.sick.ru> <200511281805.11952.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200511281805.11952.max@love2party.net> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, rwatson@FreeBSD.org, Ruslan Ermilov , Vsevolod Lobko Subject: Re: parallelizing ipfw table 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 Nov 2005 19:17:56 -0000 On Mon, Nov 28, 2005 at 06:04:50PM +0100, Max Laier wrote: M> On Monday 28 November 2005 17:19, Gleb Smirnoff wrote: M> > The number 65535 is some magic number, which means "take argument from M> > table". I will make ipfw display some word instead of 65535, for example M> > "tablearg". So, the rule will be looking like: M> > M> > pipe tablearg ip from any to table(1) M> M> This is not a good idea - IMHO. The problem is twofold: First, it adds a M> special handling for a special case and is not a general sollution to the M> problem (i.e. what if I want to use altq instead?). Second, it adds M> complexity to the already painfully complex ipfw-grammar. In my opinion we M> need a cleanup here first. This will also work for netgraph/ngtee and divert/tee (already in done in my patch). Since ALTQ uses not numbers but strings to identify its entities, adding ALTQ support here is harder, but possible. We just need alter the ipfw_table_ent() to hold strings. I will do it someday, if my current proposal won't die in a bikeshed. The ipfw-grammar diff is almost zero length - just print magic number as a string. In general I don't accept the policy: stop adding features until you do a cleanup. Following this policy we might end with a subsystem that has stalled and no one is developing it. But if someone is adding features, he usually also does some cleanup inlined. For example here I'm moving the dummynet pipe/queue to hashes, and this can be called a cleanup - at least one XXX less. I accept this kind of objection: "please stop adding features, since I am now working on the cleanup in this area", but I think this is not the case. M> I remember that we had an extensive discussion about this around M> FreeBSD-SA-05:13.ipfw - the bottom line seems to be: either parallel or M> cacheing. Stack storage should work as well. The cacheing is a good idea when one table is looked up several times for one packet. The above proposal eliminates need for such rulesets. And thus we can work towards parallelizm. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Nov 28 19:20:57 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E58C016A41F; Mon, 28 Nov 2005 19:20:57 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A19043D46; Mon, 28 Nov 2005 19:20:55 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jASJKqsq007351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Nov 2005 22:20:53 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jASJKquj007350; Mon, 28 Nov 2005 22:20:52 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 28 Nov 2005 22:20:52 +0300 From: Gleb Smirnoff To: Luigi Rizzo Message-ID: <20051128192052.GA25711@cell.sick.ru> References: <20051127005943.GR25711@cell.sick.ru> <20051127135529.GF25711@cell.sick.ru> <20051127194545.GA76200@ip.net.ua> <20051127195914.GI25711@cell.sick.ru> <20051128062732.GA58778@ip.net.ua> <20051128161934.GY25711@cell.sick.ru> <20051128083236.A65831@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051128083236.A65831@xorpc.icir.org> User-Agent: Mutt/1.5.6i Cc: Vsevolod Lobko , rwatson@FreeBSD.org, Ruslan Ermilov , net@FreeBSD.org Subject: Re: parallelizing ipfw table 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 Nov 2005 19:20:58 -0000 On Mon, Nov 28, 2005 at 08:32:36AM -0800, Luigi Rizzo wrote: L> Given that you (Gleb) are putting in some new features, I would L> suggest a variant to your tablearg thing, i.e. L> L> + a 'setvar index value' which can be put as an always-true L> option within a rule e.g. to store partial evaluation results. L> 'index' could be a small integer e.g. 0-9, value a 32-bit L> value which is either a constant or a packet field (src-ip...) L> or your tablearg. L> + allow a 'varN' arguments everywhere you can have a rule or pipe or L> queue number. L> L> This way you can easily implement your proposal, and a lot more. L> One should remember that variables are not meant to be staved L> with the packet's state (e.g. when a packet goes back and forth to L> dummynet) but other than that i think it is a useful feature and L> a simple one to implement. I agree. The introduction of local variable "tablearg" is the most unpleasant place of my patch. I will implement your proposal as soon as we have a second think that needs to be stored during one rule evaluation. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Nov 28 20:11:49 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8445016A425; Mon, 28 Nov 2005 20:11:49 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6240B43D68; Mon, 28 Nov 2005 20:11:29 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jASKBHee046839; Mon, 28 Nov 2005 22:11:17 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 25233-03; Mon, 28 Nov 2005 22:11:15 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jASK7N7h046732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Nov 2005 22:07:23 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jASK7OaP064740; Mon, 28 Nov 2005 22:07:25 +0200 (EET) (envelope-from ru) Date: Mon, 28 Nov 2005 22:07:24 +0200 From: Ruslan Ermilov To: John Palmer Message-ID: <20051128200724.GG63300@ip.net.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGu/vTNewDGZ7tmp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: bad udp cksum 26ff! 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 Nov 2005 20:11:49 -0000 --MGu/vTNewDGZ7tmp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 28, 2005 at 10:46:38AM -0800, John Palmer wrote: > I am running FreeBSD 5.4 p8. I did a tcpdump -vv -i em0. The output=20 > produced > a "bad udp cksum" with my DNS server. Does anyone know what it means? O= r,=20 > how I can > correct the problem? >=20 Turn off hardware checksums on em0, to make tcpdump(1) happy. Harmless otherwise. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --MGu/vTNewDGZ7tmp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDi2N8qRfpzJluFF4RAt9mAJ40LX7hfhLoA4RXhl+xKdgk6M6trgCbBEIj dcesoaYcqGHK9nnb8W/rdQc= =AH7T -----END PGP SIGNATURE----- --MGu/vTNewDGZ7tmp-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 28 23:51:53 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CF3716A41F for ; Mon, 28 Nov 2005 23:51:53 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2703543D5E for ; Mon, 28 Nov 2005 23:51:34 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jASNpUth010441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Nov 2005 02:51:31 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jASNpU6E010440; Tue, 29 Nov 2005 02:51:30 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 29 Nov 2005 02:51:30 +0300 From: Gleb Smirnoff To: Mihail Balikov Message-ID: <20051128235130.GE25711@cell.sick.ru> References: <20051127194545.GA76200@ip.net.ua> <002801c5f38d$2885c1c0$0cddf0d5@misho> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <002801c5f38d$2885c1c0$0cddf0d5@misho> User-Agent: Mutt/1.5.6i Cc: net@FreeBSD.org Subject: Re: parallelizing ipfw table 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 Nov 2005 23:51:53 -0000 On Sun, Nov 27, 2005 at 10:00:01PM +0200, Mihail Balikov wrote: M> I have made small patch to cache results per "table" and this caching gives M> me about 92% hit ratio with a lot of session. Can you show us the patch. How many parallel sessions are there? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Nov 29 02:49:33 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9221216A41F; Tue, 29 Nov 2005 02:49:33 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C93C43D5F; Tue, 29 Nov 2005 02:49:32 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 5DAF71A3C28; Mon, 28 Nov 2005 18:49:32 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 782F251330; Mon, 28 Nov 2005 21:49:31 -0500 (EST) Date: Mon, 28 Nov 2005 21:49:31 -0500 From: Kris Kennaway To: John Palmer Message-ID: <20051129024931.GA34483@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: bad udp cksum 26ff! 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 Nov 2005 02:49:33 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 28, 2005 at 10:46:38AM -0800, John Palmer wrote: > I am running FreeBSD 5.4 p8. I did a tcpdump -vv -i em0. The output=20 > produced > a "bad udp cksum" with my DNS server. Does anyone know what it means? O= r,=20 > how I can > correct the problem? If your NIC is doing checksum offload, tcpdump on the host won't see the right checksum, since it's only generated on the way out the door. Run tcpdump on another host on the network to verify whether it's correct on the wire. Kris --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDi8G6Wry0BWjoQKURAvb0AKCkySq7b4u3NgG4vYUZy35LRfo4RwCfVziD Hhqc7Z2Htd2mF4cKoRbeRzM= =mTHk -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 29 06:20:45 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F53F16A41F for ; Tue, 29 Nov 2005 06:20:45 +0000 (GMT) (envelope-from arcivanov@mail.ru) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48CB143D67 for ; Tue, 29 Nov 2005 06:20:44 +0000 (GMT) (envelope-from arcivanov@mail.ru) Received: from [24.128.227.175] (port=62414 helo=aii9100) by mx2.mail.ru with asmtp id 1Egyr3-000A5x-00 for freebsd-net@freebsd.org; Tue, 29 Nov 2005 09:20:42 +0300 Message-ID: <000d01c5f4ad$08ea4ea0$329da8c0@home.ivanovy.net> From: "Arcadiy Ivanov" To: Date: Tue, 29 Nov 2005 01:20:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Subject: FreeBSD <-> Windows XP IPSec Phase 1 Timeout 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 Nov 2005 06:20:45 -0000 Dear everybody, I have a following problem which you might help me solve. I'm running a FreeBSD 6.0 box as a gateway with Windows XP road warrior clients VPNing in. In order to setup secure access I want to use IPSec for traffic encryption with the plain-text PPTP for tunneling. Windows XP IPSec policy is configured to ESP everything coming in and out of TCP port 1723 and GRE and same stands for FreeBSD box. Now here is a problem. Upon initiating PPTP dial-up connection from XP the IPSec negotiations start normally, both client and server agree on encryption & hashing standards successfully. But as soon as they do agree, all communications timeout. Tcpdump on FreeBSD box and Etherpeek on Windows should the IPSec packets being delivered to both machines, but both client and server behave as if packets were not delivered at all and obviously timeout. I do have PF firewall on the gateway but the result is the same for firewall being off or on or even not loaded into kernel. I have used racoon, isakmp and ipsec-tools racoon and the results are EXACTLY the same up to the corresponding lines in the logs - as soon as encryption policies are successfully negotiated and both clients switch to secure communication mode they lose sight of each other and both timeout. I of course understand that the logs are necessary and I'm ready to provide them if anybody is interested to help me solve the problem, but I'm hoping that somebody had this problem and knows the solutions off the top of his/her head. Thanks a lot, Arcadiy From owner-freebsd-net@FreeBSD.ORG Tue Nov 29 10:46:13 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D89016A41F for ; Tue, 29 Nov 2005 10:46:13 +0000 (GMT) (envelope-from asko_nospam@ultrasoft.ee) Received: from mail.ultrasoft.ee (ns.ultrasoft.ee [213.35.215.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19ED543D72 for ; Tue, 29 Nov 2005 10:46:10 +0000 (GMT) (envelope-from asko_nospam@ultrasoft.ee) Received: from localhost (localhost [127.0.0.1]) by mail.ultrasoft.ee (Postfix) with ESMTP id 3CDE05EE0 for ; Tue, 29 Nov 2005 12:46:03 +0200 (EET) Received: from mail.ultrasoft.ee ([127.0.0.1]) by localhost (aidamees.ultrasoft.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50148-14 for ; Tue, 29 Nov 2005 12:46:02 +0200 (EET) Received: from [192.168.8.25] (unknown [192.168.8.25]) by mail.ultrasoft.ee (Postfix) with ESMTP id 25E475ED7 for ; Tue, 29 Nov 2005 12:46:02 +0200 (EET) Message-ID: <438C3172.6010806@ultrasoft.ee> Date: Tue, 29 Nov 2005 12:46:10 +0200 From: asko Organization: Ultrasoft =?ISO-8859-1?Q?O=DC?= User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at ultrasoft.ee Subject: natd redirected ports from LAN 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 Nov 2005 10:46:13 -0000 Hi, As you know, natd redirected ports in router from WAN to LAN work only from outside. http://lists.freebsd.org/pipermail/freebsd-questions/2003-August/015552.html For example, www.example.com has public IP - a.b.c.d webserver is in LAN, 192.168.1.10 router is 192.168.1.1 #rc.conf natd_enable="YES" natd_flags="-f /etc/natd.conf" natd_interface="fxp0" gateway_enable="YES" #natd.conf use_sockets yes same_ports yes unregistered_only yes redirect_port tcp 192.168.1.10:80 80 The query http://a.b.c.d:80 works from outside, but does not work from inside (LAN). One solution is redirecting local port to 192.168.1.10:80 # inetd.conf www stream tcp nowait nobody /usr/local/bin/nc nc -w 3 192.168.1.10 80 and adding ipfw rule: 00040 fwd 192.168.1.1,80 tcp from 192.168.1.0/24 to a.b.c.d dst-port 80 It works, but it is not very elegant, because it involves user level programs inetd and netcat. I'm searching for a better, faster solution.. Does it exist? -- asko From owner-freebsd-net@FreeBSD.ORG Tue Nov 29 13:07:31 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD8B816A41F for ; Tue, 29 Nov 2005 13:07:31 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36DD743D5E for ; Tue, 29 Nov 2005 13:07:30 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 59905DE; Tue, 29 Nov 2005 08:07:52 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 0FE2058D; Tue, 29 Nov 2005 08:07:50 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.54 (FreeBSD)) id 1Eh5Ch-000AYT-Om; Tue, 29 Nov 2005 13:07:27 +0000 Date: Tue, 29 Nov 2005 13:07:27 +0000 From: Brian Candler To: asko Message-ID: <20051129130727.GA40492@uk.tiscali.com> References: <438C3172.6010806@ultrasoft.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438C3172.6010806@ultrasoft.ee> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: natd redirected ports from LAN 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 Nov 2005 13:07:31 -0000 On Tue, Nov 29, 2005 at 12:46:10PM +0200, asko wrote: > I'm searching for a better, faster solution.. > Does it exist? Do your constraints allow you switch to 'pf' instead of 'ipfw'? I think you may be able to do it that way. I had a similar situation where I wanted traffic originating from the local host to be processed specially. The case in point was redirection rather than NAT, but the same principles probably apply. Using pf I forced the traffic back through the loopback interface so it was treated as 'incoming' traffic. e.g. see thread around http://lists.freebsd.org/pipermail/freebsd-pf/2005-September/001495.html Maybe in your case you just need two rdr rules: one bound to the internal interface, and one to the external one. I stopped using ipfw several years ago because of a number of issues with NAT, especially some horrible scenarios with multiple external interfaces, IPSEC tunnels, and needing to run multiple instances of natd :-{ Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Tue Nov 29 15:36:16 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2634616A420 for ; Tue, 29 Nov 2005 15:36:16 +0000 (GMT) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D240243D5C for ; Tue, 29 Nov 2005 15:36:14 +0000 (GMT) (envelope-from oppermann@networx.ch) Received: (qmail 51404 invoked from network); 29 Nov 2005 15:34:11 -0000 Received: from c00l3r.networx.ch (HELO networx.ch) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Nov 2005 15:34:11 -0000 Message-ID: <438C7561.41E09BBD@networx.ch> Date: Tue, 29 Nov 2005 16:36:01 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20051127005943.GR25711@cell.sick.ru> <20051128062732.GA58778@ip.net.ua> <20051128161934.GY25711@cell.sick.ru> <200511281805.11952.max@love2party.net> <20051128191751.GZ25711@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Max Laier , Ruslan Ermilov , rwatson@FreeBSD.org, Vsevolod Lobko , freebsd-net@FreeBSD.org Subject: Re: parallelizing ipfw table 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 Nov 2005 15:36:16 -0000 Gleb Smirnoff wrote: > On Mon, Nov 28, 2005 at 06:04:50PM +0100, Max Laier wrote: > M> I remember that we had an extensive discussion about this around > M> FreeBSD-SA-05:13.ipfw - the bottom line seems to be: either parallel or > M> cacheing. Stack storage should work as well. > > The cacheing is a good idea when one table is looked up several times > for one packet. The above proposal eliminates need for such rulesets. > And thus we can work towards parallelizm. The ipfw tables are protected by the ipfw lock. So this parallel lookup Gelb has in his patch works fine and doesn't have any races. No caching between packets can be done without extra locks. Only caching between rules can be done by saving the result on the stack. The result must not be accessed anymore once the ipfw lock has been given up. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Nov 29 16:35:34 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F35916A41F for ; Tue, 29 Nov 2005 16:35:34 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from rohrpostix.tallence.de (rohrpostix.tallence.de [213.238.47.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FFA243D6B for ; Tue, 29 Nov 2005 16:35:31 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [172.20.20.180] (unknown [193.187.215.11]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by rohrpostix.tallence.de (Postfix) with ESMTP id 503E41AD913; Tue, 29 Nov 2005 17:35:29 +0100 (CET) In-Reply-To: <20051127101824.GA3606@lagoon.freebsd.lublin.pl> References: <43894FC9.6040205@elischer.org> <20051127101824.GA3606@lagoon.freebsd.lublin.pl> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <4B01DC26-9610-41DC-9386-C172DD55640C@lassitu.de> Content-Transfer-Encoding: quoted-printable From: Stefan Bethke Date: Tue, 29 Nov 2005 17:35:36 +0100 To: =?UTF-8?Q?Pawe=C5=82_Ma=C5=82achowski?= X-Mailer: Apple Mail (2.746.2) Cc: net@freebsd.org Subject: Re: proposal: TCP rendevous 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 Nov 2005 16:35:34 -0000 Am 27.11.2005 um 11:18 schrieb Pawe=C5=82 Ma=C5=82achowski: > On Sat, Nov 26, 2005 at 10:18:49PM -0800, Julian Elischer wrote: > >> I'm still thinking about connecting systems separated by NAT however. >> that's a trickier problem. you still need to use outgoing =20 >> connections but >> no-one who is not in the path can not tell what the NAT'd packets =20 >> looke >> like. > > BTW, I've heared Windows-behind-NAT-people ;) are using http://=20 > hamachi.cc > trick, however, I've never tried. 5/8 is reserved--for now. The software is binary-only. For a better alternative, check out OpenVPN. Stefan --=20 Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-net@FreeBSD.ORG Tue Nov 29 21:27:23 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3276F16A420 for ; Tue, 29 Nov 2005 21:27:23 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from dbmail-mx3.orcon.co.nz (loadbalancer1.orcon.net.nz [219.88.242.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 752C843D58 for ; Tue, 29 Nov 2005 21:27:22 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by dbmail-mx3.orcon.co.nz (8.13.2/8.13.2/Debian-1) with ESMTP id jATLSNP8027063; Wed, 30 Nov 2005 10:28:23 +1300 Received: by heff.fud.org.nz (Postfix, from userid 1001) id A221C28430; Wed, 30 Nov 2005 10:27:18 +1300 (NZDT) Date: Wed, 30 Nov 2005 10:27:18 +1300 From: Andrew Thompson To: ?zkan KIRIK Message-ID: <20051129212718.GB44024@heff.fud.org.nz> References: <4389D8D7.7000809@mersin.edu.tr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4389D8D7.7000809@mersin.edu.tr> User-Agent: Mutt/1.5.11 X-Virus-Scanned: ClamAV 0.87.1/1198/Tue Nov 29 23:05:20 2005 on dbmail-mx3.orcon.co.nz X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: if_bridge not working with second interface 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 Nov 2005 21:27:23 -0000 On Sun, Nov 27, 2005 at 06:03:35PM +0200, ?zkan KIRIK wrote: > Hi, > > i am trying to bridge two interfaces via if_bridge. > i built a new kernel that includes "device if_bridge" line. > > # ifconfig bridge0 addm fxp0 > > # ping 10.0.0.2 > PING 10.0.0.2 (10.0.0.2): 56 data bytes > 64 bytes from 10.0.50.1: icmp_seq=0 ttl=64 time=1.847 ms > > it works. Then, I removed cable from fxp0 and plugged to fxp1. > # ifconfig bridge0 addm fxp1 > > # ping 10.0.0.2 > PING 10.0.0.2 (10.0.0.2): 56 data bytes > ping: sendto: Host is down Are you sure that fxp1 is up? make sure you have the following in rc.conf ifconfig_fxp0="up" ifconfig_fxp1="up" Your symptoms appear like you are missing the second line. Failing that, check your arp cache to see if the addresses are correct. Andrew From owner-freebsd-net@FreeBSD.ORG Wed Nov 30 01:43:20 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E52916A41F for ; Wed, 30 Nov 2005 01:43:20 +0000 (GMT) (envelope-from EDouglass@gaylordhotels.com) Received: from gaylordentertainment.com (mail.gaylordentertainment.com [12.153.11.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5028243D8C for ; Wed, 30 Nov 2005 01:43:18 +0000 (GMT) (envelope-from EDouglass@gaylordhotels.com) Received: from 10.42.4.102 by gaylordentertainment.com with ESMTP (TN SMTP Relay); Tue, 29 Nov 2005 19:42:37 -0600 X-Server-Uuid: E485C1F1-10DB-4031-9668-820096A468D3 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Nov 2005 19:42:52 -0600 Message-ID: <566E54419328A642A3A6E91376E885B1048EA08A@txex.tx.get> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wireless Thread-Index: AcX1T2I72uKEeEvoSRaO5TCoO2cEvw== From: "Douglass, Erik" To: freebsd-net@freebsd.org X-MMS-Spam-Filter-ID: A2005112910_2.0.4,4.0-7 X-TMWD-Spam-Summary: SEV=0.9; DFV=A2005112910; IFV=2.0.4,4.0-7; RPD=NA; RPDID=NA; ENG=IBF; TS=20051130014238; CAT=NONE; CON=NONE; X-WSS-ID: 6F93DC0727S3917320-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Wireless 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 Nov 2005 01:43:20 -0000 Broadcom 1370 on a Dell D610.. Anyone have any luck with this?? Not seeing any wi* entries in ifconfig. Using FreeBSD 6.0 =20 Thanks for any help!! =20 Erik Douglass Network Coordinator Gaylord Texan Resort and Convention Center Grapevine, Texas 76051 817.778.3633 edouglass@gaylordhotels.com =20 =20 =20 From owner-freebsd-net@FreeBSD.ORG Wed Nov 30 01:56:54 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64B6C16A41F for ; Wed, 30 Nov 2005 01:56:54 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id E52D443D64 for ; Wed, 30 Nov 2005 01:56:46 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id jAU1ujtZ023133; Tue, 29 Nov 2005 17:56:45 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id jAU1uj3Q023132; Tue, 29 Nov 2005 17:56:45 -0800 Date: Tue, 29 Nov 2005 17:56:45 -0800 From: Brooks Davis To: "Douglass, Erik" Message-ID: <20051130015645.GA22998@odin.ac.hmc.edu> References: <566E54419328A642A3A6E91376E885B1048EA08A@txex.tx.get> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <566E54419328A642A3A6E91376E885B1048EA08A@txex.tx.get> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-net@freebsd.org Subject: Re: Wireless 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 Nov 2005 01:56:54 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 29, 2005 at 07:42:52PM -0600, Douglass, Erik wrote: > Broadcom 1370 on a Dell D610.. Anyone have any luck with this?? Not > seeing any wi* entries in ifconfig. Using FreeBSD 6.0 We have no native support for broadcom wireless devices (the wouldn't be wi(4) anyway since we aren't Linux :). You may be able to use this card with the ndisulator. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDjQbcXY6L6fI4GtQRAhkgAJ9OBYED45cxt0/Q/5s496Z7ZUYMvgCfe7KR GMPOjrf4Vmb+JsSD2z640I4= =UEKd -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 30 02:50:30 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA7E616A420 for ; Wed, 30 Nov 2005 02:50:30 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Received: from mail.npubs.com (mail.writemehere.com [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55C9F43D8C for ; Wed, 30 Nov 2005 02:50:11 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Message-ID: <438CE0A8.4010205@memberwebs.com> From: Nate Nielsen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Date: Wed, 30 Nov 2005 03:04:43 +0000 (GMT) Subject: Memory leak in net80211 on FBSD 6.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nielsen@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2005 02:50:30 -0000 I'm experiencing a memory leak in the net80211 code. I have two atheros 5213-A cards on two embedded systems running FreeBSD 6.0. They are setup as IBSS (adhoc) stations. After roughly 15 seconds of ~14Mbps TCP traffic (single stream) I promptly run out of memory: > login: panic: kmem_malloc(4096): kmem_map too small: 25165824 total allocated > Uptime: 3m0s > Cannot dump. No dump device defined. > Automatic reboot in 5 seconds - press a key on the console to abort > Rebooting... The boxes have 64MB of memory each. vmstat -m reports the following just before the panic: > Type InUse MemUse HighUse Requests Size(s) > > 80211node 20554 20554K - 20559 512,1024 The cards are configured as follows (in other words, nothing special): > ath0: flags=8843 mtu 1500 > inet 10.2.2.5 netmask 0xffffff00 broadcast 10.2.2.255 > ether 00:15:6d:10:19:21 > media: IEEE 802.11 Wireless Ethernet OFDM/24Mbps mode 11g > status: associated > ssid jumper channel 3 bssid 02:15:6d:10:19:21 > authmode OPEN privacy OFF txpowmax 56 protmode CTS bintval 100 I've got this sorta thing in my kernel: > device wlan # 802.11 support > device wlan_wep > device wlan_ccmp > device wlan_tkip > device wlan_xauth > device wlan_acl > device ath # Atheros > device ath_hal > device ath_rate_onoe I'll continue to hack away at this problem, but I don't have much experience with the FreeBSD kernel. If anyone has any ideas, I'd love to hear from you. Cheers, Nate From owner-freebsd-net@FreeBSD.ORG Wed Nov 30 02:50:31 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E032A16A420; Wed, 30 Nov 2005 02:50:31 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Received: from mail.npubs.com (mail.zoneseven.net [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE38043D72; Wed, 30 Nov 2005 02:50:13 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Message-ID: <438D0896.1070808@memberwebs.com> From: Nate Nielsen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <438CE0A8.4010205@memberwebs.com> In-Reply-To: <438CE0A8.4010205@memberwebs.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Date: Wed, 30 Nov 2005 03:04:44 +0000 (GMT) Cc: Subject: Re: Memory leak in net80211 on FBSD 6.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nielsen@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2005 02:50:32 -0000 Nate Nielsen wrote: > I'm experiencing a memory leak in the net80211 code. I have two atheros > 5213-A cards on two embedded systems running FreeBSD 6.0. They are setup > as IBSS (adhoc) stations. After roughly 15 seconds of ~14Mbps TCP > traffic (single stream) I promptly run out of memory: > >>login: panic: kmem_malloc(4096): kmem_map too small: 25165824 total allocated >>Uptime: 3m0s >>Cannot dump. No dump device defined. >>Automatic reboot in 5 seconds - press a key on the console to abort >>Rebooting... > > The boxes have 64MB of memory each. > vmstat -m reports the following just before the panic: > >> Type InUse MemUse HighUse Requests Size(s) >> >> 80211node 20554 20554K - 20559 512,1024 I've put debugging code in node_alloc() and node_free() (in net80211/ieee80211_node.c) and can confirm that thousands of ieee80211_node structures are being allocated, at a cost of 1K a piece. I'll continue to look into this (stumbling about), but if anyone has any advice or ideas of where to look, I'd be eternally grateful. Cheers, Nate From owner-freebsd-net@FreeBSD.ORG Wed Nov 30 03:20:41 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DD9D16A41F for ; Wed, 30 Nov 2005 03:20:41 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7AA143D92 for ; Wed, 30 Nov 2005 03:20:30 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.200] ([10.0.0.200]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id jAU3KRpU069370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Nov 2005 19:20:28 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <438D1A99.6000803@errno.com> Date: Tue, 29 Nov 2005 19:20:57 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051126) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nielsen@memberwebs.com References: <438CE0A8.4010205@memberwebs.com> <438D0896.1070808@memberwebs.com> In-Reply-To: <438D0896.1070808@memberwebs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Memory leak in net80211 on FBSD 6.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2005 03:20:41 -0000 Nate Nielsen wrote: > Nate Nielsen wrote: > >>I'm experiencing a memory leak in the net80211 code. I have two atheros >>5213-A cards on two embedded systems running FreeBSD 6.0. They are setup >>as IBSS (adhoc) stations. After roughly 15 seconds of ~14Mbps TCP >>traffic (single stream) I promptly run out of memory: >> >> >>>login: panic: kmem_malloc(4096): kmem_map too small: 25165824 total allocated >>>Uptime: 3m0s >>>Cannot dump. No dump device defined. >>>Automatic reboot in 5 seconds - press a key on the console to abort >>>Rebooting... >> >>The boxes have 64MB of memory each. >>vmstat -m reports the following just before the panic: >> >> >>> Type InUse MemUse HighUse Requests Size(s) >>> >>> 80211node 20554 20554K - 20559 512,1024 > > > I've put debugging code in node_alloc() and node_free() (in > net80211/ieee80211_node.c) and can confirm that thousands of > ieee80211_node structures are being allocated, at a cost of 1K a piece. > > I'll continue to look into this (stumbling about), but if anyone has any > advice or ideas of where to look, I'd be eternally grateful. Please don't spam lots of groups. I'm aware of the leak (David Young found it in netbsd) and have a partial fix. I'll send it to you directly. Sam From owner-freebsd-net@FreeBSD.ORG Wed Nov 30 08:44:15 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08D6316A41F for ; Wed, 30 Nov 2005 08:44:15 +0000 (GMT) (envelope-from babolo@cicuta.babolo.ru) Received: from ints.mail.pike.ru (ints.mail.pike.ru [85.30.199.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FA7243D64 for ; Wed, 30 Nov 2005 08:44:13 +0000 (GMT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 52424 invoked from network); 30 Nov 2005 08:44:11 -0000 Received: from cicuta.babolo.ru (85.30.224.245) by ints.mail.pike.ru with SMTP; 30 Nov 2005 08:44:11 -0000 Received: (nullmailer pid 2095 invoked by uid 136); Wed, 30 Nov 2005 08:47:58 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <000d01c5f4ad$08ea4ea0$329da8c0@home.ivanovy.net> To: Arcadiy Ivanov Date: Wed, 30 Nov 2005 11:47:58 +0300 (MSK) From: .@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1133340478.570472.2094.nullmailer@cicuta.babolo.ru> Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD <-> Windows XP IPSec Phase 1 Timeout 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 Nov 2005 08:44:15 -0000 I am not expert in this, but I had similar problems in different environment when clocks was not synchronized exactly on both tunnel ends. > Dear everybody, > > I have a following problem which you might help me solve. I'm running a > FreeBSD 6.0 box as a gateway with Windows XP road warrior clients VPNing in. > In order to setup secure access I want to use IPSec for traffic encryption > with the plain-text PPTP for tunneling. Windows XP IPSec policy is > configured to ESP everything coming in and out of TCP port 1723 and GRE and > same stands for FreeBSD box. Now here is a problem. Upon initiating PPTP > dial-up connection from XP the IPSec negotiations start normally, both > client and server agree on encryption & hashing standards successfully. But > as soon as they do agree, all communications timeout. Tcpdump on FreeBSD box > and Etherpeek on Windows should the IPSec packets being delivered to both > machines, but both client and server behave as if packets were not delivered > at all and obviously timeout. I do have PF firewall on the gateway but the > result is the same for firewall being off or on or even not loaded into > kernel. I have used racoon, isakmp and ipsec-tools racoon and the results > are EXACTLY the same up to the corresponding lines in the logs - as soon as > encryption policies are successfully negotiated and both clients switch to > secure communication mode they lose sight of each other and both timeout. I > of course understand that the logs are necessary and I'm ready to provide > them if anybody is interested to help me solve the problem, but I'm hoping > that somebody had this problem and knows the solutions off the top of > his/her head. > > Thanks a lot, > Arcadiy > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Nov 30 08:52:51 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80FDD16A41F for ; Wed, 30 Nov 2005 08:52:51 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC6C243D66 for ; Wed, 30 Nov 2005 08:52:50 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by xproxy.gmail.com with SMTP id r21so5855190wxc for ; Wed, 30 Nov 2005 00:52:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=PKEu1/9X53DpRQqGuFDAl6c/qJUFXOCZNnlaMVM81NCLwzFaMts1n3M7iRyePi7aZDOVCxIqXQVONISHMt+NESSp25ibEQKNoS1p3iloKjobCtE5SiFXj28J8JMOhQocpiDUaHLiSo3fgdbA+J0F95op/5UxDiGjSHRJSdPXm5Y= Received: by 10.64.184.4 with SMTP id h4mr400058qbf; Wed, 30 Nov 2005 00:52:50 -0800 (PST) Received: by 10.64.213.7 with HTTP; Wed, 30 Nov 2005 00:52:49 -0800 (PST) Message-ID: <2a41acea0511300052o2dfe841bj8834a07720bebb6a@mail.gmail.com> Date: Wed, 30 Nov 2005 00:52:49 -0800 From: Jack Vogel To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Hey everyone 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 Nov 2005 08:52:51 -0000 I wanted to introduce myself to the list. I am now the primary contact at Intel for our drivers. There was some earlier email I saw in the archive about 82571/2 support, and I want to confirm that that code is coming. I hope to be adding some new feature support as well. I have been eyeing TSO which is going to need stack changes, if anyone out there has been working or just thinking about that get in touch with me about it. In any case, I am kept quite busy but I will make every effort to be here and be as responsive as i can. Regards to all, Jack From owner-freebsd-net@FreeBSD.ORG Wed Nov 30 09:20:37 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93D2716A41F for ; Wed, 30 Nov 2005 09:20:37 +0000 (GMT) (envelope-from babolo@cicuta.babolo.ru) Received: from ints.mail.pike.ru (ints.mail.pike.ru [85.30.199.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE6F443D8F for ; Wed, 30 Nov 2005 09:20:25 +0000 (GMT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 28422 invoked from network); 30 Nov 2005 09:20:24 -0000 Received: from cicuta.babolo.ru (85.30.224.245) by ints.mail.pike.ru with SMTP; 30 Nov 2005 09:20:24 -0000 Received: (nullmailer pid 2139 invoked by uid 136); Wed, 30 Nov 2005 09:24:15 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20051128105250.GP25711@cell.sick.ru> To: Gleb Smirnoff Date: Wed, 30 Nov 2005 12:24:15 +0300 (MSK) From: .@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1133342655.685708.2138.nullmailer@cicuta.babolo.ru> Cc: Vsevolod Lobko , Ruslan Ermilov , net@FreeBSD.org, rwatson@FreeBSD.org Subject: Re: parallelizing ipfw table 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 Nov 2005 09:20:37 -0000 > On Mon, Nov 28, 2005 at 01:42:41PM +0300, .@babolo.ru wrote: > .> > On Mon, Nov 28, 2005 at 08:27:32AM +0200, Ruslan Ermilov wrote: > .> > R> > Can you try my patch? Since it reduces the total number of mutex > .> > R> > operations it should be a win on UP, too. > .> > R> We're currently based on 4.x. You can try it yourself: create > .> > R> a table with 10000 entries and with value 13. Then write a > .> > R> ruleset with 13 rules that look up this table so that the last > .> > R> rule looks it up with value 13, and do a benchmark. Let me > .> > R> know what are results with and without caching. > .> > Such kind of firewall looks like unoptimized. Why should we optimize the > .> > code for non-optimized setups. Can't we avoid looking into one table > .> > 13 times each packet? > .> > .> add 47400 pipe 47400 ip from table(0, 0) to any > .> add 47401 pipe 47401 ip from table(0, 1) to any > .> add 47402 pipe 47402 ip from table(0, 2) to any > .> add 47403 pipe 47403 ip from table(0, 3) to any > .> add 47404 pipe 47404 ip from table(0, 4) to any > .> add 47405 pipe 47405 ip from table(0, 5) to any > .> add 47406 pipe 47406 ip from table(0, 6) to any > .> add 47407 pipe 47407 ip from table(0, 7) to any > .> add 47408 pipe 47408 ip from table(0, 8) to any > .> add 47409 pipe 47409 ip from table(0, 9) to any > .> > .> for different traffic consumers listed in table(0) > > I understand now. Ruslan has sent me a sample setup, too. Anyway, the > current optimization is broken on SMP, because it stores the cache > in the table itself. Parallel processing of the different packets on > SMP breaks the optimization, since different instances of ipfw_chk() > trash the cached addr one after another. > > I have two ideas about this. First, store the cache on stack. Second, > utilize the table entry value in the rule. In this case your block > can be converted to: > > add N pipe \$val ip from table(0) to any > > \$val means the value of the entry in the table. Oversimplyfied. Different resousces with own set of pipes: add 1000 skipto 3000 ip from any to table(1, 1) add 1001 skipto 4000 ip from any to table(1, 2) ... add 2000 pipe 2000 ip from table(0, 0) to any add 2001 pipe 2001 ip from table(0, 1) to any add 2500 allow ip from any to any add 3000 pipe 3000 ip from table(0, 0) to any add 3001 pipe 3001 ip from table(0, 1) to any ... Yes, I know that I can multiply table with another target numbers with price of another table lookup. From owner-freebsd-net@FreeBSD.ORG Wed Nov 30 09:24:15 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93B6716A41F for ; Wed, 30 Nov 2005 09:24:15 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5820443D8C for ; Wed, 30 Nov 2005 09:24:09 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 58605 invoked from network); 30 Nov 2005 09:22:08 -0000 Received: from c00l3r.networx.ch (HELO freebsd.org) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Nov 2005 09:22:08 -0000 Message-ID: <438D6FB9.FFBD8593@freebsd.org> Date: Wed, 30 Nov 2005 10:24:09 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0511300052o2dfe841bj8834a07720bebb6a@mail.gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, scottl@freebsd.org, yongari@freebsd.org Subject: Re: Hey everyone 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 Nov 2005 09:24:15 -0000 Jack Vogel wrote: Dear Jack, > I wanted to introduce myself to the list. I am now the primary contact > at Intel for our drivers. There was some earlier email I saw in the archive > about 82571/2 support, and I want to confirm that that code is coming. for a too long time Intel has abandoned their direct involvement in the FreeBSD 'em' driver. And you have two people with direct commit rights to the FreeBSD CVS tree. In the meantime we have taken the driver maintainance into our own hands, have rewritten parts of it and got a lot more conforming code. Not to mention that we were able to increase the performance significantly too. We have fixed many show-stopper bugs which were wedging the hardware as well. Before you continue development on your own FreeBSD driver please have a very close look the version we have in our CVS tree. You may benefit from taking that as base and continue development from it instead of your own code. The CVS commit messages explain in much detail which problems we found and how we solved them. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/em/if_em.c Intel would help us a lot if you would release the Erratas to your 'em' chip famility. > I hope to be adding some new feature support as well. I have been > eyeing TSO which is going to need stack changes, if anyone out there > has been working or just thinking about that get in touch with me about it. We have already looked into TSO a bit and so far the result is inconclusive. We may not want to make any large changes to the TCP code to faciliate any particular TSO architecture. To make the case in favor of supporting TSO it has to be shown that is provides real-world benefits and extensive benchmark results have to be provided. Any changes to our TCP code to support TSO must be well designed and be generic supporting other vendors TSO as well. However I must say that a really compelling has to be made for TSO to justify the changes and the associated long term code maintainance hurdles with it. Please have a look at this paper discussing TSO among other things: http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20TCP%20Stack.pdf > In any case, I am kept quite busy but I will make every effort to be here > and be as responsive as i can. Please get in contact with Gelb Smirnoff , Pyun YongHyeon and Scott Long . Those folks have assumed maintainership of the 'em' driver and contributed many important fixes and performance enhancements. For the time being I guess it is the best if we collect the direct CVS access of pdeuskar and tackerman and you submit patches to 'em' through one of the above contacts at FreeBSD. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Nov 30 12:28:09 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E1C916A41F for ; Wed, 30 Nov 2005 12:28:09 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 8254743D55 for ; Wed, 30 Nov 2005 12:28:08 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 44545 invoked by uid 399); 27 Nov 2005 20:28:06 -0000 Received: from localhost (HELO ?192.168.1.101?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 27 Nov 2005 20:28:06 -0000 Message-ID: <438A16D4.8050108@FreeBSD.org> Date: Sun, 27 Nov 2005 12:28:04 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <43894FC9.6040205@elischer.org> In-Reply-To: <43894FC9.6040205@elischer.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: proposal: TCP rendevous 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 Nov 2005 12:28:09 -0000 Julian Elischer wrote: > In this world of P2P apps it would be neat to have a way that two P2P apps > could attach to each other even though each is through a firewall. Most > firewalls only allow > "outgoing" connections. There is a great deal of work in this area in the IETF. It's mostly focused on NAT issues, but the same techniques are applicable to hosts with globally routable addresses behind a restrictive firewall. I'd recommend investigating that work first before reinventing any wheels here. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Wed Nov 30 13:56:43 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC61816A43D for ; Wed, 30 Nov 2005 13:56:42 +0000 (GMT) (envelope-from spadge@fromley.net) Received: from mta08-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78D4143D8A for ; Wed, 30 Nov 2005 13:56:26 +0000 (GMT) (envelope-from spadge@fromley.net) Received: from aamta11-winn.ispmail.ntl.com ([81.103.221.35]) by mta08-winn.ispmail.ntl.com with ESMTP id <20051130135623.RQKI17804.mta08-winn.ispmail.ntl.com@aamta11-winn.ispmail.ntl.com> for ; Wed, 30 Nov 2005 13:56:23 +0000 Received: from tobermory.home ([82.18.8.27]) by aamta11-winn.ispmail.ntl.com with ESMTP id <20051130135623.MLTP16192.aamta11-winn.ispmail.ntl.com@tobermory.home> for ; Wed, 30 Nov 2005 13:56:23 +0000 Received: from [192.168.124.185] (unknown [192.168.124.185]) by tobermory.home (Postfix) with ESMTP id 980E4A6DDB for ; Wed, 30 Nov 2005 13:56:20 +0000 (GMT) Message-ID: <438DAF8D.9030705@fromley.net> Date: Wed, 30 Nov 2005 13:56:29 +0000 From: Spadge User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: frequent internet death in FreeBSD 6 - no idea why. 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 Nov 2005 13:56:43 -0000 Hi all. I must admit to being completely stumped by this prooblem I am having with my FreeBSD 6 internet gateway. I don't even know where to start trying to troubleshoot it. The symptoms are: every now and then, usually (but not always) when I try to open a web page (using a client machine further down the NATed network) the browser sits there not opening anything and eventually errors out. While this happens, the gateway computer drops its connection to the internet completely, the cable modem's "cable" light goes out, starts flashing and goes back on again as if I had just unplugged the cable. Everything on the NAT side of the gateway disconnects from the internet, usually (multiple chat protocols, web browsing). Rarely, things on the gateway disconnect from the internet (ircd). I am trying to remember when this started happening, or when I noticed it at least (I am guessing they were around the same time) and it seems to me that it was around the time I had a pretty serious OS hang-up over some HDD 'setfeatures set transfer mode semaphore timeout' problem that caused a complete system lockup which required a hard reboot (physical button pushing). The HDD that was causing the problem was not the system disk, so all the data I am aware of having lost was just that: non OS-essential data. As I say, I am really stuck here. I have tried swapping out NICs, changing WAN for LAN, putting the cards in different PCI slots, rebuilding world/kernel with dummynet, rebuilding world/kernel without dummynet. I am at a loss as to what to try to do next. How do I go about finding out what's causing the problem so that I can try fixing it? spadge@tobermory$ uname -a FreeBSD tobermory.home 6.0-RELEASE FreeBSD 6.0-RELEASE #2: Wed Nov 30 02:19:31 GMT 2005 root@tobermory.home:/usr/obj/usr/src/sys/TOBERMORY i386 spadge@tobermory$ diff /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/TOBERMORY 66c66,80 < device apic # I/O APIC --- > # To make an SMP kernel, the next two are needed > options SMP # Symmetric MultiProcessor Kernel > device apic # I/O APIC > > # For ipfw/natd > > options IPFIREWALL > options IPDIVERT > options IPFIREWALL_DEFAULT_TO_ACCEPT > options IPFIREWALL_VERBOSE > > # For DUMMYNET packet shaping > # options DUMMYNET > # options HZ=1000 > spadge@tobermory$ ifconfig xl0 xl0: flags=8843 mtu 1500 options=8 inet6 fe80::260:8ff:fe79:bcdb%xl0 prefixlen 64 scopeid 0x1 inet 192.168.124.199 netmask 0xffffff00 broadcast 192.168.124.255 ether 00:60:08:79:bc:db media: Ethernet autoselect (100baseTX ) status: active spadge@tobermory$ ifconfig xl1 xl1: flags=8843 mtu 1500 options=9 inet6 fe80::250:4ff:fee9:114c%xl1 prefixlen 64 scopeid 0x2 inet 82.18.8.27 netmask 0xffffff00 broadcast 255.255.255.255 ether 00:50:04:e9:11:4c media: Ethernet autoselect (10baseT/UTP) status: active Running ipfw/nated/named/bind. DHCP client to the WAN side, fixed IPs on the LAN side. Not sure what further information is required. If there's anyone who could help shed some light on this problem, how to troubleshoot it etc, please please please do write back, I am at my wit's end here. Thanks. -- Spadge "Intoccabile" www.fromley.com From owner-freebsd-net@FreeBSD.ORG Wed Nov 30 15:17:01 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4DB716A41F for ; Wed, 30 Nov 2005 15:17:01 +0000 (GMT) (envelope-from arcivanov@mail.ru) Received: from mx3.mail.ru (mx3.mail.ru [194.67.23.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CA3743D55 for ; Wed, 30 Nov 2005 15:17:01 +0000 (GMT) (envelope-from arcivanov@mail.ru) Received: from [24.128.227.175] (port=18494 helo=aii9100) by mx3.mail.ru with asmtp id 1EhTha-000GlJ-00 for freebsd-net@freebsd.org; Wed, 30 Nov 2005 18:16:58 +0300 Message-ID: <00b301c5f5c1$1b8bd7d0$329da8c0@home.ivanovy.net> From: "Arcadiy Ivanov" To: References: <1133340478.570472.2094.nullmailer@cicuta.babolo.ru> Date: Wed, 30 Nov 2005 10:16:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Subject: Re: FreeBSD <-> Windows XP IPSec Phase 1 Timeout 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 Nov 2005 15:17:01 -0000 Well, unfortunately it is not the problem - all systems on the network are synchronized via NTP from a common source, thus at least in this test environment clock sync shouldn't be an issue. ----- Original Message ----- From: <"."@babolo.ru> To: "Arcadiy Ivanov" Cc: Sent: Wednesday, November 30, 2005 03:47 AM Subject: Re: FreeBSD <-> Windows XP IPSec Phase 1 Timeout > > I am not expert in this, but I had similar > problems in different environment when clocks > was not synchronized exactly on both tunnel ends. > >> Dear everybody, >> >> I have a following problem which you might help me solve. I'm running a >> FreeBSD 6.0 box as a gateway with Windows XP road warrior clients VPNing >> in. >> In order to setup secure access I want to use IPSec for traffic >> encryption >> with the plain-text PPTP for tunneling. Windows XP IPSec policy is >> configured to ESP everything coming in and out of TCP port 1723 and GRE >> and >> same stands for FreeBSD box. Now here is a problem. Upon initiating PPTP >> dial-up connection from XP the IPSec negotiations start normally, both >> client and server agree on encryption & hashing standards successfully. >> But >> as soon as they do agree, all communications timeout. Tcpdump on FreeBSD >> box >> and Etherpeek on Windows should the IPSec packets being delivered to both >> machines, but both client and server behave as if packets were not >> delivered >> at all and obviously timeout. I do have PF firewall on the gateway but >> the >> result is the same for firewall being off or on or even not loaded into >> kernel. I have used racoon, isakmp and ipsec-tools racoon and the results >> are EXACTLY the same up to the corresponding lines in the logs - as soon >> as >> encryption policies are successfully negotiated and both clients switch >> to >> secure communication mode they lose sight of each other and both timeout. >> I >> of course understand that the logs are necessary and I'm ready to provide >> them if anybody is interested to help me solve the problem, but I'm >> hoping >> that somebody had this problem and knows the solutions off the top of >> his/her head. >> >> Thanks a lot, >> Arcadiy >> >> _______________________________________________ >> 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 Wed Nov 30 15:24:06 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C20F716A41F for ; Wed, 30 Nov 2005 15:24:06 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Received: from mail.npubs.com (mail.wsfamily.com [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB2DF43D46 for ; Wed, 30 Nov 2005 15:24:04 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) From: Nate Nielsen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <438CE0A8.4010205@memberwebs.com> <438D0896.1070808@memberwebs.com> <438D1A99.6000803@errno.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20051130153839.53AA570DCE3@mail.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Wed, 30 Nov 2005 15:38:39 +0000 (GMT) Cc: freebsd-net@freebsd.org Subject: Re: Memory leak in net80211 on FBSD 6.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nielsen@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2005 15:24:06 -0000 Sam Leffler wrote: > Nate Nielsen wrote: >> I've put debugging code in node_alloc() and node_free() (in >> net80211/ieee80211_node.c) and can confirm that thousands of >> ieee80211_node structures are being allocated, at a cost of 1K a piece. >> >> I'll continue to look into this (stumbling about), but if anyone has any >> advice or ideas of where to look, I'd be eternally grateful. > > Please don't spam lots of groups. Apologies. > I'm aware of the leak (David Young > found it in netbsd) and have a partial fix. I'll send it to you directly. Wonderful. Looking forward to that. I've had other problems with rate control in the atheros driver. But I'll wait till I apply your patch before I look into them further, as I'd imagine it's possible the problems are related. Cheers, Nate From owner-freebsd-net@FreeBSD.ORG Wed Nov 30 16:40:55 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BC3016A41F for ; Wed, 30 Nov 2005 16:40:55 +0000 (GMT) (envelope-from daffy@xview.net) Received: from mail.oav.net (mail.oav.net [193.218.105.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D804643D68 for ; Wed, 30 Nov 2005 16:40:54 +0000 (GMT) (envelope-from daffy@xview.net) Received: from localhost (mail.oav.net [193.218.105.18]) by mail03.oav.net (Postfix) with ESMTP id 6F9A033C31; Wed, 30 Nov 2005 17:40:53 +0100 (CET) (envelope-from daffy@xview.net) Received: from mail03.oav.net ([193.218.105.18]) by localhost (mail04.oav.net [172.31.1.4]) (amavisd-new, port 10026) with LMTP id 84593-10; Wed, 30 Nov 2005 17:40:53 +0100 (CET) Received: from [192.168.0.28] (lib59-1-82-229-138-87.fbx.proxad.net [82.229.138.87]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail03.oav.net (Postfix) with ESMTP id BAF1F33C2D; Wed, 30 Nov 2005 17:40:52 +0100 (CET) (envelope-from daffy@xview.net) In-Reply-To: <20051130153839.53AA570DCE3@mail.npubs.com> References: <438CE0A8.4010205@memberwebs.com> <438D0896.1070808@memberwebs.com> <438D1A99.6000803@errno.com> <20051130153839.53AA570DCE3@mail.npubs.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7B3E3D6A-D447-4062-8D07-03C9094A3022@xview.net> Content-Transfer-Encoding: quoted-printable From: Olivier Warin Date: Wed, 30 Nov 2005 17:41:08 +0100 To: nielsen@memberwebs.com X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new at mail04.oav.net Cc: freebsd-net@freebsd.org Subject: Re: Memory leak in net80211 on FBSD 6.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2005 16:40:55 -0000 Hi, Maybee this can be fixed & commited to -CURRENT + FreeBSD6 directly ? Regards, /Olivier Le 30 nov. 05 =E0 16:38, Nate Nielsen a =E9crit : > Sam Leffler wrote: >> Nate Nielsen wrote: >>> I've put debugging code in node_alloc() and node_free() (in >>> net80211/ieee80211_node.c) and can confirm that thousands of >>> ieee80211_node structures are being allocated, at a cost of 1K a =20 >>> piece. >>> >>> I'll continue to look into this (stumbling about), but if anyone =20 >>> has any >>> advice or ideas of where to look, I'd be eternally grateful. >> >> Please don't spam lots of groups. > > Apologies. > >> I'm aware of the leak (David Young >> found it in netbsd) and have a partial fix. I'll send it to you =20 >> directly. > > Wonderful. Looking forward to that. > > I've had other problems with rate control in the atheros driver. But > I'll wait till I apply your patch before I look into them further, as > I'd imagine it's possible the problems are related. -- Olivier Warin - http://xview.net Stay connected ! From owner-freebsd-net@FreeBSD.ORG Thu Dec 1 09:15:08 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DC6116A41F for ; Thu, 1 Dec 2005 09:15:08 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from yam.park.rambler.ru (yam.park.rambler.ru [81.19.64.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id D023B43D5D for ; Thu, 1 Dec 2005 09:15:06 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by yam.park.rambler.ru (8.13.3/8.13.3) with ESMTP id jB19F55G060002 for ; Thu, 1 Dec 2005 12:15:05 +0300 (MSK) (envelope-from is@rambler-co.ru) Date: Thu, 1 Dec 2005 12:15:05 +0300 (MSK) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: freebsd-net@freebsd.org In-Reply-To: <20050901182115.F11484@is.park.rambler.ru> Message-ID: <20051201120928.N32133@is.park.rambler.ru> References: <20050901140051.G11484@is.park.rambler.ru> <20050901182115.F11484@is.park.rambler.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: strange timeout error returned by kevent() in 6.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2005 09:15:08 -0000 On Thu, 1 Sep 2005, Igor Sysoev wrote: > On Thu, 1 Sep 2005, Igor Sysoev wrote: > >> I found strange timeout errors returned by kevent() in 6.0 using >> my http server named nginx. The nginx's run on three machines: >> two 4.10-RELEASE and one 6.0-BETA3. All machines serve the same >> content (simple cluster) and each handles about 200 requests/second. >> >> On 6.0 sometimes (2 or 3 times per hour) in the daytime kevent() >> returns EV_EOF in flags and ETIMEDOUT in fflags, nevertheless: >> >> 1) nginx does not set any kernel timeout for sockets; >> 2) the total request time for such failed requests is small, 30 and so >> seconds. > > I have changed code to ignore the ETIMEDOUT error returned by kevent() > and found that subsequent sendfile() returned the ENOTCONN. > > By the way, why sendfile() may return ENOTCONN ? > I saw this error code on 4.x too. Recently I've found that kevent() in FreeBSD 5.4 may return wrong the ETIMEDOUT too. Also I've found that recv() on FreeBSD 6.0 may return wrong ETIMEDOUT error for socket that has no any kernel timeout. It seems this ETIMEDOUT error masks another error. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Thu Dec 1 09:27:16 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87E2116A41F for ; Thu, 1 Dec 2005 09:27:16 +0000 (GMT) (envelope-from comepu@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8019043D68 for ; Thu, 1 Dec 2005 09:27:03 +0000 (GMT) (envelope-from comepu@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so204603nzo for ; Thu, 01 Dec 2005 01:27:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:from:to:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=GjZyaZa2F5XggJtQPFShOLjiiNqikRwAfIS4qkWiUefm5GGeLGlscpVC6ZvlhHBrwYcxRbqrWav+tGOloovero+OZlY3flMK4xKyBNWlJql9muawh889ISzO9E+AsRTpLXFGWJnfl6g5N7G9NZi0sXdRCKKLm6CUv8MbnA0xNTM= Received: by 10.37.20.11 with SMTP id x11mr1365273nzi; Thu, 01 Dec 2005 01:27:02 -0800 (PST) Received: from wtfzhangj ( [203.212.5.196]) by mx.gmail.com with ESMTP id 24sm684614nzn.2005.12.01.01.27.00; Thu, 01 Dec 2005 01:27:02 -0800 (PST) Message-ID: <001001c5f659$4e2fe0d0$ba00a8c0@wtfzhangj> From: "Jon" To: References: <20051119120111.4BF2316A421@hub.freebsd.org> Date: Thu, 1 Dec 2005 17:26:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: what means "accf" in soisconnected function? thanks! 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, 01 Dec 2005 09:27:16 -0000 SSBhbSByZWFkaW5nICdzb2lzY29ubmVjdGVkJyBmdW5jdGlvbiBpbiAnVWlwY19zb2NrZXQyLmMn IGZpbGUuDQpJIGZpbmQgdGhpcyBsaW5lcy4gQnV0IEkgY2Fubm90IGZpbmQgYWNjZidzIG1lYW4u IGNhbiB5b3UgZXhwbGFpbiB0byBtZT90aGFuayB5b3UgdmVyeSBtdWNoIQ0KICBpZiAoKHNvLT5z b19vcHRpb25zICYgU09fQUNDRVBURklMVEVSKSA9PSAwKSB7DQogICAgLi4uDQogIH0gZWxzZSB7 DQogICBBQ0NFUFRfVU5MT0NLKCk7DQogICBTT0NLX0xPQ0soc28pOw0KICAgc28tPnNvX3VwY2Fs bCA9DQogICAgICAgaGVhZC0+c29fYWNjZi0+c29fYWNjZXB0X2ZpbHRlci0+YWNjZl9jYWxsYmFj azsNCiAgIHNvLT5zb191cGNhbGxhcmcgPSBoZWFkLT5zb19hY2NmLT5zb19hY2NlcHRfZmlsdGVy X2FyZzsNCiAgIHNvLT5zb19yY3Yuc2JfZmxhZ3MgfD0gU0JfVVBDQUxMOw0KICAgc28tPnNvX29w dGlvbnMgJj0gflNPX0FDQ0VQVEZJTFRFUjsNCiAgIFNPQ0tfVU5MT0NLKHNvKTsNCiAgIHNvLT5z b191cGNhbGwoc28sIHNvLT5zb191cGNhbGxhcmcsIE1fRE9OVFdBSVQpOw0KICB9DQo= From owner-freebsd-net@FreeBSD.ORG Thu Dec 1 09:32:41 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B82416A41F for ; Thu, 1 Dec 2005 09:32:41 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEF0743D5A for ; Thu, 1 Dec 2005 09:32:40 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 68744 invoked from network); 1 Dec 2005 09:30:28 -0000 Received: from c00l3r.networx.ch (HELO freebsd.org) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Dec 2005 09:30:28 -0000 Message-ID: <438EC339.38FA8CE5@freebsd.org> Date: Thu, 01 Dec 2005 10:32:41 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon References: <20051119120111.4BF2316A421@hub.freebsd.org> <001001c5f659$4e2fe0d0$ba00a8c0@wtfzhangj> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: what means "accf" in soisconnected function? thanks! 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, 01 Dec 2005 09:32:41 -0000 Jon wrote: > > I am reading 'soisconnected' function in 'Uipc_socket2.c' file. > I find this lines. But I cannot find accf's mean. can you explain to me?thank you very much! This is the accept filter stuff we have. Take a look at setsockopt(2) and accept_filter(9). -- Andre > if ((so->so_options & SO_ACCEPTFILTER) == 0) { > ... > } else { > ACCEPT_UNLOCK(); > SOCK_LOCK(so); > so->so_upcall = > head->so_accf->so_accept_filter->accf_callback; > so->so_upcallarg = head->so_accf->so_accept_filter_arg; > so->so_rcv.sb_flags |= SB_UPCALL; > so->so_options &= ~SO_ACCEPTFILTER; > SOCK_UNLOCK(so); > so->so_upcall(so, so->so_upcallarg, M_DONTWAIT); > } > > -------------------------------------------------------------------------------- > _______________________________________________ > 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 Dec 1 10:07:40 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF32316A420 for ; Thu, 1 Dec 2005 10:07:40 +0000 (GMT) (envelope-from bart@convex.ru) Received: from ubik.convex.ru (ubik.convex.ru [195.64.222.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D18A543D49 for ; Thu, 1 Dec 2005 10:07:38 +0000 (GMT) (envelope-from bart@convex.ru) Received: from 172.21.176.201 (bhome2.convex [172.21.176.201]) by ubik.convex.ru (8.12.11/8.12.11) with ESMTP id jB1A6vYC040210 for ; Thu, 1 Dec 2005 15:06:57 +0500 (YEKT) Date: Thu, 1 Dec 2005 15:07:30 +0500 From: bart X-Mailer: The Bat! (v1.62r) Personal X-Priority: 3 (Normal) Message-ID: <1606083455.20051201150730@convex.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------1C19E1A17C28107" X-SMTP-Vilter-Version: 1.1.8 X-SMTP-Vilter-Virus-Backend: clamd X-SMTP-Vilter-Status: clean X-SMTP-Vilter-clamd-Virus-Status: clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ifconfig description X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bart List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2005 10:07:41 -0000 ------------1C19E1A17C28107 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, previous patches had problem with quagga/zebra. here are set of patches for 5.4 that work fine. I also have patch for quagga to show interface descriptions in "sh int" command Best regards, Alex Bartolomey ------------1C19E1A17C28107-- From owner-freebsd-net@FreeBSD.ORG Thu Dec 1 17:58:03 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F04316A41F for ; Thu, 1 Dec 2005 17:58:03 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id B733143D6B for ; Thu, 1 Dec 2005 17:57:59 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 01 Dec 2005 09:57:59 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id jB1HvwxE009102; Thu, 1 Dec 2005 09:57:58 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id jB1HvwP3009101; Thu, 1 Dec 2005 09:57:58 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200512011757.jB1HvwP3009101@ambrisko.com> In-Reply-To: <20051127075830.35054.qmail@web60016.mail.yahoo.com> To: Imrani Date: Thu, 1 Dec 2005 09:57:58 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Configure wireless connection using Cisco aironet 350 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, 01 Dec 2005 17:58:03 -0000 Imrani writes: [ Charset ISO-8859-1 unsupported, converting... ] | Hi, | | I am trying to configure Cisco Aironet 350 wireless PCI card but I | get an error which I am unable to find much details for that. Following | is description of ifconfing: | | > ifconfig an0 | an0: flags=8843 mtu 1500 | inet6 fe80::209:7cff:fe22:6eab%an0 prefixlen 64 scopeid 0x2 | ether 00:09:7c:22:6e:ab | media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) | status: associated | ssid 1:myhome channel 9 | stationname FreeBSD | ano: record length mismatch -- expected 194, got 196 for Rid ff10 | authmode OPEN privacy ON deftxkey 2 txpowmax 0 rtsthreshold 0 | fragthreshold 0 roaming DEVICE | | | As you can see the wireless card is detected and status is "associated' | but my wireless connection doesn't work. I cannot even ping the router. | | Can you please help me configure wireless connection with my router. | | Also, here are more details: | | WEP on, encryption is 128 bits, BSD 6.0, PCI card is Cisco Aironet 350, | AMD athalon. Is this mini-PCI. If so down-rev the firmware. I got it working better with newer version of mini-PCI but ran into problem in which checking on status while sending data could wedge the card. Doing a kldunload/kldload fixes it but my reset attempts methods didn't :-( I also have the HW MIC support added but not the SW bits. I been derailed on too many other FreeBSD problems to make much progress. I have lots of things that need polish before they can be commited but don't have the time to do that :-( The biggest thing is an OpenIPMI compatable IPMI driver so ipmitool etc. can talk via the motherboard interface. Doug A. From owner-freebsd-net@FreeBSD.ORG Thu Dec 1 19:17:37 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50CB716A41F; Thu, 1 Dec 2005 19:17:37 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E27143D4C; Thu, 1 Dec 2005 19:17:34 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id jB1JSCOm025325; Thu, 1 Dec 2005 14:28:12 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org, freebsd-net@FreeBSD.org Date: Thu, 1 Dec 2005 14:17:09 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200512011417.11650.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV devel-20050919/1200/Thu Dec 1 12:26:35 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Subject: [PATCH] BPF Just-In-Time compiler 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, 01 Dec 2005 19:17:37 -0000 I ported 'jitter' from WinPcap 3.1 to FreeBSD for i386 and wrote amd64 support: http://people.freebsd.org/~jkim/bpf_jitter.diff I didn't do much testing but it seems working pretty well for me so far. ;-) You need the following line in the kernel configuration: options BPF_JITTER You can turn off filtering through JIT-compiled filter by setting: sysctl net.bpf.jitter.enable=0 If you are using very complex filters, it may be useful for you. Caveats are: 1. BIOCSETWF is not supported. 2. bpf_mtap2() is not supported and bpf_mtap() is partially supported. 3. amd64 and i386 only. 4. Intel assembler notation. :-( 5. ... Testing, benchmarking, reviews, comments, complaints, patches for other architectures, etc, all welcome. Cheers, Jung-uk Kim From owner-freebsd-net@FreeBSD.ORG Thu Dec 1 20:55:57 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B77516A41F for ; Thu, 1 Dec 2005 20:55:57 +0000 (GMT) (envelope-from bart@convex.ru) Received: from ubik.convex.ru (ubik.convex.ru [195.64.222.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 708EF43D45 for ; Thu, 1 Dec 2005 20:55:56 +0000 (GMT) (envelope-from bart@convex.ru) Received: from 172.21.176.201 (bhome2.convex [172.21.176.201]) by ubik.convex.ru (8.12.11/8.12.11) with ESMTP id jB1KtP95084732 for ; Fri, 2 Dec 2005 01:55:26 +0500 (YEKT) Date: Fri, 2 Dec 2005 01:55:52 +0500 From: bart X-Mailer: The Bat! (v1.62r) Personal X-Priority: 3 (Normal) Message-ID: <576037585.20051202015552@convex.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.1.8 X-SMTP-Vilter-Virus-Backend: clamd X-SMTP-Vilter-Status: clean X-SMTP-Vilter-clamd-Virus-Status: clean Subject: ifconfig description X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bart List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2005 20:55:57 -0000 *** sys/net/if.c.orig Fri Apr 15 07:52:03 2005 --- sys/net/if.c Sat Nov 26 17:34:41 2005 *************** *** 1072,1077 **** --- 1072,1078 ---- { struct ifreq *ifr; struct ifstat *ifs; + struct ifdescreq *ifrd; int error = 0; int new_flags; size_t namelen, onamelen; *************** *** 1214,1219 **** --- 1215,1232 ---- EVENTHANDLER_INVOKE(ifnet_arrival_event, ifp); /* Announce the return of the interface. */ rt_ifannouncemsg(ifp, IFAN_ARRIVAL); + break; + + /* bartp */ + + case SIOCSIFDESCR: + ifrd = (struct ifdescreq *)data; + strlcpy(ifp->if_descr, ifrd->ifrd_descr, MAXIFDESCRSIZE); + break; + + case SIOCGIFDESCR: + ifrd = (struct ifdescreq *)data; + strlcpy(ifrd->ifrd_descr, ifp->if_descr, MAXIFDESCRSIZE); break; case SIOCSIFMETRIC: *** sys/net/if.h.orig Tue Mar 1 03:03:13 2005 --- sys/net/if.h Tue Nov 29 17:21:13 2005 *************** *** 72,77 **** --- 72,80 ---- char *ifcr_buffer; /* buffer for cloner names */ }; + #define MAXIFDESCRSIZE 48 + + /* * Structure describing information about an interface * which may be of interest to management entities. *************** *** 269,274 **** --- 272,282 ---- struct sockaddr ifra_addr; struct sockaddr ifra_broadaddr; struct sockaddr ifra_mask; + }; + + struct ifdescreq { + char ifrd_name[IFNAMSIZ]; /* if name, e.g. "en0" */ + char ifrd_descr[MAXIFDESCRSIZE]; /* interface description */ }; struct ifmediareq { *** sys/net/if_var.h.orig Sun May 8 13:00:16 2005 --- sys/net/if_var.h Sat Nov 26 17:34:06 2005 *************** *** 200,205 **** --- 200,206 ---- int if_afdata_initialized; struct mtx if_afdata_mtx; struct task if_starttask; /* task for IFF_NEEDSGIANT */ + char if_descr[MAXIFDESCRSIZE]; }; typedef void if_init_f_t(void *); *** sbin/ifconfig/ifconfig.c.orig Mon Mar 21 21:05:33 2005 --- sbin/ifconfig/ifconfig.c Fri Nov 25 15:29:35 2005 *************** *** 175,180 **** --- 175,181 ---- c_func setifflags, setifmetric, setifmtu, setifcap; c_func clone_destroy; c_func setifname; + c_func setifdescr; void clone_create(void); *************** *** 310,315 **** --- 311,317 ---- { "noicmp", IFF_LINK1, setifflags }, { "mtu", NEXTARG, setifmtu }, { "name", NEXTARG, setifname }, + { "descr", NEXTARG, setifdescr }, { 0, 0, setifaddr }, { 0, 0, setifdstaddr }, }; *************** *** 1008,1013 **** --- 1010,1031 ---- (*afp->af_getaddr)(addr, DSTADDR); } + static void + setifdescr(const char *val, int dummy __unused, int s, + const struct afswtch *afp) + { + struct ifdescreq ifrd; + + strlcpy( ifrd.ifrd_name, ifr.ifr_name, sizeof(ifr.ifr_name) ); + strlcpy( ifrd.ifrd_descr, val, sizeof(ifrd.ifrd_descr) ); + + if (ioctl(s, SIOCSIFDESCR, (caddr_t)&ifrd) < 0) { + warn("ioctl (set descr)"); + return; + } + } + + /* * Note: doing an SIOCIGIFFLAGS scribbles on the union portion * of the ifreq structure, which may confuse other parts of ifconfig. *************** *** 1121,1126 **** --- 1139,1145 ---- struct rt_addrinfo info; int allfamilies, s; struct ifstat ifs; + struct ifdescreq ifrd; if (afp == NULL) { allfamilies = 1; *************** *** 1219,1224 **** --- 1238,1250 ---- #endif ) warnx("%s has no %s interface address!", name, afp->af_name); + + /* bartp */ + + strncpy(ifrd.ifrd_name, name, sizeof ifrd.ifrd_name); + if (ioctl(s, SIOCGIFDESCR, (caddr_t)&ifrd) == 0 && ifrd.ifrd_descr[0]!=0 ) { + printf(" descr: %s\n", ifrd.ifrd_descr); + } close(s); return; *** sys/sys/sockio.h.orig Wed Apr 7 10:19:49 2004 --- sys/sys/sockio.h Fri Nov 25 15:07:55 2005 *************** *** 80,85 **** --- 80,90 ---- #define SIOCSIFMAC _IOW('i', 39, struct ifreq) /* set IF MAC label */ #define SIOCSIFNAME _IOW('i', 40, struct ifreq) /* set IF name */ + /* bartp */ + #define SIOCSIFDESCR _IOW('i', 41, struct ifdescreq) /* set IF descr */ + #define SIOCGIFDESCR _IOWR('i', 42, struct ifdescreq) /* get IF descr */ + + #define SIOCADDMULTI _IOW('i', 49, struct ifreq) /* add m'cast addr */ #define SIOCDELMULTI _IOW('i', 50, struct ifreq) /* del m'cast addr */ #define SIOCGIFMTU _IOWR('i', 51, struct ifreq) /* get IF mtu */ From owner-freebsd-net@FreeBSD.ORG Thu Dec 1 21:04:05 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDD5216A41F for ; Thu, 1 Dec 2005 21:04:05 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5D9E43D58 for ; Thu, 1 Dec 2005 21:04:05 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) From: Nate Nielsen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <438CE0A8.4010205@memberwebs.com> <438D0896.1070808@memberwebs.com> <438D1A99.6000803@errno.com> <20051130153839.53AA570DCE3@mail.npubs.com> <438E0B34.9030702@errno.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20051201211848.CAA7D70DD6D@mail.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Thu, 1 Dec 2005 21:18:49 +0000 (GMT) Cc: , freebsd-net@freebsd.org Subject: Re: Memory leak in net80211 on FBSD 6.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nielsen@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2005 21:04:06 -0000 Sam Leffler wrote: > I believe the attached change plugs the leak. I gave it a shot, and the problem is still there. I've checked to make sure this is in fact the right kernel: > # strings /boot/kernel/kernel | grep ieee80211_init_neighbor > ieee80211_init_neighbor Is there further information you'd like me to get together? It appears (as I'm sure you're aware) that the number of allocations in the '80211node' malloc pool is directly related to the number of packets received over the wireless link. The memory is not 'leaked' per se. If I shutdown the system before the panic then the memory is freed (I put a few debug messages). The memory leak only occurs on one station of a adhoc pair. If I shutdown both systems, then it's a guess as to which one will be affected. However once one of them panics, then that machine will continue to be the affected machine (after reboots). > Note that there are > several issues with adhoc mode and ath devices so please try to separate > the leak from any other complaints. I'll keep that in mind. However in this case the other trouble I've had is with rate control using an insane amount of CPU. I can imagine that if thousands of seperate ieee80211_node's are allocated, then trying to do rate control on all of these would result in the condition I'm seeing. It seems the two problems could be related. Cheers, Nate From owner-freebsd-net@FreeBSD.ORG Thu Dec 1 23:17:50 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF37E16A41F; Thu, 1 Dec 2005 23:17:50 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (outbound.idiom.com [216.240.47.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66E3A43D4C; Thu, 1 Dec 2005 23:17:50 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 0746522962F; Thu, 1 Dec 2005 15:17:50 -0800 (PST) Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id jB1NHnrd081031; Thu, 1 Dec 2005 15:17:49 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <438F849D.5010500@elischer.org> Date: Thu, 01 Dec 2005 15:17:49 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jung-uk Kim References: <200512011417.11650.jkim@FreeBSD.org> In-Reply-To: <200512011417.11650.jkim@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH] BPF Just-In-Time compiler 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, 01 Dec 2005 23:17:51 -0000 Jung-uk Kim wrote: >I ported 'jitter' from WinPcap 3.1 to FreeBSD for i386 and wrote amd64 >support: > >http://people.freebsd.org/~jkim/bpf_jitter.diff > >I didn't do much testing but it seems working pretty well for me so >far. ;-) > > > > shades of DPF. >Cheers, > >Jung-uk Kim >_______________________________________________ >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 Dec 2 00:01:13 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3CC116A428; Fri, 2 Dec 2005 00:01:13 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DE4443D5C; Fri, 2 Dec 2005 00:01:12 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id jB20BxNS033833; Thu, 1 Dec 2005 19:11:59 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Julian Elischer Date: Thu, 1 Dec 2005 19:00:56 -0500 User-Agent: KMail/1.6.2 References: <200512011417.11650.jkim@FreeBSD.org> <438F849D.5010500@elischer.org> In-Reply-To: <438F849D.5010500@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit Message-Id: <200512011900.58570.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV devel-20050919/1200/Thu Dec 1 12:26:35 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-net@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [PATCH] BPF Just-In-Time compiler 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, 02 Dec 2005 00:01:13 -0000 On Thursday 01 December 2005 06:17 pm, Julian Elischer wrote: > Jung-uk Kim wrote: > >I ported 'jitter' from WinPcap 3.1 to FreeBSD for i386 and wrote > > amd64 support: > > > >http://people.freebsd.org/~jkim/bpf_jitter.diff > > > >I didn't do much testing but it seems working pretty well for me > > so far. ;-) > > shades of DPF. Or shades of BPF+. ;-) Jung-uk Kim > >Cheers, > > > >Jung-uk Kim From owner-freebsd-net@FreeBSD.ORG Fri Dec 2 01:18:18 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CF0016A41F; Fri, 2 Dec 2005 01:18:18 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA48D43D55; Fri, 2 Dec 2005 01:18:16 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 01 Dec 2005 17:18:16 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id jB21IGT9032895; Thu, 1 Dec 2005 17:18:16 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id jB21IGuu032894; Thu, 1 Dec 2005 17:18:16 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200512020118.jB21IGuu032894@ambrisko.com> In-Reply-To: <438D6FB9.FFBD8593@freebsd.org> To: Andre Oppermann Date: Thu, 1 Dec 2005 17:18:16 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, scottl@freebsd.org, Jack Vogel , yongari@freebsd.org Subject: Re: Hey everyone 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, 02 Dec 2005 01:18:18 -0000 Andre Oppermann writes: | Jack Vogel wrote: | | Dear Jack, | | > I wanted to introduce myself to the list. I am now the primary contact | > at Intel for our drivers. There was some earlier email I saw in the archive | > about 82571/2 support, and I want to confirm that that code is coming. | | for a too long time Intel has abandoned their direct involvement in | the FreeBSD 'em' driver. And you have two people with direct commit | rights to the FreeBSD CVS tree. | | In the meantime we have taken the driver maintainance into our own | hands, have rewritten parts of it and got a lot more conforming code. | Not to mention that we were able to increase the performance significantly | too. We have fixed many show-stopper bugs which were wedging the hardware | as well. ... and introduced a machine lock-up bug :-( Jack has a fix for it. So it works both ways. | Before you continue development on your own FreeBSD driver please have a | very close look the version we have in our CVS tree. You may benefit from | taking that as base and continue development from it instead of your own | code. The CVS commit messages explain in much detail which problems we | found and how we solved them. | http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/em/if_em.c | | Intel would help us a lot if you would release the Erratas to your 'em' | chip famility. I think you might be a little harsh. I think I understand where both sides are coming from. I know when I was at Vernier and Prafulla was maintaining things that he didn't take some cool changes that Sam Leffler did for us with jumbo packets so IPsec with HW crypto screamed. Since this was going to be hard for Intel to make backward compatible they didn't take the jumbo packet stuff with #ifdef mess. Now yes, Intel has been somewhat slow getting the latest greatest stuff into FreeBSD recently but in general it's a lot better then Broadcom. So we need to leverage their access to non-public documents and that Intel pays them to work on this stuff but not just for FreeBSD. I totally understand how things can get slowed down. At the company I work for that pays me to do FreeBSD work I have several FreeBSD fixes, patches and new stuff. Some is locked under NDA and can only be shared via those that have mutual NDA's. Other stuff is in a form good enough for our customers but not ready for FreeBSD. Also since our product is based on FreeBSD 4.X taking our fixes for that to FreeBSD -current -> 6 -> 5 -> 4 is a huge pain and the hacks that are okay to fix our problem and move on it not good enough for FreeBSD. Since I have to fight the next fire, I don't have the cycles to get to the point to commit. I wouldn't mind sharing the open code with people to help out (read people that can code things and not just test). Since it isn't complete I can't commit it to CVS. I guess I could use Perforce but that is yet another thing to deal with. Now I would have our work trees, Perforce and CVS repo's that add's even more work. It's almost getting to the point it is to hard to do work on FreeBSD! Now I'm sure we will be moving to FreeBSD 6 and things will get better for me. It was a good thing we didn't move to FreeBSD 5 or I'd have even more hassle. | > I hope to be adding some new feature support as well. I have been | > eyeing TSO which is going to need stack changes, if anyone out there | > has been working or just thinking about that get in touch with me about it. | | We have already looked into TSO a bit and so far the result is inconclusive. | We may not want to make any large changes to the TCP code to faciliate any | particular TSO architecture. To make the case in favor of supporting TSO | it has to be shown that is provides real-world benefits and extensive | benchmark results have to be provided. Any changes to our TCP code to | support TSO must be well designed and be generic supporting other vendors | TSO as well. However I must say that a really compelling has to be made | for TSO to justify the changes and the associated long term code maintainance | hurdles with it. | | Please have a look at this paper discussing TSO among other things: | | http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20TCP%20Stack.pdf Yes, I wonder the value of TSO and even HW crypto IPsec off-loading with IP stacks built in. Our network stack is very powerful and has lots of hooks into it that allow lots of things to be inter-mixed. I doubt HW offloading will permit the level of integration we have now. I've told various vendors that pitch this stuff no thanks. Usually most of it isn't open. | > In any case, I am kept quite busy but I will make every effort to be here | > and be as responsive as i can. | | Please get in contact with Gelb Smirnoff , Pyun YongHyeon | and Scott Long . Those folks have | assumed maintainership of the 'em' driver and contributed many important fixes | and performance enhancements. | | For the time being I guess it is the best if we collect the direct CVS | access of pdeuskar and tackerman and you submit patches to 'em' through | one of the above contacts at FreeBSD. I do agree that things should be consolidated. Let's give Jack some time to get up to speed since he seems really responsive. I think Jack coming on board is a good thing from what I've experienced so far with him. Intel in the past has accepted some bug fixes I sent to them so I don't think they totally ignore us. Doug A. From owner-freebsd-net@FreeBSD.ORG Fri Dec 2 06:16:16 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A15BD16A420 for ; Fri, 2 Dec 2005 06:16:16 +0000 (GMT) (envelope-from EDouglass@gaylordhotels.com) Received: from gaylordentertainment.com (mail.gaylordentertainment.com [12.153.11.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2027F43D53 for ; Fri, 2 Dec 2005 06:16:14 +0000 (GMT) (envelope-from EDouglass@gaylordhotels.com) Received: from 10.42.4.102 by gaylordentertainment.com with ESMTP (TN SMTP Relay); Fri, 02 Dec 2005 00:15:47 -0600 X-Server-Uuid: E485C1F1-10DB-4031-9668-820096A468D3 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 Dec 2005 00:15:49 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <566E54419328A642A3A6E91376E885B1048EA097@txex.tx.get> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Linksys wireless Thread-Index: AcX3B9dGG5gVUoGgS4aGBi0wJz/Ssg== From: "Douglass, Erik" To: freebsd-net@freebsd.org X-MMS-Spam-Filter-ID: A2005120202_2.0.4,4.0-7 X-TMWD-Spam-Summary: SEV=0.9; DFV=A2005120202; IFV=2.0.4,4.0-7; RPD=NA; RPDID=NA; ENG=IBF; TS=20051202061551; CAT=NONE; CON=NONE; X-WSS-ID: 6F91391927S4611328-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Linksys wireless 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, 02 Dec 2005 06:16:16 -0000 Does the latest release support linksys wireless pcmcia cards?? Thanks. -------------------------- Sent from my BlackBerry Wireless Handheld From owner-freebsd-net@FreeBSD.ORG Fri Dec 2 07:27:21 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEA3616A41F for ; Fri, 2 Dec 2005 07:27:20 +0000 (GMT) (envelope-from jay2xra@yahoo.com) Received: from web51604.mail.yahoo.com (web51604.mail.yahoo.com [206.190.38.209]) by mx1.FreeBSD.org (Postfix) with SMTP id 523F943D5C for ; Fri, 2 Dec 2005 07:27:20 +0000 (GMT) (envelope-from jay2xra@yahoo.com) Received: (qmail 76689 invoked by uid 60001); 2 Dec 2005 07:27:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RuXNucgVIH7CUdBWsBQCQcDF2o7kVZ7LDyqR2D0H1RrgVfUgYsx7f5Pwqjh1BQgyHqz59cpv8FUhc9zHD7WvjB3NxK2BR1HmWtCujs5aNnX1tzhjmvtve1liEYCzIq7r5PFji4CUXSkR4WXFDTIIx+DMpHcOUbfDpPAB+BJnuvw= ; Message-ID: <20051202072719.76687.qmail@web51604.mail.yahoo.com> Received: from [202.90.128.21] by web51604.mail.yahoo.com via HTTP; Thu, 01 Dec 2005 23:27:19 PST Date: Thu, 1 Dec 2005 23:27:19 -0800 (PST) From: Mark Jayson Alvarez To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: how to set a route to an AF_LINK type 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, 02 Dec 2005 07:27:21 -0000 Hi, I'm not sure what I did wrong. My carp setup with 2 machines sharing 1 virtual ip is working perfect for 3 days now, until today, I got these messages in /var/log/messages kernel: carp: incorrect hash arp_rtrequest:bad gateway 10.10.8.146 (!AF_LINK) googling brought me to this link: http://lists.freebsd.org/pipermail/freebsd-net/2004-January/002608.html However, It doesn't show how to resolve the problem. After rebooting the machine, it still doesn't work (when it is supposed to) Netstat -rn gives me: default 10.10.8.254 UGS 0 1074 xl0 10.10.8/24 link#1 UC 0 0 xl0 10.10.8.112 00:0e:a6:c9:ac:19 UHLW 1 46 xl0 1186 10.10.8.254 00:01:02:9a:7f:c3 UHLW 2 1 xl0 827 127.0.0.1 127.0.0.1 UH 0 0 lo0 Is the route type (AF_LINK) configurable? where? How will I know if it is an AF_LINK type? Rebooting doesn't fix the corrupted routing table either. Any idea how to eliminate the problem? Thanks __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Fri Dec 2 08:18:44 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CB1316A41F for ; Fri, 2 Dec 2005 08:18:44 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E51BD43D46 for ; Fri, 2 Dec 2005 08:18:43 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jB28Igv0004050; Fri, 2 Dec 2005 10:18:42 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 71213-01-10; Fri, 2 Dec 2005 10:18:40 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jB28G39l003803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2005 10:16:03 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jB28G51Q007023; Fri, 2 Dec 2005 10:16:05 +0200 (EET) (envelope-from ru) Date: Fri, 2 Dec 2005 10:16:05 +0200 From: Ruslan Ermilov To: Mark Jayson Alvarez Message-ID: <20051202081605.GR20961@ip.net.ua> References: <20051202072719.76687.qmail@web51604.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TDVcAd+kFgbLxwBe" Content-Disposition: inline In-Reply-To: <20051202072719.76687.qmail@web51604.mail.yahoo.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-net@freebsd.org Subject: Re: how to set a route to an AF_LINK type 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, 02 Dec 2005 08:18:44 -0000 --TDVcAd+kFgbLxwBe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 01, 2005 at 11:27:19PM -0800, Mark Jayson Alvarez wrote: > =20 > Hi, > =20 > I'm not sure what I did wrong. My carp setup with 2 machines sharing 1= =20 > virtual ip is working perfect for 3 days now, until today, I got these=20 > messages in /var/log/messages > =20 > kernel: carp: incorrect hash > arp_rtrequest:bad gateway 10.10.8.146 (!AF_LINK) > =20 > googling brought me to this link: > =20 > http://lists.freebsd.org/pipermail/freebsd-net/2004-January/002608.html > =20 > However, It doesn't show how to resolve the problem. After rebooting=20 > the machine, it still doesn't work (when it is supposed to) > Netstat -rn gives me: > =20 > default 10.10.8.254 UGS 0 1074 xl0 > 10.10.8/24 link#1 UC 0 0 xl0 > 10.10.8.112 00:0e:a6:c9:ac:19 UHLW 1 46 xl0 =20 > 1186 > 10.10.8.254 00:01:02:9a:7f:c3 UHLW 2 1 xl0 = =20 > 827 > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > =20 >=20 > Is the route type (AF_LINK) configurable? where? How will I know if it is= an AF_LINK type?=20 > Rebooting doesn't fix the corrupted routing table either. > Any idea how to eliminate the problem? >=20 It's the gateway's address family that is AF_LINK, not a "route type". For example, routes for 10.10.8.112 and 10.10.8.254 have gateways of type AF_LINK (Ethenet addresses). I don't know about this specific problem, but adding a route with AF_LINK gateway can be done using a route(8) command, for example: # route add -host 1.2.3.4 -link :0.1.2.3.4.5 -ifp lo0 Which doesn't make any sense, and is presented only to demonstrate the ability to add AF_LINK gateway. The following command adds an "ARP route" through em0 which doesn't have a corresponding network, and is otherwise not possible to do with the arp(8) command: # route add -host 1.2.3.4 -link :0.1.2.3.4.5 -ifp em0 -iface add host 1.2.3.4: gateway :0.1.2.3.4.5 # arp -n 1.2.3.4 ? (1.2.3.4) at 00:01:02:03:04:05 on em0 permanent [ethernet] Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --TDVcAd+kFgbLxwBe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDkALFqRfpzJluFF4RAolDAKCFoTk/Ic22HRyHkkh+G1TGwqGpLwCeNZU8 aOSpTL+347I/O4XcuJRJME0= =UXi4 -----END PGP SIGNATURE----- --TDVcAd+kFgbLxwBe-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 2 08:51:27 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C26116A41F for ; Fri, 2 Dec 2005 08:51:27 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8AAF43D4C for ; Fri, 2 Dec 2005 08:51:26 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from [84.247.144.144] (helo=lapdance.yazzy.net) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1Ei6ci-00001c-Vb; Fri, 02 Dec 2005 09:50:33 +0100 Date: Fri, 2 Dec 2005 08:50:59 +0000 From: Marcin Jessa To: bart Message-Id: <20051202085059.69d51fc2.lists@yazzy.org> In-Reply-To: <1606083455.20051201150730@convex.ru> References: <1606083455.20051201150730@convex.ru> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.7; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) Cc: freebsd-net@freebsd.org Subject: Re: ifconfig description 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, 02 Dec 2005 08:51:27 -0000 On Thu, 1 Dec 2005 15:07:30 +0500 bart wrote: > Hello, Hi Alex. > previous patches had problem with quagga/zebra. > here are set of patches for 5.4 that work fine. > I also have patch for quagga to show interface descriptions > in "sh int" command I like this fearure a lot. It makes a nice "addon" to the ifconfig command the same way changing name of devices with ifconfig does. A differrent approach would be to make your shell read the device config from say an XML file and display info like device name stored in that file. But that would require and "rc.d/" file to read the XML info and set up devices accordingly. It's more of a custom thing the same way as quagga's shell is. My question is, did you get any response from FreeBSD commiters and is there a chance to have that change commited to FreeBSD's source tree? Cheers, Marcin. From owner-freebsd-net@FreeBSD.ORG Fri Dec 2 10:09:41 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31F5816A440 for ; Fri, 2 Dec 2005 10:09:41 +0000 (GMT) (envelope-from jay2xra@yahoo.com) Received: from web51608.mail.yahoo.com (web51608.mail.yahoo.com [206.190.38.213]) by mx1.FreeBSD.org (Postfix) with SMTP id E62C443DDC for ; Fri, 2 Dec 2005 10:09:21 +0000 (GMT) (envelope-from jay2xra@yahoo.com) Received: (qmail 65996 invoked by uid 60001); 2 Dec 2005 10:09:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QyBJiwguc8cuX//l/QWPYcyrcrjItSLyutD8pxxuC+xEkeDu21urFRmmuIvIDO/PDPvkZdjJvrFG2jcm72AXtYhEd1ekGhPZ4KBErz7o2tEGrmyt0g9Gkxz0XC7dha7yd2GDA5s6gbqB7dgQhZValXgwOCaK0O9hdmPo75b+gOA= ; Message-ID: <20051202100914.65994.qmail@web51608.mail.yahoo.com> Received: from [202.90.128.21] by web51608.mail.yahoo.com via HTTP; Fri, 02 Dec 2005 02:09:14 PST Date: Fri, 2 Dec 2005 02:09:14 -0800 (PST) From: Mark Jayson Alvarez To: Ruslan Ermilov In-Reply-To: <20051202081605.GR20961@ip.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Atanas Yankov , freebsd-net@freebsd.org Subject: Re: how to set a route to an AF_LINK type 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, 02 Dec 2005 10:09:41 -0000 Hi, Ruslan Ermilov wrote: On Thu, Dec 01, 2005 at 11:27:19PM -0800, Mark Jayson Alvarez wrote: > > Hi, > > I'm not sure what I did wrong. My carp setup with 2 machines sharing 1 > virtual ip is working perfect for 3 days now, until today, I got these > messages in /var/log/messages > > kernel: carp: incorrect hash > arp_rtrequest:bad gateway 10.10.8.146 (!AF_LINK) > > googling brought me to this link: > > http://lists.freebsd.org/pipermail/freebsd-net/2004-January/002608.html > > However, It doesn't show how to resolve the problem. After rebooting > the machine, it still doesn't work (when it is supposed to) > Netstat -rn gives me: > > default 10.10.8.254 UGS 0 1074 xl0 > 10.10.8/24 link#1 UC 0 0 xl0 > 10.10.8.112 00:0e:a6:c9:ac:19 UHLW 1 46 xl0 > 1186 > 10.10.8.254 00:01:02:9a:7f:c3 UHLW 2 1 xl0 > 827 > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > > > Is the route type (AF_LINK) configurable? where? How will I know if it is an AF_LINK type? > Rebooting doesn't fix the corrupted routing table either. > Any idea how to eliminate the problem? > >It's the gateway's address family that is AF_LINK, not a "route >type". >For example, routes for 10.10.8.112 and 10.10.8.254 have >gateways of >type AF_LINK (Ethenet addresses). I don't know about this specific >problem, but adding a route with AF_LINK gateway can be done >using a >route(8) command, for example: ># route add -host 1.2.3.4 -link :0.1.2.3.4.5 -ifp lo0 >Which doesn't make any sense, and is presented only to >demonstrate >the ability to add AF_LINK gateway. The following command adds >an >"ARP route" through em0 which doesn't have a corresponding >network, >and is otherwise not possible to do with the arp(8) command: ># route add -host 1.2.3.4 -link :0.1.2.3.4.5 -ifp em0 -iface >add host 1.2.3.4: gateway :0.1.2.3.4.5 ># arp -n 1.2.3.4 >? (1.2.3.4) at 00:01:02:03:04:05 on em0 permanent [ethernet] Ok, so how will I go about my problem? I tried reinstalling FreeBSD from scratch yet it still doesn't work. Any more idea? Thanks. --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less From owner-freebsd-net@FreeBSD.ORG Fri Dec 2 17:38:02 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16B6216A41F for ; Fri, 2 Dec 2005 17:38:02 +0000 (GMT) (envelope-from juan.fco.rodriguez@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DF9643D46 for ; Fri, 2 Dec 2005 17:38:01 +0000 (GMT) (envelope-from juan.fco.rodriguez@gmail.com) Received: by nproxy.gmail.com with SMTP id q29so216216nfc for ; Fri, 02 Dec 2005 09:38:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=phdkuNTCzV6xXdrBhHhcli5MUa0cVp+ZyOq698Dpa/ANbZ6hybItKEjW43G2PPfd49QxCrAunEci1OdDihv+MkxSMsnCFJChPdHa4AfI7nUkt/KEvHwhtXvOVkg15c4rejGdf3as65XHqmgtQuRixt0HB+mGvhc0qw3YG+smh+s= Received: by 10.49.2.2 with SMTP id e2mr312280nfi; Fri, 02 Dec 2005 09:37:59 -0800 (PST) Received: by 10.49.1.15 with HTTP; Fri, 2 Dec 2005 09:37:59 -0800 (PST) Message-ID: <96b30c400512020937r42d1bec2t4e8ca9527b635603@mail.gmail.com> Date: Fri, 2 Dec 2005 18:37:59 +0100 From: Juan Rodriguez To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Does Zyxel ZyAIR-B100 works on FreeBSD-6.0 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2005 17:38:02 -0000 I'm going to buy it because it's very chip (and a bit old). I've found on the web that it's based on Prims-3.0 chipset, but I haven't found it listed on the wi man page.... -- JFRH