From owner-freebsd-net@FreeBSD.ORG Sun Jul 22 01:14:48 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85D4516A41B; Sun, 22 Jul 2007 01:14:48 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 9273E13C461; Sun, 22 Jul 2007 01:14:17 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 0977FEB20FC; Sun, 22 Jul 2007 08:56:03 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id SbzGSdlqJjkQ; Sun, 22 Jul 2007 08:56:01 +0800 (CST) Received: from charlie.delphij.net (unknown [221.216.126.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id A9546EB20EF; Sun, 22 Jul 2007 08:56:00 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type; b=lBpg/ADpi0IlEZyijhexQ55pbT6HyB7HD2PsYBFIMJ518JADog+9HSGa285SCI2pN MowRycmbwe8ui/DRKiOPQ== Message-ID: <46A2AB1F.3060507@delphij.net> Date: Sun, 22 Jul 2007 08:55:59 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.5 (X11/20070721) MIME-Version: 1.0 To: Peter Wemm References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <200707201155.44573.peter@wemm.org> In-Reply-To: <200707201155.44573.peter@wemm.org> Content-Type: multipart/mixed; boundary="------------080503060705080206030802" Cc: Andre Oppermann , current@freebsd.org, freebsd-current@freebsd.org, Robert Watson , net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 01:14:48 -0000 This is a multi-part message in MIME format. --------------080503060705080206030802 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit I was unable to apply Mike's patch so I have manually applied it. Here is a new one that should apply against today's -CURRENT. Cheers, --------------080503060705080206030802 Content-Type: text/x-patch; name="tcp_syncache.c-timerfix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_syncache.c-timerfix.patch" Index: tcp_syncache.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_syncache.c,v retrieving revision 1.123 diff -u -p -r1.123 tcp_syncache.c --- tcp_syncache.c 3 Jul 2007 12:13:43 -0000 1.123 +++ tcp_syncache.c 21 Jul 2007 16:15:07 -0000 @@ -142,7 +142,6 @@ struct syncache_head { struct mtx sch_mtx; TAILQ_HEAD(sch_head, syncache) sch_bucket; struct callout sch_timer; - int sch_nextc; u_int sch_length; u_int sch_oddeven; u_int32_t sch_secbits_odd[SYNCOOKIE_SECRET_SIZE]; @@ -233,16 +232,10 @@ static MALLOC_DEFINE(M_SYNCACHE, "syncac #define ENDPTS6_EQ(a, b) (memcmp(a, b, sizeof(*a)) == 0) -#define SYNCACHE_TIMEOUT(sc, sch, co) do { \ +#define SYNCACHE_TIMEOUT(sc) do { \ (sc)->sc_rxmits++; \ (sc)->sc_rxttime = ticks + \ TCPTV_RTOBASE * tcp_backoff[(sc)->sc_rxmits - 1]; \ - if ((sch)->sch_nextc > (sc)->sc_rxttime) \ - (sch)->sch_nextc = (sc)->sc_rxttime; \ - if (!TAILQ_EMPTY(&(sch)->sch_bucket) && !(co)) \ - callout_reset(&(sch)->sch_timer, \ - (sch)->sch_nextc - ticks, \ - syncache_timer, (void *)(sch)); \ } while (0) #define SCH_LOCK(sch) mtx_lock(&(sch)->sch_mtx) @@ -268,6 +261,7 @@ void syncache_init(void) { int i; + struct syncache_head *sch; tcp_syncache.cache_count = 0; tcp_syncache.hashsize = TCP_SYNCACHE_HASHSIZE; @@ -310,6 +304,17 @@ syncache_init(void) tcp_syncache.zone = uma_zcreate("syncache", sizeof(struct syncache), NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); uma_zone_set_max(tcp_syncache.zone, tcp_syncache.cache_limit); + + /* + * Start the syncache head timers running. They each run ten times + * a second, and are spread out so that they are not all running on + * the same clock tick. + */ + for (i = 0; i < tcp_syncache.hashsize; i++) { + sch = &tcp_syncache.hashbase[i]; + callout_reset(&(sch)->sch_timer, i * (hz / 10), + syncache_timer, (void *)(sch)); + } } /* @@ -339,8 +344,8 @@ syncache_insert(struct syncache *sc, str TAILQ_INSERT_HEAD(&sch->sch_bucket, sc, sc_hash); sch->sch_length++; - /* Reinitialize the bucket row's timer. */ - SYNCACHE_TIMEOUT(sc, sch, 1); + /* Set the retransmit timer for this socket. */ + SYNCACHE_TIMEOUT(sc); SCH_UNLOCK(sch); @@ -390,11 +395,8 @@ syncache_timer(void *xsch) * then the RST will be sent by the time the remote * host does the SYN/ACK->ACK. */ - if (sc->sc_rxttime >= tick) { - if (sc->sc_rxttime < sch->sch_nextc) - sch->sch_nextc = sc->sc_rxttime; + if (sc->sc_rxttime >= tick) continue; - } if (sc->sc_rxmits > tcp_syncache.rexmt_limit) { if ((s = tcp_log_addrs(&sc->sc_inc, NULL, NULL, NULL))) { @@ -409,11 +411,10 @@ syncache_timer(void *xsch) (void) syncache_respond(sc); tcpstat.tcps_sc_retransmitted++; - SYNCACHE_TIMEOUT(sc, sch, 0); + SYNCACHE_TIMEOUT(sc); } - if (!TAILQ_EMPTY(&(sch)->sch_bucket)) - callout_reset(&(sch)->sch_timer, (sch)->sch_nextc - tick, - syncache_timer, (void *)(sch)); + callout_reset(&(sch)->sch_timer, hz / 10, + syncache_timer, (void *)(sch)); } /* @@ -995,7 +996,7 @@ syncache_add(struct in_conninfo *inc, st ("%s: label not initialized", __func__)); #endif if (syncache_respond(sc) == 0) { - SYNCACHE_TIMEOUT(sc, sch, 1); + SYNCACHE_TIMEOUT(sc); tcpstat.tcps_sndacks++; tcpstat.tcps_sndtotal++; } --------------080503060705080206030802-- From owner-freebsd-net@FreeBSD.ORG Sun Jul 22 07:49:54 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 033BD16A417 for ; Sun, 22 Jul 2007 07:49:54 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id 21E2813C45D for ; Sun, 22 Jul 2007 07:49:52 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from [192.168.32.4] (aviko.aws-net.org.ua [192.168.32.4]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l6M7nddk030192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 Jul 2007 10:49:43 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Message-ID: <46A30C13.1030909@aws-net.org.ua> Date: Sun, 22 Jul 2007 10:49:39 +0300 From: Artyom Viklenko Organization: Art&Co. User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Stephen.Clark@seclark.us References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> <20070720172021.8EA3D13C4B3@mx1.freebsd.org> <46A10063.9010902@elischer.org> <46A10860.50804@es.net> <46A1BDDE.5080403@aws-net.org.ua> <46A2342C.1030205@seclark.us> In-Reply-To: <46A2342C.1030205@seclark.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Sun, 22 Jul 2007 10:49:44 +0300 (EEST) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on alf.aws-net.org.ua X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, Artem Belevich , Julian Elischer Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 07:49:54 -0000 Stephen Clark wrote: > Artyom Viklenko wrote: > >> Artem Belevich wrote: >> >> >>> Here's one example where MTU!=MRU would be useful. >>> >>> Think of asymmetric bandwith-limited ADSL links. Lower MTU would allow >>> lower TX latency for high priority packets when upstream is saturated, >>> yet large MRU on the downstream would be great for downloads. >>> >>> Right now with 6.2 one has to trade off lower latency for faster >>> download. >>> >>> --Artem >>> >> >> You can prioritize small packets with ACKs, for example, by other >> techniques - ALTQ one of them. >> Unconditional lovering MTU even on ADSL tend to loss throughtput. >> >> And let's think about TCP MSS. When TCP connection establishes, >> TCP stack uses MTU as measure to choose MSS. >> >> Any two hosts, connected to single Layer2 network MUST use >> same MTU. Any other cases lead to hard-to-solve problems. >> >> This is all IMHO. But I would not like to see different >> MTU and MRU on my Ethernet interfaces! :) >> >> >> > Yes but the mss is what the endpoints in the connection know about their > own mtu's, > at this point there is no knowledge of the mtu/mru's of intermediate > routers. > > Steve > Why? When two endpoints negotiated tcp connections they do know about remote mss - maximum segment that remote side can receive. PMTU is little bit anothr problem of misconfiguration on firewalls and intermediate routers. Very common situation when users block whole ICMP protocol on their router/host while connects to Internet via PPPoE/PPTP. -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Sun Jul 22 15:24:53 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37E3016A417 for ; Sun, 22 Jul 2007 15:24:53 +0000 (UTC) (envelope-from m_wlist@weirdwire.ru) Received: from weirdwire.ru (weirdwire.ru [85.118.229.210]) by mx1.freebsd.org (Postfix) with ESMTP id 45D1613C442 for ; Sun, 22 Jul 2007 15:24:51 +0000 (UTC) (envelope-from m_wlist@weirdwire.ru) Received: from mail.weirdwire.ru (localhost [127.0.0.1]) by weirdwire.ru (Postfix) with ESMTP id AA9151D1C82 for ; Sun, 22 Jul 2007 22:07:24 +0700 (NOVST) Received: from 10.23.23.1 (SquirrelMail authenticated user m_wlist) by mail.weirdwire.ru with HTTP; Sun, 22 Jul 2007 22:07:24 +0700 (NOVST) Message-ID: <51976.10.23.23.1.1185116844.squirrel@mail.weirdwire.ru> Date: Sun, 22 Jul 2007 22:07:24 +0700 (NOVST) From: m_wlist@weirdwire.ru To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal References: In-Reply-To: In-Reply-To: Subject: Policy-based routing for packets originating from local machine ('reinject' packets back into kernel?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2007 15:24:53 -0000 Hello. I have a FreeBSD machine connected to internal network and several ISPs. I have set up (with pf) nat and balanced (policy-based) routing for machines from internal network, proper routing for remote connections to interfaces that connected to corresponding ISPs. One thing that I can't manage to get done is to make balanced routing to work with packets originating from the router itself. Simple pf route-to rules don't work as it seems local packets don't have any 'in' interface -- they just emerge somewhere in kernel just before routing table and when they are accessible to pf they are already in 'out' part where policy routing is not possible (the packet are already going out on interface that is determined from rather static routing table). When there are no default route in routing table packets just have nowhere to go and fail not even reaching any pf rules. I suddenly came up with an idea how to try to get that done -- somehow 'reinject' packets back into kernel to get them processed by 'in' rule with 'route-to'. The idea sounds quite simple -- make some virtual interface with non-existing address and subnet and make default route be somewhere in that subnet. Then make another virtual interface and bridge/connect (with netgraph for example) it to first one the way that any packets sent out to first one appear back in on second. The question number one: Is there any less retarded way to do PBR for local packets? The question number two: How to do that properly? At the moment I'm trying to get that working with netgraph's ngeth interfaces. But they seem to behave in some really weird way. Details: # ifconfig ngeth0 10.42.42.1 netmask 255.255.255.250 # ngctl connect ngeth0: ngeth1: lower upper # ngctl connect ngeth1: ngeth0: lower upper ('tcpdump -ni ngeth0' on other terminal for great justice) # ping 10.42.42.2 (here after some delay I get 'host is down' messages with no output from tcpdump). # ping 10.42.42.5 (broadcast address, gives nothing from ping, and 'blal blah 10.42.42.1 > 10.42.42.5: ICMP echo request, blah' from tcpdump) (here i change tcpdump from ngeth0 to ngeth1) # ping 10.42.42.2 and # ping 10.42.42.3 give 'host is down' from ping and nothing from tcpdump # ping 10.42.42.4 (LOL WUT!) still gives 'host is down' from ping, but tcpdump -ni ngeth1 gives 'arp who-has 10.42.42.4 tell 10.42.42.1'! That raises two questins: 1) Wtf is going on? 2) How to make ngeth just send ip packet, avoiding that arp stuff (or is there any other virtual interface devices available that do that)? Seems like I don't understand something completely. From owner-freebsd-net@FreeBSD.ORG Sun Jul 22 15:43:51 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6279216A41A for ; Sun, 22 Jul 2007 15:43:51 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 4047513C4B7 for ; Sun, 22 Jul 2007 15:43:51 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 945B38C56 for ; Sun, 22 Jul 2007 11:24:01 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 22 Jul 2007 11:24:01 -0400 X-Sasl-enc: q3CZ1pvRzgrYcJYfsK3VdRdIwgpi7ODVJs5vyEny6zIS 1185117841 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 40B5D37B1 for ; Sun, 22 Jul 2007 11:24:01 -0400 (EDT) Message-ID: <46A37690.1010100@incunabulum.net> Date: Sun, 22 Jul 2007 16:24:00 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: FreeBSD-Net mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Call for testers: multicast forwarding X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2007 15:43:51 -0000 Hi, I may have some commercial work coming up which requires me to make modifications to the IPv4 multicast forwarding code in Linux. It is likely I will prototype the work in FreeBSD. It will probably not be released publicly. To prepare for this I have started cleaning up the MROUTING code; using more appropriate data structures, working on removal of the 32 vif limitation and other refinements, removal of legacy code which is no longer useful. I'd like to hear from anyone using multicast forwarding on FreeBSD who would be interested in testing these changes and suggesting other improvements.. They will most likely not make the 7.0 release but may appear in future versions. Code is not yet available as a patch set. I am working in the p4 branch bms_netdev. regards, BMS P.S. It would be good if there were a way of giving the general public read-only access to the p4 tree, this is becoming a blocking limitation of the tool for open development. From owner-freebsd-net@FreeBSD.ORG Sun Jul 22 15:44:18 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0B1116A419 for ; Sun, 22 Jul 2007 15:44:18 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.freebsd.org (Postfix) with ESMTP id 5269613C459 for ; Sun, 22 Jul 2007 15:44:18 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from fox.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by bsd.dino.sk with esmtp; Sun, 22 Jul 2007 17:46:11 +0200 id 00000038.46A37BC3.0000C003 From: Milan Obuch To: freebsd-net@freebsd.org Date: Sun, 22 Jul 2007 17:44:10 +0200 User-Agent: KMail/1.9.6 References: <51976.10.23.23.1.1185116844.squirrel@mail.weirdwire.ru> In-Reply-To: <51976.10.23.23.1.1185116844.squirrel@mail.weirdwire.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707221744.11119.freebsd-net@dino.sk> Subject: Re: Policy-based routing for packets originating from local machine ('reinject' packets back into kernel?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2007 15:44:18 -0000 On Sunday 22 July 2007, m_wlist@weirdwire.ru wrote: > Hello. > ... > > At the moment I'm trying to get that working with netgraph's ngeth > interfaces. But they seem to behave in some really weird way. > Details: > # ifconfig ngeth0 10.42.42.1 netmask 255.255.255.250 Netmask 255.255.255.250 looks weird to me. Something like this is really unusual. What does ifconfig ngeth0 show? > # ngctl connect ngeth0: ngeth1: lower upper > # ngctl connect ngeth1: ngeth0: lower upper > ('tcpdump -ni ngeth0' on other terminal for great justice) > # ping 10.42.42.2 > (here after some delay I get 'host is down' messages with no output from > tcpdump). > # ping 10.42.42.5 > (broadcast address, gives nothing from ping, and 'blal blah 10.42.42.1 > > 10.42.42.5: ICMP echo request, blah' from tcpdump) > (here i change tcpdump from ngeth0 to ngeth1) > # ping 10.42.42.2 and # ping 10.42.42.3 > give 'host is down' from ping and nothing from tcpdump > # ping 10.42.42.4 > (LOL WUT!) still gives 'host is down' from ping, but tcpdump -ni ngeth1 > gives 'arp who-has 10.42.42.4 tell 10.42.42.1'! > > That raises two questins: > 1) Wtf is going on? > 2) How to make ngeth just send ip packet, avoiding that arp stuff (or is > there any other virtual interface devices available that do that)? > I can't comment on these question, but my recommendation would be to choose more usual mask - if it's not a typo, this could cause various interesting errors. Regards, Milan -- This address is used only for mailing list response. Do not send any personal messages to it, use milan in address instead. From owner-freebsd-net@FreeBSD.ORG Sun Jul 22 18:09:46 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DACD816A417 for ; Sun, 22 Jul 2007 18:09:46 +0000 (UTC) (envelope-from netslists@gmail.com) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.241]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4D613C457 for ; Sun, 22 Jul 2007 18:09:46 +0000 (UTC) (envelope-from netslists@gmail.com) Received: by ag-out-0708.google.com with SMTP id 35so1283555aga for ; Sun, 22 Jul 2007 11:09:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hLgS1oP6nCvJ200Mo08i9XlylXimHJvnxW/dO3a2yeSm4o6uolZqi0J0gQRypKqETcFBRfWXqpjrYO9qDfMrIllQWEb9LOtssvwZ9CKIwRIWx1BQZKNjtvPboIWLE9uTEpfAqv7fPDM5U2rNTcbWsIQvNEZXN1Bcxx8E2cNWGOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=QX9EDAHWP75XsYn/6SBGvZdyF+IlOOYIKl1ueKuTBF48v+EVq7jpNgYj6yFzs18F6GejjrgmbKHUu7Z74JOMQktjOQwx1mlvS6Rt/ZfqMR8LegaQanHxg8TGfuDzUzYd1ENydqNpSr1raXdAgVB3w7+xUhnJLSTFJIGAUG2UgG8= Received: by 10.70.87.11 with SMTP id k11mr4282565wxb.1185127785072; Sun, 22 Jul 2007 11:09:45 -0700 (PDT) Received: from ?192.168.12.8? ( [72.189.172.75]) by mx.google.com with ESMTPS id r28sm3887068ele.2007.07.22.11.09.44 (version=SSLv3 cipher=RC4-MD5); Sun, 22 Jul 2007 11:09:44 -0700 (PDT) Message-ID: <46A39D67.5030900@gmail.com> Date: Sun, 22 Jul 2007 20:09:43 +0200 From: Sten Daniel Soersdal User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: karels@karels.net References: <200707211702.l6LH2ukt039317@redrock.karels.net> In-Reply-To: <200707211702.l6LH2ukt039317@redrock.karels.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Artyom Viklenko , Artem Belevich , Julian Elischer Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2007 18:09:46 -0000 Mike Karels wrote: >> Any two hosts, connected to single Layer2 network MUST use >> same MTU. Any other cases lead to hard-to-solve problems. > > I'd have to disagree. In fact, I'd say that any two hosts on the > same L2 network must use the same MRU. In particular, if a host > choses to use a lower MTU, if that also lowers the MRU, *that* is > the cause of interoperability problems. > > David DeSimone wrote: > } You are correct about misconfigured networks. In my experience, > } the only reason to ever reduce the MTU is to work around a problem > } discovered in someone else's network (not my local segment). Fixing > } the problem by getting someone else to fix their network is generally > } too hard. If MTU == MRU was forced behavior, the viability of this > } workaround would be removed, one less tool in the toolbag, so to speak. > > Exactly. In our local labs, we also reduce the MTU to test PMTU discovery. > Requiring MRU == MTU makes this more difficult. True, it's a contrived > situation, but as you say, one less tool in the toolbag. > > Mike To leave this tool in the toolbag one could set interface mtu to the upperbounds of what one needs (e.g. 1500) and use pr route --mtu setting to work around those broken networks. That shouldn't break the inbound oversized frames (frames smaller than 1500) but lower the outbound mtu. -- Sten Daniel Soersdal From owner-freebsd-net@FreeBSD.ORG Sun Jul 22 20:08:53 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAFD916A417 for ; Sun, 22 Jul 2007 20:08:53 +0000 (UTC) (envelope-from m_wlist@weirdwire.ru) Received: from weirdwire.ru (weirdwire.ru [85.118.229.210]) by mx1.freebsd.org (Postfix) with ESMTP id 731F313C4B4 for ; Sun, 22 Jul 2007 20:08:51 +0000 (UTC) (envelope-from m_wlist@weirdwire.ru) Received: from mail.weirdwire.ru (localhost [127.0.0.1]) by weirdwire.ru (Postfix) with ESMTP id 3DF431D1C82; Mon, 23 Jul 2007 03:08:43 +0700 (NOVST) Received: from 10.23.23.1 (SquirrelMail authenticated user m_wlist) by mail.weirdwire.ru with HTTP; Mon, 23 Jul 2007 03:08:44 +0700 (NOVST) Message-ID: <52002.10.23.23.1.1185134924.squirrel@mail.weirdwire.ru> In-Reply-To: <200707221744.11119.freebsd-net@dino.sk> References: <51976.10.23.23.1.1185116844.squirrel@mail.weirdwire.ru> <200707221744.11119.freebsd-net@dino.sk> Date: Mon, 23 Jul 2007 03:08:44 +0700 (NOVST) From: m_wlist@weirdwire.ru To: "Milan Obuch" User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-net@freebsd.org Subject: Re: Policy-based routing for packets originating from local machine ('reinject' packets back into kernel?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jul 2007 20:08:54 -0000 > On Sunday 22 July 2007, m_wlist@weirdwire.ru wrote: >> At the moment I'm trying to get that working with netgraph's ngeth >> interfaces. But they seem to behave in some really weird way. >> Details: >> # ifconfig ngeth0 10.42.42.1 netmask 255.255.255.250 > > Netmask 255.255.255.250 looks weird to me. Something like this is really > unusual. What does ifconfig ngeth0 show? Oh. Yes, that was a typo in command that I've copypasted here. Thank you for pointing to that. >> # ngctl connect ngeth0: ngeth1: lower upper >> # ngctl connect ngeth1: ngeth0: lower upper >> ('tcpdump -ni ngeth0' on other terminal for great justice) >> # ping 10.42.42.2 >> (here after some delay I get 'host is down' messages with no output from >> tcpdump). >> # ping 10.42.42.5 >> (broadcast address, gives nothing from ping, and 'blal blah 10.42.42.1 > >> 10.42.42.5: ICMP echo request, blah' from tcpdump) >> (here i change tcpdump from ngeth0 to ngeth1) >> # ping 10.42.42.2 and # ping 10.42.42.3 >> give 'host is down' from ping and nothing from tcpdump >> # ping 10.42.42.4 >> (LOL WUT!) still gives 'host is down' from ping, but tcpdump -ni ngeth1 >> gives 'arp who-has 10.42.42.4 tell 10.42.42.1'! >> >> That raises two questins: >> 1) Wtf is going on? >> 2) How to make ngeth just send ip packet, avoiding that arp stuff (or is >> there any other virtual interface devices available that do that)? >> > > I can't comment on these question, but my recommendation would be to > choose > more usual mask - if it's not a typo, this could cause various interesting > errors. Now It looks more sane -- arp messages appear on trying to ping every (except first that belongs to ngeth0) ip in that subnet. So the second question is still open. From owner-freebsd-net@FreeBSD.ORG Mon Jul 23 04:48:05 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE1F016A418 for ; Mon, 23 Jul 2007 04:48:04 +0000 (UTC) (envelope-from netslists@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by mx1.freebsd.org (Postfix) with ESMTP id 5724113C45A for ; Mon, 23 Jul 2007 04:48:04 +0000 (UTC) (envelope-from netslists@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1224153wxd for ; Sun, 22 Jul 2007 21:48:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=iT2Az6ABYHuYREXj7dbofkQQUXGcerL/iPToX2Z4j7iiGOU8JguXTqun173A/jSVgnq4EcZrWyRWJ7wsW6mo2gOPvrC47Q/mkZueWgNryMrBXprxLJdLwiNN/amWnqAPKvIAurNkzifBqhSZFCVslypDgm2jP5R8eWAODY85kb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=VyilgkGLYIVPXH0loil7a7MvMFqTiXXFdpT3fmBQSDXl/IT3zw4izIY70cWC1wwAikCxcGvRohcdSX3gpmg7kbjlebApuCqlrbugTTSC64M29p1BB9C/hBRnJ71sCw5Z4osCyF8biij+3X+Pz+NZ7Jdz7cFWnWkarCmKNw6ObSU= Received: by 10.70.9.8 with SMTP id 8mr4942003wxi.1185166083426; Sun, 22 Jul 2007 21:48:03 -0700 (PDT) Received: from ?192.168.12.8? ( [72.189.172.75]) by mx.google.com with ESMTPS id u25sm4531722ele.2007.07.22.21.48.02 (version=SSLv3 cipher=RC4-MD5); Sun, 22 Jul 2007 21:48:02 -0700 (PDT) Message-ID: <46A432FE.8000100@gmail.com> Date: Mon, 23 Jul 2007 06:47:58 +0200 From: Sten Daniel Soersdal User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: m_wlist@weirdwire.ru References: In-Reply-To: <51976.10.23.23.1.1185116844.squirrel@mail.weirdwire.ru> In-Reply-To: <51976.10.23.23.1.1185116844.squirrel@mail.weirdwire.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Policy-based routing for packets originating from local machine ('reinject' packets back into kernel?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jul 2007 04:48:05 -0000 m_wlist@weirdwire.ru wrote: > Hello. > > I have a FreeBSD machine connected to internal network and several ISPs. I > have set up (with pf) nat and balanced (policy-based) routing for machines > from internal network, proper routing for remote connections to interfaces > that connected to corresponding ISPs. > > One thing that I can't manage to get done is to make balanced routing to > work with packets originating from the router itself. Simple pf route-to > rules don't work as it seems local packets don't have any 'in' interface > -- they just emerge somewhere in kernel just before routing table and when > they are accessible to pf they are already in 'out' part where policy > routing is not possible (the packet are already going out on interface > that is determined from rather static routing table). > When there are no default route in routing table packets just have nowhere > to go and fail not even reaching any pf rules. > > I suddenly came up with an idea how to try to get that done -- somehow > 'reinject' packets back into kernel to get them processed by 'in' rule > with 'route-to'. The idea sounds quite simple -- make some virtual > interface with non-existing address and subnet and make default route be > somewhere in that subnet. Then make another virtual interface and > bridge/connect (with netgraph for example) it to first one the way that > any packets sent out to first one appear back in on second. > > The question number one: Is there any less retarded way to do PBR for > local packets? > The question number two: How to do that properly? > > At the moment I'm trying to get that working with netgraph's ngeth > interfaces. But they seem to behave in some really weird way. > Details: > # ifconfig ngeth0 10.42.42.1 netmask 255.255.255.250 > # ngctl connect ngeth0: ngeth1: lower upper > # ngctl connect ngeth1: ngeth0: lower upper > ('tcpdump -ni ngeth0' on other terminal for great justice) > # ping 10.42.42.2 > (here after some delay I get 'host is down' messages with no output from > tcpdump). > # ping 10.42.42.5 > (broadcast address, gives nothing from ping, and 'blal blah 10.42.42.1 > > 10.42.42.5: ICMP echo request, blah' from tcpdump) > (here i change tcpdump from ngeth0 to ngeth1) > # ping 10.42.42.2 and # ping 10.42.42.3 > give 'host is down' from ping and nothing from tcpdump > # ping 10.42.42.4 > (LOL WUT!) still gives 'host is down' from ping, but tcpdump -ni ngeth1 > gives 'arp who-has 10.42.42.4 tell 10.42.42.1'! > > That raises two questins: > 1) Wtf is going on? > 2) How to make ngeth just send ip packet, avoiding that arp stuff (or is > there any other virtual interface devices available that do that)? > > Seems like I don't understand something completely. Perhaps i'm not following completely but wouldn't this normally be the job of the loopback interface? I may be wrong about the specifics, as i haven't done this in many many years and i used ipfw on 4.x which may or may not be using different "paths". Basically you could route the default route to a loopback interface ip (127.0.0.1??) and it should, theoretically, exit and enter lo0. *If* lo0 is clonable in some way you should be able to create additional loopbacks if necessary (kernel compiletime?) in case you want to skip filter checks on lo0 specifically or just want to see how twisted it can all turn out. -- Sten Daniel Soersdal From owner-freebsd-net@FreeBSD.ORG Mon Jul 23 11:08:28 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D833516A49C for ; Mon, 23 Jul 2007 11:08:28 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A3D3913C474 for ; Mon, 23 Jul 2007 11:08:28 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l6NB8Sx8045392 for ; Mon, 23 Jul 2007 11:08:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l6NB8Ro8045389 for freebsd-net@FreeBSD.org; Mon, 23 Jul 2007 11:08:27 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Jul 2007 11:08:27 GMT Message-Id: <200707231108.l6NB8Ro8045389@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2007 11:08:28 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi o kern/110959 net [ipsec] Filtering incoming packets with enc0 does not o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net IP v4 udp fragmented packet reject o kern/113359 net [ipv6] panic sbdrop after ICMP6, packet too big o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi 16 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/103253 net inconsistent behaviour in arp reply of a bridge o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/112612 net [lo] Traffic via additional lo(4) interface shows up o o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/114095 net [carp] carp+pf delay with high state limit 14 problems total. From owner-freebsd-net@FreeBSD.ORG Tue Jul 24 11:42:52 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BA9D16A417 for ; Tue, 24 Jul 2007 11:42:52 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from mx17.bluewin.ch (mx17.bluewin.ch [195.186.18.35]) by mx1.freebsd.org (Postfix) with ESMTP id 2B5F813C45D for ; Tue, 24 Jul 2007 11:42:52 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from hbnnbsddev03.sharedtcs.net (213.3.8.216) by mx17.bluewin.ch (Bluewin 7.3.122) id 46A542BE000C857D for freebsd-net@freebsd.org; Tue, 24 Jul 2007 11:42:50 +0000 Received: from hbnnbsddev03.sharedtcs.net (localhost.sharedtcs.net [127.0.0.1]) by hbnnbsddev03.sharedtcs.net (8.13.8/8.13.8) with ESMTP id l6OBkQAN061734 for ; Tue, 24 Jul 2007 13:46:26 +0200 (CEST) (envelope-from tbeoepa1@hbnnbsddev03.sharedtcs.net) Received: (from tbeoepa1@localhost) by hbnnbsddev03.sharedtcs.net (8.13.8/8.13.8/Submit) id l6OBkQtD061733 for freebsd-net@freebsd.org; Tue, 24 Jul 2007 13:46:26 +0200 (CEST) (envelope-from tbeoepa1) Date: Tue, 24 Jul 2007 13:46:26 +0200 From: Patrick Oeschger To: freebsd-net@freebsd.org Message-ID: <20070724114626.GA61209@hbnnbsddev03.sharedtcs.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20070717110156.GA37722@hbnnbsddev03.sharedtcs.net> <2a41acea0707170917n56e35cfbyc6e0bca094bfa729@mail.gmail.com> <20070718063801.GA40653@hbnnbsddev03.sharedtcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070718063801.GA40653@hbnnbsddev03.sharedtcs.net> User-Agent: Mutt/1.4.2.1i Subject: Re: em(4)/82571eb: fifo not dma'ed to host memory X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jul 2007 11:42:52 -0000 OK - found the problem the driver in 6.2-RELEASE has different code in em_identify_hardware my hardware needs the memory access and bus master bits getting set by the driver beginning with 6.2-RELEASE this gets only set if PCIM_CMD_BUSMASTEREN is *not set* and PCIM_CMD_MEMEN is *set* - it seems the 82571EB has both parameters *not set* after init is this a bug? feature? typo? --- /root/em/if_em.c.61 Mon Jul 23 12:17:35 2007 +++ if_em.c.62 Tue Jul 24 13:04:11 2007 static void -em_identify_hardware(struct adapter * adapter) +em_identify_hardware(struct adapter *adapter) { device_t dev = adapter->dev; /* Make sure our PCI config space has the necessary stuff set */ adapter->hw.pci_cmd_word = pci_read_config(dev, PCIR_COMMAND, 2); - if (!((adapter->hw.pci_cmd_word & PCIM_CMD_BUSMASTEREN) && - (adapter->hw.pci_cmd_word & PCIM_CMD_MEMEN))) { - printf("em%d: Memory Access and/or Bus Master bits were not set! \n", - adapter->unit); + if ((adapter->hw.pci_cmd_word & PCIM_CMD_BUSMASTEREN) == 0 && + (adapter->hw.pci_cmd_word & PCIM_CMD_MEMEN)) { + device_printf(dev, "Memory Access and/or Bus Master bits " + "were not set!\n"); adapter->hw.pci_cmd_word |= (PCIM_CMD_BUSMASTEREN | PCIM_CMD_MEMEN); - pci_write_config(dev, PCIR_COMMAND, adapter->hw.pci_cmd_word, 2) ; + pci_write_config(dev, PCIR_COMMAND, + adapter->hw.pci_cmd_word, 2); } > thanks for your feedback jack - i tried the MSI stuff as first task this > morning > the interface init'ed without a problem and did not complain about MSI > what i like most is that no IRQ is assigned now, everything seems to get > handled in a TASKQ (IRQs were quite weird sometimes when having a bunch of > interfaces...) > > but now the bad news: even with MSI it is not possible to recv any frames > what makes me curious is, that the head pointer for receive fifo is *not* > counting up after receiving a frame (good_packets counter incrementing) > as far as i understand the 82571EB chipset manual, recv head counter inc > is done in hardware after receiving a good_packet and having dma'ed it to > host memory > from if_em.c/em_process_receive_interrupts: > * This routine executes in interrupt context. It replenishes > * the mbufs in the descriptor and sends data which has been > * dma'ed into host memory to upper layer. > > i did a quick test to check this on 6.1-RELENG by inserting a return > at the top of em_process_receive_interrupts (see diff) > register RDH0 is still incrementing for each good_packet received - even > without receive interrupts being processed at the driver level > > freebsd61# sysctl dev.em.0.debug_info=1 > dev.em.0.debug_iemnfo: 0:-1 Adapter hardware address = 0xc4b7c928 > em0: CTRL = 0x81c0241 RCTL = 0x8002 > em0: RDBAH0 = 0x0 RDBAL0 = 0x3e0ff000 > em0: RDLEN0 = 0x1000 RDH0 = 0x3 > em0: RDT0 = 0xff RXDCTL = 0x10000 > > ...so IMHO this increment (and also dma transfer to host memory) is done > in hardware - RDH0 is not counting up when running under 7.0-CURRENT... > > erroneous init of chipset? > anyone else running 7.0-CURRENT on a 82571EB pci express chipset? > > TIA for any help on this > pat > > details for dmesg/if_stats/diff: > > pcib9: irq 19 at device 11.0 on pci2 > pcib9: secondary bus 9 > pcib9: subordinate bus 9 > pcib9: I/O decode 0x6000-0x6fff > pcib9: memory decode 0xfd700000-0xfd7fffff > pcib9: prefetched decode 0xfce00000-0xfcefffff > pci9: on pcib9 > pci9: physical bus=9 > found-> vendor=0x8086, dev=0x105e, revid=0x06 > bus=9, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory disabled > map[14]: type Memory, range 32, base 0, size 17, memory disabled > map[18]: type I/O Port, range 32, base 0, size 5, port disabled > found-> vendor=0x8086, dev=0x105e, revid=0x06 > bus=9, slot=0, func=1 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0, size 17, memory disabled > map[14]: type Memory, range 32, base 0, size 17, memory disabled > map[18]: type I/O Port, range 32, base 0, size 5, port disabled > em0: at device > 0.0 on pci9 > pcib9: em0 requested memory range 0xfd700000-0xfd7fffff: good > pcib2: em0 requested memory range 0xfd700000-0xfd7fffff: good > pcib1: em0 requested memory range 0xfd700000-0xfd7fffff: good > em0: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at 0xfd700000 > em0: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 256 to vector 49 > em0: using IRQ 256 for MSI > em0: bpf attached > em0: Ethernet address: 00:10:f3:0c:5b:2a > em0: [FILTER] > pci9: at device 0.1 (no driver attached) > > freebsd61# diff -u sys/dev/em/if_em.c.orig sys/dev/em/if_em.c > --- sys/dev/em/if_em.c.orig Wed Jul 18 07:32:53 2007 > +++ sys/dev/em/if_em.c Wed Jul 18 07:48:42 2007 > @@ -277,6 +277,11 @@ > > INIT_DEBUGOUT("em_probe: begin"); > > + // prevent init of all em(4) devices except pci9/0/0 > + if(pci_get_bus(dev) != 0x09 || pci_get_slot(dev) != 0x00 || > + pci_get_function(dev) != 0x00) > + return (ENXIO); > + > pci_vendor_id = pci_get_vendor(dev); > if (pci_vendor_id != EM_VENDOR_ID) > return(ENXIO); > @@ -2906,6 +2911,8 @@ > u_int8_t eop = 0; > u_int16_t len, desc_len, prev_len_adj; > int i; > + > + return; > > /* Pointer to the receive descriptor being examined. */ > struct em_rx_desc *current_desc; > > On Tue, Jul 17, 2007 at 09:17:36AM -0700, Jack Vogel wrote: > > As an experiment, search in if_em.c for 'msix' look at the logic there. > > If the adapter is 82575 it will use msix, but the else clause has it > > use msi ONLY if its '>82571', change that to >=82571 and let's > > see if maybe using MSI will help you with your problems as I'm > > pretty confident its interrupt related. > > > > I had intended on making this change shortly anyway, my tests > > have shown the 571 to work fine this way. > > > > Let me know of the results. > > > > Jack From owner-freebsd-net@FreeBSD.ORG Tue Jul 24 16:25:51 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B16816A41A for ; Tue, 24 Jul 2007 16:25:51 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239]) by mx1.freebsd.org (Postfix) with ESMTP id 28FDD13C478 for ; Tue, 24 Jul 2007 16:25:51 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1314507nzf for ; Tue, 24 Jul 2007 09:25:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VAfcmt7J7qAOb3EiLEAHQS8ev9agF01yAl3mNhPGJwD4jndDlTVf2LI2E/r+xxTlyk/bhDtLCluG++z2Bv2uG/MLtF8fIEi0u4JeRf6P3J7EwBbKEXJCQmTcYA+Aqm+Vcw60F7a/1QCT96SqzE+qklpBhvFyr/oOZS9k1P+RrEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rQoteS3oRa1u91Xz9QpR/cgx0qilp9QFG3FuZXQmd86LAM9+i4HhJWgQWgeDMW7u2hr5lPm1vmFimeUPqQY3qPfkTfph+3iA+lfWVGgJd0m2wcQtCm9YQSlxg217pX3TulfwuigkcE/FuVsYw6Ik/SHm1SNjJ0MvPD+ZK8K4uN8= Received: by 10.114.152.17 with SMTP id z17mr4197191wad.1185294349775; Tue, 24 Jul 2007 09:25:49 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Tue, 24 Jul 2007 09:25:49 -0700 (PDT) Message-ID: <2a41acea0707240925q6a4faef5r893cec8ad13ca7d9@mail.gmail.com> Date: Tue, 24 Jul 2007 09:25:49 -0700 From: "Jack Vogel" To: freebsd-net@freebsd.org In-Reply-To: <20070724114626.GA61209@hbnnbsddev03.sharedtcs.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070717110156.GA37722@hbnnbsddev03.sharedtcs.net> <2a41acea0707170917n56e35cfbyc6e0bca094bfa729@mail.gmail.com> <20070718063801.GA40653@hbnnbsddev03.sharedtcs.net> <20070724114626.GA61209@hbnnbsddev03.sharedtcs.net> Subject: Re: em(4)/82571eb: fifo not dma'ed to host memory X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jul 2007 16:25:51 -0000 Hmmm, this looks like a bug, I will look more closely today. Sorry I have not been able to be more active with your problem, but things have been hectic with product launches and my own internal bug fixing. I will try to get this turned around quickly Patrick. Jack On 7/24/07, Patrick Oeschger wrote: > OK - found the problem > the driver in 6.2-RELEASE has different code in em_identify_hardware > my hardware needs the memory access and bus master bits getting set by > the driver > beginning with 6.2-RELEASE this gets only set if PCIM_CMD_BUSMASTEREN is > *not set* and PCIM_CMD_MEMEN is *set* - it seems the 82571EB has both > parameters *not set* after init > is this a bug? feature? typo? > > --- /root/em/if_em.c.61 Mon Jul 23 12:17:35 2007 > +++ if_em.c.62 Tue Jul 24 13:04:11 2007 > static void > -em_identify_hardware(struct adapter * adapter) > +em_identify_hardware(struct adapter *adapter) > { > device_t dev = adapter->dev; > > /* Make sure our PCI config space has the necessary stuff set */ > adapter->hw.pci_cmd_word = pci_read_config(dev, PCIR_COMMAND, 2); > - if (!((adapter->hw.pci_cmd_word & PCIM_CMD_BUSMASTEREN) && > - (adapter->hw.pci_cmd_word & PCIM_CMD_MEMEN))) { > - printf("em%d: Memory Access and/or Bus Master bits were not set! > \n", > - adapter->unit); > + if ((adapter->hw.pci_cmd_word & PCIM_CMD_BUSMASTEREN) == 0 && > + (adapter->hw.pci_cmd_word & PCIM_CMD_MEMEN)) { > + device_printf(dev, "Memory Access and/or Bus Master bits " > + "were not set!\n"); > adapter->hw.pci_cmd_word |= > (PCIM_CMD_BUSMASTEREN | PCIM_CMD_MEMEN); > - pci_write_config(dev, PCIR_COMMAND, adapter->hw.pci_cmd_word, 2) > ; > + pci_write_config(dev, PCIR_COMMAND, > + adapter->hw.pci_cmd_word, 2); > } > > > thanks for your feedback jack - i tried the MSI stuff as first task this > > morning > > the interface init'ed without a problem and did not complain about MSI > > what i like most is that no IRQ is assigned now, everything seems to get > > handled in a TASKQ (IRQs were quite weird sometimes when having a bunch of > > interfaces...) > > > > but now the bad news: even with MSI it is not possible to recv any frames > > what makes me curious is, that the head pointer for receive fifo is *not* > > counting up after receiving a frame (good_packets counter incrementing) > > as far as i understand the 82571EB chipset manual, recv head counter inc > > is done in hardware after receiving a good_packet and having dma'ed it to > > host memory > > from if_em.c/em_process_receive_interrupts: > > * This routine executes in interrupt context. It replenishes > > * the mbufs in the descriptor and sends data which has been > > * dma'ed into host memory to upper layer. > > > > i did a quick test to check this on 6.1-RELENG by inserting a return > > at the top of em_process_receive_interrupts (see diff) > > register RDH0 is still incrementing for each good_packet received - even > > without receive interrupts being processed at the driver level > > > > freebsd61# sysctl dev.em.0.debug_info=1 > > dev.em.0.debug_iemnfo: 0:-1 Adapter hardware address = 0xc4b7c928 > > em0: CTRL = 0x81c0241 RCTL = 0x8002 > > em0: RDBAH0 = 0x0 RDBAL0 = 0x3e0ff000 > > em0: RDLEN0 = 0x1000 RDH0 = 0x3 > > em0: RDT0 = 0xff RXDCTL = 0x10000 > > > > ...so IMHO this increment (and also dma transfer to host memory) is done > > in hardware - RDH0 is not counting up when running under 7.0-CURRENT... > > > > erroneous init of chipset? > > anyone else running 7.0-CURRENT on a 82571EB pci express chipset? > > > > TIA for any help on this > > pat > > > > details for dmesg/if_stats/diff: > > > > pcib9: irq 19 at device 11.0 on pci2 > > pcib9: secondary bus 9 > > pcib9: subordinate bus 9 > > pcib9: I/O decode 0x6000-0x6fff > > pcib9: memory decode 0xfd700000-0xfd7fffff > > pcib9: prefetched decode 0xfce00000-0xfcefffff > > pci9: on pcib9 > > pci9: physical bus=9 > > found-> vendor=0x8086, dev=0x105e, revid=0x06 > > bus=9, slot=0, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=255 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message, 64 bit > > map[10]: type Memory, range 32, base 0, size 17, memory disabled > > map[14]: type Memory, range 32, base 0, size 17, memory disabled > > map[18]: type I/O Port, range 32, base 0, size 5, port disabled > > found-> vendor=0x8086, dev=0x105e, revid=0x06 > > bus=9, slot=0, func=1 > > class=02-00-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=255 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message, 64 bit > > map[10]: type Memory, range 32, base 0, size 17, memory disabled > > map[14]: type Memory, range 32, base 0, size 17, memory disabled > > map[18]: type I/O Port, range 32, base 0, size 5, port disabled > > em0: at device > > 0.0 on pci9 > > pcib9: em0 requested memory range 0xfd700000-0xfd7fffff: good > > pcib2: em0 requested memory range 0xfd700000-0xfd7fffff: good > > pcib1: em0 requested memory range 0xfd700000-0xfd7fffff: good > > em0: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at 0xfd700000 > > em0: attempting to allocate 1 MSI vectors (1 supported) > > msi: routing MSI IRQ 256 to vector 49 > > em0: using IRQ 256 for MSI > > em0: bpf attached > > em0: Ethernet address: 00:10:f3:0c:5b:2a > > em0: [FILTER] > > pci9: at device 0.1 (no driver attached) > > > > freebsd61# diff -u sys/dev/em/if_em.c.orig sys/dev/em/if_em.c > > --- sys/dev/em/if_em.c.orig Wed Jul 18 07:32:53 2007 > > +++ sys/dev/em/if_em.c Wed Jul 18 07:48:42 2007 > > @@ -277,6 +277,11 @@ > > > > INIT_DEBUGOUT("em_probe: begin"); > > > > + // prevent init of all em(4) devices except pci9/0/0 > > + if(pci_get_bus(dev) != 0x09 || pci_get_slot(dev) != 0x00 || > > + pci_get_function(dev) != 0x00) > > + return (ENXIO); > > + > > pci_vendor_id = pci_get_vendor(dev); > > if (pci_vendor_id != EM_VENDOR_ID) > > return(ENXIO); > > @@ -2906,6 +2911,8 @@ > > u_int8_t eop = 0; > > u_int16_t len, desc_len, prev_len_adj; > > int i; > > + > > + return; > > > > /* Pointer to the receive descriptor being examined. */ > > struct em_rx_desc *current_desc; > > > > On Tue, Jul 17, 2007 at 09:17:36AM -0700, Jack Vogel wrote: > > > As an experiment, search in if_em.c for 'msix' look at the logic there. > > > If the adapter is 82575 it will use msix, but the else clause has it > > > use msi ONLY if its '>82571', change that to >=82571 and let's > > > see if maybe using MSI will help you with your problems as I'm > > > pretty confident its interrupt related. > > > > > > I had intended on making this change shortly anyway, my tests > > > have shown the 571 to work fine this way. > > > > > > Let me know of the results. > > > > > > Jack > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Jul 24 17:10:15 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13B3916A420 for ; Tue, 24 Jul 2007 17:10:15 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.232]) by mx1.freebsd.org (Postfix) with ESMTP id B7F8513C4A6 for ; Tue, 24 Jul 2007 17:10:14 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1325420nzf for ; Tue, 24 Jul 2007 10:10:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rOatzA+bvCY0xiyylBhYW/Uv8bmZdPNgSR6Jy4ZoAolr4iqupjuT9cN+fa8JOJbrjvMV4/v4gPclcyBbTTXrjBzMXu3tLpK+QZolGZPJZocmhEt8eI+kq0RMDRkM9XXku8xt4lmf1D0I80qeMr82Au8fzV3bwBQ8bQO/suKgc/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UcT7ZR3UcJFW////FzIRojzGlUk0WedfA3mTJdmJWWh1F0RzK9kjVKbOc/ixEOCwQceMd2u/2sie7BFCuop45Zt1Q69rCk85rKEqHp82R2kkfmxFpdD8UWcab20MufMI13C+z8caGSrYm2VqpgXDHJl+XAtDpyLTp4Woj/0wOt4= Received: by 10.114.175.16 with SMTP id x16mr4239771wae.1185297012636; Tue, 24 Jul 2007 10:10:12 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Tue, 24 Jul 2007 10:10:12 -0700 (PDT) Message-ID: <2a41acea0707241010o52972359g94d8b336700664ab@mail.gmail.com> Date: Tue, 24 Jul 2007 10:10:12 -0700 From: "Jack Vogel" To: freebsd-net@freebsd.org, paketix@bluewin.ch In-Reply-To: <2a41acea0707240925q6a4faef5r893cec8ad13ca7d9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070717110156.GA37722@hbnnbsddev03.sharedtcs.net> <2a41acea0707170917n56e35cfbyc6e0bca094bfa729@mail.gmail.com> <20070718063801.GA40653@hbnnbsddev03.sharedtcs.net> <20070724114626.GA61209@hbnnbsddev03.sharedtcs.net> <2a41acea0707240925q6a4faef5r893cec8ad13ca7d9@mail.gmail.com> Cc: Subject: Re: em(4)/82571eb: fifo not dma'ed to host memory X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jul 2007 17:10:15 -0000 WOW, I want to really thank you for finding this Patrick. In Febuary 2006 Gleb introduced a drastic rename of our adapter struct, it introduced a HUGE amount of diffs, we (Intel) did not want that change and eventually it was backed out, however it was in that delta that the bang got lost in this logic, and all versions have picked up that error since. There will be changes coming for both 6 and 7. Jack On 7/24/07, Jack Vogel wrote: > Hmmm, this looks like a bug, I will look more closely today. > Sorry I have not been able to be more active with your problem, > but things have been hectic with product launches and my own > internal bug fixing. I will try to get this turned around quickly > Patrick. > > Jack > > > On 7/24/07, Patrick Oeschger wrote: > > OK - found the problem > > the driver in 6.2-RELEASE has different code in em_identify_hardware > > my hardware needs the memory access and bus master bits getting set by > > the driver > > beginning with 6.2-RELEASE this gets only set if PCIM_CMD_BUSMASTEREN is > > *not set* and PCIM_CMD_MEMEN is *set* - it seems the 82571EB has both > > parameters *not set* after init > > is this a bug? feature? typo? > > > > --- /root/em/if_em.c.61 Mon Jul 23 12:17:35 2007 > > +++ if_em.c.62 Tue Jul 24 13:04:11 2007 > > static void > > -em_identify_hardware(struct adapter * adapter) > > +em_identify_hardware(struct adapter *adapter) > > { > > device_t dev = adapter->dev; > > > > /* Make sure our PCI config space has the necessary stuff set */ > > adapter->hw.pci_cmd_word = pci_read_config(dev, PCIR_COMMAND, 2); > > - if (!((adapter->hw.pci_cmd_word & PCIM_CMD_BUSMASTEREN) && > > - (adapter->hw.pci_cmd_word & PCIM_CMD_MEMEN))) { > > - printf("em%d: Memory Access and/or Bus Master bits were not set! > > \n", > > - adapter->unit); > > + if ((adapter->hw.pci_cmd_word & PCIM_CMD_BUSMASTEREN) == 0 && > > + (adapter->hw.pci_cmd_word & PCIM_CMD_MEMEN)) { > > + device_printf(dev, "Memory Access and/or Bus Master bits " > > + "were not set!\n"); > > adapter->hw.pci_cmd_word |= > > (PCIM_CMD_BUSMASTEREN | PCIM_CMD_MEMEN); > > - pci_write_config(dev, PCIR_COMMAND, adapter->hw.pci_cmd_word, 2) > > ; > > + pci_write_config(dev, PCIR_COMMAND, > > + adapter->hw.pci_cmd_word, 2); > > } > > > > > thanks for your feedback jack - i tried the MSI stuff as first task this > > > morning > > > the interface init'ed without a problem and did not complain about MSI > > > what i like most is that no IRQ is assigned now, everything seems to get > > > handled in a TASKQ (IRQs were quite weird sometimes when having a bunch of > > > interfaces...) > > > > > > but now the bad news: even with MSI it is not possible to recv any frames > > > what makes me curious is, that the head pointer for receive fifo is *not* > > > counting up after receiving a frame (good_packets counter incrementing) > > > as far as i understand the 82571EB chipset manual, recv head counter inc > > > is done in hardware after receiving a good_packet and having dma'ed it to > > > host memory > > > from if_em.c/em_process_receive_interrupts: > > > * This routine executes in interrupt context. It replenishes > > > * the mbufs in the descriptor and sends data which has been > > > * dma'ed into host memory to upper layer. > > > > > > i did a quick test to check this on 6.1-RELENG by inserting a return > > > at the top of em_process_receive_interrupts (see diff) > > > register RDH0 is still incrementing for each good_packet received - even > > > without receive interrupts being processed at the driver level > > > > > > freebsd61# sysctl dev.em.0.debug_info=1 > > > dev.em.0.debug_iemnfo: 0:-1 Adapter hardware address = 0xc4b7c928 > > > em0: CTRL = 0x81c0241 RCTL = 0x8002 > > > em0: RDBAH0 = 0x0 RDBAL0 = 0x3e0ff000 > > > em0: RDLEN0 = 0x1000 RDH0 = 0x3 > > > em0: RDT0 = 0xff RXDCTL = 0x10000 > > > > > > ...so IMHO this increment (and also dma transfer to host memory) is done > > > in hardware - RDH0 is not counting up when running under 7.0-CURRENT... > > > > > > erroneous init of chipset? > > > anyone else running 7.0-CURRENT on a 82571EB pci express chipset? > > > > > > TIA for any help on this > > > pat > > > > > > details for dmesg/if_stats/diff: > > > > > > pcib9: irq 19 at device 11.0 on pci2 > > > pcib9: secondary bus 9 > > > pcib9: subordinate bus 9 > > > pcib9: I/O decode 0x6000-0x6fff > > > pcib9: memory decode 0xfd700000-0xfd7fffff > > > pcib9: prefetched decode 0xfce00000-0xfcefffff > > > pci9: on pcib9 > > > pci9: physical bus=9 > > > found-> vendor=0x8086, dev=0x105e, revid=0x06 > > > bus=9, slot=0, func=0 > > > class=02-00-00, hdrtype=0x00, mfdev=1 > > > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > > intpin=a, irq=255 > > > powerspec 2 supports D0 D3 current D0 > > > MSI supports 1 message, 64 bit > > > map[10]: type Memory, range 32, base 0, size 17, memory disabled > > > map[14]: type Memory, range 32, base 0, size 17, memory disabled > > > map[18]: type I/O Port, range 32, base 0, size 5, port disabled > > > found-> vendor=0x8086, dev=0x105e, revid=0x06 > > > bus=9, slot=0, func=1 > > > class=02-00-00, hdrtype=0x00, mfdev=1 > > > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > > intpin=b, irq=255 > > > powerspec 2 supports D0 D3 current D0 > > > MSI supports 1 message, 64 bit > > > map[10]: type Memory, range 32, base 0, size 17, memory disabled > > > map[14]: type Memory, range 32, base 0, size 17, memory disabled > > > map[18]: type I/O Port, range 32, base 0, size 5, port disabled > > > em0: at device > > > 0.0 on pci9 > > > pcib9: em0 requested memory range 0xfd700000-0xfd7fffff: good > > > pcib2: em0 requested memory range 0xfd700000-0xfd7fffff: good > > > pcib1: em0 requested memory range 0xfd700000-0xfd7fffff: good > > > em0: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at 0xfd700000 > > > em0: attempting to allocate 1 MSI vectors (1 supported) > > > msi: routing MSI IRQ 256 to vector 49 > > > em0: using IRQ 256 for MSI > > > em0: bpf attached > > > em0: Ethernet address: 00:10:f3:0c:5b:2a > > > em0: [FILTER] > > > pci9: at device 0.1 (no driver attached) > > > > > > freebsd61# diff -u sys/dev/em/if_em.c.orig sys/dev/em/if_em.c > > > --- sys/dev/em/if_em.c.orig Wed Jul 18 07:32:53 2007 > > > +++ sys/dev/em/if_em.c Wed Jul 18 07:48:42 2007 > > > @@ -277,6 +277,11 @@ > > > > > > INIT_DEBUGOUT("em_probe: begin"); > > > > > > + // prevent init of all em(4) devices except pci9/0/0 > > > + if(pci_get_bus(dev) != 0x09 || pci_get_slot(dev) != 0x00 || > > > + pci_get_function(dev) != 0x00) > > > + return (ENXIO); > > > + > > > pci_vendor_id = pci_get_vendor(dev); > > > if (pci_vendor_id != EM_VENDOR_ID) > > > return(ENXIO); > > > @@ -2906,6 +2911,8 @@ > > > u_int8_t eop = 0; > > > u_int16_t len, desc_len, prev_len_adj; > > > int i; > > > + > > > + return; > > > > > > /* Pointer to the receive descriptor being examined. */ > > > struct em_rx_desc *current_desc; > > > > > > On Tue, Jul 17, 2007 at 09:17:36AM -0700, Jack Vogel wrote: > > > > As an experiment, search in if_em.c for 'msix' look at the logic there. > > > > If the adapter is 82575 it will use msix, but the else clause has it > > > > use msi ONLY if its '>82571', change that to >=82571 and let's > > > > see if maybe using MSI will help you with your problems as I'm > > > > pretty confident its interrupt related. > > > > > > > > I had intended on making this change shortly anyway, my tests > > > > have shown the 571 to work fine this way. > > > > > > > > Let me know of the results. > > > > > > > > Jack > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From owner-freebsd-net@FreeBSD.ORG Tue Jul 24 23:35:47 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0CD416A418; Tue, 24 Jul 2007 23:35:47 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id 374FB13C45D; Tue, 24 Jul 2007 23:35:47 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.49.198] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1IDTur3keF-0006XZ; Wed, 25 Jul 2007 01:35:46 +0200 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Wed, 25 Jul 2007 01:35:39 +0200 User-Agent: KMail/1.9.7 References: <200706160347.33331.max@love2party.net> <20070710131224.GC64775@tirith.brixandersen.dk> <200707101520.12272.max@love2party.net> In-Reply-To: <200707101520.12272.max@love2party.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4595827.uBupxcFmas"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707250135.44846.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19XQPMZXwvmt6l9YRd7u2DCxz7/ijWh4VA/7p7 1z727oefuZAjldNYh2fv028KK1opbVajbiSP6Qsw0Ni7hmCcuP n7TyJ7TOqmqNm3nuaMTckCklU0xqJpTwPnrehf7J+Y= Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: RELENG_6 patch [Re: pf 4.1 Update available for testing] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2007 23:35:47 -0000 --nextPart4595827.uBupxcFmas Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline now available at: http://people.freebsd.org/~mlaier/PF41/ with=20 instructions how to build. Please test if possible and provide me with feedback. Again, this work can't be MFC'ed, but I'll try to keep up2date patches=20 available for RELENG_6 and release branches. =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 --nextPart4595827.uBupxcFmas Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGpozQXyyEoT62BG0RAhXwAJ97UC5tpWRD4sNlqvYiIHql5K169wCfZ+e7 SHJsmcsjTCdI3bzVmDOcoYY= =rsU4 -----END PGP SIGNATURE----- --nextPart4595827.uBupxcFmas-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 05:11:10 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A82DC16A41F for ; Wed, 25 Jul 2007 05:11:10 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 8830D13C45A for ; Wed, 25 Jul 2007 05:11:10 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so95485waf for ; Tue, 24 Jul 2007 22:11:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=S0DNujTGzt9ZtprNriU4ECrLcOGxb7VpdPhwK038fdfAAr3Ihlgl5l/dxmiB8ovYRTJfEQTzUqXkbFHgiSQetWUNEN7PFxj7JNoMY3tPaAX8I5DP83ywcpG68Evfa3qu/Frbm+Y406+Bz4TUDBe9fE6+5jGlm3UVpQ0JYpiyjeQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=DuPDmmDpBD5/mDuZ4rSIxjX0rfeLT8aRKCS9vNFUj/ka3/w5wHFMrPV8vpoFCMFPrJHiEXxWGw7m8KwLn/VktH5o8lpdqAANhAR4hkyOWQYF90QZfBkR7PwjR1hEkq06CKJf0t7QQ+y/TaPtL4d683EmZIvxpKuovx9p2UDb/cc= Received: by 10.114.106.1 with SMTP id e1mr278435wac.1185340270084; Tue, 24 Jul 2007 22:11:10 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Tue, 24 Jul 2007 22:11:09 -0700 (PDT) Message-ID: <2a41acea0707242211k6ebe3b77p6a9341b1b2d40210@mail.gmail.com> Date: Tue, 24 Jul 2007 22:11:10 -0700 From: "Jack Vogel" To: freebsd-net , "FreeBSD Stable List" , "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Merged em driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 05:11:10 -0000 The next driver I that I release via Intel channels is going to merge the code for 6 and 7. I was thinking that I could check that into the tip and it would make the most current version buildable on either RELEASE, was wondering if that is looked upon favorably or not? I have code ready to do that if getting it into 7.0 would be desireable. Jack From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 05:40:24 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEC6D16A41B for ; Wed, 25 Jul 2007 05:40:24 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id 85F7513C46A for ; Wed, 25 Jul 2007 05:40:24 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 80843 invoked from network); 25 Jul 2007 05:40:23 -0000 Received: from 209.68.2.70 (HELO localhost) (209.68.2.70) by relay01.pair.com with SMTP; 25 Jul 2007 05:40:23 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 25 Jul 2007 00:40:22 -0500 (CDT) From: Mike Silbersack To: Peter Wemm In-Reply-To: <200707201155.44573.peter@wemm.org> Message-ID: <20070725003706.U79872@odysseus.silby.com> References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <200707201155.44573.peter@wemm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andre Oppermann , current@freebsd.org, freebsd-current@freebsd.org, Robert Watson , net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 05:40:25 -0000 On Fri, 20 Jul 2007, Peter Wemm wrote: > TCP: [127.0.0.1]:52446 to [127.0.0.1]:1128 tcpflags 0x10; > syncache_expand: Segment failed SYNCOOKIE authentication, segment > rejected (probably spoofed) > [...] > > How on earth can localhost be spoofing itself? This is getting quite > absurd. :-( Any extra ACK that arrives is probably being processed by the syncookie code is my guess. So, I think that the problem is probably anywhere except in the syncookie code. > I'll give your patch a shot and see if it improves things at all. It won't, not for this case. :( But I'll get it committed ASAP, because it fixes other cases. Unless, that is, things IRL keep interrupting me. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 05:58:36 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8272A16A418; Wed, 25 Jul 2007 05:58:36 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6140613C442; Wed, 25 Jul 2007 05:58:36 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l6P5waCr065501; Wed, 25 Jul 2007 05:58:36 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l6P5waZl065497; Wed, 25 Jul 2007 05:58:36 GMT (envelope-from remko) Date: Wed, 25 Jul 2007 05:58:36 GMT Message-Id: <200707250558.l6P5waZl065497@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/114714: [gre][patch] gre(4) is not MPSAFE and does not support keys X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 05:58:36 -0000 Synopsis: [gre][patch] gre(4) is not MPSAFE and does not support keys Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Wed Jul 25 05:58:21 UTC 2007 Responsible-Changed-Why: This looks something more networking specific, reassign. http://www.freebsd.org/cgi/query-pr.cgi?pr=114714 From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 06:03:20 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23DF616A41F; Wed, 25 Jul 2007 06:03:20 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 038CC13C461; Wed, 25 Jul 2007 06:03:20 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l6P63JuT066073; Wed, 25 Jul 2007 06:03:19 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l6P63JA8066069; Wed, 25 Jul 2007 06:03:19 GMT (envelope-from remko) Date: Wed, 25 Jul 2007 06:03:19 GMT Message-Id: <200707250603.l6P63JA8066069@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/114839: [fxp] fxp looses ability to speak with traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 06:03:20 -0000 Synopsis: [fxp] fxp looses ability to speak with traffic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Wed Jul 25 06:03:17 UTC 2007 Responsible-Changed-Why: This seems more appropriate for the networking list, reassign. http://www.freebsd.org/cgi/query-pr.cgi?pr=114839 From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 06:46:32 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D00216A417 for ; Wed, 25 Jul 2007 06:46:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id D7A7813C469 for ; Wed, 25 Jul 2007 06:46:31 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 12CB3EB2884; Wed, 25 Jul 2007 14:28:24 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id iDcGIDcpmUJR; Wed, 25 Jul 2007 14:28:21 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id D5FE6EB2879; Wed, 25 Jul 2007 14:28:20 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=fgKhnwXKoMmtY8yBOCs5VWgB4qG+/TUMf1HDbIySwDyxx1r1hCpzUR9LQKaft/Q31 DW4LMerrHKYoxgmfrcYdg== Message-ID: <46A6ED6F.7090908@delphij.net> Date: Wed, 25 Jul 2007 14:27:59 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0707242211k6ebe3b77p6a9341b1b2d40210@mail.gmail.com> In-Reply-To: <2a41acea0707242211k6ebe3b77p6a9341b1b2d40210@mail.gmail.com> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigCB1FBDE5214C236551365BDF" Cc: freebsd-net , FreeBSD Current , FreeBSD Stable List Subject: Re: Merged em driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 06:46:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCB1FBDE5214C236551365BDF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jack Vogel wrote: > The next driver I that I release via Intel channels is going to > merge the code for 6 and 7. I was thinking that I could check that > into the tip and it would make the most current version buildable > on either RELEASE, was wondering if that is looked upon favorably > or not? I have code ready to do that if getting it into 7.0 would be > desireable. I think that if the change is not quite intrusive (e.g. add some ifdef blocks rather than restructuring the code heavily) then it would be desirable to have it hit the tree before we branch RELENG_7. However, if the change would be very late then it would be better to have it delayed and only "backport" important fixes in a case-by-case manner. My $0.02 :-) Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigCB1FBDE5214C236551365BDF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpu1vOfuToMruuMARCrcVAJ4iitqQwbmX6AYI9ka7ZCZmPijZQwCfZyGh YoPZKbwIUaaXP7DmxFaMgOo= =bi+2 -----END PGP SIGNATURE----- --------------enigCB1FBDE5214C236551365BDF-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 08:31:45 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAD6416A419; Wed, 25 Jul 2007 08:31:45 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id B9E1413C481; Wed, 25 Jul 2007 08:31:45 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 591D649688; Wed, 25 Jul 2007 04:31:45 -0400 (EDT) Date: Wed, 25 Jul 2007 09:31:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Silbersack In-Reply-To: <20070725003706.U79872@odysseus.silby.com> Message-ID: <20070725093019.E83919@fledge.watson.org> References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <200707201155.44573.peter@wemm.org> <20070725003706.U79872@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andre Oppermann , current@freebsd.org, Peter Wemm , freebsd-current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 08:31:46 -0000 On Wed, 25 Jul 2007, Mike Silbersack wrote: > On Fri, 20 Jul 2007, Peter Wemm wrote: > >> TCP: [127.0.0.1]:52446 to [127.0.0.1]:1128 tcpflags 0x10; >> syncache_expand: Segment failed SYNCOOKIE authentication, segment >> rejected (probably spoofed) >> [...] >> >> How on earth can localhost be spoofing itself? This is getting quite >> absurd. :-( > > Any extra ACK that arrives is probably being processed by the syncookie code > is my guess. So, I think that the problem is probably anywhere except in > the syncookie code. > >> I'll give your patch a shot and see if it improves things at all. > > It won't, not for this case. :( > > But I'll get it committed ASAP, because it fixes other cases. Unless, that > is, things IRL keep interrupting me. FYI, I received an informal report a few days ago that the SYN cache was ignoring RSTs, and kept transmitting SYN/ACK's even though a RST had been sent. This was during some local network testing where a host sends SYN packets out to a large number of other hosts, then quickly resets the connections after getting SYN/ACK's. Given that your previous work suggests that the syncache timer never fires at all, I'm not quite sure what to make of this report, but once your patches are in I can ask them to rerun it on one of my hosts and see. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 10:29:37 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 726FF16A418 for ; Wed, 25 Jul 2007 10:29:37 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id C32EF13C459 for ; Wed, 25 Jul 2007 10:29:36 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id F35087C0067; Wed, 25 Jul 2007 12:05:19 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id CtihbBXnPN6p; Wed, 25 Jul 2007 12:05:19 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id 7B4917C005B; Wed, 25 Jul 2007 12:05:04 +0200 (CEST) Date: Wed, 25 Jul 2007 12:05:04 +0200 From: Gergely CZUCZY To: Pound Mailing List Message-ID: <20070725100504.GA24034@harmless.hu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-net@freebsd.org Subject: backends periodically rendered DEAD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 10:29:37 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I'm testing pound at the moment, and running paralelly around 15-18 apache benchmarks for a session-tracking test. However pound keeps on losing the backends periodically and it restores them a few seconds later they come back, and go back to DEAD again. It's a FreeBSD 6.2-p6. While the backends are marked as DEAD I'm unable to reach them from a browser (say, elinks) directly. FreeBSD lvs1.in.publishing.hu 6.2-RELEASE-p6 FreeBSD 6.2-RELEASE-p6 #1: Tue= Jul 24 08:07:07 UTC 2007 toor@pointyhat.office:/usr/obj/usr/src/sys/LV= S i386 it's like this: 0. http Listener 192.168.4.55:80 a 0. Service active (0) 0. Backend PF_INET 10.0.0.1:80 active (7 27125.432 sec) DEAD 1. Service active (0) 0. Backend PF_INET 10.0.0.1:80 active (7 32400.306 sec) DEAD 1. Backend PF_INET 10.0.0.2:80 active (2 0.000 sec) DEAD 2. Backend PF_INET 10.0.0.3:80 active (2 26940.430 sec) DEAD I've got log messages like: Jul 25 11:54:00 lvs1 pound: BackEnd 10.0.0.1:80 resurrect Jul 25 11:54:00 lvs1 pound: BackEnd 10.0.0.3:80 resurrect Jul 25 11:54:05 lvs1 pound: backend 10.0.0.1:80 connect: Operation not perm= itted Jul 25 11:54:05 lvs1 last message repeated 27 times Jul 25 11:54:05 lvs1 pound: no back-end "GET /phpinfo-lycos.html HTTP/1.0" = =66rom 192.168.4.21 Jul 25 11:53:31 lvs1 pound: error copy server cont: Broken pipe Jul 25 11:53:34 lvs1 pound: backend 10.0.0.1:80 connect: Operation not perm= itted Jul 25 11:53:34 lvs1 pound: backend 10.0.0.3:80 connect: Operation not perm= itted Jul 25 11:53:34 lvs1 pound: backend 10.0.0.3:80 connect: Operation not perm= itted Jul 25 11:54:27 lvs1 pound: error copy server cont: Broken pipe Jul 25 11:54:27 lvs1 pound: error copy server cont: Connection reset by peer Jul 25 11:54:27 lvs1 pound: error copy server cont: Broken pipe And every combination of these with "no back-end" messages, but I've grepped those out. I'm using the pf(4) packet filter, but the log shows no dropped or denied p= ackets. To be honest, I don't really know where to begin with this issue. I've set = the following sysctls in order to have enough free ports in the range to connect to the w= eb backends: net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 20000 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 20000 I've googled around, but found nothing really relevant. What data should I collect to be able to resolve this issue? I've sent this mail both to the pound and the freebsd-net@ mailing list because I don't really know where the issue really lies. Please take this into account in the replies. Sincerely, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owHNVr9vHEUUNoloJkIiQkSUT45EYsW73r1fcRad4sR2EqOIWPFBCgo0tzt3O9ze zDIz6+PSEImGIgWioEGCDiqkICF6KkRDQYlEDxJ/BN/s2o6d4ASUFPjn3ux733vv e+/Ne5++dHLhxOlfHnz/7oX7n33xwrenbg0vTCvn1DiYcrMrVRBHURy0OlG7E7SD Ns9awyzO4l67F2eXRte+oe11rZxQLhjMS5GQEx+6lbLgUr1Bac6NFa5fuVGwyvbl NqQttZVOapWQVIVU4uDdwHBlR8IEmyrVmVTjhD6otBNZUBqpHB8WgrEboij0MmNb 56YwZx3EqNSVyog7crmgqZ4CbJk4jkylVC3ADS+gOCduatm4G8SrjJc8hcZQqDRH wBNLI22IkxXWwsHAGZ5OvL43FMK2noldYfbsTYQoLWlFBQLyQh4KCkJllkphJGJI eW0U0tIxAxSNP15yCjMjMYOpVHv5gjsA48WcUgRQAzUxjHX9gTlNG5tXNoiPQS+c 2XLnLECuGSGu7mxQL2wFZS+kO7ksxFFfuAErCE+AI1uD1OxVyjNKwDUCPDRejYz2 rg2Nnlk4dN7y+TIJpGlilyiTRqSumMP6vtli18Yh/CmrYSFtDh7CvKqdub15c/PK ziacOuLjoeOzcUKDSvQZvVkV1OpQtJpEF/FDbw/WqRXhwX85rc1aqVEB85y7UI9G MhXJSmXNih6+X/+3Jl2xc7ty850+2yGS7dUeY9ITVMiJZ0PahBFFIeXOlXRTWhQc wosvtcK4txp2wm43WY2IM28QYjsC5Z8K4qmTu4LOR0v1m/rd1YZX2r723tZbmwOK o9B/xzXAnvxFal2MW92w0275FC81rHuA+HmAt9GSUdiOeo+A1/DHQLQOQ7RgK4qi x9Rbx6q3j6q3epc6EcI7DIGqwsuxduiIMU3RRHwsmhQkrE5xl+I46XYSWPaF0zRS Upvc9F15KFj0SWV8uf0XzfaTNLtHNPe644hNtKKCXkK30L7c31GkEA0+TPsoJ9xE /wxZcOv244X5UqCZM1QAOYnTJ7qhmu4OvCuL10H3SpmXUo10UMxTbcPcTQu6MRhs r8RhtEh91u/1fIs+rNxWzA5baCft+IgFYQwutVSXc6TK+OsLYSLGq0aDACplKR7R 7zxnop4G2f5fQHYSJOwZiPvX+uuNW94dlKpwNJzDJ2Ge2Rl2BQT4AVXPkKFUTcx6 5K92K2gmXU6Lhypu8aBJl2lYOWr6FwVcghqXa+joyg++elwcDLlydL6zhJkKxh2N ZIHJ1ej7l771bY7p4Us7M9pjEVzPhJJ4Kvus1rNAHcATQblWmIvLtEWZVuecH0Z+ Zk6UntEsF6aeUEMxlqoJwF/mJK2tRNg47CnsM297pLEbzOAmwzDAoIIcwjeZn6ya cg5hoXQ1zjHmBOLQxtUiXhe7x7g2tVc1/tGfz/pMDA9macKUcJh3/k8ZeoBaL8TQ xR2QUK/bbXePlRlJ44Uw2aLoGKGnwxwB2b9y9bjw071ebppcjOodBfXuZ/I+qUYU Ypcrn9I7mKWUccd9tqoiA/8p6NuLHHl5uBxYXeyKQ7xf3jNrsWc1x1MuCxpqn52G tb2NDL91XsD20GYBYlmrZb1LWBccG4qUVyizJyQf+rXV/XeFFDak7UJw6Dk+Eazx TME0T1MYdgc5FWUtzdiOVCnQijk2x+vCjPFE63er9O6ceX+cTmjcHIdpfbyG7XVa oDuwzjAWBP1WxO4IX8O22QbpOj7AdUsNPaXRIGzqlzsQy420ImSfXD754oJfk/d3 7NMn7v6w8GXnpzOdB6/zl9XZ377u/XVv8urnv/6+8JX5Ob59/7tXzv55a+2jHz8+ c+qP6LV7fwM= =s6j8 -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 10:33:20 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1B6016A417 for ; Wed, 25 Jul 2007 10:33:20 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 71FC913C467 for ; Wed, 25 Jul 2007 10:33:20 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IDdoZ-0008yT-UN; Wed, 25 Jul 2007 18:09:55 +0800 Message-ID: <46A72173.7070907@micom.mng.net> Date: Wed, 25 Jul 2007 18:09:55 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.5 (X11/20070724) MIME-Version: 1.0 To: Alexander Motin References: <1159971789.00612536.1159960802@10.7.7.3> <4524055D.7060906@mavhome.dp.ua> <4529C408.5070807@micom.mng.net> <452A008B.8040804@mavhome.dp.ua> <452A0F2A.3000901@micom.mng.net> <452A164A.9080507@mavhome.dp.ua> <45814888.1060301@micom.mng.net> <45814B40.4080004@mavhome.dp.ua> In-Reply-To: <45814B40.4080004@mavhome.dp.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd and vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 10:33:20 -0000 Alexander Motin wrote: > Hi. > > Ganbold wrote: >> Is it possible to give static IP addresses to the users using mpd? >> How it should be done? User is authenticating with radius server. > > Your RADIUS server should send FRAMED_IP_ADDRESS attribute to mpd > specifying required IP address. When mpd will get that attribute it > will propose it to client instead of specified in "set ipcp ranges" > option. > I tried it in mpd-3.18, Radius server sends Framed IP Address, however mpd still assigns IP specified in "set ipcp ranges 192.168.5.2/32 192.168.5.169/25" What could be a problem? How to solve this issue? thanks, Ganbold -- Science! true daughter of Old Time thou art! Who alterest all things with thy peering eyes. Why preyest thou thus upon the poet's heart, Vulture, whose wings are dull realities? How should he love thee? or how deem thee wise? Who wouldst not leave him in his wandering To seek for treasure in the jewelled skies, Albeit he soared with an undaunted wing? Hast thou not dragged Diana from her car? And driven the Hamadryad from the wood To seek a shelter in some happier star? Hast thou not torn the Naiad from her flood, The Elfin from the green grass, and from me The summer dream beneath the tamarind tree? -- Edgar Allen Poe, "Science, a Sonnet" From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 10:43:02 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BB3016A417 for ; Wed, 25 Jul 2007 10:43:02 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id D6BAB13C45A for ; Wed, 25 Jul 2007 10:43:01 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=Jr4OL4N1A/jq80MaDwhbVgemQPwpqaMxxPL8kSz3H4xFFo4j9F7HzDUf35e27TUnLkPNG9OkywPCzHVfDvPsfXh1DvHDqxUMKJhNRBjQ1lKI+UhXRxMGVVvIWi81UM5n6t91sQlz+2z9SVjeMc38/jkE0Pje439buT7ZHhdSOpk=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1IDeKY-000ErI-7j; Wed, 25 Jul 2007 14:42:58 +0400 Date: Wed, 25 Jul 2007 14:42:53 +0400 From: Eygene Ryabinkin To: Gergely CZUCZY Message-ID: <20070725104253.GL1510@void.codelabs.ru> References: <20070725100504.GA24034@harmless.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070725100504.GA24034@harmless.hu> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: Pound Mailing List , freebsd-net@freebsd.org Subject: Re: backends periodically rendered DEAD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 10:43:02 -0000 Gergely, good day. Wed, Jul 25, 2007 at 12:05:04PM +0200, Gergely CZUCZY wrote: > I'm testing pound at the moment, and running paralelly around 15-18 > apache benchmarks for a session-tracking test. > > However pound keeps on losing the backends periodically and it > restores them a few seconds later they come back, and go back > to DEAD again. And what 'netstat -na' tells you when your backends are in the DEAD state? -- Eygene From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 11:03:20 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 660CC16A417 for ; Wed, 25 Jul 2007 11:03:20 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id C957C13C45A for ; Wed, 25 Jul 2007 11:03:19 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IDeeC-0009V7-7I; Wed, 25 Jul 2007 19:03:16 +0800 Message-ID: <46A72DF3.8040109@micom.mng.net> Date: Wed, 25 Jul 2007 19:03:15 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.5 (X11/20070724) MIME-Version: 1.0 To: Mihai Tanasescu References: <1159971789.00612536.1159960802@10.7.7.3> <4524055D.7060906@mavhome.dp.ua> <4529C408.5070807@micom.mng.net> <452A008B.8040804@mavhome.dp.ua> <452A0F2A.3000901@micom.mng.net> <452A164A.9080507@mavhome.dp.ua> <45814888.1060301@micom.mng.net> <45814B40.4080004@mavhome.dp.ua> <46A72173.7070907@micom.mng.net> <46A72BFF.1020301@duras.ro> In-Reply-To: <46A72BFF.1020301@duras.ro> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd and vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 11:03:20 -0000 Mihai Tanasescu wrote: > Sorry for asking as a follow-up to your question...but do you have a > working config for MPD and pptp. > > > I'm desperately trying to get mine to work...but mpd refuses to listen > to connections on my interface (it starts, it gives no errors, it > loads the pptp1 config, I can access its console, etc). > > > > > > Something like: default: load pptp0 load pptp1 pptp0: new -i ng0 pptp0 pptp0 set ipcp ranges 192.168.1.2/32 192.168.5.1/24 load pptp_standard pptp1: new -i ng1 pptp1 pptp1 set ipcp ranges 192.168.1.2/32 192.168.5.2/24 load pptp_standard pptp_standard: set iface idle 0 set iface disable on-demand set iface disable proxy-arp set iface enable tcpmssfix set iface mtu 1500 set iface route default set iface enable radius-session set bundle no multilink set bundle disable multilink set bundle enable compression set bundle max-logins 3 set bundle enable radius-acct set bundle enable radius-auth # set link type pptp set link no pap set link enable chap set link keep-alive 10 60 set link max-redial -1 set link yes acfcomp protocomp set link mtu 1460 set link latency 0 set ipcp dns 192.168.1.1 192.168.0.1 set ipcp yes vjcomp set ccp yes mppc set ccp yes mpp-e40 mpd.links --------------------------------------- pptp0: set link type pptp set pptp self 192.168.1.1 set pptp enable incoming set pptp disable originate pptp1: set link type pptp set pptp self 192.168.1.1 set pptp enable incoming set pptp disable originate set ccp yes mpp-e128 set ccp yes mpp-stateless set pptp self 192.168.1.1 set pptp enable incoming set pptp disable originate ############### set radius timeout 10 set radius config /usr/local/etc/mpd/radius.conf set radius retries 3 I tested it a long ago with mpd-3.18. It worked at that time. hth, Ganbold -- Boys will be boys, and so will a lot of middle-aged men. -- Kin Hubbard From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 11:03:51 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8542116A417 for ; Wed, 25 Jul 2007 11:03:51 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id D233613C442 for ; Wed, 25 Jul 2007 11:03:49 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from [10.100.0.23] (vl-office.vl.net.ua [194.44.81.189]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l6PB3e3h076671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jul 2007 14:03:44 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Message-ID: <46A72E0B.2040600@aws-net.org.ua> Date: Wed, 25 Jul 2007 14:03:39 +0300 From: Artyom Viklenko Organization: Art&Co. User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Ganbold References: <1159971789.00612536.1159960802@10.7.7.3> <4524055D.7060906@mavhome.dp.ua> <4529C408.5070807@micom.mng.net> <452A008B.8040804@mavhome.dp.ua> <452A0F2A.3000901@micom.mng.net> <452A164A.9080507@mavhome.dp.ua> <45814888.1060301@micom.mng.net> <45814B40.4080004@mavhome.dp.ua> <46A72173.7070907@micom.mng.net> In-Reply-To: <46A72173.7070907@micom.mng.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Wed, 25 Jul 2007 14:03:45 +0300 (EEST) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on alf.aws-net.org.ua X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, Alexander Motin Subject: Re: mpd and vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 11:03:51 -0000 Ganbold wrote: > Alexander Motin wrote: >> Hi. >> >> Ganbold wrote: >>> Is it possible to give static IP addresses to the users using mpd? >>> How it should be done? User is authenticating with radius server. >> >> Your RADIUS server should send FRAMED_IP_ADDRESS attribute to mpd >> specifying required IP address. When mpd will get that attribute it >> will propose it to client instead of specified in "set ipcp ranges" >> option. >> > > I tried it in mpd-3.18, Radius server sends Framed IP Address, however > mpd still assigns IP specified in "set ipcp ranges 192.168.5.2/32 > 192.168.5.169/25" > What could be a problem? How to solve this issue? > Check if you include set ipcp enable radius-ip in your bundle description. -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 11:06:30 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B407B16A418 for ; Wed, 25 Jul 2007 11:06:30 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 57ACC13C442 for ; Wed, 25 Jul 2007 11:06:30 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IDehI-0009Wx-JY; Wed, 25 Jul 2007 19:06:28 +0800 Message-ID: <46A72EB3.5070002@micom.mng.net> Date: Wed, 25 Jul 2007 19:06:27 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.5 (X11/20070724) MIME-Version: 1.0 To: Nikos Vassiliadis References: <1159971789.00612536.1159960802@10.7.7.3> <45814B40.4080004@mavhome.dp.ua> <46A72173.7070907@micom.mng.net> <200707251401.14455.nvass@teledomenet.gr> In-Reply-To: <200707251401.14455.nvass@teledomenet.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: mpd and vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 11:06:30 -0000 Nikos Vassiliadis wrote: > On Wednesday 25 July 2007 13:09, Ganbold wrote: > >> I tried it in mpd-3.18, Radius server sends Framed IP Address, however >> mpd still assigns IP specified in "set ipcp ranges 192.168.5.2/32 >> 192.168.5.169/25" >> What could be a problem? How to solve this issue? >> > > If you enable "radius-ip" option, mpd will use > Framed-IP-Address offered by your RADIUS. > > From here: > http://www.bretterklieber.com/mpd/doc3/mpd22.html > Oh, I see, will try it shortly and let you know. > Off topic, why not mpd4? > Yes, definitely I will upgrade it, but later when I have more time. thanks a lot, Ganbold > Nikos > > > > -- Reporter: "How did you like school when you were growing up, Yogi?" Yogi Berra: "Closed." From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 11:09:36 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32ACB16A419 for ; Wed, 25 Jul 2007 11:09:36 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from mail.duras.ro (mail.duras.ro [86.105.56.133]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3C613C481 for ; Wed, 25 Jul 2007 11:09:35 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from localhost (localhost [127.0.0.1]) by mail.duras.ro (Postfix) with ESMTP id 844148A2F1; Wed, 25 Jul 2007 14:09:36 +0300 (EEST) Received: from mail.duras.ro ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29894-10; Wed, 25 Jul 2007 14:09:34 +0300 (EEST) Received: from [86.105.56.194] (ma.plimb.cu.barca.prin.padure.ro [86.105.56.194]) by mail.duras.ro (Postfix) with ESMTP id C0DDC8FE9; Wed, 25 Jul 2007 14:09:34 +0300 (EEST) Message-ID: <46A72F6E.80704@duras.ro> Date: Wed, 25 Jul 2007 14:09:34 +0300 From: Mihai Tanasescu User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Ganbold References: <1159971789.00612536.1159960802@10.7.7.3> <4524055D.7060906@mavhome.dp.ua> <4529C408.5070807@micom.mng.net> <452A008B.8040804@mavhome.dp.ua> <452A0F2A.3000901@micom.mng.net> <452A164A.9080507@mavhome.dp.ua> <45814888.1060301@micom.mng.net> <45814B40.4080004@mavhome.dp.ua> <46A72173.7070907@micom.mng.net> <46A72BFF.1020301@duras.ro> <46A72DF3.8040109@micom.mng.net> In-Reply-To: <46A72DF3.8040109@micom.mng.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (RedHat) at duras.ro Cc: freebsd-net@freebsd.org Subject: Re: mpd and vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 11:09:36 -0000 Ganbold wrote: > Mihai Tanasescu wrote: >> Sorry for asking as a follow-up to your question...but do you have a >> working config for MPD and pptp. >> >> >> I'm desperately trying to get mine to work...but mpd refuses to >> listen to connections on my interface (it starts, it gives no errors, >> it loads the pptp1 config, I can access its console, etc). >> >> >> >> >> >> > Something like: > > default: > load pptp0 > load pptp1 > > pptp0: > new -i ng0 pptp0 pptp0 > set ipcp ranges 192.168.1.2/32 192.168.5.1/24 > load pptp_standard > > pptp1: > new -i ng1 pptp1 pptp1 > set ipcp ranges 192.168.1.2/32 192.168.5.2/24 > load pptp_standard > > pptp_standard: > > set iface idle 0 > set iface disable on-demand > set iface disable proxy-arp > set iface enable tcpmssfix > set iface mtu 1500 > set iface route default > set iface enable radius-session > > set bundle no multilink > set bundle disable multilink > set bundle enable compression > set bundle max-logins 3 > set bundle enable radius-acct > set bundle enable radius-auth > > # set link type pptp > set link no pap > set link enable chap > set link keep-alive 10 60 > set link max-redial -1 > set link yes acfcomp protocomp > set link mtu 1460 > set link latency 0 > > > set ipcp dns 192.168.1.1 192.168.0.1 > set ipcp yes vjcomp > > set ccp yes mppc > set ccp yes mpp-e40 > > > > mpd.links > --------------------------------------- > pptp0: > set link type pptp > set pptp self 192.168.1.1 > set pptp enable incoming > set pptp disable originate > pptp1: > set link type pptp > set pptp self 192.168.1.1 > set pptp enable incoming > set pptp disable originate > > set ccp yes mpp-e128 > set ccp yes mpp-stateless > > set pptp self 192.168.1.1 > set pptp enable incoming > set pptp disable originate > > ############### > > set radius timeout 10 > set radius config /usr/local/etc/mpd/radius.conf > set radius retries 3 > > I tested it a long ago with mpd-3.18. It worked at that time. > > hth, > > Ganbold > > Thanks, Now it works...got to figure out what I was missing. From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 11:15:20 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1AE616A418 for ; Wed, 25 Jul 2007 11:15:20 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 51A9213C46A for ; Wed, 25 Jul 2007 11:15:20 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 728B31CC58; Wed, 25 Jul 2007 23:02:58 +1200 (NZST) Date: Wed, 25 Jul 2007 23:02:58 +1200 From: Andrew Thompson To: FreeBSD-net Message-ID: <20070725110258.GA20688@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Subject: bridge handbook section X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 11:15:20 -0000 Hi, I have started updating the bridge section of the Handbook here, http://nzfug.nz.freebsd.org/nzfug/HandbookUpdates/NetworkBridging Any additions or corrections would be appreciated, just drop me an email. cheers, Andrew From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 11:18:23 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14F7F16A41B for ; Wed, 25 Jul 2007 11:18:23 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from smtp.teledomenet.gr (smtp.teledomenet.gr [213.142.128.2]) by mx1.freebsd.org (Postfix) with ESMTP id C203513C474 for ; Wed, 25 Jul 2007 11:18:22 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from iris (unknown [192.168.1.71]) by smtp.teledomenet.gr (Postfix) with ESMTP id 98A22142DFD; Wed, 25 Jul 2007 14:00:36 +0300 (EEST) From: Nikos Vassiliadis To: freebsd-net@freebsd.org Date: Wed, 25 Jul 2007 14:01:14 +0300 User-Agent: KMail/1.9.1 References: <1159971789.00612536.1159960802@10.7.7.3> <45814B40.4080004@mavhome.dp.ua> <46A72173.7070907@micom.mng.net> In-Reply-To: <46A72173.7070907@micom.mng.net> X-NCC-RegID: gr.telehouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707251401.14455.nvass@teledomenet.gr> Cc: Ganbold Subject: Re: mpd and vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 11:18:23 -0000 On Wednesday 25 July 2007 13:09, Ganbold wrote: > I tried it in mpd-3.18, Radius server sends Framed IP Address, however > mpd still assigns IP specified in "set ipcp ranges 192.168.5.2/32 > 192.168.5.169/25" > What could be a problem? How to solve this issue? If you enable "radius-ip" option, mpd will use =46ramed-IP-Address offered by your RADIUS. =46rom here: http://www.bretterklieber.com/mpd/doc3/mpd22.html Off topic, why not mpd4? Nikos From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 11:18:43 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A67316A419 for ; Wed, 25 Jul 2007 11:18:43 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id F40FB13C45A for ; Wed, 25 Jul 2007 11:18:42 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IDet7-0009dA-Ch; Wed, 25 Jul 2007 19:18:41 +0800 Message-ID: <46A73190.2090501@micom.mng.net> Date: Wed, 25 Jul 2007 19:18:40 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.5 (X11/20070724) MIME-Version: 1.0 To: Nikos Vassiliadis References: <1159971789.00612536.1159960802@10.7.7.3> <45814B40.4080004@mavhome.dp.ua> <46A72173.7070907@micom.mng.net> <200707251401.14455.nvass@teledomenet.gr> In-Reply-To: <200707251401.14455.nvass@teledomenet.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: mpd and vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 11:18:43 -0000 Nikos Vassiliadis wrote: > On Wednesday 25 July 2007 13:09, Ganbold wrote: > >> I tried it in mpd-3.18, Radius server sends Framed IP Address, however >> mpd still assigns IP specified in "set ipcp ranges 192.168.5.2/32 >> 192.168.5.169/25" >> What could be a problem? How to solve this issue? >> > > If you enable "radius-ip" option, mpd will use > Framed-IP-Address offered by your RADIUS. > > From here: > http://www.bretterklieber.com/mpd/doc3/mpd22.html > > Off topic, why not mpd4? > > Nikos > > > > It works. One question, does this syntax also apply for mpd-4.2.x? thanks, Ganbold -- LSD melts in your mind, not in your hand. From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 11:19:05 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 360E016A417 for ; Wed, 25 Jul 2007 11:19:05 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from mail.duras.ro (mail.duras.ro [86.105.56.133]) by mx1.freebsd.org (Postfix) with ESMTP id CEB9A13C474 for ; Wed, 25 Jul 2007 11:19:04 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from localhost (localhost [127.0.0.1]) by mail.duras.ro (Postfix) with ESMTP id 3E83822707 for ; Wed, 25 Jul 2007 13:52:51 +0300 (EEST) Received: from mail.duras.ro ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29894-05 for ; Wed, 25 Jul 2007 13:52:49 +0300 (EEST) Received: from [86.105.56.194] (ma.plimb.cu.barca.prin.padure.ro [86.105.56.194]) by mail.duras.ro (Postfix) with ESMTP id 317A92E54 for ; Wed, 25 Jul 2007 13:52:49 +0300 (EEST) Message-ID: <46A72B80.8040400@duras.ro> Date: Wed, 25 Jul 2007 13:52:48 +0300 From: Mihai Tanasescu User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) 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: by amavisd-new-20030616-p10 (RedHat) at duras.ro Subject: Can't get MPD to work..doesn't listen on 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: Wed, 25 Jul 2007 11:19:05 -0000 Hello, I've just setup my first MPD for establishing a PPTP tunnel with some Windows clients...and I don't understand why it doesn't bind to my interface IP to listen for incoming connections. My config looks like this: mpd.conf startup: set console open set console ip 86.105.56.134 set console user skyraven test default: load pptp1 pptp1: new -i ng0 pptp1 pptp1 set iface disable on-demand set iface enable proxy-arp set iface idle 0 set iface enable tcpmssfix set bundle enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp set ipcp ranges 172.20.1.1/32 172.20.1.51/32 set ipcp dns 172.20.1.1 set ipcp nbns 172.20.1.1 172.20.1.8 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless mpd.links pptp1: set link type pptp set pptp sef my-public-ip-address set pptp enable incoming set pptp disable originate After starting mpd I get no errors, I have the netgraph modules loaded but nothing is listening on tcp port 1723 for pptp (and the socket isn't already in use). Any ideas what I might be doing wrong ? (sorry for being just a newb here) I don't know if this is the right list to ask or if it would be better to direct this to freebsd-questions. Sorry. From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 11:24:45 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED20516A41B for ; Wed, 25 Jul 2007 11:24:45 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5310813C459 for ; Wed, 25 Jul 2007 11:24:45 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 13001 invoked from network); 25 Jul 2007 11:20:08 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Jul 2007 11:20:08 -0000 Message-ID: <46A7330F.6000204@freebsd.org> Date: Wed, 25 Jul 2007 13:25:03 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Robert Watson References: <20070709234401.S29353@odysseus.silby.com> <20070710132253.GJ1038@void.codelabs.ru> <20070710202028.I34890@odysseus.silby.com> <200707201155.44573.peter@wemm.org> <20070725003706.U79872@odysseus.silby.com> <20070725093019.E83919@fledge.watson.org> In-Reply-To: <20070725093019.E83919@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Peter Wemm , freebsd-current@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7 TCP syncache fix: request for testers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 11:24:46 -0000 Robert Watson wrote: > On Wed, 25 Jul 2007, Mike Silbersack wrote: > >> On Fri, 20 Jul 2007, Peter Wemm wrote: >> >>> TCP: [127.0.0.1]:52446 to [127.0.0.1]:1128 tcpflags 0x10; >>> syncache_expand: Segment failed SYNCOOKIE authentication, segment >>> rejected (probably spoofed) >>> [...] >>> >>> How on earth can localhost be spoofing itself? This is getting quite >>> absurd. :-( >> >> Any extra ACK that arrives is probably being processed by the >> syncookie code is my guess. So, I think that the problem is probably >> anywhere except in the syncookie code. I guess it is a late ACK for a connection that is being shut down. Once the tcpcb of the connection is gone any further segments will hit the syncache and cause such an error message. The real problem seems to be in the connection shutdown sequence that either somehow prematurely completes or emits spurious packets after completion. >>> I'll give your patch a shot and see if it improves things at all. >> >> It won't, not for this case. :( >> >> But I'll get it committed ASAP, because it fixes other cases. Unless, >> that is, things IRL keep interrupting me. > > FYI, I received an informal report a few days ago that the SYN cache was > ignoring RSTs, and kept transmitting SYN/ACK's even though a RST had > been sent. This was during some local network testing where a host > sends SYN packets out to a large number of other hosts, then quickly > resets the connections after getting SYN/ACK's. Given that your > previous work suggests that the syncache timer never fires at all, I'm > not quite sure what to make of this report, but once your patches are in > I can ask them to rerun it on one of my hosts and see. Not all RST lead to the termination of the syncache entry. It'd be helpful to know which log messages the local network test generated. There are two possibilities: "Our SYN|ACK was rejected, connection attempt aborted by remote endpoint", or "Spurious RST, segment rejected". Only the former causes the termination of the syncache entry. I fear the distinction between these two cases is over- engineered and they should be collapsed together. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 11:53:57 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEACA16A41B for ; Wed, 25 Jul 2007 11:53:57 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from smtp.teledomenet.gr (smtp.teledomenet.gr [213.142.128.2]) by mx1.freebsd.org (Postfix) with ESMTP id A508313C45B for ; Wed, 25 Jul 2007 11:53:57 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from iris (unknown [192.168.1.71]) by smtp.teledomenet.gr (Postfix) with ESMTP id D733D1427E4; Wed, 25 Jul 2007 14:53:56 +0300 (EEST) From: Nikos Vassiliadis To: Ganbold Date: Wed, 25 Jul 2007 14:54:34 +0300 User-Agent: KMail/1.9.1 References: <1159971789.00612536.1159960802@10.7.7.3> <200707251401.14455.nvass@teledomenet.gr> <46A73190.2090501@micom.mng.net> In-Reply-To: <46A73190.2090501@micom.mng.net> X-NCC-RegID: gr.telehouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707251454.34922.nvass@teledomenet.gr> Cc: freebsd-net@freebsd.org Subject: Re: mpd and vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 11:53:58 -0000 On Wednesday 25 July 2007 14:18, Ganbold wrote: > Nikos Vassiliadis wrote: > > On Wednesday 25 July 2007 13:09, Ganbold wrote: > >> I tried it in mpd-3.18, Radius server sends Framed IP Address, > >> however mpd still assigns IP specified in "set ipcp ranges > >> 192.168.5.2/32 192.168.5.169/25" > >> What could be a problem? How to solve this issue? > > > > If you enable "radius-ip" option, mpd will use > > Framed-IP-Address offered by your RADIUS. > > > > From here: > > http://www.bretterklieber.com/mpd/doc3/mpd22.html > > > > Off topic, why not mpd4? > > > > Nikos > > It works. One question, does this syntax also apply for mpd-4.2.x? Hm, "radius-ip" option is removed from mpd4, according to the change log. Maybe the behaviour is automated now, what Alexander described in your previous email. > Alexander Motin wrote: > > Hi. > > > > Ganbold wrote: > >> Is it possible to give static IP addresses to the users using mpd? > >> How it should be done? User is authenticating with radius server. > > > > Your RADIUS server should send FRAMED_IP_ADDRESS attribute to mpd > > specifying required IP address. When mpd will get that attribute it > > will propose it to client instead of specified in "set ipcp ranges" > > option. HTH, Nikos From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 15:01:21 2007 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0C9C16A418 for ; Wed, 25 Jul 2007 15:01:21 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id A218613C442 for ; Wed, 25 Jul 2007 15:01:21 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id E5129B3CE for ; Wed, 25 Jul 2007 11:01:18 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 25 Jul 2007 11:01:18 -0400 X-Sasl-enc: 2IA/8kSnVpII4RpmsQw2YT335Pv0pvZ9qo4K83+R9Hxb 1185375677 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 7BECB3F38 for ; Wed, 25 Jul 2007 11:01:17 -0400 (EDT) Message-ID: <46A765B9.8010201@incunabulum.net> Date: Wed, 25 Jul 2007 16:01:13 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [PATCH] add check for IP Router Alert X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 15:01:21 -0000 Please see the following patch which adds a check for the IP Router Alert option, for use by in-kernel IPv4 protocol domain consumers: http://people.freebsd.org/~bms/dump/ipoptions-routeralert.patch Comments/review before commit appreciated. regards BMS From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 18:08:17 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF96116A419 for ; Wed, 25 Jul 2007 18:08:17 +0000 (UTC) (envelope-from adityaa.kiran@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 8619813C48D for ; Wed, 25 Jul 2007 18:08:17 +0000 (UTC) (envelope-from adityaa.kiran@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so324992waf for ; Wed, 25 Jul 2007 11:08:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=T+mD4sBgt54dOruaPndlMMplmsjpr4Qz0QFhHAfSimqr0elIo09w1H4AiiA5ItkhZ8xSflNwQKURGh5kykorEpn3A5SZDQNFdmy/h6uQLKyEYcEKaGRXWNup8MoLDaJ0jU3sBxmG6/HOhZaSpRsb7Y03D7wbKT4qW0K6dCpLjk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=aO2UrafCOqFFalvkPKGFrbwjUxhc4tOWA2UcPE9lSfSCJZT5TORflmXQmiRB44/bC3m1UA0kpGCSOQzS5p8syBREefjf1K2Vw4bkTpwaR2+lt1NwkifXUwbdRr4q7HpITVTRE7+XgrXczN5X7P0C0RXfWafD5niEX48W3Zf3yv0= Received: by 10.115.55.1 with SMTP id h1mr865821wak.1185385191536; Wed, 25 Jul 2007 10:39:51 -0700 (PDT) Received: by 10.115.111.10 with HTTP; Wed, 25 Jul 2007 10:39:51 -0700 (PDT) Message-ID: <994cd1cf0707251039j7eaf167fh5851fc979ee2b60@mail.gmail.com> Date: Wed, 25 Jul 2007 23:09:51 +0530 From: "aditya kiran" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Ipsec - PF_KEY and set_policy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 18:08:17 -0000 Hi, I was just trying to understand PF_KEY interface for ipsec settings. So, setkey uses it to do that. but i could find another system call - ipsec_set_policy. Could any body let me know why there are two interfaces to configure ipsec? Thanks, Aditya From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 20:23:41 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 546B816A419 for ; Wed, 25 Jul 2007 20:23:41 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from mail.duras.ro (mail.duras.ro [86.105.56.133]) by mx1.freebsd.org (Postfix) with ESMTP id 0BE3113C467 for ; Wed, 25 Jul 2007 20:23:41 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from localhost (localhost [127.0.0.1]) by mail.duras.ro (Postfix) with ESMTP id 962358FE9 for ; Wed, 25 Jul 2007 23:23:43 +0300 (EEST) Received: from mail.duras.ro ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10102-02 for ; Wed, 25 Jul 2007 23:23:41 +0300 (EEST) Received: from [86.105.56.194] (ma.plimb.cu.barca.prin.padure.ro [86.105.56.194]) by mail.duras.ro (Postfix) with ESMTP id 73B1F2E61 for ; Wed, 25 Jul 2007 23:23:41 +0300 (EEST) Message-ID: <46A7B14B.4000603@duras.ro> Date: Wed, 25 Jul 2007 23:23:39 +0300 From: Mihai Tanasescu User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) 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: by amavisd-new-20030616-p10 (RedHat) at duras.ro Subject: MPD and fragmentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 20:23:41 -0000 Hello, With help from another FreeBSD user on this list I was able to set up an MPD pptp server to allow windows machines to connect to it. Unfortunately now I've stumbled upon some strange behaviors. First of all I'm getting icmp losses even if I use a test LAN to make a tunnel to the local FBSD machine, but these don't seem to affect my transfer rate when trying to get a large file via HTTP from the same machine. What bothers me most is that some sites (like msn.com, microsoft.com, etc) don't seem to be loading. What I first thought about was the mss problem and so I discovered the following: 22:54:36.633254 IP (tos 0x0, ttl 64, id 14254, offset 0, flags [DF], proto: ICMP (1), length: 56) FBSD-IP > 207.68.183.32: ICMP FBSD-IP unreachable - need to frag (mtu 1336), length 36 In my config file I have: set iface mtu 1500 set link mtu 1440 set iface enable tcpmssfix My full config is posted here: http://pastebin.com/m66a3c05f My system: FreeBSD 6.1-RELEASE-p17 MPD 4.1 I played a bit with the above mentioned values with no luck unfortunately. I'm still wondering (don't know if I'm right) if a too large packet comes from 207.68.183.32 why doesn't it get fragmented upon being sent via ng0 -> pptp1 and instead of this happening my machine sends an ICMP unreachable back. Also I have pf running on that machine with a NAT rule for traffic not destined to the local network (but after several experiments with that nothing changed in regard to the problem I have). I'm banging my head against the wall as I don't know what else to try anymore. Can someone help me out ? From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 21:43:42 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7901816A417 for ; Wed, 25 Jul 2007 21:43:42 +0000 (UTC) (envelope-from therior@ukr.net) Received: from ffe1.ukr.net (ffe1.ukr.net [195.214.192.7]) by mx1.freebsd.org (Postfix) with ESMTP id 0C50213C45E for ; Wed, 25 Jul 2007 21:43:42 +0000 (UTC) (envelope-from therior@ukr.net) Received: from mail by ffe1.ukr.net with local ID 1IDoNA-000AiQ-AY for freebsd-net@freebsd.org; Thu, 26 Jul 2007 00:26:20 +0300 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="windows-1251" MIME-Version: 1.0 To: freebsd-net@freebsd.org From: "freebsd kernel panic" X-Life: is great, enjoy it! X-Mailer: freemail.ukr.net mPOP 3.3 X-Originating-Ip: [194.242.59.98] X-Browser: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.4) Gecko/20070715 Firefox/2.0.0.4 Message-Id: Date: Thu, 26 Jul 2007 00:26:20 +0300 Subject: 3com 3c905c-tx Fast Etherlink Xl X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jul 2007 21:43:42 -0000 good afternoon! a computer droops from a network map! a network map is built-in, it is written on a system board, that network "1Gb"! before on freebsd 6.1 6.2 STABLE such was never, but I the world did not collect, only kernel! Tried to be connected to two channel, thought that error from a channel...! 1. I start dhclient, long thinks and does not determine Ipv4, do network configuration and routing I by hands. 2. start of Xorg: Mozilla and Firefox work in the internet - a computer hangs up. 3. mount Samba, copy a file, and after 2-10min. a computer hangs up, there was it 5-10 times. 4. ftp works normally.ok? I did not activate other interface! Tried everything that could, in delivery such is present nowhere, did not find! (it was only from 2000-2003 year) If I understood correctly, an error is in a kernel.(if_xl.c???)? In ravines (log) nothing is present about it! Tried to turn off and include apci... I want to include this network because for it speed to become very rapid what at other network maps! (at home on Adsl2+) ********************************* 3com 3c905c-tx Fast Etherlink Xl Jul 15 22:52:49 dhcppc0 kernel: xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xa400-0xa47f mem 0xf7000000-0xf700007f irq 23 at device 11.0 on pci2 Jul 15 22:52:49 dhcppc0 kernel: miibus0: on xl0 Jul 15 22:52:49 dhcppc0 kernel: e1000phy0: PHY 24 on miibus0 Jul 15 22:52:49 dhcppc0 kernel: e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Jul 15 22:52:49 dhcppc0 kernel: xl0: Ethernet address: 00:0d:87:5b:ee:b5 Jul 15 22:52:49 dhcppc0 kernel: xl0: [ITHREAD] #ifconfig ed0: flags=8843 metric 0 mtu 1500 ether 52:54:ab:13:61:56 inet 192.168.1.33 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (10baseT/UTP) xl0: flags=8802 metric 0 mtu 1500 options=9 ether 00:0d:87:5b:ee:b5 inet 192.168.1.34 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 # uname -a FreeBSD dhcppc0 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Sun Jul 15 21:51:08 EEST 2007 root@dhcppc0:/usr/obj/usr/src/sys/MYKERNEL i386 machine i386 cpu I686_CPU ident MYKERNEL # To statically compile in device wiring instead of /boot/device.hints hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=1000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options AUDIT # Security event auditing options IPFIREWALL options IPDIVERT options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE_LIMIT=5 options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options IPSTEALTH options DUMMYNET # Debugging for use in -current options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed options COMPAT_LINUX # HARDWARE DEVICE CONFIGURATION #options DEVICE_POLLING # To include support for VGA VESA video modes options VESA # Turn on extra debugging checks and output for VESA support. options VESA_DEBUG device acpi options ACPI_DEBUG #!options ACPI_NO_SEMAPHORES # ACPI Video Extensions (LCD backlight/brightness, video output, etc.) device acpi_video # Bus support. device pci # ATA and ATAPI devices device ata device atapicam device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) device vga # VGA video card driver # The following option probably won't work with the LCD displays. options VGA_WIDTH90 # support 90 column modes options VGA_DEBUG device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets device sound device snd_ich device logo_saver # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module device bpf # Berkeley packet filter device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 00:13:03 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9EB416A417 for ; Thu, 26 Jul 2007 00:13:03 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id 50B6113C45A for ; Thu, 26 Jul 2007 00:13:02 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 08:13:01 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 08:13:01 +0800 Received: from [172.23.17.155] ([172.23.17.155]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 08:13:01 +0800 Message-ID: <46A7E70E.70204@zyxel.com.tw> Date: Thu, 26 Jul 2007 08:13:02 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: aditya kiran References: <994cd1cf0707251039j7eaf167fh5851fc979ee2b60@mail.gmail.com> In-Reply-To: <994cd1cf0707251039j7eaf167fh5851fc979ee2b60@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2007 00:13:01.0239 (UTC) FILETIME=[BA701C70:01C7CF19] Cc: freebsd-net@freebsd.org Subject: Re: Ipsec - PF_KEY and set_policy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jul 2007 00:13:03 -0000 As far as I know, setkey is used for IPsec SP and SA configuration. ipsec_set_policy() could transfer a string to "policy request", which is defined in RFC 2367 PF_KEY. Internally, setkey() will call ipsec_set_policy() to construct the message then send it down to the kernel. However, ipsec_set_policy() is used only for SP, not SA. blue aditya kiran wrote: > Hi, > I was just trying to understand PF_KEY interface for ipsec settings. So, > setkey uses it to do that. but i could find another system call - > ipsec_set_policy. Could any body let me know why there are two > interfaces to > configure ipsec? > Thanks, > Aditya > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 03:13:53 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BEBE16A418 for ; Thu, 26 Jul 2007 03:13:53 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id 47F2C13C480 for ; Thu, 26 Jul 2007 03:13:52 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 11:13:51 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 11:13:52 +0800 Received: from [172.23.17.155] ([172.23.17.155]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 11:13:51 +0800 Message-ID: <46A81171.1040107@zyxel.com.tw> Date: Thu, 26 Jul 2007 11:13:53 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) 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-OriginalArrivalTime: 26 Jul 2007 03:13:51.0340 (UTC) FILETIME=[FD9A22C0:01C7CF32] Subject: SADB_X_SPDFLUSH message handling for latest version of IPsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jul 2007 03:13:53 -0000 Hi, all: Recently I found the behavior for the command "setkey -FP" is quite different for the latest version IPsec (known as FAST_IPSEC before). Before the command would erase all the existed SP entries; currently the command would not. After digging the codes, I found the state of the SP entries will be set as IPSEC_SPSTATE_DEAD, but the entries will not be unlink from the SPD. Why needs to keep the entry in SPD? Is there any special purpose? Without the removal, it's hard to tell whether the SP entry still takes effect since "setkey -PD" will not show its status. On the other hand, SA is like usual, once the "setkey -F" is typed in, the SA entries will be erased right away. Thanks. BR, blue From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 06:09:40 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72EC816A41F for ; Thu, 26 Jul 2007 06:09:40 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7B813C45A for ; Thu, 26 Jul 2007 06:09:38 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from [10.100.0.23] (vl-office.vl.net.ua [194.44.81.189]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l6Q69Lb3087006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jul 2007 09:09:30 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Message-ID: <46A83A91.9090803@aws-net.org.ua> Date: Thu, 26 Jul 2007 09:09:21 +0300 From: Artyom Viklenko Organization: Art&Co. User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Mihai Tanasescu References: <46A7B14B.4000603@duras.ro> In-Reply-To: <46A7B14B.4000603@duras.ro> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Thu, 26 Jul 2007 09:09:32 +0300 (EEST) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on alf.aws-net.org.ua X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: MPD and fragmentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jul 2007 06:09:40 -0000 Mihai Tanasescu wrote: > Hello, > > > With help from another FreeBSD user on this list I was able to set up an > MPD pptp server to allow windows machines to connect to it. > > Unfortunately now I've stumbled upon some strange behaviors. > > First of all I'm getting icmp losses even if I use a test LAN to make a > tunnel to the local FBSD machine, but these don't seem to affect my > transfer rate when trying to get a large file via HTTP from the same > machine. > > What bothers me most is that some sites (like msn.com, microsoft.com, > etc) don't seem to be loading. > What I first thought about was the mss problem and so I discovered the > following: > > 22:54:36.633254 IP (tos 0x0, ttl 64, id 14254, offset 0, flags [DF], > proto: ICMP (1), length: 56) FBSD-IP > 207.68.183.32: ICMP FBSD-IP > unreachable - need to frag (mtu 1336), length 36 > > In my config file I have: > set iface mtu 1500 > set link mtu 1440 > set iface enable tcpmssfix > > My full config is posted here: > http://pastebin.com/m66a3c05f > My system: > FreeBSD 6.1-RELEASE-p17 > MPD 4.1 > > I played a bit with the above mentioned values with no luck unfortunately. > I'm still wondering (don't know if I'm right) if a too large packet > comes from 207.68.183.32 why doesn't it get fragmented upon being sent > via ng0 -> pptp1 and instead of this happening my machine sends an ICMP > unreachable back. > Also I have pf running on that machine with a NAT rule for traffic not > destined to the local network (but after several experiments with that > nothing changed in regard to the problem I have). > > I'm banging my head against the wall as I don't know what else to try > anymore. > > Can someone help me out ? If you use PF, try to add rule scrub in all fragment rassemble no-df And VERY carefully check your ruleset. May be you block icmp in some place and PMTU doesn't work. As as last resort you can add max-mss to scrub rule. may be some value in range of 1300-1460. Sometimes it helps. -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 06:33:29 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED60A16A419 for ; Thu, 26 Jul 2007 06:33:29 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from mail.alkar.net (mail.alkar.net [195.248.191.95]) by mx1.freebsd.org (Postfix) with ESMTP id 79EA013C45A for ; Thu, 26 Jul 2007 06:33:29 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from [195.248.178.122] (HELO [192.168.3.2]) by mail.alkar.net (CommuniGate Pro SMTP 5.1.10) with ESMTPS id 813447927; Thu, 26 Jul 2007 09:33:28 +0300 Message-ID: <46A84034.30301@freebsd.org> Date: Thu, 26 Jul 2007 09:33:24 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mihai Tanasescu References: <1185405812.00779376.1185395402@10.7.7.3> In-Reply-To: <1185405812.00779376.1185395402@10.7.7.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: MPD and fragmentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jul 2007 06:33:30 -0000 Mihai Tanasescu wrote: > First of all I'm getting icmp losses even if I use a test LAN to make a > tunnel to the local FBSD machine, but these don't seem to affect my > transfer rate when trying to get a large file via HTTP from the same > machine. I have just merged small pptp windowing related patch to 6-STABLE, you can try it. Also you can try to disable windowing completely in mpd config, it is not really needed > What bothers me most is that some sites (like msn.com, microsoft.com, > etc) don't seem to be loading. > What I first thought about was the mss problem and so I discovered the > following: > > 22:54:36.633254 IP (tos 0x0, ttl 64, id 14254, offset 0, flags [DF], > proto: ICMP (1), length: 56) FBSD-IP > 207.68.183.32: ICMP FBSD-IP > unreachable - need to frag (mtu 1336), length 36 It is widely known problem whith broken PMTUD at Microsoft. They filter that ICMP packets. > In my config file I have: > set iface mtu 1500 > set link mtu 1440 There is no need to specify both. Mpd will calculate iface mtu based on link mtu. iface mtu will be used only as upper limit. > set iface enable tcpmssfix Actually that should help, but it is strange to see "need to frag (mtu 1336)" in you tcpdump. 1336 looks too small to me. What MTUs do you have around at the interfaces? > My full config is posted here: > http://pastebin.com/m66a3c05f > My system: > FreeBSD 6.1-RELEASE-p17 > MPD 4.1 MPD 4.2.2 was released some time ago. > I played a bit with the above mentioned values with no luck unfortunately. > I'm still wondering (don't know if I'm right) if a too large packet > comes from 207.68.183.32 why doesn't it get fragmented upon being sent > via ng0 -> pptp1 and instead of this happening my machine sends an ICMP > unreachable back. TCP packets usually have DF flag set which denies fragmentation. You can enable multilink PPP feature, it will give you complete 1500 bytes MTU and will process fragmentation by itself, but it will lead to bigger overhead and probably some lower peak performance. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 08:41:58 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61C9816A41B for ; Thu, 26 Jul 2007 08:41:58 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from mail.duras.ro (mail.duras.ro [86.105.56.133]) by mx1.freebsd.org (Postfix) with ESMTP id B824A13C459 for ; Thu, 26 Jul 2007 08:41:57 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from localhost (localhost [127.0.0.1]) by mail.duras.ro (Postfix) with ESMTP id 677E48CD44; Thu, 26 Jul 2007 11:41:58 +0300 (EEST) Received: from mail.duras.ro ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24444-02; Thu, 26 Jul 2007 11:41:56 +0300 (EEST) Received: from [192.168.1.130] (unknown [192.168.1.130]) by mail.duras.ro (Postfix) with ESMTP id 41B918A2F2; Thu, 26 Jul 2007 11:41:56 +0300 (EEST) Message-ID: <46A85E54.5090303@duras.ro> Date: Thu, 26 Jul 2007 11:41:56 +0300 From: Mihai Tanasescu User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Artyom Viklenko References: <46A7B14B.4000603@duras.ro> <46A83A91.9090803@aws-net.org.ua> In-Reply-To: <46A83A91.9090803@aws-net.org.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (RedHat) at duras.ro Cc: freebsd-net@freebsd.org, mav@freebsd.org Subject: Re: MPD and fragmentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jul 2007 08:41:58 -0000 Artyom Viklenko wrote: > Mihai Tanasescu wrote: >> Hello, >> >> >> With help from another FreeBSD user on this list I was able to set up >> an MPD pptp server to allow windows machines to connect to it. >> >> Unfortunately now I've stumbled upon some strange behaviors. >> >> First of all I'm getting icmp losses even if I use a test LAN to make >> a tunnel to the local FBSD machine, but these don't seem to affect my >> transfer rate when trying to get a large file via HTTP from the same >> machine. >> >> What bothers me most is that some sites (like msn.com, microsoft.com, >> etc) don't seem to be loading. >> What I first thought about was the mss problem and so I discovered >> the following: >> >> 22:54:36.633254 IP (tos 0x0, ttl 64, id 14254, offset 0, flags [DF], >> proto: ICMP (1), length: 56) FBSD-IP > 207.68.183.32: ICMP FBSD-IP >> unreachable - need to frag (mtu 1336), length 36 >> >> In my config file I have: >> set iface mtu 1500 >> set link mtu 1440 >> set iface enable tcpmssfix >> >> My full config is posted here: >> http://pastebin.com/m66a3c05f >> My system: >> FreeBSD 6.1-RELEASE-p17 >> MPD 4.1 >> >> I played a bit with the above mentioned values with no luck >> unfortunately. >> I'm still wondering (don't know if I'm right) if a too large packet >> comes from 207.68.183.32 why doesn't it get fragmented upon being >> sent via ng0 -> pptp1 and instead of this happening my machine sends >> an ICMP unreachable back. >> Also I have pf running on that machine with a NAT rule for traffic >> not destined to the local network (but after several experiments with >> that nothing changed in regard to the problem I have). >> >> I'm banging my head against the wall as I don't know what else to try >> anymore. >> >> Can someone help me out ? > > > If you use PF, try to add rule > > scrub in all fragment rassemble no-df > > And VERY carefully check your ruleset. May be you block icmp in some > place > and PMTU doesn't work. > > As as last resort you can add > max-mss to scrub rule. may be some value in > range of 1300-1460. > > Sometimes it helps. > Tried playing with the pf options. I have removed from mpd the iface mtu option and now I only have set iface mtu 1460. Still when trying to access www.msn.com (and similar sites) I see with tcpdump: After lowering the MSS from pf the communication started like this: 11:25:02.980179 IP (tos 0x0, ttl 127, id 31152, offset 0, flags [DF], proto: TCP (6), length: 48) 86.105.56.134.65390 > 207.68.183.32.80: S, cksum 0x977a (correct), 942644994:942644994(0) win 65535 (the outgoing mss got lowered to 1300) 86.105.56.134 = my test IP address on which I'm NAT-ing packets from ng0 with pf 11:25:03.190826 IP (tos 0x0, ttl 63, id 40014, offset 0, flags [none], proto: TCP (6), length: 44) 207.68.183.32.80 > 86.105.56.134.65390: S, cksum 0x5fb4 (correct), 3691466834:3691466834(0) ack 942644995 win 8190 11:25:03.191677 IP (tos 0x0, ttl 127, id 31155, offset 0, flags [DF], proto: TCP (6), length: 40) 86.105.56.134.65390 > 207.68.183.32.80: ., cksum 0x9733 (correct), 1:1(0) ack 1 win 65535 11:25:03.192210 IP (tos 0x0, ttl 127, id 31157, offset 0, flags [DF], proto: TCP (6), length: 804) 86.105.56.134.65390 > 207.68.183.32.80: P 1:765(764) ack 1 win 65535 11:25:03.422363 IP (tos 0x0, ttl 63, id 40290, offset 0, flags [DF], proto: TCP (6), length: 1440) 207.68.183.32.80 > 86.105.56.134.65390: P 1:1401(1400) ack 765 win 8190 11:25:03.422417 IP (tos 0x0, ttl 64, id 58490, offset 0, flags [DF], proto: ICMP (1), length: 56) 86.105.56.134 > 207.68.183.32: ICMP 86.105.56.134 unreachable - need to frag (mtu 1396), length 36 IP (tos 0x0, ttl 63, id 40290, offset 0, flags [DF], proto: TCP (6), length: 1440) 207.68.183.32.80 > 86.105.56.134.65390: [|tcp] The is the ng0 established MTU: ng0: flags=88d1 mtu 1396 inet 192.168.1.129 --> 192.168.1.130 netmask 0xffffffff I have upgraded MPD to 4.2 pkg_info | grep mpd mpd-4.2.2 Multi-link PPP daemon based on netgraph(4) I have disabled windowing: set pptp disable windowing I have enabled the multilink for a test: set bundle enable multilink The Ethernet interface (rl0 - 86.105.56.134) that is used both as the endpoint for tunnel connections and for NAT for anything not destined to the local net: rl0: flags=8843 mtu 1500 Also I'm upgrading the system today from 6.1 to 6.2. I tried transferring data inside my net without going through the pf NAT but unfortunately I'm not seeing any problem here that could help me replicate the icmp unreachable need frag mtu 1396 problem. Have you got any more ideas on what I should try ? From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 12:13:29 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C01DB16A420 for ; Thu, 26 Jul 2007 12:13:29 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id 505C613C465 for ; Thu, 26 Jul 2007 12:13:27 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from [10.100.0.23] (vl-office.vl.net.ua [194.44.81.189]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l6QCDBCR090289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jul 2007 15:13:16 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Message-ID: <46A88FD8.5010200@aws-net.org.ua> Date: Thu, 26 Jul 2007 15:13:12 +0300 From: Artyom Viklenko Organization: Art&Co. User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Mihai Tanasescu References: <46A7B14B.4000603@duras.ro> <46A83A91.9090803@aws-net.org.ua> <46A85E54.5090303@duras.ro> In-Reply-To: <46A85E54.5090303@duras.ro> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Thu, 26 Jul 2007 15:13:18 +0300 (EEST) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on alf.aws-net.org.ua X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: MPD and fragmentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jul 2007 12:13:29 -0000 Mihai Tanasescu wrote: > Artyom Viklenko wrote: >> If you use PF, try to add rule >> >> scrub in all fragment rassemble no-df >> >> And VERY carefully check your ruleset. May be you block icmp in some >> place >> and PMTU doesn't work. >> >> As as last resort you can add >> max-mss to scrub rule. may be some value in >> range of 1300-1460. >> >> Sometimes it helps. >> > > Tried playing with the pf options. > > I have removed from mpd the iface mtu option and now I only have set > iface mtu 1460. > > Still when trying to access www.msn.com (and similar sites) I see with > tcpdump: From my systems www.msn.com resolves in 65.54.152.126. When I connect from my book to my freebsd router with pptp - I see mtu 1396 bytes on ng interface: ng5: flags=88d1 mtu 1396 inet 192.168.35.254 --> 192.168.35.1 netmask 0xffffffff I connect to Internet via ADSL/PPPoE which runs to same freebsd router with mpd. MTU is 1496. In pf I have scrub in all fragment reassemble no-df max-mss 1452 so, mss is notaffected by max-mss when tcp connection establishes from notebook. But www.msn.com sends packets with mss = 1356 bytes which corresponds with ng interface mtu of 1396. router runs freebsd 5.5 with mpd 3.18 - yes, have plans to upgrade :) in mpd.conf my pptp server configured with pptp_std: set bundle enable compression set bundle disable multilink set bundle enable noretry set bundle max-logins 0 set bundle enable radius-auth set bundle enable radius-acct set iface disable on-demand set iface disable proxy-arp set iface idle 1800 set iface enable tcpmssfix set iface mtu 1460 set iface enable radius-idle radius-session radius-route set link yes acfcomp protocomp set link yes pap set link enable chap-md5 chap-msv1 chap-msv2 chap set link mtu 1460 set link mru 1460 set link keep-alive 10 60 set link max-redial -1 set ipcp yes vjcomp set ipcp dns 192.168.32.253 192.168.32.254 set ipcp nbns 192.168.32.253 set ipcp ranges 192.168.35.254/32 192.168.35.1/28 set ipcp enable radius-ip set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e56 set ccp yes mpp-e128 set ccp yes mpp-stateless set pptp enable incoming set pptp disable originate set pptp disable windowing set pptp disable delayed-ack set radius retries 3 set radius timeout 3 set radius server 192.168.32.253 XXXXXXXXXXXXXXX 1812 1813 set radius me 192.168.32.254 set radius acct-update 300 All works fine. :) > > After lowering the MSS from pf the communication started like this: > > 11:25:02.980179 IP (tos 0x0, ttl 127, id 31152, offset 0, flags [DF], > proto: TCP (6), length: 48) 86.105.56.134.65390 > 207.68.183.32.80: S, > cksum 0x977a (correct), 942644994:942644994(0) win 65535 1300,nop,nop,sackOK> > (the outgoing mss got lowered to 1300) > > 86.105.56.134 = my test IP address on which I'm NAT-ing packets from ng0 > with pf > > 11:25:03.190826 IP (tos 0x0, ttl 63, id 40014, offset 0, flags [none], > proto: TCP (6), length: 44) 207.68.183.32.80 > 86.105.56.134.65390: S, > cksum 0x5fb4 (correct), 3691466834:3691466834(0) ack 942644995 win 8190 > > 11:25:03.191677 IP (tos 0x0, ttl 127, id 31155, offset 0, flags [DF], > proto: TCP (6), length: 40) 86.105.56.134.65390 > 207.68.183.32.80: ., > cksum 0x9733 (correct), 1:1(0) ack 1 win 65535 > 11:25:03.192210 IP (tos 0x0, ttl 127, id 31157, offset 0, flags [DF], > proto: TCP (6), length: 804) 86.105.56.134.65390 > 207.68.183.32.80: P > 1:765(764) ack 1 win 65535 > 11:25:03.422363 IP (tos 0x0, ttl 63, id 40290, offset 0, flags [DF], > proto: TCP (6), length: 1440) 207.68.183.32.80 > 86.105.56.134.65390: P > 1:1401(1400) ack 765 win 8190 > 11:25:03.422417 IP (tos 0x0, ttl 64, id 58490, offset 0, flags [DF], > proto: ICMP (1), length: 56) 86.105.56.134 > 207.68.183.32: ICMP > 86.105.56.134 unreachable - need to frag (mtu 1396), length 36 > IP (tos 0x0, ttl 63, id 40290, offset 0, flags [DF], proto: TCP > (6), length: 1440) 207.68.183.32.80 > 86.105.56.134.65390: [|tcp] > > The is the ng0 established MTU: > > ng0: flags=88d1 mtu 1396 > inet 192.168.1.129 --> 192.168.1.130 netmask 0xffffffff > > I have upgraded MPD to 4.2 > > pkg_info | grep mpd > mpd-4.2.2 Multi-link PPP daemon based on netgraph(4) > > I have disabled windowing: > set pptp disable windowing > > I have enabled the multilink for a test: > set bundle enable multilink > > The Ethernet interface (rl0 - 86.105.56.134) that is used both as the > endpoint for tunnel connections and for NAT for anything not destined to > the local net: > rl0: flags=8843 mtu 1500 > > Also I'm upgrading the system today from 6.1 to 6.2. > > I tried transferring data inside my net without going through the pf NAT > but unfortunately I'm not seeing any problem here that could help me > replicate the icmp unreachable need frag mtu 1396 problem. > > > Have you got any more ideas on what I should try ? -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 12:18:11 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 780D116A4C6 for ; Thu, 26 Jul 2007 12:18:11 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id 1960313C46A for ; Thu, 26 Jul 2007 12:18:09 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from [10.100.0.23] (vl-office.vl.net.ua [194.44.81.189]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l6QCI3lE090340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jul 2007 15:18:04 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Message-ID: <46A890FB.8030805@aws-net.org.ua> Date: Thu, 26 Jul 2007 15:18:03 +0300 From: Artyom Viklenko Organization: Art&Co. User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Mihai Tanasescu References: <46A7B14B.4000603@duras.ro> <46A83A91.9090803@aws-net.org.ua> <46A85E54.5090303@duras.ro> <46A88FD8.5010200@aws-net.org.ua> In-Reply-To: <46A88FD8.5010200@aws-net.org.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Thu, 26 Jul 2007 15:18:05 +0300 (EEST) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on alf.aws-net.org.ua X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: MPD and fragmentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jul 2007 12:18:11 -0000 Artyom Viklenko wrote: > > I connect to Internet via ADSL/PPPoE which runs to same freebsd router > with mpd. > MTU is 1496. In pf I have Sorry, MTU is 1492 bytes, sure. :) -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 01:11:17 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3776216A417 for ; Fri, 27 Jul 2007 01:11:17 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id 6F37013C461 for ; Fri, 27 Jul 2007 01:11:15 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 09:11:12 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 09:11:13 +0800 Received: from [172.23.17.155] ([172.23.17.155]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 09:11:12 +0800 Message-ID: <46A94632.6070602@zyxel.com.tw> Date: Fri, 27 Jul 2007 09:11:14 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) 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-OriginalArrivalTime: 27 Jul 2007 01:11:12.0556 (UTC) FILETIME=[05D68EC0:01C7CFEB] Subject: IPv6 IPsec tunnel configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jul 2007 01:11:17 -0000 Dear all: I want to set up the gif tunnel for IPv6 IPsec as the Freebsd Handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html "VPN over IPsec" suggested for IPv4. However, I could not configure the local IP address via "ifconfig gif0 inet6 ", ifconfig will complain the parameters are invalid! Is there any other way to configure the IPv6 IPsec tunnel? Thanks. BR, Yi-Wen From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 01:18:18 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E687416A419 for ; Fri, 27 Jul 2007 01:18:18 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from snipe.secure-computing.net (snipe.secure-computing.net [209.240.66.149]) by mx1.freebsd.org (Postfix) with ESMTP id BA0C213C45B for ; Fri, 27 Jul 2007 01:18:18 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from [192.168.1.3] (unknown [209.240.66.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ecrist@secure-computing.net) by snipe.secure-computing.net (Postfix) with ESMTP id BFE6317026; Thu, 26 Jul 2007 20:18:17 -0500 (CDT) In-Reply-To: <46A94632.6070602@zyxel.com.tw> References: <46A94632.6070602@zyxel.com.tw> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5D49E8B3-4ECB-45FF-807C-D0EE69BCAC54@secure-computing.net> Content-Transfer-Encoding: 7bit From: Eric F Crist Date: Thu, 26 Jul 2007 20:18:15 -0500 To: blue X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org Subject: Re: IPv6 IPsec tunnel configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jul 2007 01:18:19 -0000 On Jul 26, 2007, at 8:11 PMJul 26, 2007, blue wrote: > Dear all: > > I want to set up the gif tunnel for IPv6 IPsec as the Freebsd > Handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ > ipsec.html > "VPN over IPsec" suggested for IPv4. However, I could not configure > the local IP address via > "ifconfig gif0 inet6 IPv6 address>", ifconfig will complain the parameters are invalid! > > Is there any other way to configure the IPv6 IPsec tunnel? > > Thanks. > Take a look here and see if this helps you at all: https://www.secure-computing.net/wiki/index.php/IPv6_on_FreeBSD_6.2 ----- Eric F Crist Secure Computing Networks From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 02:41:08 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A33616A417; Fri, 27 Jul 2007 02:41:08 +0000 (UTC) (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 25ACE13C459; Fri, 27 Jul 2007 02:41:08 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 440EB1A3C1A; Thu, 26 Jul 2007 19:41:05 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id E5DDABBB1; Thu, 26 Jul 2007 22:41:07 -0400 (EDT) Date: Thu, 26 Jul 2007 22:41:07 -0400 From: Kris Kennaway To: Julian Elischer Message-ID: <20070727024107.GA69300@rot26.obsecurity.org> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net> <20070720111539.U1096@fledge.watson.org> <46A100C2.1030606@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A100C2.1030606@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Robert Watson , freebsd-pf@freebsd.org, Max Laier Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2007 02:41:08 -0000 On Fri, Jul 20, 2007 at 11:36:50AM -0700, Julian Elischer wrote: > Robert Watson wrote: > > > >On Tue, 17 Jul 2007, Max Laier wrote: > > > >So far I have had 0 (zero) reports of problems since this thread began. > >Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* > >try running their firewalls without debug.mpsafenet -- ignore the > >witness warnings and/or disable witness, and let us know if you > >experience deadlocks. We're reaching the very end of the merge cycle > >for 7.0, and I would really like to remove the Giant crutches (now > >effectively unused) from the network stack so it's not part of the > >ABI/API, the code is simplified and cleaned up, etc. > > > > does "problem" include a LOR message, or only a deadlock? > I've seen plenty of the first, but not the second. Various users have reported definite deadlocks relating to uid/gid firewall rules in the past. Kris From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 02:46:27 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CE0116A419 for ; Fri, 27 Jul 2007 02:46:27 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id A113313C457 for ; Fri, 27 Jul 2007 02:46:26 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 10:46:25 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 10:46:25 +0800 Received: from [172.23.17.155] ([172.23.17.155]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 10:46:24 +0800 Message-ID: <46A95C84.4040609@zyxel.com.tw> Date: Fri, 27 Jul 2007 10:46:28 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric F Crist References: <46A94632.6070602@zyxel.com.tw> <5D49E8B3-4ECB-45FF-807C-D0EE69BCAC54@secure-computing.net> In-Reply-To: <5D49E8B3-4ECB-45FF-807C-D0EE69BCAC54@secure-computing.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2007 02:46:24.0615 (UTC) FILETIME=[527D9770:01C7CFF8] Cc: freebsd-net@freebsd.org Subject: Re: IPv6 IPsec tunnel configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jul 2007 02:46:27 -0000 Dear Eric: Thanks for your reply, but this page explains how to setup configured tunnel for IPv6 packets over IPv4 network. I need a gif0 interface whose endpoints are both IPv6 address, and the display should be like: gif0: flags=8051 mtu 1280 tunnel inet aa:bb:cc:dd::ee --> ww:xx:yy::zz inet6 11:22:33:44::11 --> 55:66:77:88::55 netmask 0xffffffffffffffff But currently I could not succeed in making the inner addresses. Eric F Crist wrote: > On Jul 26, 2007, at 8:11 PMJul 26, 2007, blue wrote: > >> Dear all: >> >> I want to set up the gif tunnel for IPv6 IPsec as the Freebsd >> Handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ >> ipsec.html >> "VPN over IPsec" suggested for IPv4. However, I could not configure >> the local IP address via >> "ifconfig gif0 inet6 > IPv6 address>", ifconfig will complain the parameters are invalid! >> >> Is there any other way to configure the IPv6 IPsec tunnel? >> >> Thanks. >> > > Take a look here and see if this helps you at all: > > https://www.secure-computing.net/wiki/index.php/IPv6_on_FreeBSD_6.2 > > > ----- > Eric F Crist > Secure Computing Networks > > > From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 06:44:27 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CCB716A417 for ; Fri, 27 Jul 2007 06:44:27 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by mx1.freebsd.org (Postfix) with ESMTP id EAAB913C442 for ; Fri, 27 Jul 2007 06:44:26 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from unknown-10-101-133-146.yahoo.com.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1-b.corp.dcn.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id l6R6XiR0034677; Thu, 26 Jul 2007 23:33:45 -0700 (PDT) Date: Fri, 27 Jul 2007 15:32:55 +0900 Message-ID: From: "George V. Neville-Neil" To: blue In-Reply-To: <46A7E70E.70204@zyxel.com.tw> References: <994cd1cf0707251039j7eaf167fh5851fc979ee2b60@mail.gmail.com> <46A7E70E.70204@zyxel.com.tw> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, aditya kiran Subject: Re: Ipsec - PF_KEY and set_policy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jul 2007 06:44:27 -0000 At Thu, 26 Jul 2007 08:13:02 +0800, blue wrote: > > As far as I know, setkey is used for IPsec SP and SA configuration. > ipsec_set_policy() could transfer a string to "policy request", which is > defined in RFC 2367 PF_KEY. Internally, setkey() will call > ipsec_set_policy() to construct the message then send it down to the > kernel. However, ipsec_set_policy() is used only for SP, not SA. > And expanding on this just a bit, there is a difference between a policy (SP) and an association (SA) which is important to understand. A policy describes something more general, such as "Between network A and network B use an IPSEC ESP tunnel for all traffic." while an association is an active communication channel like, "Between address A and address B we have a tunnel using ESP with key X." There are two databases in the kernel for this, a Security Policy Database which is manipulated using the ipsec_set_policy() routing, and a Security Association Database which is manipulated using direct calls to PF Key sockets. See RFC 2401 for a good intro to these concepts. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 06:46:29 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD7AC16A418 for ; Fri, 27 Jul 2007 06:46:29 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2-b.corp.dcn.yahoo.com (mrout2-b.corp.dcn.yahoo.com [216.109.112.28]) by mx1.freebsd.org (Postfix) with ESMTP id 88C6913C458 for ; Fri, 27 Jul 2007 06:46:29 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from unknown-10-101-133-146.yahoo.com.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l6R6a4vj003984; Thu, 26 Jul 2007 23:36:04 -0700 (PDT) Date: Fri, 27 Jul 2007 15:35:15 +0900 Message-ID: From: gnn@freebsd.org To: blue In-Reply-To: <46A81171.1040107@zyxel.com.tw> References: <46A81171.1040107@zyxel.com.tw> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: SADB_X_SPDFLUSH message handling for latest version of IPsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jul 2007 06:46:29 -0000 At Thu, 26 Jul 2007 11:13:53 +0800, blue wrote: > > Hi, all: > > Recently I found the behavior for the command "setkey -FP" is quite > different for the latest version IPsec (known as FAST_IPSEC before). > Before the command would erase all the existed SP entries; currently the > command would not. After digging the codes, I found the state of the SP > entries will be set as IPSEC_SPSTATE_DEAD, but the entries will not be > unlink from the SPD. Why needs to keep the entry in SPD? Is there any > special purpose? Without the removal, it's hard to tell whether the SP > entry still takes effect since "setkey -PD" will not show its status. On > the other hand, SA is like usual, once the "setkey -F" is typed in, the > SA entries will be erased right away. Can you give an example of this? On my test systems this works for me: dut2 ? cat /etc/ipsec.conf spdadd 10.0.0.1/32 10.0.0.2/32 any -P out ipsec esp/tunnel/10.0.0.1-10.0.0.2/require; spdadd 10.0.0.2/32 10.0.0.1/32 any -P in ipsec esp/tunnel/10.0.0.2-10.0.0.1/require; add 10.0.0.1 10.0.0.2 esp 0x1000 -E des-cbc 0x3ffe05014819ffff; dut2 ? setkey -f !$ setkey -f /etc/ipsec.conf dut2 ? setkey -DP 10.0.0.2[any] 10.0.0.1[any] any in ipsec esp/tunnel/10.0.0.2-10.0.0.1/require spid=13 seq=1 pid=72816 refcnt=1 10.0.0.1[any] 10.0.0.2[any] any out ipsec esp/tunnel/10.0.0.1-10.0.0.2/require spid=12 seq=0 pid=72816 refcnt=1 dut2 ? setkey -D 10.0.0.1 10.0.0.2 esp mode=any spi=4096(0x00001000) reqid=0(0x00000000) E: des-cbc 3ffe0501 4819ffff seq=0x00000000 replay=0 flags=0x00000040 state=mature created: Jul 22 23:10:07 2007 current: Jul 22 23:10:12 2007 diff: 5(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=72817 refcnt=1 dut2 ? setkey -FP dut2 ? setkey -DP No SPD entries. dut2 ? Best, George From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 07:38:02 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C91B916A41A; Fri, 27 Jul 2007 07:38:02 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A56B213C428; Fri, 27 Jul 2007 07:38:02 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l6R7c2ug056267; Fri, 27 Jul 2007 07:38:02 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l6R7c2jO056263; Fri, 27 Jul 2007 07:38:02 GMT (envelope-from remko) Date: Fri, 27 Jul 2007 07:38:02 GMT Message-Id: <200707270738.l6R7c2jO056263@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/114915: [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver fixes (including endianness) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jul 2007 07:38:02 -0000 Synopsis: [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver fixes (including endianness) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Fri Jul 27 07:38:01 UTC 2007 Responsible-Changed-Why: Over to the appropriate mailinglist. http://www.freebsd.org/cgi/query-pr.cgi?pr=114915 From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 07:50:31 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4215C16A417 for ; Fri, 27 Jul 2007 07:50:31 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from mail.duras.ro (mail.duras.ro [86.105.56.133]) by mx1.freebsd.org (Postfix) with ESMTP id 0114A13C48D for ; Fri, 27 Jul 2007 07:50:30 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from localhost (localhost [127.0.0.1]) by mail.duras.ro (Postfix) with ESMTP id 6E3398C50B; Fri, 27 Jul 2007 10:50:31 +0300 (EEST) Received: from mail.duras.ro ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19552-06; Fri, 27 Jul 2007 10:50:29 +0300 (EEST) Received: from [192.168.1.130] (unknown [192.168.1.130]) by mail.duras.ro (Postfix) with ESMTP id 7198A2E3B; Fri, 27 Jul 2007 10:50:29 +0300 (EEST) Message-ID: <46A9A3C7.3090908@duras.ro> Date: Fri, 27 Jul 2007 10:50:31 +0300 From: Mihai Tanasescu User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Artyom Viklenko References: <46A7B14B.4000603@duras.ro> <46A83A91.9090803@aws-net.org.ua> <46A85E54.5090303@duras.ro> <46A88FD8.5010200@aws-net.org.ua> <46A890FB.8030805@aws-net.org.ua> In-Reply-To: <46A890FB.8030805@aws-net.org.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (RedHat) at duras.ro Cc: freebsd-net@freebsd.org Subject: Re: MPD and fragmentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jul 2007 07:50:31 -0000 Artyom Viklenko wrote: > Artyom Viklenko wrote: >> >> I connect to Internet via ADSL/PPPoE which runs to same freebsd >> router with mpd. >> MTU is 1496. In pf I have > > Sorry, MTU is 1492 bytes, sure. :) > > Sorry to say ..but the problem was on my side :(. Thank you all for the trouble and the advice you provided. My setup has something like this: PPTP machine --> Cisco 3750 --> HTB Linux bridge for bandwidth limiting -- BSD router the HTB machine was already decreasing mss to 1400. I changed the value on the HTB machine from 1400 to 1300 (for a test) and now everything works like a charm. Never thought of looking there for the problem. Thanks. From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 09:28:19 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17CB916A419 for ; Fri, 27 Jul 2007 09:28:19 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id ACE3C13C4A3 for ; Fri, 27 Jul 2007 09:28:18 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 17:28:17 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 17:28:17 +0800 Received: from [172.23.17.155] ([172.23.17.155]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 17:28:16 +0800 Message-ID: <46A9BAB4.9030309@zyxel.com.tw> Date: Fri, 27 Jul 2007 17:28:20 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gnn@freebsd.org References: <46A81171.1040107@zyxel.com.tw> In-Reply-To: X-OriginalArrivalTime: 27 Jul 2007 09:28:16.0415 (UTC) FILETIME=[763E4AF0:01C7D030] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: SADB_X_SPDFLUSH message handling for latest version of IPsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jul 2007 09:28:19 -0000 gnn@freebsd.org wrote: >At Thu, 26 Jul 2007 11:13:53 +0800, >blue wrote: > > >>Hi, all: >> >>Recently I found the behavior for the command "setkey -FP" is quite >>different for the latest version IPsec (known as FAST_IPSEC before). >>Before the command would erase all the existed SP entries; currently the >>command would not. After digging the codes, I found the state of the SP >>entries will be set as IPSEC_SPSTATE_DEAD, but the entries will not be >>unlink from the SPD. Why needs to keep the entry in SPD? Is there any >>special purpose? Without the removal, it's hard to tell whether the SP >>entry still takes effect since "setkey -PD" will not show its status. On >>the other hand, SA is like usual, once the "setkey -F" is typed in, the >>SA entries will be erased right away. >> >> > >Can you give an example of this? On my test systems this works for >me: > >dut2 ? cat /etc/ipsec.conf >spdadd 10.0.0.1/32 10.0.0.2/32 any -P out ipsec esp/tunnel/10.0.0.1-10.0.0.2/require; >spdadd 10.0.0.2/32 10.0.0.1/32 any -P in ipsec esp/tunnel/10.0.0.2-10.0.0.1/require; >add 10.0.0.1 10.0.0.2 esp 0x1000 -E des-cbc 0x3ffe05014819ffff; >dut2 ? setkey -f !$ >setkey -f /etc/ipsec.conf >dut2 ? setkey -DP >10.0.0.2[any] 10.0.0.1[any] any > in ipsec > esp/tunnel/10.0.0.2-10.0.0.1/require > spid=13 seq=1 pid=72816 > refcnt=1 >10.0.0.1[any] 10.0.0.2[any] any > out ipsec > esp/tunnel/10.0.0.1-10.0.0.2/require > spid=12 seq=0 pid=72816 > refcnt=1 >dut2 ? setkey -D >10.0.0.1 10.0.0.2 > esp mode=any spi=4096(0x00001000) reqid=0(0x00000000) > E: des-cbc 3ffe0501 4819ffff > seq=0x00000000 replay=0 flags=0x00000040 state=mature > created: Jul 22 23:10:07 2007 current: Jul 22 23:10:12 2007 > diff: 5(s) hard: 0(s) soft: 0(s) > last: hard: 0(s) soft: 0(s) > current: 0(bytes) hard: 0(bytes) soft: 0(bytes) > allocated: 0 hard: 0 soft: 0 > sadb_seq=0 pid=72817 refcnt=1 >dut2 ? setkey -FP >dut2 ? setkey -DP >No SPD entries. >dut2 ? > >Best, >George > > > Hi, I was tracing the codes so had the conclusion. in key_spdflush() in key.c, the loop for (dir = 0; dir < IPSEC_DIR_MAX; dir++) { SPTREE_LOCK(); LIST_FOREACH(sp, &sptree[dir], chain) sp->state = IPSEC_SPSTATE_DEAD; SPTREE_UNLOCK(); } only sets policy entry's status as DEAD, but not remove it from the SPD. On the other hand, in KAME implementation (known as IPSEC in previous FreeBSD version), the SP entry will be removed. for (sp = TAILQ_FIRST(&sptailq); sp; sp = nextsp) { nextsp = TAILQ_NEXT(sp, tailq); if (sp->persist) continue; if (sp->state == IPSEC_SPSTATE_DEAD) continue; key_sp_dead(sp); key_sp_unlink(sp); sp = NULL; } Thanks. BR, blue From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 09:39:25 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE9CA16A41A for ; Fri, 27 Jul 2007 09:39:25 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8FB3813C46E for ; Fri, 27 Jul 2007 09:39:25 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from jayce.zen.inc (jayce.zen.inc [192.168.1.7]) by smtp.zeninc.net (smtpd) with ESMTP id EAD583F73 for ; Fri, 27 Jul 2007 11:39:22 +0200 (CEST) Received: by jayce.zen.inc (Postfix, from userid 1000) id 245582E464; Fri, 27 Jul 2007 11:39:23 +0200 (CEST) Date: Fri, 27 Jul 2007 11:39:22 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20070727093922.GA981@jayce.zen.inc> References: <46A81171.1040107@zyxel.com.tw> <46A9BAB4.9030309@zyxel.com.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A9BAB4.9030309@zyxel.com.tw> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: SADB_X_SPDFLUSH message handling for latest version of IPsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jul 2007 09:39:25 -0000 On Fri, Jul 27, 2007 at 05:28:20PM +0800, blue wrote: [....] > I was tracing the codes so had the conclusion. in key_spdflush() in key.c, > the loop > > for (dir = 0; dir < IPSEC_DIR_MAX; dir++) { > SPTREE_LOCK(); > LIST_FOREACH(sp, &sptree[dir], chain) > sp->state = IPSEC_SPSTATE_DEAD; > SPTREE_UNLOCK(); > } > > only sets policy entry's status as DEAD, but not remove it from the SPD. On > the other hand, in KAME implementation (known as IPSEC in previous FreeBSD > version), the SP entry will be removed. > > for (sp = TAILQ_FIRST(&sptailq); sp; sp = nextsp) { > nextsp = TAILQ_NEXT(sp, tailq); > if (sp->persist) > continue; > if (sp->state == IPSEC_SPSTATE_DEAD) > continue; > key_sp_dead(sp); > key_sp_unlink(sp); > sp = NULL; > } Have a look at key_sp_unlink: static void key_sp_unlink(sp) struct secpolicy *sp; { /* remove from SP index */ if (__LIST_CHAINED(sp)) { LIST_REMOVE(sp, chain); key_freesp(sp); } } For now, it has just been removed from the list. And then have a look at key_freesp: void key_freesp(sp) struct secpolicy *sp; { /* sanity check */ if (sp == NULL) panic("key_freesp: NULL pointer is passed."); sp->refcnt--; KEYDEBUG(KEYDEBUG_IPSEC_STAMP, printf("DP freesp cause refcnt--:%d SP:%p\n", sp->refcnt, sp)); if (sp->refcnt == 0) key_delsp(sp); return; } The SPD entry will only be "really" removed if it's reference count is 0. In both IPSec stacks, the memory structure can't just be removed because some other parts of the kernel may still be using it (that's why there is a reference count). They just use different ways to mark the SP entry as "obsolete", and to clean the structure when it won't be used anymore... Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 11:55:39 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A54B16A418 for ; Fri, 27 Jul 2007 11:55:39 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 0AB0513C47E for ; Fri, 27 Jul 2007 11:55:38 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 18A0D7C009E for ; Fri, 27 Jul 2007 13:55:37 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id xqYceRJoV0lN for ; Fri, 27 Jul 2007 13:55:36 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id AB8887C009D for ; Fri, 27 Jul 2007 13:55:20 +0200 (CEST) Date: Fri, 27 Jul 2007 13:55:20 +0200 From: Gergely CZUCZY To: freebsd-net@freebsd.org Message-ID: <20070727115520.GA10957@harmless.hu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline User-Agent: mutt-ng/devel-r804 (FreeBSD) Subject: more interrupts with polling(4) on em(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2007 11:55:39 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Good morning, I've noticed 33K interrupts/sec on an em(4) gigabit interface on a box. This many interrupts seemed a bit too high, so I thought I should enable polling(4). After enabling it i've got 55K per second, even higher. I've just done "ifconfig em1 polling", and by this the number of interrupts increased. options DEVICE_POLLING is in the kernel. The system is: FreeBSD lvs1.in.publishing.hu 6.2-RELEASE-p6 FreeBSD 6.2-RELEASE-p6 #2: Fri= Jul 27 10:57:50 UTC 2007 toor@pointyhat.in.publishing.hu:/usr/obj/usr/= src/sys/LVS i386 Isn't polling supposed to lower the interrupt load? What am I doing wrong here? I don't think this is the expected behaviour, at least, not by me. Sincerely, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owFlU71rFEEUjwk2gxZBsH4qmqi3e1+5u7gSoiaXcCb4lTMpLGQ/3u2O7s6sM7OX XCqxUUgQsRICklILQUT/ABFthICtYCuWlhYWvr14IegWszPvvfm99/u9N08OjwwN j+68fnvr7ObTrQOvRr54Z5LMGBFaiau6XFjlUqlMy7law6paZa9aqTTqExNebQIb 9bmX38ZnpDAojNXupeiAwTVTTGOXi/PgR67SaKYy07Em2SBulutUam64FA5wEXOB e762coXuoLKawpcBF6ED9zJpMLBSxYVxvRgZm5cygEQqQf4CY62xLoKQhvsYQLW6 QJgGlcpSo4safZACXAGYjE+chpCHrsfNbkjH9ZG8zAVPrtnQjriGxBW9fQCgEROC pRC6ZaSEiIdRAbSEFphIZmFkWAs07eIAUOQFQipjIhVSPhsudghq10EmyFPn5YbS QK22ACkqRjVKERQAuyj68Kjsv6zuZNpAIAXCcd6hqA4PiUh5kOF4gZgF4PWoFKrd RKRDlniEKTv7SXDhK3Q1BoQr01x4DbPN5dZM8/a1q4uLrSvzwPOoPsJdVAJjimzT Qfe0wYS8DptTiJeWZiHu6rLNhZ1mRElHVIYdZVC3K9aN5mLz4lLTSuswCP7HfKLi kItPMbicxVBpQLnk1BpOrQQ32zNQKZUakH+ks7qQSmLQi1zzXzKnmGlVlN6d/n+K aeUXqdDi4vISAK9O1hnJp8WYGegEOktp5KiPRkIsV6kjOdM9hcjmBtOMrVA2cBNq bSDza6tK0kr9wOm+LYckpcXdXb25ZjkMrqXo04iCh5Hb5TJT1BbCJMVNIR/MvEEJ kqJL1AgCi3s0tfOoQtrBzHrmr/dY4vLYSAfCXbPt980X6AElMWpNrBmzrKlKia0g Co7UbdTGhnk6ZJqOWsY0MKmSNIFJPgs5FcU15X00PXJwKH+pg1c+Ovzix9D2u+vO ++3lje/Lx3a8Q48ffHrzeevD0PMTv8TP6jP7YfHo71MnNz5u3j/ytfQH =m10o -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 11:39:20 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B47D16A50C for ; Fri, 27 Jul 2007 11:39:20 +0000 (UTC) (envelope-from magpasikat@yahoo.com) Received: from web44911.mail.sp1.yahoo.com (web44911.mail.sp1.yahoo.com [68.180.197.137]) by mx1.freebsd.org (Postfix) with SMTP id 03DBB13C467 for ; Fri, 27 Jul 2007 11:39:19 +0000 (UTC) (envelope-from magpasikat@yahoo.com) Received: (qmail 42156 invoked by uid 60001); 27 Jul 2007 11:39:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=cztQTPOUll6tgqqKQhuA4MJYayVnm0H0iY74IMWk012r6emZfAr6fgBP/xelCqSj7WpK1aKgs1U9VsrSq72NQ6d/pdX0tBhhdpJ/QKwKIR5dYpVERrt/ab1dUZ3awtrfGKM7CH8lOr16GM/em4Tv28gx6cUITpJY3xdntJNGQBs=; X-YMail-OSG: .ECi1sYVM1mKCS0vDamGEIZ.zveouVZMOYeGWG4Wz2xofwX0QY8L.4oqJ_KsNNKhE4Odxi9SWMBk4ytZkNI0pt4re3aMF7uLIBE- Received: from [58.71.34.137] by web44911.mail.sp1.yahoo.com via HTTP; Fri, 27 Jul 2007 04:39:19 PDT Date: Fri, 27 Jul 2007 04:39:19 -0700 (PDT) From: Martha Pasikatan To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1815166390-1185536359=:41995" Content-Transfer-Encoding: 8bit Message-ID: <716032.41995.qm@web44911.mail.sp1.yahoo.com> X-Mailman-Approved-At: Fri, 27 Jul 2007 12:20:08 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Computer hangs after creating 30,000 one2many netgraph nodes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jul 2007 11:39:20 -0000 --0-1815166390-1185536359=:41995 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I tried running a script that does nothing but create 50,000 netgraph nodes. After creating about 30,000 netgraph nodes, the computer crashes. I tried this with the tee node but it was able to successfully create 50,000 nodes. Can I know what the limits of each netgraph nodes are? How to identify when the limit has been reached? I'm using an application that makes use of the netgraph library and during stress testing it keeps hanging because of this. If anyone can give me a solution to prevent the system from hanging out of using too many netgraph nodes, that would be appreciated. I'm attaching the script I used for creating 50,000 netgraph nodes. Before running a script I created one one2many node named node0. Any help, ideas, corrections are appreciated. matt --------------------------------- Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. --0-1815166390-1185536359=:41995 Content-Type: application/octet-stream; name="create_5000_one2many.sh" Content-Transfer-Encoding: base64 Content-Description: 2095498312-create_5000_one2many.sh Content-Disposition: attachment; filename="create_5000_one2many.sh" IyEvYmluL3NoCgppPScwJwoKd2hpbGUgWyAkaSAtbGUgNTAwMDAgXQpkbwog IGVjaG8gIm5nY3RsIG1rcGVlciBub2RlJGk6IG9uZTJtYW55IG1hbnkwIG9u ZSIKICBuZ2N0bCBta3BlZXIgbm9kZSRpOiBvbmUybWFueSBtYW55MCBvbmUK ICBpMj1gZXhwciAkaSArIDFgCiAgZWNobyAibmdjdGwgbmFtZSBub2RlJGk6 bWFueTAgbm9kZSRpMiIKICBuZ2N0bCBuYW1lIG5vZGUkaTptYW55MCBub2Rl JGkyCiAgaT1gZXhwciAkaSArIDFgCmRvbmUKCg== --0-1815166390-1185536359=:41995-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 14:01:06 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 317D916A417 for ; Fri, 27 Jul 2007 14:01:06 +0000 (UTC) (envelope-from agile.quad@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mx1.freebsd.org (Postfix) with ESMTP id DFB9713C48E for ; Fri, 27 Jul 2007 14:01:05 +0000 (UTC) (envelope-from agile.quad@gmail.com) Received: by wr-out-0506.google.com with SMTP id i23so485879wra for ; Fri, 27 Jul 2007 07:01:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=XuTpJphJ9oYVe4q3HDchhwDIYqdv8PKkegfs21p5ZM3TDAe7WIXZ/nQtCQcNrzb2qt79nVPHCJQTys84iXf06XNsvBFuqVBEv/SMuQLBBlbakjsQyrxz3aiCsPPGoCTtSWu1fVKbrRj+sbhdpUyIXQnvd6N6OKKdBdR/I01sn18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Wxh6z0+3jvyZ8dX0Vt72Bf47cmUh79U2Xr6uTTXawVShxMMcz7ukL0Rl+i4daHs++UM61qSsnZYGRG9PZBDl4/1UYqM4iHdjQj89I3Nig0tgXZZ0O6weECpGpvTDhHjAgEGbUwgvQIjmsa/Ws2cydbg/OBn6cNDASIlKa0g1AdY= Received: by 10.78.56.19 with SMTP id e19mr741431hua.1185543327705; Fri, 27 Jul 2007 06:35:27 -0700 (PDT) Received: by 10.78.137.9 with HTTP; Fri, 27 Jul 2007 06:35:27 -0700 (PDT) Message-ID: Date: Fri, 27 Jul 2007 16:35:27 +0300 From: Oleg To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5712_30337467.1185543327669" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: reincarnation of bug kern/95665: [if_tun] "ping: sendto: No buffer space available" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jul 2007 14:01:06 -0000 ------=_Part_5712_30337467.1185543327669 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, I can reproduce this bug easly with tap echo server (attached here), that I was small reworked. steps (almost same): (All ip addresses/macs hardcoded in code). On first machine run echo server, on second add root@pc2# route add -net 192.168.125.1/24 ip-addr-of-first-machine and root@pc2# ping -f -n 192.168.125.2 While flood pinging, on first machine run ping for checking: root@pc1# ping 192.168.125.2 PING 192.168.125.2 (192.168.125.2): 56 data bytes 64 bytes from 192.168.125.2 : icmp_seq=0 ttl=64 time=0.554 ms 64 bytes from 192.168.125.2: icmp_seq=1 ttl=64 time=0.180 ms ... wait for a while ... ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available With best regards, Oleg Dolgov. ------=_Part_5712_30337467.1185543327669 Content-Type: application/octet-stream; name=tun_icmp_echo_reply.c Content-Transfer-Encoding: base64 X-Attachment-Id: f_f4mpfgml Content-Disposition: attachment; filename="tun_icmp_echo_reply.c" LyoKUGluZyByZXBseSBzZXJ2ZXI6LSkgdXNpbmcgVFVOIChGcmVlQlNEIDYuMCkuCgpUZXN0IG9y aWdpbmFsbHkgbWFkZSB0byB0ZXN0IHRoZSB0aHJvdXB1dCBvZiBUVU4gdXNpbmcgJ3BpbmcnIGlu IGZsb29kCnBpbmcgbW9kZS4gSG93ZXZlciB0aGVyZSBzZWVtcyB0byBiZSBhIGJ1ZyBpbiBGcmVl QlNEIHRoYXQgd2hlbiBzZW5kaW5nCmEgbWFzc2l2ZSBhbW91bnQgb2YgcmVxdWVzdHMgdG8gdGhl IG9wZW5lZCBUVU4gaW50ZXJmYWNlIGl0IHdpbGwgImhhbmciLgpQaW5nIHdpbGwgc2F5ICJwaW5n OiBzZW5kdG86IE5vIGJ1ZmZlciBzcGFjZSBhdmFpbGFibGUiCgpJIGhhdmUgc2VhcmNoZWQgZ29v Z2xlIGZvciB0aGlzIGVycm9yIGFuZCBtYW55IHBlb3BsZSBoYXZlIHJlcG9ydGVkIGl0CndpdGgg bm8gc29sdXRpb24gcHJlc2VudGVkLiBUaGUgcHJvYmxlbSBzZWVtIHRvIGV4aXN0IGZvciBhIG51 bWJlciBvZgpuZXR3b3JrIGRyaXZlcnMgKEkgc3VmZmVyIHRoaXMgd2l0aCB0aGUgbnZlIGRyaXZl ciBhcyB3ZWxsKS4gVGhpcyBpcwphIHNpbXBsZSB0ZXN0IHByb2dyYW0gdG8gcHJvZHVjZSB0aGlz IGJ1ZyB3aXRoIGEgVFVOIGludGVyZmFjZS4KClRoaXMgdGVzdCBhc3N1bWVzIHlvdSBoYXZlIGEg bGFuIHdpdGggdHdvIFBDcy4gVGhlIEZyZWVCU0QgYm94IGlzIFBDMS4KCiAgKy0tIExBTiAtLSsK ICB8ICAgICAgICAgfAogUEMxICAgICAgIFBDMgoKSSdtIGxhenkgc28gdG8gY29uZmlndXJlIHRo ZSBUVU4gaW50ZXJmYWNlIG9uIFBDMSBkbzoKIyBzeXNjdGwgbmV0LmluZXQuaXAuZm9yd2FyZGlu Zz0xCiMgY2F0IC9kZXYvdGFwCiMgXkMKIyBpZmNvbmZpZwoKWW91IHNob3VsZCBzZWUgYXQgbGVh c3Qgb25lIHRhcCBpbnRlcmZhY2UgbGlzdGVkLiBSZXBsYWNlIHRoZQpkZWZpbmUgVFVOX0RFVklD RSBpbiB0aGlzIGZpbGUgd2l0aCB0aGUgbGlzdGVkIGludGVyZmFjZS4gZS5nLgovZGV2L3RhcDEK CkNvbXBpbGUgdGhpcyBmaWxlIGxpa2UgdGhpczoKIyBnY2MgLW8gdGFwX2ljbXBfZWNob19yZXBs eSB0dW5faWNtcF9lY2hvX3JlcGx5LmMKClJ1biB0aGUgcHJvZ3JhbToKIyAuL3RhcF9pY21wX2Vj aG9fcmVwbHkKCkNvbmZpZ3VyZSB0aGUgVFVOIGludGVyZmFjZS4gVGhlIHJlYXNvbiBpdCdzIGRv bmUgbm93IGlzIGJlY2F1c2Ugd2hlbgp0aGUgVFVOIGRldmljZSBpcyBvcGVuZWQgYnkgdGhlIHBy b2dyYW0gdGhlIHJvdXRlIGlzIHJlbW92ZWQuCgpUaGUgSVAgYWRkcmVzcyAxMC4wLjAuNCBzaG91 bGQgYmUgcmVwbGFjZWQgYnkgdGhlIElQIGFkZHJlc3Mgb2YgdGhlCmV4dGVybmFsIGludGVyZmFj ZSBvZiBQQzEuCgojIGlmY29uZmlnIHRhcDEgaW5ldCAxMC4wLjAuNCAxOTIuMTY4LjI1NC4zMyBu ZXRtYXNrIDI1NS4yNTUuMjU1LjI1NSAKCk9uIFBDMSwgJ2lmY29uZmlnJyBzaG91bGQgc2hvdyB0 aGlzOgoKdGFwMTogZmxhZ3M9ODA1MTxVUCxQT0lOVE9QT0lOVCxSVU5OSU5HLE1VTFRJQ0FTVD4g bXR1IDE1MDAKICAgICAgICBpbmV0IDEwLjAuMC40IC0tPiAxOTIuMTY4LjI1NC4zMyBuZXRtYXNr IDB4ZmZmZmZmZmYgCiAgICAgICAgaW5ldDYgZmU4MDo6MjEzOmQ0ZmY6ZmU4MzplMzc4JXRhcDEg cHJlZml4bGVuIDY0IHNjb3BlaWQgMHg2IAogICAgICAgIE9wZW5lZCBieSBQSUQgMTI1MwoKJ25l dHN0YXQgLW5yJyBzaG91bGQgc2hvdyB0aGlzOgoKMTkyLjE2OC4yNTQuMzMgICAgIDEwLjAuMC40 ICAgICAgICAgICBVSCAgICAgICAgICAwICAgICAgICAwICAgdGFwMQoKT2theSwgbm93IHRvIHRo ZSB0ZXN0cy4gSWYgeW91IGZsb29kIHBpbmcgdGhpcyBwcm9ncmFtIGxvY2FsbHkgZnJvbQpQQzEg eW91IHdpbGwgc3VmZmVyIGZyb20gdGhlICJObyBidWZmZXIgc3BhY2UgYXZhaWxhYmxlIiBzeW5k cm9tZQphZnRlciBzb21lIFggdGhvdXNhbmQgcGFja2V0cy4gSWYgeW91IG9uIHRoZSBvdGhlciBo YW5kIGZsb29kIHBpbmcKZnJvbSBQQzIgb3ZlciB0aGUgTEFOIGV2ZXJ5dGhpbmcgd2lsbCBiZSBk YW5keS4gUHJvYmFibHkgYmVjYXVzZSB0aGUKTEFOIGlzIHNsb3dlci4gSSBoYXZlIHNlbnQgMSww MDAsMDAwIHBhY2tldHMgdGhpcyB3YXkgd2l0aCBubyBwcm9ibGVtLgoKRG8gdGhpcyBsb2NhbGx5 OgojIHBpbmcgLWMgMTAwMDAwIC1zIDk3MiAtZiAtbiAtcSAxOTIuMTY4LjI1NC4zMwoKWW91IGNh biBydW4gdGhlICdpZnN0YXQnIHByb2dyYW0gaW4gYW5vdGhlciB0ZXJtaW5hbCB3aW5kb3cgdG8g c2VlCndoZW4gbm90aGluZyBnb2VzIHRvIHRoZSBUVU4gaW50ZXJmYWNlIGFueW1vcmUuCgpJZiB0 aGUgcGluZyBjb21tYW5kIGFib3ZlIHNlZW0gdG8gaGF2ZSBmcm96ZW4sIGRvIGEgXkMgdG8gYWJv cnQgaXQuCklmIGl0IGRvZXNuJ3QgZnJlZXplLCB1cCB0aGUgbnVtYmVyIG9mIHBhY2tldHMgdG8g c2VuZC4KCiMgcGluZyAxOTIuMTY4LjI1NC4zMwpQSU5HIDE5Mi4xNjguMjU0LjMzICgxOTIuMTY4 LjI1NC4zMyk6IDU2IGRhdGEgYnl0ZXMKcGluZzogc2VuZHRvOiBObyBidWZmZXIgc3BhY2UgYXZh aWxhYmxlCnBpbmc6IHNlbmR0bzogTm8gYnVmZmVyIHNwYWNlIGF2YWlsYWJsZQoKVm9pbGEhCgpT ZW5kaW5nIGZld2VyIHBhY2tldHMgKHNvIHBpbmcgZG9lc24ndCBoYW5nKSBjb25maXJtIHRoYXQg bm8gcGFja2V0cwphcmUgbG9zdC4gU28gSSBkb24ndCBzZWUgaG93IGFueSBidWZmZXIgc3BhY2Ug Y291bGQgYmUgdXNlZCB1cC4KCiMgcGluZyAtYyAyMDAwMCAtcyA5NzIgLWYgLW4gLXEgMTkyLjE2 OC4yNTQuMzMKUElORyAxOTIuMTY4LjI1NC4zMyAoMTkyLjE2OC4yNTQuMzMpOiA5NzIgZGF0YSBi eXRlcwoKLS0tIDE5Mi4xNjguMjU0LjMzIHBpbmcgc3RhdGlzdGljcyAtLS0KMjAwMDAgcGFja2V0 cyB0cmFuc21pdHRlZCwgMjAwMDAgcGFja2V0cyByZWNlaXZlZCwgMCUgcGFja2V0IGxvc3MKcm91 bmQtdHJpcCBtaW4vYXZnL21heC9zdGRkZXYgPSAwLjAxMy8wLjAyMC8wLjE5MS8wLjAwNCBtcwoK ClRvIHBpbmcgZnJvbSBQQzIgeW91IGhhdmUgdG8gc2V0dXAgYSByb3V0ZSB0byBQQzEgb2YgY291 cnNlIGJ1dCBJIGRvbid0CmRlc2NyaWJlIGhvdyB0byBkbyB0aGF0LgoKUmVtZW1iZXIgdGhhdCB5 b3UgaGF2ZSB0byBjb25maWd1cmUgdGhlIHRhcCBpbnRlcmZhY2Ugd2l0aCBpZmNvbmZpZwpldmVy eXRpbWUgeW91IHJlc3RhcnQgdGhpcyBwcm9ncmFtIChzaW5jZSB0aGUgcm91dGUgaXMgcmVtb3Zl ZCB3aGVuCnRoZSB0YXAgaW50ZXJmYWNlIGlzIG9wZW5lZCkuCgpTb21lIGluZm9ybWF0aW9uIGFi b3V0IFBDMSBpbiBteSBjYXNlOgpDUFU6IEFNRCBBdGhsb24odG0pIDY0IFgyIER1YWwgQ29yZSBQ cm9jZXNzb3IgMzgwMCsgKDIwMTAuMzEtTUh6IDY4Ni1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkF1 dGhlbnRpY0FNRCIgIElkID0gMHgyMGZiMSAgU3RlcHBpbmcgPSAxCiAgRmVhdHVyZXM9MHgxNzhi ZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdF LE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVMKSCxNTVgsRlhTUixTU0UsU1NFMixIVFQ+CiAgRmVh dHVyZXMyPTB4MTxTU0UzPgogIEFNRCBGZWF0dXJlcz0weGUyNTAwODAwPFNZU0NBTEwsTlgsTU1Y Kyw8YjI1PixMTSwzRE5vdyssM0ROb3c+CiAgSHlwZXJ0aHJlYWRpbmc6IDIgbG9naWNhbCBDUFVz CnJlYWwgbWVtb3J5ICA9IDEwNzM2NzYyODggKDEwMjMgTUIpCmF2YWlsIG1lbW9yeSA9IDEwMzcz OTM5MjAgKDk4OSBNQikKQUNQSSBBUElDIFRhYmxlOiA8TnZpZGlhIEFXUkRBQ1BJPgpGcmVlQlNE L1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiAyIENQVXMKIGNwdTAgKEJTUCk6 IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAxCiovCgojaW5jbHVkZSA8c3RkaW8u aD4KI2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5jbHVkZSA8ZmNudGwuaD4KCiNpbmNsdWRlIDxzeXMv dHlwZXMuaD4KI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KI2luY2x1ZGUgPG5ldC9ldGhlcm5ldC5o PgojaW5jbHVkZSA8bmV0L2lmX2FycC5oPgoKdHlwZWRlZiB1bnNpZ25lZCBjaGFyICBVODsKdHlw ZWRlZiB1bnNpZ25lZCBzaG9ydCBVMTY7CnR5cGVkZWYgdW5zaWduZWQgaW50ICAgVTMyOwoKI2Rl ZmluZSBUQVBfREVWSUNFICAgInRhcDMiCiNkZWZpbmUgVEFQX01BQyAgICAgICIwMDoxMzpFQzow MDowMDpBRSIKI2RlZmluZSBUQVBfSVAgICAgICAgIjE5Mi4xNjguMTI1LjIiCgojZGVmaW5lIFRB UF9JTkVUICAgICAiMTkyLjE2OC4xMjUuMSIKI2RlZmluZSBUQVBfSU5FVF9NQUMgIjAwOjEzOkVD OjEyOjM0OjU2IgojZGVmaW5lIFRBUF9NQVNLICAgICAiMjU1LjI1NS4yNTUuMCIKI2RlZmluZSBU QVBfQkNBU1QgICAgIjE5Mi4xNjguMTI1LjI1NSIKCnR5cGVkZWYgc3RydWN0CnsKICAgIFU4ICB2 ZXJfaGRyX2xlbjsgICAgIC8qIFZlcnNpb24sIEhlYWRlciBMZW5ndGggKGluIHdvcmRzKSAqLwog ICAgVTggIHRvczsgICAgICAgICAgICAgLyogVHlwZSBvZiBTZXJ2aWNlICovCiAgICBVMTYgcGt0 X2xlbjsgICAgICAgICAvKiBQYWNrZXQgTGVuZ3RoIChpbiBieXRlcykgKi8KICAgIFUxNiBpZDsg ICAgICAgICAgICAgIC8qIElkZW50aWZpY2F0aW9uICovCiAgICBVMTYgZmxhZ3NfZnJhZ19vZmY7 ICAvKiBGbGFncywgRnJhZ21lbnQgT2Zmc2V0Ki8KICAgIFU4ICB0dGw7ICAgICAgICAgICAgIC8q IFRpbWUgdG8gTGl2ZSAqLwogICAgVTggIHByb3RvOyAgICAgICAgICAgLyogUHJvdG9jb2xsICov CiAgICBVMTYgY2tzdW07ICAgICAgICAgICAvKiBIZWFkZXIgQ2hlY2tzdW0gKi8KICAgIFUzMiBz X2FkZHI7ICAgICAgICAgIC8qIFNvdXJjZSBBZGRyZXNzICovCiAgICBVMzIgZF9hZGRyOyAgICAg ICAgICAvKiBEZXN0aW5hdGlvbiBBZGRyZXNzICovCn0gSXBIZWFkZXJfdDsKCnR5cGVkZWYgc3Ry dWN0CnsKICAgIFU4ICB0eXBlOwogICAgVTggIGNvZGU7CiAgICBVMTYgY2tzdW07CiAgICBVMTYg aWQ7CiAgICBVMTYgc2Vxbm87Cn0gSWNtcEhlYWRlcl90OwoKVTMyIElwSGVhZGVyX0dldEhlYWRl ckxlbmd0aChJcEhlYWRlcl90KiBwKTsKClUzMiBJcEhlYWRlcl9HZXRQYWNrZXRMZW5ndGgoSXBI ZWFkZXJfdCogcCk7CgpVMzIgSXBIZWFkZXJfR2V0UHJvdG9jb2xsKElwSGVhZGVyX3QqIHApOwoK dm9pZCBJcEhlYWRlcl9Td2FwQWRkcihJcEhlYWRlcl90KiBwKTsKCnZvaWQgRXRoSGVhZGVyX1N3 YXBNYWMoc3RydWN0IGV0aGVyX2hlYWRlciogcCk7Cgp2b2lkIEFycEhlYWRlcl9Td2FwQWRkcihz dHJ1Y3QgYXJwaGRyICpwKTsKClUxNiBJcENrc3VtKFUxNiogZGF0YSwgaW50IG5fYnl0ZXMpOwoK dm9pZCBIZXhEdW1wKFU4KiBwLCBpbnQgbl9ieXRlcyk7CgovKgogKiBSZWFkIGZyb20gcHJldmlv dXNseSBzZXR1cCAvZGV2L3RhcFggZGV2aWNlLCBjYWxjdWxhdGUgSUNNUCBlY2hvIHJlcGx5IGFu ZCB3cml0ZSBpdCBiYWNrLgogKi8KaW50IG1haW4gKCkKewogICAgSXBIZWFkZXJfdCogICBpcF9o ZHI7CiAgICBJY21wSGVhZGVyX3QqIGljbXBfaGRyOwogICAgVTMyIGJ1Zls0MDBdOyAgLyogU2hv dWxkIGNvdmVyIE1UVSA9IDE1MDAgKi8KICAgIFUzMiBzX2FkZHI7CiAgICBVMzIgaXBfaGRyX2xl bjsKICAgIFUzMiBpcF9wa3RfbGVuOwogICAgVTMyIGljbXBfcGt0X2xlbjsKICAgIGludCB0YXBf ZmQ7CiAgICBpbnQgbl9wa3RzID0gMDsKCXN0cnVjdCBldGhlcl9oZWFkZXIgKmV0aF9oZHI7Cglz dHJ1Y3QgYXJwaGRyICphcnBfaGRyOwoKICAgIHRhcF9mZCA9IG9wZW4oIi9kZXYvIlRBUF9ERVZJ Q0UsIE9fUkRXUik7CiAgICBpZiAodGFwX2ZkID09IC0xKQogICAgewogICAgICAgIHBlcnJvcigi ZmFpbGVkIHRvIG9wZW4gL2Rldi8iIFRBUF9ERVZJQ0UgIlxuIik7CiAgICAgICAgZXhpdCgxKTsK ICAgIH0KCglpZiAoc3lzdGVtKCJpZmNvbmZpZyAiIFRBUF9ERVZJQ0UgIiBsaW5rICIgVEFQX0lO RVRfTUFDKSAhPSAwIHx8CgkJc3lzdGVtKCJpZmNvbmZpZyAiIFRBUF9ERVZJQ0UgIiBpbmV0ICIg VEFQX0lORVQgIiBuZXRtYXNrICIgVEFQX01BU0sgIiBicm9hZGNhc3QgIiBUQVBfQkNBU1QpICE9 IDApCgl7CgkJcHJpbnRmKCJjYW50IGNvbmZpZ3VyZSAiIFRBUF9ERVZJQ0UgIiBkZXZpY2VcbiIp OwoJCWV4aXQoMik7Cgl9CgogICAgLyogcGFja2V0IChwa3QpID0gaGVhZGVyIChoZHIpICsgcGF5 bG9hZCAqLwogICAgCiAgICB3aGlsZSAoKGlwX3BrdF9sZW4gPSByZWFkKHRhcF9mZCwgYnVmLCBz aXplb2YoYnVmKSkpID49IHNpemVvZihJcEhlYWRlcl90KSkKICAgIHsKCQkvL3ByaW50ZigicmVh ZGVkICVkXG4iLCBpcF9wa3RfbGVuKTsKCQlldGhfaGRyID0gKHN0cnVjdCBldGhlcl9oZWFkZXIq KSBidWY7CgkJaWYgKG50b2hzKGV0aF9oZHItPmV0aGVyX3R5cGUpID09IEVUSEVSVFlQRV9BUlAp IHsKCQkJYXJwX2hkciA9IChzdHJ1Y3QgYXJwaGRyKikgKGV0aF9oZHIrMSk7CgkJCWlmIChudG9o cyhhcnBfaGRyLT5hcl9vcCkgIT0gQVJQT1BfUkVRVUVTVCkgewoJCQkJcHJpbnRmKCJFOiB1bmtu b3duIGFycCBvcCAweCUwOFhcbiIsIGFycF9oZHItPmFyX29wKTsKCQkJCWNvbnRpbnVlOwoJCQl9 CgkJCWlmIChpbmV0X2FkZHIoVEFQX0lQKSAhPSAqKHVfbG9uZyopYXJfdHBhKGFycF9oZHIpKSB7 CgkJCQlwcmludGYoIkU6IG5vdCBteSBpcCBhZGRyZXNzICVzXG4iLCBpbmV0X250b2EoKih1X2xv bmcqKWFyX3RwYShhcnBfaGRyKSkpOwoJCQkJY29udGludWU7CgkJCX0KCQkJYXJwX2hkci0+YXJf b3AgPSBodG9ucyhBUlBPUF9SRVBMWSk7CgkJCW1lbWNweShhcl90aGEoYXJwX2hkciksIGV0aGVy X2F0b24oVEFQX01BQyksIEVUSEVSX0FERFJfTEVOKTsKCQkJQXJwSGVhZGVyX1N3YXBBZGRyKGFy cF9oZHIpOwoJCQkvL21lbWNweShldGhfaGRyLT5ldGhlcl9kaG9zdCwgZXRoZXJfYXRvbihUQVBf TUFDKSwgRVRIRVJfQUREUl9MRU4pOwoJCQlFdGhIZWFkZXJfU3dhcE1hYyhldGhfaGRyKTsKCQkJ d3JpdGUodGFwX2ZkLCBidWYsIGlwX3BrdF9sZW4pOwoJCQkvL3ByaW50ZigiYXJwIHJlcGx5IHNl bmRlZCAoJWx1KVxuIiwgaXBfcGt0X2xlbik7CgkJCWNvbnRpbnVlOwoJCX0KCQlpZiAobnRvaHMo ZXRoX2hkci0+ZXRoZXJfdHlwZSkgIT0gRVRIRVJUWVBFX0lQKSB7CgkJCXByaW50ZigiRTogdW5r bm93biBwYWNrZXQgMHglMDhYXG4iLCBldGhfaGRyLT5ldGhlcl90eXBlKTsKCQkJY29udGludWU7 CgkJfQogICAgICAgIGlwX2hkciAgICAgICA9IChJcEhlYWRlcl90KikoZXRoX2hkcisxKTsKICAg ICAgICBpcF9oZHJfbGVuICAgPSBJcEhlYWRlcl9HZXRIZWFkZXJMZW5ndGgoaXBfaGRyKTsKICAg ICAgICBpY21wX2hkciAgICAgPSAoSWNtcEhlYWRlcl90KikoKGNoYXIqKWlwX2hkciArIGlwX2hk cl9sZW4qNCk7CiAgICAgICAgaWNtcF9wa3RfbGVuID0gaXBfcGt0X2xlbiAtIChpcF9oZHJfbGVu ICogNCk7CgogICAgICAgIGlmIChpcF9wa3RfbGVuIC0gRVRIRVJfSERSX0xFTiAhPSBJcEhlYWRl cl9HZXRQYWNrZXRMZW5ndGgoaXBfaGRyKSkKICAgICAgICB7CiAgICAgICAgICAgIHByaW50Zigi RTogcmVhZCBkYXRhIGxlbmd0aCBkb2VzIG5vdCBtYXRjaCBJUCBwYWNrZXQgbGVuZ3RoICglZCAl ZClcbiIsCiAgICAgICAgICAgICAgICAgICBpcF9wa3RfbGVuLCBJcEhlYWRlcl9HZXRQYWNrZXRM ZW5ndGgoaXBfaGRyKSk7CiAgICAgICAgICAgIGNvbnRpbnVlOwogICAgICAgIH0KICAgICAgICAK ICAgICAgICBpZiAoSXBIZWFkZXJfR2V0UHJvdG9jb2xsKGlwX2hkcikgIT0gMSkKICAgICAgICB7 CiAgICAgICAgICAgIHByaW50ZigiRTogTm8gSUNNUCBJUCBwYWNrZXQhIik7CiAgICAgICAgICAg IGNvbnRpbnVlOwogICAgICAgIH0KICAgICAgICAKICAgICAgICBpZiAoaWNtcF9wa3RfbGVuIDwg c2l6ZW9mKCppY21wX2hkcikpCiAgICAgICAgewogICAgICAgICAgICBwcmludGYoIkU6IE5vIElD TVAgZGF0YSBpbiBJUCBwYWNrZXQhXG4iKTsKICAgICAgICAgICAgY29udGludWU7CiAgICAgICAg fQogICAgICAgIAogICAgICAgIGlmIChpY21wX2hkci0+dHlwZSAhPSA4KQogICAgICAgIHsKICAg ICAgICAgICAgcHJpbnRmKCJFOiBObyBJQ01QIGVjaG8gbWVzc2FnZSBuX3BrdHM9JWQhXG4iLCBu X3BrdHMpOwogICAgICAgICAgICBjb250aW51ZTsKICAgICAgICB9CgogICAgICAgIElwSGVhZGVy X1N3YXBBZGRyKGlwX2hkcik7CiAgICAgICAgCiAgICAgICAgaWNtcF9oZHItPnR5cGUgID0gMDsK ICAgICAgICBpY21wX2hkci0+Y2tzdW0gPSAwOwoKICAgICAgICBpY21wX2hkci0+Y2tzdW0gPSBJ cENrc3VtKChVMTYqKWljbXBfaGRyLCBpY21wX3BrdF9sZW4pOwoKCQlFdGhIZWFkZXJfU3dhcE1h YyhldGhfaGRyKTsKCiAgICAgICAgLyogU2VuZCBiYWNrIHBhY2tldC4gKi8KICAgICAgICB3cml0 ZSh0YXBfZmQsIGJ1ZiwgaXBfcGt0X2xlbik7CiAgICAgICAgCiAgICAgICAgbl9wa3RzKys7CiAg ICB9CiAgICAKICAgIHByaW50ZigiVGhhdCdzIGVub3VnaCBmb3IgdG9kYXkga2lkcyFcbiIpOwog ICAgCiAgICBjbG9zZSh0YXBfZmQpOwogICAgCiAgICByZXR1cm4gMDsKfQoKCi8qIEdldCBoZWFk ZXIgbGVuZ3RoIGluIDQgYnl0ZSB3b3Jkcy4gKi8KVTMyIElwSGVhZGVyX0dldEhlYWRlckxlbmd0 aChJcEhlYWRlcl90KiBwKQp7CiAgICByZXR1cm4gcC0+dmVyX2hkcl9sZW4gJiAweDBGOwp9CgpV MzIgSXBIZWFkZXJfR2V0UGFja2V0TGVuZ3RoKElwSGVhZGVyX3QqIHApCnsKICAgIHJldHVybiBu dG9ocyhwLT5wa3RfbGVuKTsKfQoKVTMyIElwSGVhZGVyX0dldFByb3RvY29sbChJcEhlYWRlcl90 KiBwKQp7CiAgICByZXR1cm4gcC0+cHJvdG87Cn0KCnZvaWQgSXBIZWFkZXJfU3dhcEFkZHIoSXBI ZWFkZXJfdCogcCkKewogICAgVTMyIHNfYWRkciA9IHAtPnNfYWRkcjsKICAgIHAtPnNfYWRkciAg PSBwLT5kX2FkZHI7CiAgICBwLT5kX2FkZHIgID0gc19hZGRyOwp9Cgp2b2lkIEV0aEhlYWRlcl9T d2FwTWFjKHN0cnVjdCBldGhlcl9oZWFkZXIqIHApCnsKCXVfY2hhciBldGhlcl9ob3N0W0VUSEVS X0FERFJfTEVOXTsKCgltZW1jcHkoZXRoZXJfaG9zdCwgICAgIHAtPmV0aGVyX2Rob3N0LCBFVEhF Ul9BRERSX0xFTik7CgltZW1jcHkocC0+ZXRoZXJfZGhvc3QsIHAtPmV0aGVyX3Nob3N0LCBFVEhF Ul9BRERSX0xFTik7CgltZW1jcHkocC0+ZXRoZXJfc2hvc3QsIGV0aGVyX2hvc3QsICAgICBFVEhF Ul9BRERSX0xFTik7Cn0KCnZvaWQgQXJwSGVhZGVyX1N3YXBBZGRyKHN0cnVjdCBhcnBoZHIgKnAp CnsKCWNhZGRyX3Qgc2hhID0gYXJfc2hhKHApOwoJY2FkZHJfdCB0aGEgPSBhcl90aGEocCk7Cglz aXplX3QgY29uc3QgdHN6ID0gcC0+YXJfaGxuICsgcC0+YXJfcGxuOwoJY2FkZHJfdCB0ID0gbWFs bG9jKHRzeik7CgltZW1jcHkodCwgc2hhLCB0c3opOwoJbWVtY3B5KHNoYSwgdGhhLCB0c3opOwoJ bWVtY3B5KHRoYSwgdCwgdHN6KTsKCWZyZWUodCk7Cn0KCnZvaWQgSGV4RHVtcChVOCogcCwgaW50 IG5fYnl0ZXMpCnsKCXdoaWxlKG5fYnl0ZXMtLSkgewoJCXByaW50ZigiJTAyWCAiLCAoaW50KSAq cCsrKTsKCX0KCXByaW50ZigiXG4iKTsKfQoKCi8qKgogKiBDaGVja3N1bSByb3V0aW5lIGZvciBJ bnRlcm5ldCBQcm90b2NvbCBmYW1pbHkgaGVhZGVycyAoQyBWZXJzaW9uKQogKgogKiBAcGFyYW0g ZGF0YSAgICAgUG9pbnRlciB0byBkYXRhIHRvIGNhbGN1bGF0ZSBjaGVja3N1bSBmb3IuCiAqIEBw YXJhbSBuX2J5dGVzICBMZW5ndGggaW4gYnl0ZXMuCiAqLwpVMTYgSXBDa3N1bShVMTYqIGRhdGEs IGludCBuX2J5dGVzKQp7CiAgICBpbnQgbmxlZnQ7CiAgICBpbnQgc3VtOwogICAgVTE2ICp3Owog ICAgdW5pb24gewogICAgICAgIFUxNiB1czsKICAgICAgICBVOCAgdWNbMl07CiAgICB9IGxhc3Q7 CiAgICBVMTYgYW5zd2VyOwoKICAgIG5sZWZ0ID0gbl9ieXRlczsKICAgIHN1bSA9IDA7CiAgICB3 ID0gZGF0YTsKCiAgICAvKgogICAgICogT3VyIGFsZ29yaXRobSBpcyBzaW1wbGUsIHVzaW5nIGEg MzIgYml0IGFjY3VtdWxhdG9yIChzdW0pLCB3ZSBhZGQKICAgICAqIHNlcXVlbnRpYWwgMTYgYml0 IHdvcmRzIHRvIGl0LCBhbmQgYXQgdGhlIGVuZCwgZm9sZCBiYWNrIGFsbCB0aGUKICAgICAqIGNh cnJ5IGJpdHMgZnJvbSB0aGUgdG9wIDE2IGJpdHMgaW50byB0aGUgbG93ZXIgMTYgYml0cy4KICAg ICAqLwogICAgd2hpbGUgKG5sZWZ0ID4gMSkKICAgIHsKICAgICAgICBzdW0gKz0gKncrKzsKICAg ICAgICBubGVmdCAtPSAyOwogICAgfQoKICAgIC8qIG1vcCB1cCBhbiBvZGQgYnl0ZSwgaWYgbmVj ZXNzYXJ5ICovCiAgICBpZiAobmxlZnQgPT0gMSkKICAgIHsKICAgICAgICBsYXN0LnVjWzBdID0g KihVOCAqKXc7CiAgICAgICAgbGFzdC51Y1sxXSA9IDA7CiAgICAgICAgc3VtICs9IGxhc3QudXM7 CiAgICB9CgogICAgLyogYWRkIGJhY2sgY2Fycnkgb3V0cyBmcm9tIHRvcCAxNiBiaXRzIHRvIGxv dyAxNiBiaXRzICovCiAgICBzdW0gPSAoc3VtID4+IDE2KSArIChzdW0gJiAweGZmZmYpOyAgICAg LyogYWRkIGhpIDE2IHRvIGxvdyAxNiAqLwogICAgc3VtICs9IChzdW0gPj4gMTYpOyAgICAgICAg ICAgICAgICAgICAgIC8qIGFkZCBjYXJyeSAqLwogICAgYW5zd2VyID0gfnN1bTsgICAgICAgICAg ICAgICAgICAgICAgICAgIC8qIHRydW5jYXRlIHRvIDE2IGJpdHMgKi8KICAgIAogICAgcmV0dXJu KGFuc3dlcik7Cn0K ------=_Part_5712_30337467.1185543327669-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 15:57:38 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7339B16A41A for ; Fri, 27 Jul 2007 15:57:38 +0000 (UTC) (envelope-from lee@wildcard.net.uk) Received: from ded.office.wildcard.net.uk (ded.office.wildcard.net.uk [82.138.232.50]) by mx1.freebsd.org (Postfix) with ESMTP id C9C1413C45A for ; Fri, 27 Jul 2007 15:57:37 +0000 (UTC) (envelope-from lee@wildcard.net.uk) Received: from [192.168.15.3] (gate.int.office.wildcard.net.uk [192.168.15.3]) by ded.office.wildcard.net.uk (8.13.3/8.13.3) with ESMTP id l6RFZTFf023326 for ; Fri, 27 Jul 2007 16:35:29 +0100 (BST) (envelope-from lee@wildcard.net.uk) Message-ID: <46AA1082.6010503@wildcard.net.uk> Date: Fri, 27 Jul 2007 16:34:26 +0100 From: Lee Johnston User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 31-Bit IPv4 Prefixes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jul 2007 15:57:38 -0000 Hi all, We've just been allocated a /31 for a point-to-point over ethernet. Any idea if FreeBSD supports 31-bit prefixes as per RFC 3021? All I'm getting are: arp: 00:02:4a:9c:b8:81 attempts to modify permanent entry for xx.xx.xx.xx on em2.3211 Regards, Lee. -- Lee Johnston Wildcard Networks Tel: +44 (0)845 165 1510 Fax: +44 (0)845 165 1511 DDI: +44 (0)191 580 1011 Email: lee@wildcard.net.uk Web: http://www.wildcard.net.uk/ From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 23:02:52 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66C8C16A417 for ; Fri, 27 Jul 2007 23:02:52 +0000 (UTC) (envelope-from m.oe@x-trader.de) Received: from mxpool.hostedoffice.ag (fw1.hostedoffice.ag [81.20.90.82]) by mx1.freebsd.org (Postfix) with ESMTP id EB7DC13C45B for ; Fri, 27 Jul 2007 23:02:51 +0000 (UTC) (envelope-from m.oe@x-trader.de) Received: from qhexhub1.hosting.inetserver.de (10.20.10.20) by activesync.hostedoffice.ag (10.20.9.11) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sat, 28 Jul 2007 00:52:14 +0200 Received: from [192.168.100.100] (84.177.229.163) by mail.hostedoffice.ag (10.20.10.20) with Microsoft SMTP Server id 8.0.685.24; Sat, 28 Jul 2007 00:51:59 +0200 Message-ID: <46AA7710.2070803@x-trader.de> Date: Sat, 28 Jul 2007 00:52:00 +0200 From: Markus Oestreicher User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gergely CZUCZY References: <20070727115520.GA10957@harmless.hu> In-Reply-To: <20070727115520.GA10957@harmless.hu> Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: more interrupts with polling(4) on em(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2007 23:02:52 -0000 Gergely CZUCZY schrieb: > Good morning, > > I've noticed 33K interrupts/sec on an em(4) gigabit interface on > a box. This many interrupts seemed a bit too high, so I thought > I should enable polling(4). After enabling it i've got 55K per > second, even higher. > > I've just done "ifconfig em1 polling", and by this the number > of interrupts increased. How does vmstat -i look like before and after? Markus From owner-freebsd-net@FreeBSD.ORG Sat Jul 28 06:26:07 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85C8916A417; Sat, 28 Jul 2007 06:26:07 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6D5EE13C468; Sat, 28 Jul 2007 06:26:07 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (andre@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l6S6Q7w0036968; Sat, 28 Jul 2007 06:26:07 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l6S6Q771036964; Sat, 28 Jul 2007 06:26:07 GMT (envelope-from andre) Date: Sat, 28 Jul 2007 06:26:07 GMT Message-Id: <200707280626.l6S6Q771036964@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org From: andre@FreeBSD.org Cc: Subject: Re: kern/112612: [lo] Traffic via additional lo(4) interface shows up on lo0 in bpf(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 06:26:07 -0000 Synopsis: [lo] Traffic via additional lo(4) interface shows up on lo0 in bpf(4) Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Sat Jul 28 06:25:45 UTC 2007 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=112612 From owner-freebsd-net@FreeBSD.ORG Sat Jul 28 16:34:01 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C1F216A419 for ; Sat, 28 Jul 2007 16:34:01 +0000 (UTC) (envelope-from netslists@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.227]) by mx1.freebsd.org (Postfix) with ESMTP id 2152713C461 for ; Sat, 28 Jul 2007 16:34:01 +0000 (UTC) (envelope-from netslists@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so887663wxd for ; Sat, 28 Jul 2007 09:34:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=fOt2i95jOHeb3GBtfIh3JyeTtN7guoM3HK4VpBFFIKVVb8ZOuEPjpwVQonIcqECvusjlsqHKCMWXrSRcEti/r9blqkeh07hlsut4hhk2OUJDDBHOIN7tWFtYusxPNIK/3kQEGeNmCHFdM/iLDgijOu0GtwWT4SRtEojJQEk/j90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=puIGQMcFYrRqetyUPyDMUj9c6ulGVBlF6E1rKDoh0C8XRKUkdGV3OSuyFzuX2QasaBdqO6Mcl3eTyWQ4c/OOWXVqAwinUaOkQKZyNzB0RBCJQPWjRcY1c3XkoNiYoMHaA0365uv8UWSixvvmIdx8YguDKEBV+z+6xK4UzeoyR2c= Received: by 10.70.33.8 with SMTP id g8mr7096251wxg.1185640439968; Sat, 28 Jul 2007 09:33:59 -0700 (PDT) Received: from ?192.168.12.8? ( [72.189.172.75]) by mx.google.com with ESMTPS id o29sm1250571elf.2007.07.28.09.33.59 (version=SSLv3 cipher=RC4-MD5); Sat, 28 Jul 2007 09:33:59 -0700 (PDT) Message-ID: <46AB6FF1.6030007@gmail.com> Date: Sat, 28 Jul 2007 12:33:53 -0400 From: Sten Daniel Soersdal User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Lee Johnston References: <46AA1082.6010503@wildcard.net.uk> In-Reply-To: <46AA1082.6010503@wildcard.net.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 31-Bit IPv4 Prefixes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 16:34:01 -0000 Lee Johnston wrote: > Hi all, > > We've just been allocated a /31 for a point-to-point over ethernet. Any > idea if FreeBSD supports 31-bit prefixes as per RFC 3021? All I'm > getting are: > > arp: 00:02:4a:9c:b8:81 attempts to modify permanent entry for > xx.xx.xx.xx on em2.3211 > It is likely that the /31 is not routed through your pppoe tunnel but instead assigned to your pppoe tunnel. Probably they expect you to use those two addresses in combination with NAT. Routed operation is usually only possible (without trickery) on /30 or larger. But perhaps your /31 falls neatly within a /30 and they did not route the network/broadcast address? Why not just ask your provider how you were thought to use these addresses? You are the customer, you cannot be expected to be the routing wiz on *their* network. I always ask anyway, the explanations are sometimes colorful but often i hear "oh, wait a minute, this doesn't make sense! hang on...". -- Sten Daniel Soersdal From owner-freebsd-net@FreeBSD.ORG Sat Jul 28 16:38:59 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E0C116A41F for ; Sat, 28 Jul 2007 16:38:59 +0000 (UTC) (envelope-from netslists@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by mx1.freebsd.org (Postfix) with ESMTP id E616E13C46C for ; Sat, 28 Jul 2007 16:38:58 +0000 (UTC) (envelope-from netslists@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so888183wxd for ; Sat, 28 Jul 2007 09:38:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=tps1k+Sg4jUfhsQ55YbSLqH2W3bZSlHfTR9QFa4fE5zmcanOWotMxPlOIbJusTKuBlitYP8+bGt0LKSKAhgqKxdGmfJIq1qKWOPFr13r0YFfuZI9vjjHu5CMs/KB7uczazKyaHsVHl3pZfGhnT9ozenHyO3glA4fkSw4vQxNR7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hjG4UqJmGPXTPvRPfz9i90qSvlZ7JvjWfJuNXblVRO0Z9Z3Ulcpq1tJLZ0vM236i1CMkoCkpFyyHXz0fKkqCtJWwjqY8tGbG3pX0WF/4fy3Axk1mc+Xhx5lSwQ5VpLHDQV25q7KK4ldeAjS3tHkq7ddjHaAONG/VRwXQEo8gQ6I= Received: by 10.70.58.7 with SMTP id g7mr7036319wxa.1185640737544; Sat, 28 Jul 2007 09:38:57 -0700 (PDT) Received: from ?192.168.12.8? ( [72.189.172.75]) by mx.google.com with ESMTPS id i27sm1240212elf.2007.07.28.09.38.55 (version=SSLv3 cipher=RC4-MD5); Sat, 28 Jul 2007 09:38:57 -0700 (PDT) Message-ID: <46AB7119.7000806@gmail.com> Date: Sat, 28 Jul 2007 12:38:49 -0400 From: Sten Daniel Soersdal User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Lee Johnston References: <46AA1082.6010503@wildcard.net.uk> In-Reply-To: <46AA1082.6010503@wildcard.net.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 31-Bit IPv4 Prefixes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 16:38:59 -0000 Lee Johnston wrote: > Hi all, > > We've just been allocated a /31 for a point-to-point over ethernet. Any > idea if FreeBSD supports 31-bit prefixes as per RFC 3021? All I'm > getting are: > > arp: 00:02:4a:9c:b8:81 attempts to modify permanent entry for > xx.xx.xx.xx on em2.3211 > Oh and if the addresses were assigned as pppoe endpoint-address (+ 1) then all you do is setup both addresses on pppoe interface with /32 masks. -- Sten Daniel Soersdal From owner-freebsd-net@FreeBSD.ORG Sat Jul 28 17:08:37 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3915E16A417 for ; Sat, 28 Jul 2007 17:08:37 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from optimus.centralmiss.com (ns.centralmiss.com [206.156.254.79]) by mx1.freebsd.org (Postfix) with ESMTP id 0F9BB13C483 for ; Sat, 28 Jul 2007 17:08:36 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by optimus.centralmiss.com (Postfix) with ESMTP id 0DF5C28B36; Sat, 28 Jul 2007 11:37:52 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 9285361C42; Sat, 28 Jul 2007 11:37:51 -0500 (CDT) Date: Sat, 28 Jul 2007 11:37:51 -0500 From: "Matthew D. Fuller" To: Lee Johnston Message-ID: <20070728163751.GU21345@over-yonder.net> References: <46AA1082.6010503@wildcard.net.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46AA1082.6010503@wildcard.net.uk> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.16-fullermd.4 (2007-06-09) Cc: freebsd-net@freebsd.org Subject: Re: 31-Bit IPv4 Prefixes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 17:08:37 -0000 On Fri, Jul 27, 2007 at 04:34:26PM +0100 I heard the voice of Lee Johnston, and lo! it spake thus: > > We've just been allocated a /31 for a point-to-point over ethernet. > Any idea if FreeBSD supports 31-bit prefixes as per RFC 3021? I don't think it does (but that's not positive knowledge). You can probably faking it by assigning the address as a /32, then manually adding a static route through that interface to the other address. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-net@FreeBSD.ORG Sat Jul 28 21:03:42 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3349916A41B for ; Sat, 28 Jul 2007 21:03:42 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id A82D113C48D for ; Sat, 28 Jul 2007 21:03:41 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so977373uge for ; Sat, 28 Jul 2007 14:03:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=qVi5k8c5eowKLROThHbKTLSRXzp8WERNCWiNoJUk+LdBDvVRrObpzL1NIukhuXoGSlVmzZAVu3Ok+7QACUDKDRA7XXxsVf2gqa9GPbBwlt5RTsp1wwAJYj6Y649cf1+YjIBQezu/kQGl1CdSOjW/e3iOeJl+Nedjx6THtkYWJJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=JH7bScwPxiwmWfimRTr7g6J4zU0NyCiPUZTncpEirBnRB25t7OakmvPgux3AB4e/Q3xVdU9lMzhk3opNHy9yvkZ3t9OnBjdYYT14P8XVM/ysvlpjhMhxcgtBnc7+W7yA6fY9lq/YZE70QASbPvZrSIc7VG8d2Mh/VszPkVqI4Nc= Received: by 10.78.190.10 with SMTP id n10mr1089230huf.1185656620575; Sat, 28 Jul 2007 14:03:40 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Sat, 28 Jul 2007 14:03:40 -0700 (PDT) Message-ID: Date: Sat, 28 Jul 2007 14:03:40 -0700 From: "Kip Macy" To: freebsd-net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: call for ALTQ users X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2007 21:03:42 -0000 I'm looking at extending ifnet to support multiple tx queues. It appears that this will inevitably interact with ALTQ. I don't know anyone using ALTQ so I need users to raise their hands to eventually test prospective changes. Thanks. -Kip