From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 00:53:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E30916A419 for ; Sun, 20 Jan 2008 00:53:31 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 98C2113C448 for ; Sun, 20 Jan 2008 00:53:30 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 66743867; Sun, 20 Jan 2008 02:53:29 +0200 Message-ID: <47929B88.3050303@FreeBSD.org> Date: Sun, 20 Jan 2008 02:53:28 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Michael MacLeod References: <1200479046.00010232.1200466203@10.7.7.3> <1200479105.00010249.1200468002@10.7.7.3> <1200482587.00010258.1200469801@10.7.7.3> <1200489793.00010290.1200478201@10.7.7.3> <1200518607.00010486.1200507002@10.7.7.3> <478E834E.4080302@FreeBSD.org> <47927858.4050702@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer , Nikos Vassiliadis Subject: Re: Multilink PPP Download Speeds With Round-Robin Packets 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, 20 Jan 2008 00:53:31 -0000 Michael MacLeod wrote: >> After peer rejected multilink once, mpd is not trying to negotiate it >> any more. I am not sure it is a correct behaviour, but Cisco manuals >> recommend to configure LAC in a way that avoids rejections. >> >> User-land ppp seems to have specific workaround for this case while mpd >> does not. I don't very like this idea, but probably I could add this if >> you like to test it. > > If that's what it takes, I'm happy to test it. Also, the engineers at > my ISP are remarkably approachable, and if you tell me what to ask > them I can probably get you a decent answer pretty quick. After rereading RFC I have found that your provider operation possibly not perfect but it is correct. It is possible to hint peer to use multilink after rejecting by sending NAK. I have made some changes to handle that in mpd5 CVS and merged them into mpd4 branch. You can get new mpd version to test from mpd CVS repository: https://sourceforge.net/cvs/?group_id=14145 -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 08:50:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD9C616A418 for ; Sun, 20 Jan 2008 08:50:51 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 5F8FC13C465 for ; Sun, 20 Jan 2008 08:50:51 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id ED6E91144D; Sun, 20 Jan 2008 19:32:51 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from anzac.hos (132.169.233.220.exetel.com.au [220.233.169.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 0139D11437 for ; Sun, 20 Jan 2008 19:32:47 +1100 (EST) Message-ID: <4793072F.9030909@modulus.org> Date: Sun, 20 Jan 2008 19:32:47 +1100 From: Andrew Snow User-Agent: Thunderbird 2.0.0.0 (X11/20070426) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 7.0-RC1 onboard em1 intel pro1000 vanishing occasionally 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, 20 Jan 2008 08:50:51 -0000 Hi, I have a recent Supermicro board (Super X7DWT Intel 5400 chipset) with two onboard NICs - Intel (ESB2/Gilgal) 82563EB Dual-Port Gigabit Ethernet Controller Usually boot up looks like this: em0: port 0x3000-0x301f mem 0xda020000-0xda03ffff,0xda000000-0xda01ffff irq 44 at device 0.0 on pci5 em0: Using MSI interrupt em0: Ethernet address: 00:30:48:7e:20:e0 em0: [FILTER] em1: port 0x3020-0x303f mem 0xda060000-0xda07ffff,0xda040000-0xda05ffff irq 40 at device 0.1 on pci5 em1: Using MSI interrupt em1: Ethernet address: 00:30:48:7e:20:e1 em1: [FILTER] Sometimes when I reboot this happens: em0: port 0x3000-0x301f mem 0xda020000-0xda03ffff,0xda000000-0xda01ffff irq 44 at device 0.0 on pci5 em0: Using MSI interrupt em0: Ethernet address: 00:30:48:7e:20:e0 em0: [FILTER] em1: port 0x3020-0x303f mem 0xda060000-0xda07ffff,0xda040000-0xda05ffff irq 40 at device 0.1 on pci5 em1: Using MSI interrupt em1: Setup of Shared code failed device_attach: em1 attach returned 6 And em1 does not exist after that. Power cycling the machine seems to fix it for the next boot. Any suggestions? Regards, - Andrew From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 16:36:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3E8A16A41B for ; Sun, 20 Jan 2008 16:36:12 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 8580713C4D5 for ; Sun, 20 Jan 2008 16:36:12 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1JGcqo-00070x-2j for freebsd-net@freebsd.org; Sun, 20 Jan 2008 08:16:50 -0800 Message-ID: <14983301.post@talk.nabble.com> Date: Sun, 20 Jan 2008 08:16:50 -0800 (PST) From: s3raphi To: freebsd-net@freebsd.org In-Reply-To: <20070709234401.S29353@odysseus.silby.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: seraphi.lord@gmail.com References: <20070709234401.S29353@odysseus.silby.com> 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, 20 Jan 2008 16:36:12 -0000 *Originally posted to freebsd-questions@freebsd.org mailing list but moved here. Original may be found at http://www.nabble.com/FreeBSD-7.0-RC1-syncache-problems-under-high-load-to14977783.html#a14981104 I am running web polygraph against a FreeBSD7.0-RC1 squid server and experiencing problems. I have run the same test against the same hardware on FreeBSD 6.1 without issue. This seems to be specific to FreeBSD 7. The problem is related to the number of client connections: 250 Clients - runs great. 500 Clients- scores well in polygraph, but does have a few errored requests 750-2000 Clients - Error rate spikes way up and performance takes a nosedive. I turned on TCP debugging on the server and found lots of this: Jan 19 18:12:46 FlashCache kernel: TCP: [192.168.200.2]:60525 to [192.168.200.1]:8080 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Jan 19 18:12:46 FlashCache kernel: TCP: [192.168.200.2]:50115 to [192.168.200.1]:8080 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK Jan 19 18:12:47 FlashCache kernel: TCP: [192.168.200.2]:50132 to [192.168.200.1]:8080; syncache_timer: Response timeout, retransmitting (1) SYN|ACK Jan 19 18:12:48 FlashCache kernel: TCP: [192.168.200.2]:50132 to [192.168.200.1]:8080 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK Jan 19 18:12:48 FlashCache kernel: TCP: [192.168.200.2]:50138 to [192.168.200.1]:8080 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK Jan 19 18:12:48 FlashCache kernel: TCP: [192.168.200.2]:50144 to [192.168.200.1]:8080 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK Jan 19 18:12:49 FlashCache kernel: TCP: [192.168.200.2]:50169 to [192.168.200.1]:8080 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK Jan 19 18:12:49 FlashCache kernel: TCP: [192.168.200.2]:50170 to [192.168.200.1]:8080 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK Jan 19 18:12:52 FlashCache kernel: TCP: [192.168.200.2]:50203 to [192.168.200.1]:8080 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK Jan 19 18:12:52 FlashCache kernel: TCP: [192.168.200.2]:50167 to [192.168.200.1]:8080; syncache_timer: Response timeout, retransmitting (1) SYN|ACK Jan 19 18:12:52 FlashCache kernel: TCP: [192.168.200.2]:50166 to [192.168.200.1]:8080; syncache_timer: Response timeout, retransmitting (1) SYN|ACK This looks similar to what is described in this thread. Has your fix been rolled in to RC1? I am using a generic kernel, and have this problem on both ethernet cards I have tested with(nfe and bge) These two machines were connected by a switch, but are now directly connected and have the same problem regardless. -S3raphi Mike Silbersack wrote: > > > I've found one of the causes of the network instability of FreeBSD 7; the > tcp syncache fails to retransmit SYN-ACK packets. This causes interesting > problems when packet loss is experienced during connection setup. The > symptoms that I have witnessed are twofold: > > 1. If the third part of the 3WHS is lost, the client will believe that > the connection is in the ESTABLISHED state, while the server will still > have the connection in the syncache. > 2. Subsequently, the above syncache entry will stay stuck in the syncache > forever. If you attempt to re-use that same 4-tuple, the syncache will > ack the new SYN with the old sequence number. > > Anyway, the attached patch simplifies the syncache structure a bit and > makes it retransmit properly. I'd appreciate testing from anyone who has > experienced TCP problems with FreeBSD 7, as well as anyone who is pushing > significant traffic through FreeBSD 7. > > I'm not interested in FreeBSD 6 testers, since the FreeBSD 6 syncache has > a different structure and is not affected by this bug. > > FWIW, here's how to prove the existence of the bug. Install nemesis from > ports, then use it to send SYN packets at your FreeBSD 7 machine. As of > now, you should see only one SYN-ACK reply, and you should also notice > that the sysctl net.inet.tcp.syncache.count goes up, but does not come > back down. > > Once you have applied the patch, you should see the behavior demonstrated > below: > >>From your client machine: (nemesis will pick an IP to spoof, change that > if you wish.) > nemesis tcp -y 80 -D 10.1.1.6 > > TCP Packet Injected > > On your FreeBSD 7 machine: > > patrocles# tcpdump -n port 80 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on nve0, link-type EN10MB (Ethernet), capture size 96 bytes > 23:49:02.075118 IP 133.120.85.92.48922 > 10.1.1.6.80: S > 1519649939:1519649939(0) win 4096 > 23:49:02.075165 IP 10.1.1.6.80 > 133.120.85.92.48922: S > 269601671:269601671(0) ack 1519649940 win 65535 > 23:49:05.164195 IP 10.1.1.6.80 > 133.120.85.92.48922: S > 269601671:269601671(0) ack 1519649940 win 65535 > 23:49:11.264245 IP 10.1.1.6.80 > 133.120.85.92.48922: S > 269601671:269601671(0) ack 1519649940 win 65535 > 23:49:23.364342 IP 10.1.1.6.80 > 133.120.85.92.48922: S > 269601671:269601671(0) ack 1519649940 win 65535 > > Thanks, > > Mike "Silby" Silbersack > --- /usr/src/sys.old/netinet/tcp_syncache.c 2007-06-24 20:17:31.000000000 > -0500 > +++ /usr/src/sys/netinet/tcp_syncache.c 2007-07-09 00:46:18.000000000 > -0500 > @@ -149,7 +150,6 @@ > 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]; > @@ -240,16 +240,10 @@ > > #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) > @@ -275,6 +269,7 @@ > syncache_init(void) > { > int i; > + struct syncache_head *sch; > > tcp_syncache.cache_count = 0; > tcp_syncache.hashsize = TCP_SYNCACHE_HASHSIZE; > @@ -317,6 +312,17 @@ > 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)); > + } > } > > /* > @@ -346,8 +352,8 @@ > 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); > > @@ -398,8 +404,6 @@ > * host does the SYN/ACK->ACK. > */ > if (sc->sc_rxttime >= tick) { > - if (sc->sc_rxttime < sch->sch_nextc) > - sch->sch_nextc = sc->sc_rxttime; > continue; > } > > @@ -416,11 +420,10 @@ > > (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)); > } > > /* > @@ -1007,7 +1010,7 @@ > ("%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++; > } > > _______________________________________________ > 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" > -- View this message in context: http://www.nabble.com/FreeBSD-7-TCP-syncache-fix%3A-request-for-testers-tp11515217p14983301.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 20:26:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53B8B16A41A for ; Sun, 20 Jan 2008 20:26:06 +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 381AE13C45D for ; Sun, 20 Jan 2008 20:26:06 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so3255557waf.3 for ; Sun, 20 Jan 2008 12:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=pA3xpeKQKH4/brGIZxGr1n7BieB1NTqS/n+bcZiLo0o=; b=mlqHttl+K/HRfC27BcWbtIuNOMPZK7LF646znwjP4eT+T+uBU0q0JfYyy4uhzWtXbRBN21WsALvfFR8ARhFlW/SjUcFRBLg+Te/uvUZdKYeo8HGZXo7TYnow8O00neQ5lVr2xw8Syidv76plHGdJVBosFqvk77+aWXXB7s3JagE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jZvQ3ejFU8SijBGmgI8u+sHVJXOIDFETTf8QuZjVUugewvc6vHFC0yxuBHtCS+UYqLAXLv/cw+BFKP6YsGjvmuDJ6tkglwIjnzKppvCLnvN9cX5RqRKq4wlq5bl4ViRecZ+g9w1HXzSBikqH/DA89ys5Ry2mmCdahdFIzq5q6Lw= Received: by 10.114.27.20 with SMTP id a20mr4335472waa.101.1200860765950; Sun, 20 Jan 2008 12:26:05 -0800 (PST) Received: by 10.114.39.18 with HTTP; Sun, 20 Jan 2008 12:26:05 -0800 (PST) Message-ID: <2a41acea0801201226t3f7eb2d0qfd12102d1d480529@mail.gmail.com> Date: Sun, 20 Jan 2008 12:26:05 -0800 From: "Jack Vogel" To: "Andrew Snow" In-Reply-To: <4793072F.9030909@modulus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4793072F.9030909@modulus.org> Cc: freebsd-net@freebsd.org Subject: Re: 7.0-RC1 onboard em1 intel pro1000 vanishing occasionally 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, 20 Jan 2008 20:26:06 -0000 Hi Andrew, Someone else has already reported this to me and in fact he is testing a shared code fix to see if it resolves it. I will be updating the driver if it does. Jack On Jan 20, 2008 12:32 AM, Andrew Snow wrote: > > Hi, > > I have a recent Supermicro board (Super X7DWT > Intel 5400 chipset) with two onboard NICs - Intel (ESB2/Gilgal) 82563EB > Dual-Port Gigabit Ethernet Controller > > > > Usually boot up looks like this: > > em0: port > 0x3000-0x301f mem 0xda020000-0xda03ffff,0xda000000-0xda01ffff irq 44 at > device 0.0 on pci5 > em0: Using MSI interrupt > em0: Ethernet address: 00:30:48:7e:20:e0 > em0: [FILTER] > em1: port > 0x3020-0x303f mem 0xda060000-0xda07ffff,0xda040000-0xda05ffff irq 40 at > device 0.1 on pci5 > em1: Using MSI interrupt > em1: Ethernet address: 00:30:48:7e:20:e1 > em1: [FILTER] > > Sometimes when I reboot this happens: > > em0: port > 0x3000-0x301f mem 0xda020000-0xda03ffff,0xda000000-0xda01ffff irq 44 at > device 0.0 on pci5 > em0: Using MSI interrupt > em0: Ethernet address: 00:30:48:7e:20:e0 > em0: [FILTER] > em1: port > 0x3020-0x303f mem 0xda060000-0xda07ffff,0xda040000-0xda05ffff irq 40 at > device 0.1 on pci5 > em1: Using MSI interrupt > em1: Setup of Shared code failed > device_attach: em1 attach returned 6 > > And em1 does not exist after that. Power cycling the machine seems to > fix it for the next boot. > > > Any suggestions? > > > Regards, > > - Andrew > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 20:40:07 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98DD816A4C4 for ; Sun, 20 Jan 2008 20:40:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9506F13C448 for ; Sun, 20 Jan 2008 20:40:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0KKe4kD080881 for ; Sun, 20 Jan 2008 20:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0KKe40l080880; Sun, 20 Jan 2008 20:40:04 GMT (envelope-from gnats) Date: Sun, 20 Jan 2008 20:40:04 GMT Message-Id: <200801202040.m0KKe40l080880@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Marius Strobl Cc: Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marius Strobl List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2008 20:40:07 -0000 The following reply was made to PR kern/112654; it has been noted by GNATS. From: Marius Strobl To: Nagy Keve , wforms@Safe-mail.net, bug-followup@FreeBSD.org Cc: Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 Date: Sun, 20 Jan 2008 21:37:55 +0100 On Mon, Jan 14, 2008 at 08:10:02AM +0000, Nagy Keve wrote: > > An important update is that my earlier conclusion regarding the patch was f= > lawed. > The patch DOES WORK on RELENG_6, it gets rid of the kernel panic upon loadi= > ng the module and it DOES FIND the appropriate cable media connected. I a= > m still unable to explain what caused the "no carrier" issue during my ea= > rlier attempts with this patch. That probably was because of nsphy(4) not being the correct driver in order to determine the link status of this PHY. > So the concept is proved, this could be a proper fix if we can get the pcn = > driver to use ns_phy instead of uk_phy. With the current patch both ns_ph= > y and uk_phy shows up in dmesg, and I would rather see ns_phy only. > Could you please give a kernel built with the patch at: http://people.freebsd.org/~marius/nsphyter.diff or for RELENG_6: http://people.freebsd.org/~marius/nsphyter.diff_RELENG_6 instead of the patch for nsphy(4) a try? Marius From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 22:26:47 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FD4D16A46B for ; Sun, 20 Jan 2008 22:26:47 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.freebsd.org (Postfix) with ESMTP id 3DE3A13C474 for ; Sun, 20 Jan 2008 22:26:47 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so2578126pyb.10 for ; Sun, 20 Jan 2008 14:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9rUNct1Reuwxq9S0JJIOtoWOZEq7/zKhqB0ZOykJqNQ=; b=lAdFlSZvPah/uSfjvJkcv/OIaQOPqOYAAkl7xTBvuW0DSI4LlQ4Wrbizbh3/ttBB6/DkOjtREZMobcgm9Mq8NelpTS55jrx/sVrzIMhabCWjhyl4YPNqCVP5Okp2PUZeU8+x7RPyq5lGZKMa8bMPI0lgSXXqcOCXKzkPcZA5xNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=xrWca5ENayLXEmh46RMaYTG1E9R79GZFzjS2KmDvcjw9y/+i83yp7QvGqAIYwdZR8FKkCE5UEDRzjjiuA6jjS3bH00w5W6v0kj2aiYZ0S1tlqC4hV4ZVXJPT6nlZUxCgN6lXKkMMX+K5/a2mehVctHk3eC8/hi2xnbYPRFPb1CA= Received: by 10.65.154.2 with SMTP id g2mr13178110qbo.55.1200868006039; Sun, 20 Jan 2008 14:26:46 -0800 (PST) Received: by 10.64.179.20 with HTTP; Sun, 20 Jan 2008 14:26:45 -0800 (PST) Message-ID: Date: Sun, 20 Jan 2008 17:26:45 -0500 From: "Michael MacLeod" To: "Alexander Motin" In-Reply-To: <47929B88.3050303@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1200479046.00010232.1200466203@10.7.7.3> <1200479105.00010249.1200468002@10.7.7.3> <1200482587.00010258.1200469801@10.7.7.3> <1200489793.00010290.1200478201@10.7.7.3> <1200518607.00010486.1200507002@10.7.7.3> <478E834E.4080302@FreeBSD.org> <47927858.4050702@FreeBSD.org> <47929B88.3050303@FreeBSD.org> Cc: freebsd-net@freebsd.org, Julian Elischer , Nikos Vassiliadis Subject: Re: Multilink PPP Download Speeds With Round-Robin Packets 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, 20 Jan 2008 22:26:47 -0000 I figured out the real source of the problem. Turns out Bell went and screwed up the lantern test mappings on my connections, and dropped the profile on one of them to 3 megabits (which I didn't know because the lantern was mis-mapped). So I've spent the last several weeks racking my brains trying to figure out what the hell was going on. Due to happenstance, I have another DSL connection (yes, a third one) that syncs at 8 megabits down that still has sync (The account's been canceled, but Bell can't even cancel an account right. I have three cancellation numbers!). So I plugged my router into the DSL modem that has a 6 meg profile (even though the lantern says it's out of service) and into the supposed to be canceled line, and now here's the result: http://www.dslreports.com/im/44226057/2364.png I really appreciate all the help though, and I'm still going to test out the new mpd code. It might end up waiting until I get my DSL lines and profiles straightened out though, which I hope to have finished this week. Cheers Mike Oh, and if your curious why I'm talking about Bell rather than TekSavvy, it's because I had Bell install the lines directly, and TekSavvy is just selling me a login. I don't know if this is common practice elsewhere in the world, but in Canada the old monopoly telco's were forced to resell their service wholesale to other providers, which means all DSL service in Ontario and Quebec connect through a Bell 'cloud', and your login determines which ISP your connection terminates at. This has lots of advantages, like having two logins for redundancy :) On Jan 19, 2008 7:53 PM, Alexander Motin wrote: > After rereading RFC I have found that your provider operation possibly > not perfect but it is correct. It is possible to hint peer to use > multilink after rejecting by sending NAK. > I have made some changes to handle that in mpd5 CVS and merged them into > mpd4 branch. You can get new mpd version to test from mpd CVS > repository: https://sourceforge.net/cvs/?group_id=14145 > > -- > Alexander Motin > From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 00:03:17 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FA3716A47A; Mon, 21 Jan 2008 00:03:17 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E97D913C46E; Mon, 21 Jan 2008 00:03:16 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0L03GtD097692; Mon, 21 Jan 2008 00:03:16 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0L03GRT097688; Mon, 21 Jan 2008 00:03:16 GMT (envelope-from linimon) Date: Mon, 21 Jan 2008 00:03:16 GMT Message-Id: <200801210003.m0L03GRT097688@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/119839: [ng_netflow] ng_netflow can consume large sums of memory if export hook isn't connected 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, 21 Jan 2008 00:03:17 -0000 Old Synopsis: ng_netflow can consume large sums of memory if export hook isn't connected New Synopsis: [ng_netflow] ng_netflow can consume large sums of memory if export hook isn't connected Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 21 00:01:33 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=119839 From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 00:19:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00E0316A419 for ; Mon, 21 Jan 2008 00:19:32 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id 9DC4E13C448 for ; Mon, 21 Jan 2008 00:19:31 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 51698 invoked from network); 20 Jan 2008 23:52:50 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 20 Jan 2008 23:52:50 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 20 Jan 2008 17:52:50 -0600 (CST) From: Mike Silbersack To: s3raphi In-Reply-To: <14983301.post@talk.nabble.com> Message-ID: <20080120175048.H39017@odysseus.silby.com> References: <20070709234401.S29353@odysseus.silby.com> <14983301.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-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: Mon, 21 Jan 2008 00:19:32 -0000 On Sun, 20 Jan 2008, s3raphi wrote: > I am running web polygraph against a FreeBSD7.0-RC1 squid server and > experiencing problems. I have run the same test against the same hardware on > FreeBSD 6.1 without issue. This seems to be specific to FreeBSD 7. > The problem is related to the number of client connections: > 250 Clients - runs great. > 500 Clients- scores well in polygraph, but does have a few errored requests > 750-2000 Clients - Error rate spikes way up and performance takes a > nosedive. > > This looks similar to what is described in this thread. Has your fix been > rolled in to RC1? The syncache in 7.0-RC1 has all known bugs fixed, so either you are encountering a new bug or simply having a lot of packet loss. Please try to use tcpdump to capture traffic while these errors are occuring, and include info as to whether you are using any firewalls of any sort anywhere in the connection. Then send that to me and I'll get to it as soon as I can, which may be a week from now. -Mike From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 05:27:51 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6377916A418 for ; Mon, 21 Jan 2008 05:27:51 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.freebsd.org (Postfix) with ESMTP id 45C0A13C43E for ; Mon, 21 Jan 2008 05:27:51 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.mx.meer.net (8.12.10/8.12.6) with ESMTP id m0L5Ro7T036090; Sun, 20 Jan 2008 21:27:50 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m0L5RolQ062508; Sun, 20 Jan 2008 21:27:50 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (61.204.211.246.customerlink.pwd.ne.jp [61.204.211.246]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m0L5Ro9p084171; Sun, 20 Jan 2008 21:27:50 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Mon, 21 Jan 2008 14:27:49 +0900 Message-ID: From: gnn@freebsd.org To: Randall Stewart In-Reply-To: <478FB53B.60808@cisco.com> References: <7izlv4pe47.wl%gnn@neville-neil.com> <478FB53B.60808@cisco.com> 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.50 (i386-apple-darwin8.10.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: net@freebsd.org Subject: Re: Are there known issues with multicast on Intel Pro 1000? 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, 21 Jan 2008 05:27:51 -0000 At Thu, 17 Jan 2008 15:06:19 -0500, randall wrote: > > gnn@freebsd.org wrote: > > Howdy, > > > > At my current gig we find that the network interface locks up if we > > subject it to a high rate of multicast traffic. Since the whole > > purpose of this box is to do multicast (it absorbs a feed of data over > > multicast manipulates and then sends it out again over multicast) it's > > a "bad thing" if this kind of thing does not work. > > > > What I currently know is not complete but I figured I could start > > here. > > > > The symptom is that all network communication stops, but the system > > itself is still responsive, so I can get to the console and get > > information. > > If you let it run long enough does it eventually lock up? > > I have seen similar behavior when a lock is not released when > I was breaking things :-) > > Everything is fine EXCEPT the interface.. for a while.. then > eventually you get a train-wreck :-) > > I would drop to ddb and do the show locks.. > > Also I believe top (or ps) will tell you what locks are being > waited on in a course way... I think the ps in DDB will do this. On closer inspection it looks like an "out of mbufs" situation and so the right answer is to "up the nmbclusters" but there seem to be other issues with this code and multicast so I'm likely to jump into DDB and look more closely at it, likely next week. Thanks, George From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 06:41:52 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4439B16A417; Mon, 21 Jan 2008 06:41:52 +0000 (UTC) (envelope-from jhealy@swin.edu.au) Received: from swin.edu.au (gpo5.cc.swin.edu.au [136.186.1.225]) by mx1.freebsd.org (Postfix) with ESMTP id AA50213C455; Mon, 21 Jan 2008 06:41:51 +0000 (UTC) (envelope-from jhealy@swin.edu.au) Received: from groupwise.swin.edu.au (hwncl3-inet.cc.swin.edu.au [136.186.3.197]) by swin.edu.au (8.13.6.20060614/8.13.1) with ESMTP id m0L5v5ih014184; Mon, 21 Jan 2008 16:57:05 +1100 Received: from [136.186.229.102] (jhealy.caia.swin.edu.au [136.186.229.102]) by groupwise.swin.edu.au with ESMTP; Mon, 21 Jan 2008 16:57:03 +1100 Message-ID: <4794342E.8080602@swin.edu.au> Date: Mon, 21 Jan 2008 16:57:02 +1100 From: James Healy User-Agent: Thunderbird 2.0.0.6 (X11/20071113) MIME-Version: 1.0 To: Andre Oppermann References: <20071219123305.Y95322@fledge.watson.org> <47693DBD.6050104@swin.edu.au> <476A45D6.6030305@freebsd.org> <47858D35.6060006@swin.edu.au> <4786D23A.1080509@freebsd.org> In-Reply-To: <4786D23A.1080509@freebsd.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on gpo5.cc.swin.edu.au Cc: Lawrence Stewart , net@freebsd.org, Robert Watson , grenville armitage , arch@freebsd.org Subject: Re: Coordinating TCP projects 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, 21 Jan 2008 06:41:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andre Oppermann wrote: > The first cut is now at //depot/projects/tcp_reass/ however I made > a mistake when creating the branch and now the code is in the same > changeset as the branching itself. Doesn't make it easy to do a > diff. Have to see how I can fix that. Anyway, have a look and I'm > going to finish/fix the code tomorrow evening. Our initial thoughts on dynamically resizing the TCP reassembly queue in step with the receive buffer size to avoid segments being dropped unnecessarily have been superseded by the tcp_reass branch. Amongst a number of number of optimisations, this dynamic cap is now implemented. Hopefully we'll find some spare cycles to test the branch out soon. James Healy http://caia.swin.edu.au/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHlDQu4oawkrbYo/kRAvZdAJkB+vBb8Eu/a4cCqF/6v0q221/dNwCfbqOU Qvm2dFjGlJ2AQmOTFEeOZZ8= =053h -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 07:41:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3470616A418 for ; Mon, 21 Jan 2008 07:41:06 +0000 (UTC) (envelope-from steev@steev.net) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 0C9F713C442 for ; Mon, 21 Jan 2008 07:41:05 +0000 (UTC) (envelope-from steev@steev.net) Received: from [192.168.2.251] (ip72-213-148-73.ok.ok.cox.net [72.213.148.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 913B56550C for ; Mon, 21 Jan 2008 07:13:54 +0000 (UTC) Message-ID: <479445FF.4050407@steev.net> Date: Mon, 21 Jan 2008 01:13:03 -0600 From: Steev Klimaszewski User-Agent: Thunderbird 2.0.0.9 (X11/20080113) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Possibly related to ath0 Ierrs 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, 21 Jan 2008 07:41:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I was looking through the archive, and I came across the ath0 Ierrs thread - and I am facing a similar issue. A little background... The machine is a 1ghz Athlon, with 640MB of ram. There is a vr0 device, a de0 device, and sis0 device and an ath0 device. The ath0 device is a TP-Link TL-WN650G. This means the antenna is actually built on to the card, and cannot be removed. The operating system of the machine is actually pfSense 1.2-RC4, which is based on FreeBSD 6.2. Linux reports this Atheros card (and another that I also had similar issues with) as 02:0b.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) Basically what I come up with is, when in ap mode, cards can connect, however I cannot push any traffic through the Atheros card. This was tested with a DWL-G650, a Cisco Aironet 350, an Orinoco Gold Classic, as well as a Broadcom 4318 card. All of them can connect to the Atheros card, but no traffic gets passed, and I cannot ping the ap either. the output of athstats is (with no cards connected): # athstats 1 hardware error interrupts 525 tx management frames 831 tx frames discarded prior to association 10 tx stopped 'cuz no xmit buffer 232 tx failed 'cuz FIFO underrun 1110 tx failed 'cuz bogus xmit rate 368 tx frames with rts enabled 720 tx frames with an alternate rate 6032 rx failed 'cuz of FIFO overrun 2875 rx management frames 161904 beacon setup failed 'cuz no mbuf 379518991 beacons transmitted 588 periodic calibration failures 21 tx used alternate antenna Antenna profile: [2] tx 766 rx 4802 [3] tx 341 rx 0 And if I attempt to connect a card, I get: # athstats 1 hardware error interrupts 559 tx management frames 21779 tx frames discarded prior to association 10 tx stopped 'cuz no xmit buffer 238 tx failed 'cuz FIFO underrun 1154 tx failed 'cuz bogus xmit rate 392 tx frames with rts enabled 737 tx frames with an alternate rate 6101 rx failed 'cuz of FIFO overrun 2898 rx management frames 164038 beacon setup failed 'cuz no mbuf 1822242855 beacons transmitted 596 periodic calibration failures 449 tx used alternate antenna Antenna profile: [2] tx 11248 rx 25151 [3] tx 10836 rx 632 This is a new card (the TL-WN650G) - so I am wondering if maybe I just happened to have gotten a bad card? Any light that can be shed on this would be greatly appreciated. The pfSense irc channel is not extremely active so I haven't gotten much help out of them as to anything that pfSense itself does, so I can better troubleshoot. Thanks for you time, Steev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHlEX/7ejdT1xPb2gRAgG6AJ9eA8hEcyZkR0TPJKL3rOcjxuGTKgCgmW1x EWP5KYlj3Q5u4dF6+8r9Zbw= =u6Tb -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 09:42:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D19516A418 for ; Mon, 21 Jan 2008 09:42:52 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id 494D013C442 for ; Mon, 21 Jan 2008 09:42:52 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1927451rvb.43 for ; Mon, 21 Jan 2008 01:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=Cvy7aId8il4N6Bj6DnAKteft214tSMOp4SzpnYsl7Hs=; b=UE/Ftre1FnTz5JGgaZe1rxQJ31qKfOsb6+IdppMq7uspKvpbnBCyNZWLvMJp3YCNN3kA7YijAiKVv+C66r7hgeGMWJaDMKcbYZ1lQ5ZGmrTSmvXJ1efCfoY/gvRdu6oXGqBldr8DQ59IZnRoimb5j8+WDebJRXLOR1tpc0ZcuRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=PhTb/Yeob/CKgbPlXe7kzmhulMGPiikRBMB/9aYihEvq/IUNS54yVei1PcB8ji8iIOAaBvZewslBcm78an1aFECpSatmwqHpO4Nge9a7ndH9Gs3D/KLndlF3RvR/obvxGP8v9yNKnfhDJMmKWks27P3VpNmhzzIx70JiJWDOv50= Received: by 10.140.250.14 with SMTP id x14mr4302604rvh.119.1200908571367; Mon, 21 Jan 2008 01:42:51 -0800 (PST) Received: by 10.141.170.18 with HTTP; Mon, 21 Jan 2008 01:42:51 -0800 (PST) Message-ID: <2e77fc10801210142g560f6f65p9908957d0c7a799e@mail.gmail.com> Date: Mon, 21 Jan 2008 11:42:51 +0200 From: "Niki Denev" Sender: ndenev@gmail.com To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 3a540560e2cac566 Subject: [PATCH] "/etc/rc.d/pf reload" fails if there are macros defined in pf_flags rcvar. 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, 21 Jan 2008 09:42:52 -0000 Hi, I'm using the pf_flags rc var to set macros for pf.conf files i use in redundant router configuration. This way i can have exactly the same pf.conf on all of the routers, and still set host specific options as "hostid" used by pfsync via rc.conf The problem is that when i use "/etc/rc.d/pf reload" to reload the rules, the rc.d/pf script first executes pfctl with -n option to check the pf.conf syntax, but fails to include the $pf_flags var, and fails because of undefined macros. The following patch fixed this for me. --- pf.orig 2008-01-21 11:18:27.000000000 +0200 +++ pf 2008-01-21 11:29:56.000000000 +0200 @@ -50,7 +50,7 @@ pf_reload() { echo "Reloading pf rules." - $pf_program -n -f "$pf_rules" || return 1 + $pf_program -n -f "$pf_rules" $pf_flags || return 1 # Flush everything but existing state entries that way when # rules are read in, it doesn't break established connections. $pf_program -Fnat -Fqueue -Frules -FSources -Finfo -FTables -Fosfp > /dev/null 2>&1 -- Niki From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 09:49:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 498B516A420 for ; Mon, 21 Jan 2008 09:49:16 +0000 (UTC) (envelope-from gdakos@enovation.gr) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.77]) by mx1.freebsd.org (Postfix) with ESMTP id 566B213C4D3 for ; Mon, 21 Jan 2008 09:49:14 +0000 (UTC) (envelope-from gdakos@enovation.gr) Received: from John (host3.ep-pc75.ondsl.gr [83.235.249.3]) by kane.otenet.gr (8.13.8/8.13.8/Debian-3) with SMTP id m0L9OO5F013154 for ; Mon, 21 Jan 2008 11:24:28 +0200 Message-ID: <001b01c85c0f$6ca051d0$1e01c80a@John> From: "Enovation Technologies" To: Date: Mon, 21 Jan 2008 11:24:23 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3100 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: help 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, 21 Jan 2008 09:49:16 -0000 hello. i am newbie on freebsd and i have a problem with 2 nics i have 2 nics re0 and re1 on re0 i have installing this ip # -- sysinstall generated deltas -- # Thu Dec 6 15:26:31 2007 ifconfig_re0=3D"inet 10.200.1.37 netmask 255.255.255.0" defaultrouter=3D"10.200.1.1" hostname=3D"zeus.local" i want to install on re1 another ip 10.200.1.40 i configure with sysinstall my second nic , but when i restart my box i = have this message arp: 10.200.1.1 is on re0 but got reply from 00:50:7f:b0:a0:f8 on re1 my question is how to configure 2 nics with different ip on same box = in the same subnet. thanks From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 09:51:22 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26B3116A476 for ; Mon, 21 Jan 2008 09:51:22 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 59CBD13C4E9 for ; Mon, 21 Jan 2008 09:51:21 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 38142 invoked from network); 21 Jan 2008 09:13:10 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Jan 2008 09:13:10 -0000 Message-ID: <47946B1B.7070009@freebsd.org> Date: Mon, 21 Jan 2008 10:51:23 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: James Healy References: <20071219123305.Y95322@fledge.watson.org> <47693DBD.6050104@swin.edu.au> <476A45D6.6030305@freebsd.org> <47858D35.6060006@swin.edu.au> <4786D23A.1080509@freebsd.org> <4794342E.8080602@swin.edu.au> In-Reply-To: <4794342E.8080602@swin.edu.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart , net@freebsd.org, Robert Watson , grenville armitage , arch@freebsd.org Subject: Re: Coordinating TCP projects 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, 21 Jan 2008 09:51:22 -0000 James Healy wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andre Oppermann wrote: >> The first cut is now at //depot/projects/tcp_reass/ however I made >> a mistake when creating the branch and now the code is in the same >> changeset as the branching itself. Doesn't make it easy to do a >> diff. Have to see how I can fix that. Anyway, have a look and I'm >> going to finish/fix the code tomorrow evening. > > Our initial thoughts on dynamically resizing the TCP reassembly queue in > step with the receive buffer size to avoid segments being dropped > unnecessarily have been superseded by the tcp_reass branch. > > Amongst a number of number of optimisations, this dynamic cap is now > implemented. Hopefully we'll find some spare cycles to test the branch > out soon. It's not yet finished. I expect to be done later this week. I'll send an announcement when the code is ready for wider testing. Any exercising and testing of the code you can do is very appreciated. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 10:13:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0B4816A41B for ; Mon, 21 Jan 2008 10:13:19 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 70BF613C465 for ; Mon, 21 Jan 2008 10:13:19 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id D8EDA89688; Mon, 21 Jan 2008 05:13:18 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 21 Jan 2008 05:13:18 -0500 X-Sasl-enc: YrvsjxX6MONwZls0kB7MRbW/0bR1y6GJfvcf8UGVWp7f 1200910395 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 64F3950F8; Mon, 21 Jan 2008 05:13:15 -0500 (EST) Message-ID: <4794703A.4020801@FreeBSD.org> Date: Mon, 21 Jan 2008 10:13:14 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Enovation Technologies References: <001b01c85c0f$6ca051d0$1e01c80a@John> In-Reply-To: <001b01c85c0f$6ca051d0$1e01c80a@John> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: help 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, 21 Jan 2008 10:13:19 -0000 Enovation Technologies wrote: > i configure with sysinstall my second nic , but when i restart my box i have this message > arp: 10.200.1.1 is on re0 but got reply from 00:50:7f:b0:a0:f8 on re1 > > > my question is how to configure 2 nics with different ip on same box in the same subnet. > Configure the second with a /32 prefix (netmask 255.255.255.255) instead of the usual netmask. You will always receive the arp warning unless you disable it by setting sysctl net.link.ether.inet.log_arp_wrong_iface and net.link.ether.inet.log_arp_movements to 0. These limitations *may* go away in future releases. later BMS From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 11:07:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4597916A419 for ; Mon, 21 Jan 2008 11:07:04 +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 2B83413C447 for ; Mon, 21 Jan 2008 11:07:04 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0LB74vr047074 for ; Mon, 21 Jan 2008 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0LB73lq047070 for freebsd-net@FreeBSD.org; Mon, 21 Jan 2008 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Jan 2008 11:07:03 GMT Message-Id: <200801211107.m0LB73lq047070@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2008 11:07:04 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/115360 net [ipv6] IPv6 address and if_bridge don't play well toge 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue f kern/62374 net panic: free: multiple frees 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/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/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 o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116172 net [tun] [panic] Network / ipv6 recursive mutex panic o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash (regression) o kern/118880 net [ipv6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card (regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem f kern/119548 net [pf] [ath] [patch] PF Altq with ath hostap problem 32 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] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] fstat(1): add INET/INET6 socket details as in o bin/117339 net [patch] route(8): loading routing management commands f kern/118722 net [tcp] Many old TCP connections in SYN_RCVD state o kern/118727 net [ng] [patch] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118975 net [bge] [patch] Broadcom 5906 not handled by FreeBSD o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119839 net [ng_netflow] ng_netflow can consume large sums of memo 24 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 11:10:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B47C16A419 for ; Mon, 21 Jan 2008 11:10:35 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from wawa.yandex.ru (wawa.yandex.ru [87.250.250.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2059E13C47E for ; Mon, 21 Jan 2008 11:10:32 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from [127.0.0.1] (localhost.yandex.ru [127.0.0.1]) by wawa.yandex.ru (8.14.1/8.14.1/Debian-9) with ESMTP id m0LAwRFF027448; Mon, 21 Jan 2008 13:58:27 +0300 Message-ID: <47947AD3.2040708@yandex-team.ru> Date: Mon, 21 Jan 2008 13:58:27 +0300 From: Vladimir Ivanov Organization: Yandex LLC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071119 Iceape/1.1.7 (Debian-1.1.7-1) MIME-Version: 1.0 To: Jack Vogel References: <4793072F.9030909@modulus.org> <2a41acea0801201226t3f7eb2d0qfd12102d1d480529@mail.gmail.com> In-Reply-To: <2a41acea0801201226t3f7eb2d0qfd12102d1d480529@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Andrew Snow Subject: Re: 7.0-RC1 onboard em1 intel pro1000 vanishing occasionally 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, 21 Jan 2008 11:10:35 -0000 Hi, All Jack Vogel wrote: > Hi Andrew, > > Someone else has already reported this to me and in fact he is testing > a shared code > fix to see if it resolves it. I will be updating the driver if it does. > > Jack > We've same issue w/Supermicro boards if IPMI daughterboard installed. A problem looks as PHY reg reads/writes fails. I suppose they use buggy (incompatible) technique to make "virtual lan" channel for remote KVM support. On some systems we can start interfaces via warm boot, sometimes not, sometimes we can recover it w/powercord unplug, sometimes - not. 100% workaround: remove IPMI daughterboard. Also, I've a several systems w/IPMI which works Ok. > On Jan 20, 2008 12:32 AM, Andrew Snow wrote: > >> Hi, >> >> I have a recent Supermicro board (Super X7DWT >> Intel 5400 chipset) with two onboard NICs - Intel (ESB2/Gilgal) 82563EB >> Dual-Port Gigabit Ethernet Controller >> >> >> >> Usually boot up looks like this: >> >> em0: port >> 0x3000-0x301f mem 0xda020000-0xda03ffff,0xda000000-0xda01ffff irq 44 at >> device 0.0 on pci5 >> em0: Using MSI interrupt >> em0: Ethernet address: 00:30:48:7e:20:e0 >> em0: [FILTER] >> em1: port >> 0x3020-0x303f mem 0xda060000-0xda07ffff,0xda040000-0xda05ffff irq 40 at >> device 0.1 on pci5 >> em1: Using MSI interrupt >> em1: Ethernet address: 00:30:48:7e:20:e1 >> em1: [FILTER] >> >> Sometimes when I reboot this happens: >> >> em0: port >> 0x3000-0x301f mem 0xda020000-0xda03ffff,0xda000000-0xda01ffff irq 44 at >> device 0.0 on pci5 >> em0: Using MSI interrupt >> em0: Ethernet address: 00:30:48:7e:20:e0 >> em0: [FILTER] >> em1: port >> 0x3020-0x303f mem 0xda060000-0xda07ffff,0xda040000-0xda05ffff irq 40 at >> device 0.1 on pci5 >> em1: Using MSI interrupt >> em1: Setup of Shared code failed >> device_attach: em1 attach returned 6 >> >> And em1 does not exist after that. Power cycling the machine seems to >> fix it for the next boot. >> >> >> Any suggestions? >> >> [skip] Trully, -- Vladimir Ivanov Network Operations Center OOO "Yandex" t: +7 495 739-7000 f: +7 495 739-7070 @: noc@yandex.net (corporate) wawa@yandex-team.ru (personal) www: www.yandex.ru -- From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 12:01:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF3AB16A468 for ; Mon, 21 Jan 2008 12:01:30 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 95A9C13C4E8 for ; Mon, 21 Jan 2008 12:01:29 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 3F4EA11450; Mon, 21 Jan 2008 23:01:27 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.20.30.100] (unknown [220.233.218.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 5988E11437; Mon, 21 Jan 2008 23:01:23 +1100 (EST) Message-ID: <4794895F.7060402@modulus.org> Date: Mon, 21 Jan 2008 23:00:31 +1100 From: Andrew Snow User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Vladimir Ivanov References: <4793072F.9030909@modulus.org> <2a41acea0801201226t3f7eb2d0qfd12102d1d480529@mail.gmail.com> <47947AD3.2040708@yandex-team.ru> In-Reply-To: <47947AD3.2040708@yandex-team.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 7.0-RC1 onboard em1 intel pro1000 vanishing occasionally 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, 21 Jan 2008 12:01:30 -0000 Vladimir Ivanov wrote: > We've same issue w/Supermicro boards if IPMI daughterboard installed. A > problem looks as PHY reg reads/writes fails. Ahh, that explains it, thanks. The management cards seem to cause multiple problems with the FreeBSD em driver over time. I don't want to give up the IPMI cards so I'll just keep using system reset to get em1 working, it usually only takes 1 or 2 resets. My IPMI card has an option for external/dedicated LAN port so I might try that also. - Andrew From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 12:40:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36C8416A480 for ; Mon, 21 Jan 2008 12:40:27 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from wawa.yandex.ru (wawa.yandex.ru [87.250.250.1]) by mx1.freebsd.org (Postfix) with ESMTP id 992AF13C458 for ; Mon, 21 Jan 2008 12:40:26 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from [127.0.0.1] (localhost.yandex.ru [127.0.0.1]) by wawa.yandex.ru (8.14.1/8.14.1/Debian-9) with ESMTP id m0LCeMbc029390; Mon, 21 Jan 2008 15:40:24 +0300 Message-ID: <479492B6.3080400@yandex-team.ru> Date: Mon, 21 Jan 2008 15:40:22 +0300 From: Vladimir Ivanov Organization: Yandex LLC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071119 Iceape/1.1.7 (Debian-1.1.7-1) MIME-Version: 1.0 To: Andrew Snow References: <4793072F.9030909@modulus.org> <2a41acea0801201226t3f7eb2d0qfd12102d1d480529@mail.gmail.com> <47947AD3.2040708@yandex-team.ru> <4794895F.7060402@modulus.org> In-Reply-To: <4794895F.7060402@modulus.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 7.0-RC1 onboard em1 intel pro1000 vanishing occasionally 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, 21 Jan 2008 12:40:27 -0000 Andrew Snow wrote: > Vladimir Ivanov wrote: >> We've same issue w/Supermicro boards if IPMI daughterboard installed. >> A problem looks as PHY reg reads/writes fails. > > Ahh, that explains it, thanks. > > The management cards seem to cause multiple problems with the FreeBSD em > driver over time. I don't want to give up the IPMI cards so I'll just > keep using system reset to get em1 working, it usually only takes 1 or > 2 resets. > > My IPMI card has an option for external/dedicated LAN port so I might > try that also. We keep trying same way. It is the only way to disable virtual lan channel I seem :-| But Jack gave me another hope. WBR -- Vladimir Ivanov Network Operations Center OOO "Yandex" t: +7 495 739-7000 f: +7 495 739-7070 @: noc@yandex.net (corporate) wawa@yandex-team.ru (personal) www: www.yandex.ru -- From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 15:25:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FDE416A469 for ; Mon, 21 Jan 2008 15:25:53 +0000 (UTC) (envelope-from sascha=freebsd-net=freebsd.org=veyfegdl@holzleiter.name) Received: from serverbitch.de (serverbitch.de [212.227.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id 0892213C506 for ; Mon, 21 Jan 2008 15:25:53 +0000 (UTC) (envelope-from sascha=freebsd-net=freebsd.org=veyfegdl@holzleiter.name) Received: from transfer.telemaxx.gfsrv.net ([85.115.3.230] helo=[192.168.71.190]) by serverbitch.de with esmtpsa (SSLv3:AES256-SHA:256) (Exim) (envelope-from ) id 1JGyFd-000JQ7-Ko for freebsd-net@freebsd.org; Mon, 21 Jan 2008 16:07:53 +0100 From: Sascha Holzleiter To: freebsd-net@freebsd.org Content-Type: text/plain Date: Mon, 21 Jan 2008 16:07:54 +0100 Message-Id: <1200928074.66357.12.camel@dreamland.gameforge.local> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Network buffer problem 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, 21 Jan 2008 15:25:53 -0000 Hi, i've bit of an understanding issue with the netstat output which seems to condradict itself a bit. One of our production machines has a moderate network load (24mbit on a 100mbit device) and quite frequently shows a packet loss rate around 2% on peak times. A netstat -s -p ip output looks like this: 1459405058 packets sent from this host 0 packets sent with fabricated ip header 411987593 output packets dropped due to no bufs, etc. So there are a lot of packets dropped due to buffers. But the mbuffer statistic with netstat -m shows no sign of this: 3470/2095/5565 mbufs in use (current/cache/total) 1536/1078/2614/25600 mbuf clusters in use (current/cache/total/max) 1536/145 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 3939K/2679K/6619K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/7/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 5646 calls to protocol drain routines There are no mbufs denied ever, the mbuf max is far above the total amount used so i'm a bit at a loss what's the problem here but it seems to be some kind of buffer issue. I already raised kern.ipc.maxsockbuf to 16777216 and the nmbclusters is still at 25600 which seems fine according to the mbuf statistic above. This is on a GENERIC FreeBSD 6.2 system with an em network card at 100mbit. Greetings, Sascha From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 16:46:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE25816A417; Mon, 21 Jan 2008 16:46:22 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog17.obsmtp.com (s200aog17.obsmtp.com [207.126.144.131]) by mx1.freebsd.org (Postfix) with SMTP id CE70C13C458; Mon, 21 Jan 2008 16:46:21 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob017.postini.com ([207.126.147.11]) with SMTP; Mon, 21 Jan 2008 16:46:15 UTC Received: from bill.mintel.co.uk (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id F216A18141B; Mon, 21 Jan 2008 16:46:14 +0000 (GMT) Message-ID: <4794CC56.2030802@tomjudge.com> Date: Mon, 21 Jan 2008 16:46:14 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <001b01c85c0f$6ca051d0$1e01c80a@John> <4794703A.4020801@FreeBSD.org> In-Reply-To: <4794703A.4020801@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Enovation Technologies Subject: Re: help 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, 21 Jan 2008 16:46:22 -0000 Bruce M. Simpson wrote: > Enovation Technologies wrote: >> i configure with sysinstall my second nic , but when i restart my box >> i have this message >> arp: 10.200.1.1 is on re0 but got reply from 00:50:7f:b0:a0:f8 on re1 >> >> >> my question is how to configure 2 nics with different ip on same box >> in the same subnet. >> > > Configure the second with a /32 prefix (netmask 255.255.255.255) instead > of the usual netmask. > > You will always receive the arp warning unless you disable it by setting > sysctl > net.link.ether.inet.log_arp_wrong_iface and > net.link.ether.inet.log_arp_movements to 0. > > These limitations *may* go away in future releases. > Surely this configuration will cause all the reply's to be routed out of re0 without some form of pfil layer manipulation? Tom From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 17:48:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBDC516A41A for ; Mon, 21 Jan 2008 17:48:28 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by mx1.freebsd.org (Postfix) with ESMTP id B9EAB13C4CC for ; Mon, 21 Jan 2008 17:48:28 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 1JH0kz-0001ih-8D for freebsd-net@freebsd.org; Mon, 21 Jan 2008 17:48:25 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp3.email.verio.net with esmtp id 1JH0kz-0007P9-3c for freebsd-net@freebsd.org; Mon, 21 Jan 2008 17:48:25 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id ABEDB8E296; Mon, 21 Jan 2008 11:48:18 -0600 (CST) Date: Mon, 21 Jan 2008 11:48:18 -0600 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20080121174818.GA11928@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <001b01c85c0f$6ca051d0$1e01c80a@John> <4794703A.4020801@FreeBSD.org> <4794CC56.2030802@tomjudge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <4794CC56.2030802@tomjudge.com> Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: help X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2008 17:48:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Judge wrote: > > >> my question is how to configure 2 nics with different ip on same > >> box in the same subnet. > > > > Configure the second with a /32 prefix (netmask 255.255.255.255) > > instead of the usual netmask. > > Surely this configuration will cause all the reply's to be routed out > of re0 without some form of pfil layer manipulation? If both nic's are connected to the same broadcast domain, what difference does it make which nic sends the traffic? - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFHlNrhFSrKRjX5eCoRAgTEAJ9HgbLoMNiDUyI+3pPQr15ZofJjqACfUncG y6742bpKKJdP3iVrZiLQox4= =3cat -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 18:10:02 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2D8216A469 for ; Mon, 21 Jan 2008 18:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 90B3613C46B for ; Mon, 21 Jan 2008 18:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0LIA2e9082687 for ; Mon, 21 Jan 2008 18:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0LIA2G5082686; Mon, 21 Jan 2008 18:10:02 GMT (envelope-from gnats) Date: Mon, 21 Jan 2008 18:10:02 GMT Message-Id: <200801211810.m0LIA2G5082686@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Matthew X. Economou" Cc: Subject: Re: kern/117271: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in /boot/loader.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Matthew X. Economou" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2008 18:10:02 -0000 The following reply was made to PR kern/117271; it has been noted by GNATS. From: "Matthew X. Economou" To: , Cc: Subject: Re: kern/117271: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in /boot/loader.conf Date: Mon, 21 Jan 2008 12:17:23 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C85C27.93B17660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I can confirm this problem (GENERIC kernel on RELENG_6_3, i.e., 6.3-RELEASE). I also found that if I boot with if_tap loaded at boot time by /boot/loader.conf, I can unload and reload the tap driver (kldunload if_tap; kldload if_tap) and then start OpenVPN without any problems. ------=_NextPart_000_0023_01C85C27.93B17660 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOszCCBwgw ggXwoAMCAQICChYAlZkAAQAAAHAwDQYJKoZIhvcNAQEFBQAwUTETMBEGCgmSJomT8ixkARkWA29y ZzEWMBQGCgmSJomT8ixkARkWBmlydG5vZzEiMCAGA1UEAxMZSVJUTk9HLk9SRyBSb290IEF1dGhv cml0eTAeFw0wNzA5MjUxODM3NDRaFw0wODA5MjQxODM3NDRaMIGnMRMwEQYKCZImiZPyLGQBGRYD b3JnMRYwFAYKCZImiZPyLGQBGRYGaXJ0bm9nMRMwEQYDVQQLEwpNeUJ1c2luZXNzMQ4wDAYDVQQL EwVVc2VyczERMA8GA1UECxMIU0JTVXNlcnMxHDAaBgNVBAMTE01hdHRoZXcgWC4gRWNvbm9tb3Ux IjAgBgkqhkiG9w0BCQEWE3hlbm9waG9uQGlydG5vZy5vcmcwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAMghkqwkEd0cuBSeyjc0ouYCJlNi72KT1uajTByyuVfckGqtdXFVlhoJF1MzjnqpUw8A 6pk2EUIoZr9CK3t3gtfCyg5CD/2Mzc/7bgC46TXSGQ6qFEi/HtOgbXcIkVOqLTSv3hTh8rhfK5bL 2o13CWiHyjmxBkD1Pdka2YvueZdBAgMBAAGjggQNMIIECTALBgNVHQ8EBAMCBaAwNgYJKoZIhvcN AQkPBCkwJzANBggqhkiG9w0DAgIBODANBggqhkiG9w0DBAIBODAHBgUrDgMCBzAdBgNVHQ4EFgQU c5u8UU6hQsExMvkmjVLGAHKQWlswFwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaA FCpIoZ65QNVXdsdF7FIYwfB61Ve+MIIBZQYDVR0fBIIBXDCCAVgwggFUoIIBUKCCAUyGgbtsZGFw Oi8vQ049SVJUTk9HLk9SRyBSb290IEF1dGhvcml0eSgxKSxDTj1zdnIxLENOPUNEUCxDTj1QdWJs aWMgS2V5IFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9aXJ0bm9nLERD PW9yZy8/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3Ry aWJ1dGlvblBvaW50hkZodHRwOi8vc3ZyMS5pcnRub2cub3JnL0NlcnRFbnJvbGwvSVJUTk9HLk9S RyUyMFJvb3QlMjBBdXRob3JpdHkoMSkuY3JshkRmaWxlOi8vXFxzdnIxLmlydG5vZy5vcmcvQ2Vy dEVucm9sbC9JUlROT0cuT1JHIFJvb3QgQXV0aG9yaXR5KDEpLmNybDCCAY4GCCsGAQUFBwEBBIIB gDCCAXwwgbMGCCsGAQUFBzABhoGmbGRhcDovL0NOPUlSVE5PRy5PUkcgUm9vdCBBdXRob3JpdHks Q049QUlBLENOPVB1YmxpYyBLZXkgU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz1pcnRub2csREM9b3JnLz9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTBiBggrBgEFBQcwAYZWaHR0cDovL3N2cjEuaXJ0bm9nLm9yZy9DZXJ0 RW5yb2xsL3N2cjEuaXJ0bm9nLm9yZ19JUlROT0cuT1JHJTIwUm9vdCUyMEF1dGhvcml0eSgxKS5j cnQwYAYIKwYBBQUHMAGGVGZpbGU6Ly9cXHN2cjEuaXJ0bm9nLm9yZy9DZXJ0RW5yb2xsL3N2cjEu aXJ0bm9nLm9yZ19JUlROT0cuT1JHIFJvb3QgQXV0aG9yaXR5KDEpLmNydDApBgNVHSUEIjAgBgor BgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQwYDVR0RBDwwOqAjBgorBgEEAYI3FAIDoBUM E3hlbm9waG9uQGlydG5vZy5vcmeBE3hlbm9waG9uQGlydG5vZy5vcmcwDQYJKoZIhvcNAQEFBQAD ggEBAHDOxYgKLkgD8xjxzDZVbc30p8sM7sNjaST4/KBVaEaMo7Wv+sMy+/Q5+OaXGwXVglof3CMR FH0KEi2vTwdrt4wmiSacygfqnlDdgBI1Yw+eqXzSGGcNYHRrtKMn+UN837BiBby+U6i4k/WwlmZv v3xQawDd17sZ0zf8Xlye++s2+FMEtlZa4SLoiA1NJEiVS+RE8mh/6Yr4CBqoMEHV+zOciqHIVdVf dvOaRuOFtnv1+bx7oiPwuCqC/uNrJi2FAkGjbYVLei1X3x4RX7ASl5d8DaKkbmozgGDpEI7W07aH OwvrJLQFLYq0Mhibro4vv+L1aXvpGAVcFWouNTKbK+EwggejMIIGi6ADAgECAhBluZdHFVh8oEzX i+HMf5M7MA0GCSqGSIb3DQEBBQUAMFExEzARBgoJkiaJk/IsZAEZFgNvcmcxFjAUBgoJkiaJk/Is ZAEZFgZpcnRub2cxIjAgBgNVBAMTGUlSVE5PRy5PUkcgUm9vdCBBdXRob3JpdHkwHhcNMDUwMzAz MTQzODM3WhcNMTAwMzAzMTQ0ODM3WjBRMRMwEQYKCZImiZPyLGQBGRYDb3JnMRYwFAYKCZImiZPy LGQBGRYGaXJ0bm9nMSIwIAYDVQQDExlJUlROT0cuT1JHIFJvb3QgQXV0aG9yaXR5MIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyE4xTXFne6/D+ArV8QDbzimf/S0TPsDCr6FNTiBVUmEN SpNeLGB/O95wiTeybNh5WhPB+6x4DKK69TGfcL2UgIu0KNGQo0Ygby/A6kKtn6nrDwNjqiYk//IW pdS2C48hlOX2NBXhHHp3Uc8fALWl8MXR3uAeCHjeAMYJ7O1+r6pw2OEtHdxZcdP9qLqtIhNrHEiJ IMJMZwBuDo0taIGnk5tfIWHaj77zxrwb3bgTw42jnaUqP9HfKnTsS9ULU9yo5XNPKU2sJtzubjW+ bmKQVI+s1uht32cex6OeclUDt2TzME9tvBU3RJhUuEuO1diprUkdsNg4JcyUfIa96drN6wIDAQAB o4IEdTCCBHEwEwYJKwYBBAGCNxQCBAYeBABDAEEwCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFCpIoZ65QNVXdsdF7FIYwfB61Ve+MIIByQYDVR0fBIIBwDCCAbwwggG4oIIB tKCCAbCGZmZpbGU6Ly9DOlxXSU5ET1dTXHN5c3RlbTMyXENlcnRTcnZcQ2VydEVucm9sbFwlM0ND YU5hbWUlM0UlM0NDUkxOYW1lU3VmZml4JTNFJTNDRGVsdGFDUkxBbGxvd2VkJTNFLmNybIaBk2xk YXA6Ly9DTj08Q0FUcnVuY2F0ZWROYW1lPjxDUkxOYW1lU3VmZml4PixDTj08U2VydmVyU2hvcnRO YW1lPixDTj1DRFAsQ049UHVibGljIEtleSBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyw8Q29uZmlndXJh dGlvbkNvbnRhaW5lcj48Q0RQT2JqZWN0Q2xhc3M+L4ZeaHR0cDovLyUzQ3NlcnZlcmRuc25hbWUl M0UvQ2VydEVucm9sbC8lM0NDYU5hbWUlM0UlM0NDUkxOYW1lU3VmZml4JTNFJTNDRGVsdGFDUkxB bGxvd2VkJTNFLmNybIZQZmlsZTovL1xcPFNlcnZlckROU05hbWU+L0NlcnRFbnJvbGwvPENhTmFt ZT48Q1JMTmFtZVN1ZmZpeD48RGVsdGFDUkxBbGxvd2VkPi5jcmwwEgYJKwYBBAGCNxUBBAUCAwEA ATBEBgNVHSAEPTA7MDkGCSsGAQQB0WQAATAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd2ViLmlydG5v Zy5vcmcvbGVnYWwvY2EwggHPBggrBgEFBQcBAQSCAcEwggG9MHMGCCsGAQUFBzAChmdmaWxlOi8v QzpcV0lORE9XU1xzeXN0ZW0zMlxDZXJ0U3J2XENlcnRFbnJvbGxcJTNDU2VydmVyRE5TTmFtZSUz RV8lM0NDYU5hbWUlM0UlM0NDZXJ0aWZpY2F0ZU5hbWUlM0UuY3J0MHoGCCsGAQUFBzAChm5sZGFw Oi8vQ049PENBVHJ1bmNhdGVkTmFtZT4sQ049QUlBLENOPVB1YmxpYyBLZXkgU2VydmljZXMsQ049 U2VydmljZXMsPENvbmZpZ3VyYXRpb25Db250YWluZXI+PENBT2JqZWN0Q2xhc3M+LzBrBggrBgEF BQcwAoZfaHR0cDovLyUzQ3NlcnZlcmRuc25hbWUlM0UvQ2VydEVucm9sbC8lM0NTZXJ2ZXJETlNO YW1lJTNFXyUzQ0NhTmFtZSUzRSUzQ0NlcnRpZmljYXRlTmFtZSUzRS5jcnQwXQYIKwYBBQUHMAKG UWZpbGU6Ly9cXDxTZXJ2ZXJETlNOYW1lPi9DZXJ0RW5yb2xsLzxTZXJ2ZXJETlNOYW1lPl88Q2FO YW1lPjxDZXJ0aWZpY2F0ZU5hbWU+LmNydDAjBgkrBgEEAYI3FQIEFgQUVTgfUfp1gLMYngiR0CwR zTjx/g0wDQYJKoZIhvcNAQEFBQADggEBAHlQMSPOE1jl+qYYh6lKOr9v6JvZSDnTGpBEDJItlgwJ NmPZHRXt4KjqgMQZ86rvHeVXeu8L7H+g1SegHQo1vTElzUtQ6NDpO6u3Wuhib5IHivtAOSoCWi39 wsqrmn8mnAGxaBqNv7b616upZa3e4O+HFq2p+1+Te3+y7YY9qtUEdinxD+IxKzC7sNfW8cedVokJ EXkazM2g367Wr96aGM/4zNRoeObPbRFRJuPIU9avo4TDji+Tlpw6xXwRnobtyZQD+NKi3NS/NoP1 GSxFcdpt8hwnLNbixgWT0mIlC9VOkZyE1YjpY2iWQPBEIJ4mnxMiaMtoJTX9Uyb3mzxD+PwxggKx MIICrQIBATBfMFExEzARBgoJkiaJk/IsZAEZFgNvcmcxFjAUBgoJkiaJk/IsZAEZFgZpcnRub2cx IjAgBgNVBAMTGUlSVE5PRy5PUkcgUm9vdCBBdXRob3JpdHkCChYAlZkAAQAAAHAwCQYFKw4DAhoF AKCCAagwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMTIxMTcx NzIzWjAjBgkqhkiG9w0BCQQxFgQUqhASb0qjcmdPC+BLyKPLdIplYgcwZwYJKoZIhvcNAQkPMVow WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbgYJKwYBBAGCNxAEMWEwXzBRMRMwEQYK CZImiZPyLGQBGRYDb3JnMRYwFAYKCZImiZPyLGQBGRYGaXJ0bm9nMSIwIAYDVQQDExlJUlROT0cu T1JHIFJvb3QgQXV0aG9yaXR5AgoWAJWZAAEAAABwMHAGCyqGSIb3DQEJEAILMWGgXzBRMRMwEQYK CZImiZPyLGQBGRYDb3JnMRYwFAYKCZImiZPyLGQBGRYGaXJ0bm9nMSIwIAYDVQQDExlJUlROT0cu T1JHIFJvb3QgQXV0aG9yaXR5AgoWAJWZAAEAAABwMA0GCSqGSIb3DQEBAQUABIGAbHG6vr5ivvMb Qk1itZbyR+pKow03cG9pgk81aWBc4fXA/+lLHGOBB4l47JMIBnx6NpHhSpA4Vpy3NR8sJcHI4xfc cqaA7hBpJxDLekICXxDE8sE4w+h1hlHPOsQtb8GvdCEmAikjqaqSiu+Gypan/af7at4zlvQ6mMTs shZR6dsAAAAAAAA= ------=_NextPart_000_0023_01C85C27.93B17660-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 19:20:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 611A716A418 for ; Mon, 21 Jan 2008 19:20:09 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200bog10.obsmtp.com (s200bog10.obsmtp.com [207.126.150.124]) by mx1.freebsd.org (Postfix) with SMTP id 3615913C47E for ; Mon, 21 Jan 2008 19:20:07 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu2sys200bob010.postini.com ([207.126.147.11]) with SMTP; Mon, 21 Jan 2008 19:20:06 UTC Received: from bill.mintel.co.uk (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 8665018141E for ; Mon, 21 Jan 2008 19:20:06 +0000 (GMT) Message-ID: <4794F065.5070800@tomjudge.com> Date: Mon, 21 Jan 2008 19:20:05 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <001b01c85c0f$6ca051d0$1e01c80a@John> <4794703A.4020801@FreeBSD.org> <4794CC56.2030802@tomjudge.com> <20080121174818.GA11928@verio.net> In-Reply-To: <20080121174818.GA11928@verio.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: help 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, 21 Jan 2008 19:20:09 -0000 David DeSimone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tom Judge wrote: >>>> my question is how to configure 2 nics with different ip on same >>>> box in the same subnet. >>> Configure the second with a /32 prefix (netmask 255.255.255.255) >>> instead of the usual netmask. >> Surely this configuration will cause all the reply's to be routed out >> of re0 without some form of pfil layer manipulation? > > If both nic's are connected to the same broadcast domain, what > difference does it make which nic sends the traffic? > This could cause some arp related issues at the other end? What if the remote end point updates its arp entry because it thinks the remote endpoints address has changed (as it has a direct route to the network i.e. it has an IP in 10.200.1/24). It may be worth the original OP investigating if_lagg as it may provide some better solutions. Tom From owner-freebsd-net@FreeBSD.ORG Mon Jan 21 21:26:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16D7E16A41A for ; Mon, 21 Jan 2008 21:26:19 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5C57313C45B for ; Mon, 21 Jan 2008 21:26:18 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so2112042rvb.43 for ; Mon, 21 Jan 2008 13:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=DeRwatgjonbefUkh2mwu86gdcqqWzwoNY7jKVbzy84E=; b=k2PR8aKf5AfkbIUXAh/Ee6f0Bu4JzojUFwQUVHCupkfgOJWyblsefYHGf+pCaK7Fj554P7UbUIckLXlv2LiG2lfS6xy7TS/hSLqOaCX76hYrrsFKAtdIOKUS/8QRAMt/HFZaykA1S/dnjjIDgEh3jzokK/VNkzs9VpkCWeC5x0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ueYY2oNqGYdZ40/RN6YO79PWxRPw1kQtUbgNWfd2uqlfLv1OUIPVXGYIPMeb9DMl7S6HHJPiFE5JuWAppSJKd2BZWkF2qIW/jPQ+wnsMGgE8YQ3M9sCFB9bAxn8g60le6Etv/2TDUNEwLYWWBojtf+xWZnHUeOenFe4jKyELCqY= Received: by 10.141.141.3 with SMTP id t3mr4776077rvn.226.1200950777761; Mon, 21 Jan 2008 13:26:17 -0800 (PST) Received: by 10.141.170.18 with HTTP; Mon, 21 Jan 2008 13:26:17 -0800 (PST) Message-ID: <2e77fc10801211326t21239b58o5b5c7604a2980543@mail.gmail.com> Date: Mon, 21 Jan 2008 23:26:17 +0200 From: "Niki Denev" Sender: ndenev@gmail.com To: freebsd-net@freebsd.org In-Reply-To: <2e77fc10801210142g560f6f65p9908957d0c7a799e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2e77fc10801210142g560f6f65p9908957d0c7a799e@mail.gmail.com> X-Google-Sender-Auth: c4c3d8d1ea8789a8 Subject: Re: [PATCH] "/etc/rc.d/pf reload" fails if there are macros defined in pf_flags rcvar. 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, 21 Jan 2008 21:26:19 -0000 On Jan 21, 2008 11:42 AM, Niki Denev wrote: > Hi, > > I'm using the pf_flags rc var to set macros for pf.conf files i use in > redundant router configuration. > This way i can have exactly the same pf.conf on all of the routers, > and still set host specific > options as "hostid" used by pfsync via rc.conf > The problem is that when i use "/etc/rc.d/pf reload" to reload the rules, > the rc.d/pf script first executes pfctl with -n option to check the > pf.conf syntax, but fails to include > the $pf_flags var, and fails because of undefined macros. > The following patch fixed this for me. > > --- pf.orig 2008-01-21 11:18:27.000000000 +0200 > +++ pf 2008-01-21 11:29:56.000000000 +0200 > @@ -50,7 +50,7 @@ > pf_reload() > { > echo "Reloading pf rules." > - $pf_program -n -f "$pf_rules" || return 1 > + $pf_program -n -f "$pf_rules" $pf_flags || return 1 > # Flush everything but existing state entries that way when > # rules are read in, it doesn't break established connections. > $pf_program -Fnat -Fqueue -Frules -FSources -Finfo -FTables > -Fosfp > /dev/null 2>&1 > > > > -- > Niki > Just filed under misc/119874 From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 14:57:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4892716A417 for ; Tue, 22 Jan 2008 14:57:57 +0000 (UTC) (envelope-from styxshixg@gmail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.241]) by mx1.freebsd.org (Postfix) with ESMTP id 0ECEE13C447 for ; Tue, 22 Jan 2008 14:57:56 +0000 (UTC) (envelope-from styxshixg@gmail.com) Received: by hs-out-2122.google.com with SMTP id h53so2472296hsh.11 for ; Tue, 22 Jan 2008 06:57:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=OgP32Ew8ripQxRJU2/OFff94ukQK/WLojeVjNvmbjpY=; b=YHeAZHwuOm+nMmjYT7Zg5UuGJLf4kYMlaYOUjugcVVs+GUkrPAzs2YKZfssRHaOOjO0vzk5iy3QaDkQ/C6C1q4f1M/SOM9npEBYsvn9sKEDHP0FoU6PCRcjFsqM0zc/ceM3qnQbT5LhoVl6wj51KvXXskJvNE7NTFQv+YI9zIKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=cFFvUlDf9fQO3jrXkVZXO9yjgznQ7mtsV0I6Py40jZ6HiY0mwKWNgp0gCjfo4L2GYxjUiE4rgn9q3VXvC9qUm1six1UKFMCLz763Si4wbgP+BGzzqlf9GUtxD74CDZtntfkRHKXCCGiOwGtY9fgEx3YskQb/QuEnRwhflfiKkr8= Received: by 10.114.37.1 with SMTP id k1mr6937612wak.6.1201012188795; Tue, 22 Jan 2008 06:29:48 -0800 (PST) Received: by 10.114.171.15 with HTTP; Tue, 22 Jan 2008 06:29:48 -0800 (PST) Message-ID: <8236bb940801220629h4fd8477eg68c1621bb1713d4@mail.gmail.com> Date: Tue, 22 Jan 2008 22:29:48 +0800 From: "xingang shi" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: routing table lookup algorithm 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, 22 Jan 2008 14:57:57 -0000 One of Andr=E9 Oppermann's paper memtioned that there will be a new routing table lookup algorithm in FreeBSD 7, Anyone knows is there any document about this algorithm? Or which part of the src code is for this function. Thanks very much. regards xingang From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 18:30:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9B8416A419 for ; Tue, 22 Jan 2008 18:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9DFA313C458 for ; Tue, 22 Jan 2008 18:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0MIU3Ut018484 for ; Tue, 22 Jan 2008 18:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0MIU312018478; Tue, 22 Jan 2008 18:30:03 GMT (envelope-from gnats) Date: Tue, 22 Jan 2008 18:30:03 GMT Message-Id: <200801221830.m0MIU312018478@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: wforms@Safe-mail.net Cc: Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wforms@Safe-mail.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2008 18:30:03 -0000 The following reply was made to PR kern/112654; it has been noted by GNATS. From: wforms@Safe-mail.net To: bug-followup@freebsd.org Cc: marius@alchemy.franken.de, "Andy Farkas" Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 Date: Tue, 22 Jan 2008 19:23:17 +0100 New test was carried out today using Marius' patch (and not using Andy's patch at the same time). The new kernel re-introduces the original problem, loading the if_pcn driver while the RJ45 cable is connected results in a kernel panic and the system reboots. While the cable is disconnected the if_pcn module loads fine, after which the cable can be plugged back and the card can be used as expected. ### Here is what shows up upon "kldload if_pcn" while the cable is unplugged ### pcn0: port 0x2180-0x219f mem 0xfebff800-0xfebff81f irq 17 at device 9.0 on pci0 pcn0: Chip ID 2624 (Am79C972) miibus5: on pcn0 nsphyter0: on miibus5 nsphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ukphy0: on miibus5 ukphy0: 10baseT, 10baseT-FDX, auto pcn0: Ethernet address: 00:06:29:50:d9:9e ### At that point ifconfig says: ### root@netfinity ~# ifconfig pcn0 pcn0: flags=8802 mtu 1500 ether 00:06:29:50:d9:9e media: Ethernet autoselect (none) status: no carrier ### Then I connect the RJ45 cable coming from the switch and: ### root@netfinity ~# ifconfig pcn0 pcn0: flags=8802 mtu 1500 ether 00:06:29:50:d9:9e media: Ethernet autoselect (100baseTX ) status: active root@netfinity ~# ### Now here is what "kldload if_pcn" does while the cable is connected: ### pcn0: port 0x2180-0x219f mem 0xfebff800-0xfebff81f irq 17 at device 9.0 on pci0 pcn0: Chip ID 2624 (Am79C972) miibus5: on pcn0 nsphyter0: on miibus5 nsphyter0: no media present ifmedia_set: no match for 0x0/0xfffffff panic: ifmedia_set Regards, Keve From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 19:50:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 469C316A419 for ; Tue, 22 Jan 2008 19:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3C5E813C459 for ; Tue, 22 Jan 2008 19:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0MJo3q7023407 for ; Tue, 22 Jan 2008 19:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0MJo30l023406; Tue, 22 Jan 2008 19:50:03 GMT (envelope-from gnats) Date: Tue, 22 Jan 2008 19:50:03 GMT Message-Id: <200801221950.m0MJo30l023406@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Marius Strobl Cc: Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marius Strobl List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2008 19:50:04 -0000 The following reply was made to PR kern/112654; it has been noted by GNATS. From: Marius Strobl To: bug-followup@freebsd.org Cc: Andy Farkas , wforms@Safe-mail.net Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 Date: Tue, 22 Jan 2008 20:43:48 +0100 On Tue, Jan 22, 2008 at 07:23:17PM +0100, wforms@Safe-mail.net wrote: > New test was carried out today using Marius' patch (and not using Andy's patch at the same time). > The new kernel re-introduces the original problem, loading the if_pcn driver while the RJ45 cable is connected results in a kernel panic and the system reboots. While the cable is disconnected the if_pcn module loads fine, after which the cable can be plugged back and the card can be used as expected. > > ### Here is what shows up upon "kldload if_pcn" while the cable is unplugged ### > pcn0: port 0x2180-0x219f mem 0xfebff800-0xfebff81f > irq 17 at device 9.0 on pci0 > pcn0: Chip ID 2624 (Am79C972) > miibus5: on pcn0 > nsphyter0: on miibus5 > nsphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ukphy0: on miibus5 > ukphy0: 10baseT, 10baseT-FDX, auto > pcn0: Ethernet address: 00:06:29:50:d9:9e > > ### At that point ifconfig says: ### > root@netfinity ~# ifconfig pcn0 > pcn0: flags=8802 mtu 1500 > ether 00:06:29:50:d9:9e > media: Ethernet autoselect (none) > status: no carrier > ### Then I connect the RJ45 cable coming from the switch and: ### > root@netfinity ~# ifconfig pcn0 > pcn0: flags=8802 mtu 1500 > ether 00:06:29:50:d9:9e > media: Ethernet autoselect (100baseTX ) > status: active > root@netfinity ~# > > > ### Now here is what "kldload if_pcn" does while the cable is connected: ### > pcn0: port 0x2180-0x219f mem 0xfebff800-0xfebff81f > irq 17 at device 9.0 on pci0 > pcn0: Chip ID 2624 (Am79C972) > miibus5: on pcn0 > nsphyter0: on miibus5 > nsphyter0: no media present > ifmedia_set: no match for 0x0/0xfffffff > panic: ifmedia_set > Could you please: 1) try again with the nsphyter patch already in place and http://people.freebsd.org/~marius/nsphyter.c copied on top of the existing src/sys/dev/mii/nsphyter.c? The new one uses the reset function from nsphy(4), which is about the only thing I can think of making the difference that a nsphy(4) hacked to attach to the DP83843 doesn't panic. 2) In case it also panics with the nsphyter.c provide a backtrace. Thanks, Marius From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 21:23:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C80716A420 for ; Tue, 22 Jan 2008 21:23:19 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from mx31.bluewin.ch (mx31.bluewin.ch [195.186.18.42]) by mx1.freebsd.org (Postfix) with ESMTP id 296FF13C4D1 for ; Tue, 22 Jan 2008 21:23:19 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from hbnnbsddev91.sharedtcs.net (213.3.8.216) by mx31.bluewin.ch (Bluewin wppuqpqq 7.3.121) id 4795E272000DBC2F for freebsd-net@freebsd.org; Tue, 22 Jan 2008 21:11:54 +0000 Received: from hbnnbsddev01.sharedtcs.net (localhost.sharedtcs.net [127.0.0.1]) by hbnnbsddev01.sharedtcs.net (8.13.8/8.13.8) with ESMTP id m0MHeT0c064335 for ; Tue, 22 Jan 2008 18:40:29 +0100 (CET) (envelope-from tbeoepa1@hbnnbsddev01.sharedtcs.net) Received: (from tbeoepa1@localhost) by hbnnbsddev01.sharedtcs.net (8.13.8/8.13.8/Submit) id m0MHeSvj064334 for freebsd-net@freebsd.org; Tue, 22 Jan 2008 18:40:28 +0100 (CET) (envelope-from tbeoepa1) Date: Tue, 22 Jan 2008 18:40:28 +0100 From: Patrick Oeschger To: freebsd-net@freebsd.org Message-ID: <20080122174028.GA64136@hbnnbsddev01.sharedtcs.net> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: 6.3-RELEASE/7.0-RC1: em(4) fails on 82571EB_SERDES 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, 22 Jan 2008 21:23:19 -0000 maybe i found two issues which are em(4) related... i tested the 6.3-RELEASE on a appliance which has two on-board SFP slots chipset: i82571eb (serdes with tbi-interface) em4@pci8:0:0: class=0x020000 card=0x10761903 chip=0x10608086 rev=0x06 hdr=0x00 em5@pci8:0:1: class=0x020000 card=0x10761903 chip=0x10608086 rev=0x06 hdr=0x00 first issue: on the SFP ports link status is always up - even if no fiber optic cable is attached this problem seems to be E1000_STATUS_LU related (in serdes mode the chipset will use the LU flag to indicate 'signal loss' which it gets signaled from the SFP module - PCIe* Gbe Controllers Open Source Software Developer's Manual DocID: 316080-001 (December 2006) 8.3.3 Loss of Signal/Link Status Indication 14.8.3 Mac/SerDes (TBI-Mode) Link Setup the following patch resolved this issue during my test: --- sys/dev/em/if_em.c.orig 2008-01-22 16:55:06.000000000 +0100 +++ sys/dev/em/if_em.c 2008-01-22 13:33:58.000000000 +0100 @@ -2491,9 +2494,21 @@ { struct ifnet *ifp = adapter->ifp; device_t dev = adapter->dev; + bool status_lu = E1000_READ_REG(&adapter->hw, E1000_STATUS) & + E1000_STATUS_LU; + + if ((adapter->hw.device_id == E1000_DEV_ID_82571EB_SERDES) && + (!(E1000_READ_REG(&adapter->hw, E1000_TXCW) & E1000_TXCW_ANE)) && + (E1000_READ_REG(&adapter->hw, E1000_CTRL) & E1000_CTRL_SLU)) { + if (E1000_READ_REG(&adapter->hw, E1000_STATUS) & + E1000_STATUS_LU) { + status_lu = 0; + } else { + status_lu = 1; + } + } - if (E1000_READ_REG(&adapter->hw, E1000_STATUS) & - E1000_STATUS_LU) { + if (status_lu) { if (adapter->link_active == 0) { e1000_get_speed_and_duplex(&adapter->hw, &adapter->link_speed, &adapter->link_duplex); second issue: during branching of the fibre optic cabling i get a few messages regarding 'coalesced states' Jan 22 10:36:00 test kernel: em4: 2 link states coalesced this seems to be because of link state interrupts generated by the chipset during branching of the fiber optic cable the link can change quickly multiple times the following patch resolved this issue during my test: ...maybe the driver needs the same for EM_FAST_IRQ and POLLING(?) --- sys/dev/em/if_em.c.orig 2008-01-22 16:55:06.000000000 +0100 +++ sys/dev/em/if_em.c 2008-01-22 13:33:58.000000000 +0100 @@ -1460,7 +1460,9 @@ struct adapter *adapter = arg; struct ifnet *ifp; uint32_t reg_icr; - + bool do_update = (adapter->hw.device_id == + E1000_DEV_ID_82571EB_SERDES) ? + FALSE : TRUE; EM_CORE_LOCK(adapter); ifp = adapter->ifp; @@ -1499,7 +1501,8 @@ callout_stop(&adapter->timer); adapter->hw.mac.get_link_status = 1; e1000_check_for_link(&adapter->hw); - em_update_link_status(adapter); + if (do_update) + em_update_link_status(adapter); /* Deal with TX cruft when link lost */ em_tx_purge(adapter); callout_reset(&adapter->timer, hz, - is there any way to get 82571_SERDES working in a future release of the em(4) driver? input on this issue is very welcome br -pat- From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 22:12:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BADAF16A420 for ; Tue, 22 Jan 2008 22:12:36 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpauth01.prod.mesa1.secureserver.net (smtpauth01.prod.mesa1.secureserver.net [64.202.165.181]) by mx1.freebsd.org (Postfix) with SMTP id AAD3813C4DB for ; Tue, 22 Jan 2008 22:12:36 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 10933 invoked from network); 22 Jan 2008 21:45:08 -0000 Received: from unknown (24.144.77.185) by smtpauth01.prod.mesa1.secureserver.net (64.202.165.181) with ESMTP; 22 Jan 2008 21:45:08 -0000 Message-ID: <479663C0.3090606@seclark.us> Date: Tue, 22 Jan 2008 16:44:32 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: duplicate packet using divert X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2008 22:12:36 -0000 Hello List, does anyone have a program that uses the divert socket to duplicate an incoming packet so it can be sent to another address. Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 23:42:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62CF216A41A for ; Tue, 22 Jan 2008 23:42:07 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 5287213C461 for ; Tue, 22 Jan 2008 23:42:07 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 7465F1EDDD25; Tue, 22 Jan 2008 15:24:12 -0800 (PST) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id 5B9932807E; Tue, 22 Jan 2008 15:24:12 -0800 (PST) X-AuditID: 11807130-a8442bb0000028a7-45-47967b1ccba8 Received: from cswiger1.apple.com (cswiger1.apple.com [17.214.13.96]) by relay11.apple.com (Apple SCV relay) with ESMTP id 3A89328057; Tue, 22 Jan 2008 15:24:12 -0800 (PST) Message-Id: <715218DB-7DE4-4CCF-A858-03AC05BA4732@mac.com> From: Chuck Swiger To: Stephen.Clark@seclark.us In-Reply-To: <479663C0.3090606@seclark.us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 22 Jan 2008 15:24:11 -0800 References: <479663C0.3090606@seclark.us> X-Mailer: Apple Mail (2.915) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-net@freebsd.org Subject: Re: duplicate packet using divert X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2008 23:42:07 -0000 On Jan 22, 2008, at 1:44 PM, Stephen Clark wrote: > does anyone have a program that uses the divert socket to duplicate > an incoming packet so it can be > sent to another address. Well, I assume you could start with the ipfw "tee" directive and /usr/ src/sbin/natd ...? -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Jan 22 23:49:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C36AA16A419 for ; Tue, 22 Jan 2008 23:49:05 +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 9797013C469 for ; Tue, 22 Jan 2008 23:49:05 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so4677594waf.3 for ; Tue, 22 Jan 2008 15:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=2uc1PDt7JCb3DkKo31cc3b983JFyJV/h0l0v0ZnFR7c=; b=Cgn1zvvoMFKJIphnYvb1UqQXrr6DbtrTQWrpEetna4/Ut/YBzbcAf+tMCs97tEn+QpuslknfIakF5R2tK4VmMFd6kK/0TJMMy4QSwq1qX1V/oP2xc+bvn6JXb2wWXpUVDjqOlcUizz22kcyXgxQGvsUTWJ1YEabCpIU07kh1V6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZXhYMXpz4scpqaomnE5RF3Jd1fcUFKt41a/v/qFckvGdeFrOSnQ7mjG2s8DECJSFfaQobV1X+BnakaE4yfTRx/6TIMyDnMKUL2hEIs+3JQMsufXcAWcZjqSEj6+1riVQ3WPAxWKR7ELYCwk0CQKtwf2KMeHQQ7FqV5CPViZi6TY= Received: by 10.114.95.1 with SMTP id s1mr7260866wab.99.1201045745230; Tue, 22 Jan 2008 15:49:05 -0800 (PST) Received: by 10.114.177.4 with HTTP; Tue, 22 Jan 2008 15:49:05 -0800 (PST) Message-ID: <2a41acea0801221549u1fdcc201g46dc4d1d516ee823@mail.gmail.com> Date: Tue, 22 Jan 2008 15:49:05 -0800 From: "Jack Vogel" To: freebsd-net@freebsd.org In-Reply-To: <20080122174028.GA64136@hbnnbsddev01.sharedtcs.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080122174028.GA64136@hbnnbsddev01.sharedtcs.net> Subject: Re: 6.3-RELEASE/7.0-RC1: em(4) fails on 82571EB_SERDES 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, 22 Jan 2008 23:49:05 -0000 On Jan 22, 2008 9:40 AM, Patrick Oeschger wrote: > maybe i found two issues which are em(4) related... > i tested the 6.3-RELEASE on a appliance which has two on-board SFP slots > chipset: i82571eb (serdes with tbi-interface) > em4@pci8:0:0: class=0x020000 card=0x10761903 chip=0x10608086 rev=0x06 hdr=0x00 > em5@pci8:0:1: class=0x020000 card=0x10761903 chip=0x10608086 rev=0x06 hdr=0x00 > > first issue: > on the SFP ports link status is always up - even if no fiber optic cable is > attached > this problem seems to be E1000_STATUS_LU related (in serdes mode the chipset > will use the LU flag to indicate 'signal loss' which it gets signaled from the > SFP module > - PCIe* Gbe Controllers Open Source Software Developer's Manual > DocID: 316080-001 (December 2006) > 8.3.3 Loss of Signal/Link Status Indication > 14.8.3 Mac/SerDes (TBI-Mode) Link Setup > the following patch resolved this issue during my test: > > --- sys/dev/em/if_em.c.orig 2008-01-22 16:55:06.000000000 +0100 > +++ sys/dev/em/if_em.c 2008-01-22 13:33:58.000000000 +0100 > @@ -2491,9 +2494,21 @@ > { > struct ifnet *ifp = adapter->ifp; > device_t dev = adapter->dev; > + bool status_lu = E1000_READ_REG(&adapter->hw, E1000_STATUS) & > + E1000_STATUS_LU; > + > + if ((adapter->hw.device_id == E1000_DEV_ID_82571EB_SERDES) && > + (!(E1000_READ_REG(&adapter->hw, E1000_TXCW) & E1000_TXCW_ANE)) && > + (E1000_READ_REG(&adapter->hw, E1000_CTRL) & E1000_CTRL_SLU)) { > + if (E1000_READ_REG(&adapter->hw, E1000_STATUS) & > + E1000_STATUS_LU) { > + status_lu = 0; > + } else { > + status_lu = 1; > + } > + } > > - if (E1000_READ_REG(&adapter->hw, E1000_STATUS) & > - E1000_STATUS_LU) { > + if (status_lu) { > if (adapter->link_active == 0) { > e1000_get_speed_and_duplex(&adapter->hw, > &adapter->link_speed, &adapter->link_duplex); > > second issue: > during branching of the fibre optic cabling i get a few messages regarding > 'coalesced states' > Jan 22 10:36:00 test kernel: em4: 2 link states coalesced > this seems to be because of link state interrupts generated by the chipset > during branching of the fiber optic cable the link can change quickly > multiple times > the following patch resolved this issue during my test: > ...maybe the driver needs the same for EM_FAST_IRQ and POLLING(?) > > --- sys/dev/em/if_em.c.orig 2008-01-22 16:55:06.000000000 +0100 > +++ sys/dev/em/if_em.c 2008-01-22 13:33:58.000000000 +0100 > @@ -1460,7 +1460,9 @@ > struct adapter *adapter = arg; > struct ifnet *ifp; > uint32_t reg_icr; > - > + bool do_update = (adapter->hw.device_id == > + E1000_DEV_ID_82571EB_SERDES) ? > + FALSE : TRUE; > EM_CORE_LOCK(adapter); > ifp = adapter->ifp; > > @@ -1499,7 +1501,8 @@ > callout_stop(&adapter->timer); > adapter->hw.mac.get_link_status = 1; > e1000_check_for_link(&adapter->hw); > - em_update_link_status(adapter); > + if (do_update) > + em_update_link_status(adapter); > /* Deal with TX cruft when link lost */ > em_tx_purge(adapter); > callout_reset(&adapter->timer, hz, > > - is there any way to get 82571_SERDES working in a future release of the > em(4) driver? > > input on this issue is very welcome > br > -pat- Thanks for the info Pat. SERDES isn't FIBER, and I'm not positive, but off the top of my head I'd say that link down is not supposed to be possible, isn't it? SERDES is like backplane connections in Bladeservers or similar things. On the other hand I really don't think that its been at all tested in FreeBSD so I appreciate your patch and feedback, I will try and look at your code and see about getting the fixes in. I am very busy right now so please be patient with me :) Jack From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 08:10:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5969316A494 for ; Wed, 23 Jan 2008 08:10:11 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from mx23.bluewin.ch (mx23.bluewin.ch [195.186.18.38]) by mx1.freebsd.org (Postfix) with ESMTP id 11EE713C4DB for ; Wed, 23 Jan 2008 08:10:10 +0000 (UTC) (envelope-from paketix@bluewin.ch) Received: from hbnnbsddev91.sharedtcs.net (213.3.8.216) by mx23.bluewin.ch (Bluewin wppuqpqq 7.3.121) id 4795DF8E00182A6B for freebsd-net@freebsd.org; Wed, 23 Jan 2008 08:10:09 +0000 Received: from hbnnbsddev91.sharedtcs.net (localhost.sharedtcs.net [127.0.0.1]) by hbnnbsddev91.sharedtcs.net (8.13.8/8.13.8) with ESMTP id m0N8Asqx067017 for ; Wed, 23 Jan 2008 09:10:54 +0100 (CET) (envelope-from tbeoepa1@hbnnbsddev91.sharedtcs.net) Received: (from tbeoepa1@localhost) by hbnnbsddev91.sharedtcs.net (8.13.8/8.13.8/Submit) id m0N8AsK8067016 for freebsd-net@freebsd.org; Wed, 23 Jan 2008 09:10:54 +0100 (CET) (envelope-from tbeoepa1) Date: Wed, 23 Jan 2008 09:10:54 +0100 From: Patrick Oeschger To: freebsd-net@freebsd.org Message-ID: <20080123081054.GC65204@hbnnbsddev91.sharedtcs.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20080122174028.GA64136@hbnnbsddev01.sharedtcs.net> <2a41acea0801221549u1fdcc201g46dc4d1d516ee823@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0801221549u1fdcc201g46dc4d1d516ee823@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Subject: Re: 6.3-RELEASE/7.0-RC1: em(4) fails on 82571EB_SERDES 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, 23 Jan 2008 08:10:11 -0000 On Tue, Jan 22, 2008 at 03:49:05PM -0800, Jack Vogel wrote: > On Jan 22, 2008 9:40 AM, Patrick Oeschger wrote: > > maybe i found two issues which are em(4) related... > > i tested the 6.3-RELEASE on a appliance which has two on-board SFP slots > > chipset: i82571eb (serdes with tbi-interface) > > em4@pci8:0:0: class=0x020000 card=0x10761903 chip=0x10608086 rev=0x06 hdr=0x00 > > em5@pci8:0:1: class=0x020000 card=0x10761903 chip=0x10608086 rev=0x06 hdr=0x00 > > > > first issue: > > on the SFP ports link status is always up - even if no fiber optic cable is > > attached > > this problem seems to be E1000_STATUS_LU related (in serdes mode the chipset > > will use the LU flag to indicate 'signal loss' which it gets signaled from the > > SFP module > > - PCIe* Gbe Controllers Open Source Software Developer's Manual > > DocID: 316080-001 (December 2006) > > 8.3.3 Loss of Signal/Link Status Indication > > 14.8.3 Mac/SerDes (TBI-Mode) Link Setup > > the following patch resolved this issue during my test: > > > > --- sys/dev/em/if_em.c.orig 2008-01-22 16:55:06.000000000 +0100 > > +++ sys/dev/em/if_em.c 2008-01-22 13:33:58.000000000 +0100 > > @@ -2491,9 +2494,21 @@ > > { > > struct ifnet *ifp = adapter->ifp; > > device_t dev = adapter->dev; > > + bool status_lu = E1000_READ_REG(&adapter->hw, E1000_STATUS) & > > + E1000_STATUS_LU; > > + > > + if ((adapter->hw.device_id == E1000_DEV_ID_82571EB_SERDES) && > > + (!(E1000_READ_REG(&adapter->hw, E1000_TXCW) & E1000_TXCW_ANE)) && > > + (E1000_READ_REG(&adapter->hw, E1000_CTRL) & E1000_CTRL_SLU)) { > > + if (E1000_READ_REG(&adapter->hw, E1000_STATUS) & > > + E1000_STATUS_LU) { > > + status_lu = 0; > > + } else { > > + status_lu = 1; > > + } > > + } > > > > - if (E1000_READ_REG(&adapter->hw, E1000_STATUS) & > > - E1000_STATUS_LU) { > > + if (status_lu) { > > if (adapter->link_active == 0) { > > e1000_get_speed_and_duplex(&adapter->hw, > > &adapter->link_speed, &adapter->link_duplex); > > > > second issue: > > during branching of the fibre optic cabling i get a few messages regarding > > 'coalesced states' > > Jan 22 10:36:00 test kernel: em4: 2 link states coalesced > > this seems to be because of link state interrupts generated by the chipset > > during branching of the fiber optic cable the link can change quickly > > multiple times > > the following patch resolved this issue during my test: > > ...maybe the driver needs the same for EM_FAST_IRQ and POLLING(?) > > > > --- sys/dev/em/if_em.c.orig 2008-01-22 16:55:06.000000000 +0100 > > +++ sys/dev/em/if_em.c 2008-01-22 13:33:58.000000000 +0100 > > @@ -1460,7 +1460,9 @@ > > struct adapter *adapter = arg; > > struct ifnet *ifp; > > uint32_t reg_icr; > > - > > + bool do_update = (adapter->hw.device_id == > > + E1000_DEV_ID_82571EB_SERDES) ? > > + FALSE : TRUE; > > EM_CORE_LOCK(adapter); > > ifp = adapter->ifp; > > > > @@ -1499,7 +1501,8 @@ > > callout_stop(&adapter->timer); > > adapter->hw.mac.get_link_status = 1; > > e1000_check_for_link(&adapter->hw); > > - em_update_link_status(adapter); > > + if (do_update) > > + em_update_link_status(adapter); > > /* Deal with TX cruft when link lost */ > > em_tx_purge(adapter); > > callout_reset(&adapter->timer, hz, > > > > - is there any way to get 82571_SERDES working in a future release of the > > em(4) driver? > > > > input on this issue is very welcome > > br > > -pat- > > Thanks for the info Pat. SERDES isn't FIBER, and I'm not positive, but off the > top of my head I'd say that link down is not supposed to be possible, isn't it? > > SERDES is like backplane connections in Bladeservers or similar things. > > On the other hand I really don't think that its been at all tested in FreeBSD > so I appreciate your patch and feedback, I will try and look at your code > and see about getting the fixes in. > > I am very busy right now so please be patient with me :) > > Jack thanks for your feedback jack well, i guess my description was a bit misleading then, this stuff is not related to bladeservers and/or backplanes... the SERDES/TBI interface is the interface between the ethernet chipset and the small form-factor pluggable (SFP) module - SFP is like GBIC, just with a smaller footprint. [http://en.wikipedia.org/wiki/SFP_transceiver] The fibre optic link will go down if the fibre optic cable gets disconnected from the SFP module - the SFP tells this to the ethernet chipset using the SERDES/TBI interface which connects the SFP to the chipset. no worries if you are very busy right now there is no pressure from my side to put the changes into the code i just thought this could be interesting for others as well let me know when you had a closer look at the code -pat- From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 12:54:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3605116A41A for ; Wed, 23 Jan 2008 12:54:56 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by mx1.freebsd.org (Postfix) with SMTP id E92E113C461 for ; Wed, 23 Jan 2008 12:54:55 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 27904 invoked from network); 23 Jan 2008 12:54:54 -0000 Received: from unknown (24.144.77.185) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 23 Jan 2008 12:54:54 -0000 Message-ID: <479738F8.9010905@seclark.us> Date: Wed, 23 Jan 2008 07:54:16 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Chuck Swiger References: <479663C0.3090606@seclark.us> <715218DB-7DE4-4CCF-A858-03AC05BA4732@mac.com> In-Reply-To: <715218DB-7DE4-4CCF-A858-03AC05BA4732@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: duplicate packet using divert X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2008 12:54:56 -0000 Chuck Swiger wrote: > On Jan 22, 2008, at 1:44 PM, Stephen Clark wrote: >> does anyone have a program that uses the divert socket to duplicate >> an incoming packet so it can be >> sent to another address. > > Well, I assume you could start with the ipfw "tee" directive and > /usr/src/sbin/natd ...? > Thanks Chuck - I have been thinking the same thing - just thought someone may have already done this. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 13:01:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6006A16A478 for ; Wed, 23 Jan 2008 13:01:02 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from hatert.nijmegen.internl.net (mailrelay1.nijmegen.internl.net [217.149.192.44]) by mx1.freebsd.org (Postfix) with ESMTP id F38B713C47E for ; Wed, 23 Jan 2008 13:01:01 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtp20.nijmegen.internl.net by hatert.nijmegen.internl.net via smtp20.nijmegen.internl.net [217.149.192.18] with ESMTP for id m0NBCrbf006942 (8.13.6/2.04); Wed, 23 Jan 2008 12:12:53 +0100 (MET) Received: from mail.bsd4all.org (113-9.bbned.dsl.internl.net [82.215.9.113]) by smtp20.nijmegen.internl.net (8.13.8/2.04) with ESMTP id m0NBCoOv027263 for ; Wed, 23 Jan 2008 12:12:51 +0100 (CET) Received: from localhost (mailgw [192.168.1.12]) by mail.bsd4all.org (Postfix) with ESMTP id 6E87E50901 for ; Wed, 23 Jan 2008 12:12:50 +0100 (CET) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from mail.bsd4all.org ([192.168.1.1]) by localhost (fwgw.homebrew.bsd4all.org [192.168.1.12]) (amavisd-new, port 10024) with ESMTP id NddnWnUOKi0z for ; Wed, 23 Jan 2008 12:12:39 +0100 (CET) Received: from bsd4all.org (adexlinge10 [192.168.10.16]) by mail.bsd4all.org (Postfix) with ESMTP id 3137A508F7 for ; Wed, 23 Jan 2008 12:12:39 +0100 (CET) MIME-Version: 1.0 Date: Wed, 23 Jan 2008 12:12:36 +0100 Message-ID: Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 X-MS-TNEF-Correlator: Thread-Topic: ypxfr: call to rpc.ypxfrd failed: RPC: Timed out thread-index: AchdsNvQRlOxWjvJST6JoDIw+JQziw== From: "Peter Blok" To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ypxfr: call to rpc.ypxfrd failed: RPC: Timed out 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, 23 Jan 2008 13:01:02 -0000 SGksDQoNCiANCg0KSWYgc2VlbiBhIGNvdXBsZSBvZiBjb21wbGFpbnRzIGFib3V0IHRoZSBtZXNz YWdlIGJlbG93LiBJIGhhdmUgZm91bmQgdGhlIGlzc3VlIGluIHlweGZyIGZ1bmN0aW9uIHlweGZy ZF9nZXRfbWFwLiBUaGUgdGltZXZhbCBzdHJ1Y3QgaXMgaW5pdGlhbGl6ZWQgd2l0aCBhIHRpbWVv dXQgb2YgMjUgdXNlYy4gSW5zaWRlIGxpYmMgdGhpcyB3aWxsIHJlc3VsdCBpbiBhIHBvbGwgdGlt ZW91dCBvZiAwLCB3aGljaCB3aWxsIHJldHVybiBpbW1lZGlhdGVseSByYWlzaW5nIHRoaXMgZXJy b3IuIE15IHF1ZXN0aW9uIGlzOiB3aGF0IHdvdWxkIGJlIGEgc2FuZSB2YWx1ZSBmb3IgdGhpcyB0 aW1lb3V0LiBTb21ld2hlcmUgZWxzZSBpbiB5cHhmciBhIHRpbWVvdXQgb2YgMTAgc2Vjb25kcyBp cyB1c2VkLCBidXQgSSB3b25kZXIgaWYgdGhhdCB3b3VsZCBiZSB0b28gbG9uZyBiZWZvcmUgcmV2 ZXJ0aW5nIGJhY2sgdG8gdGhlIG9sZCB0cmFuc2ZlciBtZXRob2Qgd2l0aG91dCB5cHhmcmQuDQoN CiANCg0KIC91c3IvbGliZXhlYy95cHhmciDiiJJmIHBhc3N3ZC5ieW5hbWUNCg0KeXB4ZnI6IGNh bGwgdG8gcnBjLnlweGZyZCBmYWlsZWQ6IFJQQzogVGltZWQgb3V0DQoNCnlweGZyOiBFeGl0aW5n OiBNYXAgc3VjY2Vzc2Z1bGx5IHRyYW5zZmVycmVkDQoNCg== From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 14:52:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B8EF16A41A for ; Wed, 23 Jan 2008 14:52:52 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpout06.prod.mesa1.secureserver.net (smtpout06-04.prod.mesa1.secureserver.net [64.202.165.227]) by mx1.freebsd.org (Postfix) with SMTP id CDD7B13C447 for ; Wed, 23 Jan 2008 14:52:51 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 5157 invoked from network); 23 Jan 2008 14:52:51 -0000 Received: from unknown (24.144.77.185) by smtpout06-04.prod.mesa1.secureserver.net (64.202.165.227) with ESMTP; 23 Jan 2008 14:52:50 -0000 Message-ID: <4797549C.2080209@seclark.us> Date: Wed, 23 Jan 2008 09:52:12 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Stephen.Clark@seclark.us References: <479663C0.3090606@seclark.us> <715218DB-7DE4-4CCF-A858-03AC05BA4732@mac.com> <479738F8.9010905@seclark.us> In-Reply-To: <479738F8.9010905@seclark.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: duplicate packet using divert X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2008 14:52:52 -0000 Stephen Clark wrote: > Chuck Swiger wrote: >> On Jan 22, 2008, at 1:44 PM, Stephen Clark wrote: >>> does anyone have a program that uses the divert socket to duplicate >>> an incoming packet so it can be >>> sent to another address. >> >> Well, I assume you could start with the ipfw "tee" directive and >> /usr/src/sbin/natd ...? >> > Thanks Chuck - I have been thinking the same thing - just thought > someone may have already > done this. > > Steve > Hi Chuck, ipfw add 50 tee natd udp from any to 20.x.x.120 dst-port 14050 in natd -verbose -a 20.x.x.120 -redirect_address 10.0.129.101 20.x.x.120 this seems to do the trick. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 15:50:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47E9316A41A for ; Wed, 23 Jan 2008 15:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 32B5D13C465 for ; Wed, 23 Jan 2008 15:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0NFo24B027993 for ; Wed, 23 Jan 2008 15:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0NFo2sg027992; Wed, 23 Jan 2008 15:50:02 GMT (envelope-from gnats) Date: Wed, 23 Jan 2008 15:50:02 GMT Message-Id: <200801231550.m0NFo2sg027992@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: wforms@Safe-mail.net Cc: Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wforms@Safe-mail.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2008 15:50:03 -0000 The following reply was made to PR kern/112654; it has been noted by GNATS. From: wforms@Safe-mail.net To: bug-followup@FreeBSD.org Cc: marius@alchemy.franken.de, chuzzwassa@gmail.com Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 Date: Wed, 23 Jan 2008 16:47:23 +0100 BINGO! Adding this latest nsphyter.c edition of Marius to his former patchset resulted = in a reliably working pcn driver. So whatever you tried there Marius, is the = key to the kernel panic problem I reported this PR for. The kernel I built = with your latest update now loads the if_pcn module without the kernel panic, = regardless of the RJ45 cable being connected or disconnected, and the pcn0 = adapter reliably recognizes the presence of the cable. The adapter worked fine = for basic network testings. I do not know how ready you consider the current code to be the final fix for = my PR, or if you need to incorporate the things we just learnt here into a = larger and more uniformly written patch before it can migrate to the src system. = I also do not know if a proper fix for FreeBSD 6 needs to be much different = than for FreeBSD 7, I only recognized that your RELENG_6 patchset introduced = this new nsphyter thing which did not exist in 6.x before. So I am uncertain = how much of this are you or the FreeBSD Team willing_to/can inject into RELENG_6 = about now. However, judging from your latest followup I assume that there may = not be necessarry to add nsphyter to RELENG_6 just now, because a simplified = fix implementing this latest reset function change of yours in the good old = ukphy section of the current 6.3-STABLE code might be perfectly good enough = for the time being. But this is not for me to decide, I simply mentioned this as a possible option. Anyway, GOOD JOB guys! Thank you! P.S.: That backtrace thing I should have given you in case your patch does = not work, is unknown for me. I assume it may be usefull to know this in the = future and I am happy to improve my knowledge, so if you can point me to a = page where I can learn what that is, I would appreciate it. From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 20:20:36 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C08E716A468 for ; Wed, 23 Jan 2008 20:20:36 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from davie.textdrive.com (davie.textdrive.com [207.7.108.101]) by mx1.freebsd.org (Postfix) with ESMTP id BA0D913C46A for ; Wed, 23 Jan 2008 20:20:36 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from [192.168.0.79] (2.ten-net.org [71.6.14.2]) by davie.textdrive.com (Postfix) with ESMTP id CA3FAC2511 for ; Wed, 23 Jan 2008 19:56:35 +0000 (GMT) Message-Id: From: Sean Chittenden To: net@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 23 Jan 2008 11:56:33 -0800 X-Mailer: Apple Mail (2.915) Cc: Subject: SO_LINGER brokenness... 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, 23 Jan 2008 20:20:36 -0000 Howdy. Looks like SO_LINGER is broken on loopback. Here's the test case: 0. Install memcached (databases/memcached) 1. Download test_linger.c: fetch http://sean.chittenden.org/pubfiles/freebsd/test_linger.c 2. Compile: gcc test_linger.c -o test_linger 3. Fire up memcached in a new window: memcached -vvv -p 11211 4. Test: ./test_linger localhost 11211 5. Watch for either: <16 new client connection <16 set valid_key 0 0 8 >16 STORED <16 set valid_key 0 0 8 >16 STORED <16 connection closed. Fail. or <16 new client connection <16 set valid_key 0 0 8 >16 STORED <16 set valid_key 0 0 8 >16 STORED <16 get ENOENT_key >16 END <16 connection closed. Win. Can someone verify that my test case is correct? If it is, I'll port it to src/tools/regression/sockets/. Broken or not, I don't think the behavior suggested in src/netinet/ tcp_usrreq.c:1498 is correct. A The test above write(2)'s and read(2)'s some data successfully before testing the validity of the half-close(2)'ed state, so I'm not worried about whether or not a SYN has been received. I haven't looked too closely yet, but it looks like tcp_close() needs to call to sbflush() if SO_LINGER is set (in fact, it doesn't look like there's any special handling of linger in tcp_subr.c, so I'm not sure if I'm glancing in the right area). /* * User issued close, and wish to trail through shutdown states: * if never received SYN, just forget it. If got a SYN from peer, * but haven't sent FIN, then go to FIN_WAIT_1 state to send peer a FIN. * If already got a FIN from peer, then almost done; go to LAST_ACK * state. In all other cases, have already sent FIN to peer (e.g. * after PRU_SHUTDOWN), and just have to play tedious game waiting * for peer to send FIN or not respond to keep-alives, etc. * We can let the user exit from the close as soon as the FIN is acked. */ Thoughts/guidance? -sc -- Sean Chittenden sean@chittenden.org http://sean.chittenden.org/ From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 21:53:40 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 868E516A419; Wed, 23 Jan 2008 21:53:40 +0000 (UTC) (envelope-from marius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6E25813C4F6; Wed, 23 Jan 2008 21:53:40 +0000 (UTC) (envelope-from marius@FreeBSD.org) Received: from freefall.freebsd.org (marius@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0NLrexw066656; Wed, 23 Jan 2008 21:53:40 GMT (envelope-from marius@freefall.freebsd.org) Received: (from marius@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0NLrexk066652; Wed, 23 Jan 2008 21:53:40 GMT (envelope-from marius) Date: Wed, 23 Jan 2008 21:53:40 GMT Message-Id: <200801232153.m0NLrexk066652@freefall.freebsd.org> To: marius@FreeBSD.org, freebsd-net@FreeBSD.org, marius@FreeBSD.org From: marius@FreeBSD.org Cc: Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 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, 23 Jan 2008 21:53:40 -0000 Synopsis: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 Responsible-Changed-From-To: freebsd-net->marius Responsible-Changed-By: marius Responsible-Changed-When: Wed Jan 23 21:53:19 UTC 2008 Responsible-Changed-Why: grab http://www.freebsd.org/cgi/query-pr.cgi?pr=112654 From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 21:54:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FEAF16A510 for ; Wed, 23 Jan 2008 21:54:07 +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 C67F813C4CC for ; Wed, 23 Jan 2008 21:54:05 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 85219 invoked from network); 23 Jan 2008 21:15:26 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Jan 2008 21:15:26 -0000 Message-ID: <4797B77E.2090605@freebsd.org> Date: Wed, 23 Jan 2008 22:54:06 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Mike Silbersack , kmacy@FreeBSD.org References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> In-Reply-To: <200711200656.lAK6u4bc021279@repoman.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 23 Jan 2008 21:54:07 -0000 Mike Silbersack wrote: > silby 2007-11-20 06:56:04 UTC > > FreeBSD src repository > > Modified files: > sys/netinet tcp_syncache.c > Log: > Comment out the syncache's test which ensures that hosts which negotiate TCP > timestamps in the initial SYN packet actually use them in the rest of the > connection. Unfortunately, during the 7.0 testing cycle users have already > found network devices that violate this constraint. > > RFC 1323 states 'and may send a TSopt in other segments' rather than > 'and MUST send', so we must allow it. > > Discovered by: Rob Zietlow > Tracked down by: Kip Macy > PR: bin/118005 > > Revision Changes Path > 1.134 +6 -0 src/sys/netinet/tcp_syncache.c > > kmacy 2007-12-12 06:11:50 UTC > > FreeBSD src repository > > Modified files: > sys/netinet tcp_syncache.c > Log: > Remove spurious timestamp check. RFC 1323 explicitly states that timestamps MAY > be transmitted if negotiated. > > Revision Changes Path > 1.138 +1 -17 src/sys/netinet/tcp_syncache.c These changes and their rationale are not really correct. The citation from RFC1323 is grossly misrepresented. The partly cited sentence says that timestamps may only be transmitted if they were negotiated. It doesn't say that timestamps may or may not be sent after they were negotiated. In fact RFC1323 Section 3.2 explicitly states: "For simplicity and symmetry, we specify that timestamps always be sent and echoed in both directions." It is also the unchallenged consensus view of the IETF TCPM is that timestamps must be sent when negotiated [1]. It is not allowed to not include them when agreed so at SYN time. Any deviation of this is a violation of the RFC. Thus the test was correct and valid. OTOH the enforcement of this rule wasn't really there before and it may be argued that we've got a POLA violation here. A careful reading of the referenced PR bin/118005 and its audit trail do not support the conclusion that the enforcement is the root cause of the symptoms described. The submitter makes a clear distinction between inside and outside of his LAN. Inside everything continues to work just fine. It's outside of his LAN that certain machines can't establish connections to the upgraded machine. The cited outside machines are FreeBSD 6.2, OpenBSD 4.1 and Linux RHEL 4U4. All these operating systems correctly implement RFC1323 timestamps and do not omit them once negotiated. Hence it is very likely that the root cause is in some device along the path munging the packets in a non-RFC conform way. Perhaps a reverse-NAT gateway on his Internet gateway. Or some other packet rewriting system. The PR needs to reopened and the root cause properly inspected. Based on the rationale above I'd like to re-instate the test in HEAD because a) it is correct and b) even if disabled to serve as education for future readers of the SYN/SYN-ACK/ACK path. If the test has to remain disabled we should include a clear description including which systems and their revisions fail the test. Alternatively the test should be modified to disable sending of timestamps if this situation occurs as they are a pointless waste of bits anyway as they won't ever be returned back to us to measure anything. [1] http://www1.ietf.org/mail-archive/web/tcpm/current/msg02507.html and (many) following messages in that thread -- Andre Index: tcp_syncache.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_syncache.c,v retrieving revision 1.141 diff -u -p -r1.141 tcp_syncache.c --- tcp_syncache.c 19 Dec 2007 16:56:28 -0000 1.141 +++ tcp_syncache.c 23 Jan 2008 21:33:49 -0000 @@ -914,12 +914,41 @@ syncache_expand(struct in_conninfo *inc, goto failed; } + /* + * If timestamps were present in the SYN and we accepted + * them in our SYN|ACK RFC1323 Section 3.2 requires them + * to be present from now on. And vice versa. + */ + if ((sc->sc_flags & SCF_TIMESTAMP) && !(to->to_flags & TOF_TS)) { + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) + log(LOG_DEBUG, "%s; %s: Timestamp missing, " + "segment rejected\n", s, __func__); +#ifdef TCP_BROKEN_TS + /* + * There appear to be non-conformant devices that + * negotiate timestamps but then fail to include + * them in every segment from then on. + * + * Evidence of this really happening is inconclusive + * and specific operating systems or firmware and their + * revisions are not known. + * + * For a work-around disable sending of timestamps + * as they become a pointless waste of bandwidth + * if we won't get them reflected back anyway. + */ + sc->sc_flags &= ~SCF_TIMESTAMP; +#else + goto failed; +#endif + } if (!(sc->sc_flags & SCF_TIMESTAMP) && (to->to_flags & TOF_TS)) { if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: Timestamp not expected, " "segment rejected\n", s, __func__); goto failed; } + /* * If timestamps were negotiated the reflected timestamp * must be equal to what we actually sent in the SYN|ACK. From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 22:10:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6C5B16A46E for ; Wed, 23 Jan 2008 22:10:53 +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 9103A13C46B for ; Wed, 23 Jan 2008 22:10:53 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 85509 invoked from network); 23 Jan 2008 21:32:13 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Jan 2008 21:32:13 -0000 Message-ID: <4797BB6E.9060201@freebsd.org> Date: Wed, 23 Jan 2008 23:10:54 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: xingang shi References: <8236bb940801220629h4fd8477eg68c1621bb1713d4@mail.gmail.com> In-Reply-To: <8236bb940801220629h4fd8477eg68c1621bb1713d4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: routing table lookup algorithm 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, 23 Jan 2008 22:10:54 -0000 xingang shi wrote: > One of André Oppermann's paper memtioned that there will be a new routing > table lookup algorithm in FreeBSD 7, > Anyone knows is there any document about this algorithm? Or which part of > the src code is for this function. I haven't implemented the new routing table lookup code yet. I hope to do it this year and to run extensive tests on it. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 22:16:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EA4C16A41B for ; Wed, 23 Jan 2008 22:16:35 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: from coruscant.far-far-away.us (coruscant.far-far-away.us [70.91.196.65]) by mx1.freebsd.org (Postfix) with SMTP id 3FA3813C465 for ; Wed, 23 Jan 2008 22:16:34 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: (qmail 22888 invoked from network); 23 Jan 2008 16:44:08 -0500 Received: from pknat1.passkey.com (HELO ?192.168.16.168?) (68.162.198.134) by coruscant.far-far-away.us with SMTP; 23 Jan 2008 16:44:08 -0500 From: Yousif Hassan To: freebsd-net@freebsd.org Content-Type: text/plain Date: Wed, 23 Jan 2008 16:50:22 -0500 Message-Id: <1201125022.2106.67.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: network interface monitoring? 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, 23 Jan 2008 22:16:35 -0000 Net-gurus: I hope this is the right list to write to regarding this question (feel free to redirect me to ports@ if that sounds more appropriate). I'm looking for a facility to automatically detect network interface carrier state changes (a network cable gets plugged/unplugged; a laptop's wireless button gets turned on/off; etc.) and then to run a user script on it. The use case, fairly obvious I guess, is to execute ifconfig and/or DHCP commands upon carrier detection; this will make my laptop that much more useful. ;) NetBSD has ifwatchd - which seems perfectly designed for this use case: http://www.freebsd.org/cgi/man.cgi?query=ifwatchd&apropos=0&sektion=0&manpath=NetBSD+4.0 ifwatchd has not been ported to FreeBSD - does FreeBSD have anything similar? I can't imagine I'm the first to ask this question; it seems almost everyone with a laptop would want this. Thanks for your time/attention...! (please CC me as I am not subscribed here) --Yousif From owner-freebsd-net@FreeBSD.ORG Wed Jan 23 22:20:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E84A716A418 for ; Wed, 23 Jan 2008 22:20:56 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 86E6713C458 for ; Wed, 23 Jan 2008 22:20:56 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id m0NMKlR5014403; Wed, 23 Jan 2008 16:20:47 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id m0NMKlg0014402; Wed, 23 Jan 2008 16:20:47 -0600 (CST) (envelope-from brooks) Date: Wed, 23 Jan 2008 16:20:47 -0600 From: Brooks Davis To: Yousif Hassan Message-ID: <20080123222047.GA14264@lor.one-eyed-alien.net> References: <1201125022.2106.67.camel@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <1201125022.2106.67.camel@localhost> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 23 Jan 2008 16:20:47 -0600 (CST) Cc: freebsd-net@freebsd.org Subject: Re: network interface monitoring? 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, 23 Jan 2008 22:20:57 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 23, 2008 at 04:50:22PM -0500, Yousif Hassan wrote: > Net-gurus: >=20 > I hope this is the right list to write to regarding this question (feel > free to redirect me to ports@ if that sounds more appropriate). >=20 > I'm looking for a facility to automatically detect network interface > carrier state changes (a network cable gets plugged/unplugged; a > laptop's wireless button gets turned on/off; etc.) and then to run a > user script on it. The use case, fairly obvious I guess, is to execute > ifconfig and/or DHCP commands upon carrier detection; this will make my > laptop that much more useful. ;) devd already does a lot of this and is used to control dhclient execution. ifstated from openbsd is also in ports. -- Brooks --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHl72+XY6L6fI4GtQRAiB8AJ97wzGVB53w+3FkxcmazaGUuDZCAgCgoHfV Ygn4LrmrVGeQ5g5MCr1VjT4= =u+8f -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 02:34:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62B5B16A41A for ; Thu, 24 Jan 2008 02:34:41 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5070213C459 for ; Thu, 24 Jan 2008 02:34:41 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 5618A8D541; Wed, 23 Jan 2008 21:34:40 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 23 Jan 2008 21:34:40 -0500 X-Sasl-enc: IHLnFE4/dVKnwTDx0358Fq3faZ6B2/DXFn4FBNDkIJTC 1201142080 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 CE829FAF1; Wed, 23 Jan 2008 21:34:39 -0500 (EST) Message-ID: <4797F93E.3010709@FreeBSD.org> Date: Thu, 24 Jan 2008 02:34:38 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Yousif Hassan References: <1201125022.2106.67.camel@localhost> In-Reply-To: <1201125022.2106.67.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: network interface monitoring? 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, 24 Jan 2008 02:34:41 -0000 Yousif Hassan wrote: > ifwatchd has not been ported to FreeBSD - does FreeBSD have anything > similar? Try ports/net/ifstated (from OpenBSD). BMS From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 05:27:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 664F016A41B for ; Thu, 24 Jan 2008 05:27:27 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4EC7613C4DD for ; Thu, 24 Jan 2008 05:27:27 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so168694waf.3 for ; Wed, 23 Jan 2008 21:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=XLORr7pSylHTUwMBDn2I5Z65D54Y3yuIXuWEZ4QGu1U=; b=B5jp+YrVYcsDjq1qICXM+65aw38QHKppBJ7QrZX8dpndz5DT5GmjwxFv47cSQMqwcOh1Q/Ah7EyixONLXQGPR9m/Kw6yhsas651c7wO1lned+fwA1GOpdy91pUjyuxixLuqL1mLvVxJybpqmAAcgEAsy5fAoh0XHWRFn2lcqUuI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NiWNptKQDagx91O89sysM4/8NHOjXGHHu8HR/Bnjsr20DGEOH/1f1CI0S7Rh0vVX8MycsD4wK3bj/jmZ6CyansYzp3goQN+EZTB6HQh55kMYCG9vmtTv+FAKMd4C1rUj5ShemeRalp2Y21ZVV+ZCPxGkKCFPXGCq9sft9PQZf2s= Received: by 10.114.161.11 with SMTP id j11mr242497wae.127.1201150717563; Wed, 23 Jan 2008 20:58:37 -0800 (PST) Received: by 10.114.255.16 with HTTP; Wed, 23 Jan 2008 20:58:37 -0800 (PST) Message-ID: Date: Wed, 23 Jan 2008 20:58:37 -0800 From: "Kip Macy" To: "Andre Oppermann" In-Reply-To: <4797B77E.2090605@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> Cc: Mike Silbersack , kmacy@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, src-committers@freebsd.org, freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 24 Jan 2008 05:27:27 -0000 Did you talk to the original submitter? Note that FreeBSD's TCP stack is for use in servers and is not intending as a validating TCP stack. If you would like it to serve as such you would better served by tracking down the ANVL tests that FreeBSD fails. Also note that there is no MUST in the following sentence: "For simplicity and symmetry, we specify that timestamps always be sent and echoed in both directions." So it is clearly open to interpretation. -Kip On Jan 23, 2008 1:54 PM, Andre Oppermann wrote: > > Mike Silbersack wrote: > > silby 2007-11-20 06:56:04 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/netinet tcp_syncache.c > > Log: > > Comment out the syncache's test which ensures that hosts which negotiate TCP > > timestamps in the initial SYN packet actually use them in the rest of the > > connection. Unfortunately, during the 7.0 testing cycle users have already > > found network devices that violate this constraint. > > > > RFC 1323 states 'and may send a TSopt in other segments' rather than > > 'and MUST send', so we must allow it. > > > > Discovered by: Rob Zietlow > > Tracked down by: Kip Macy > > PR: bin/118005 > > > > Revision Changes Path > > 1.134 +6 -0 src/sys/netinet/tcp_syncache.c > > > > kmacy 2007-12-12 06:11:50 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/netinet tcp_syncache.c > > Log: > > Remove spurious timestamp check. RFC 1323 explicitly states that timestamps MAY > > be transmitted if negotiated. > > > > Revision Changes Path > > 1.138 +1 -17 src/sys/netinet/tcp_syncache.c > > These changes and their rationale are not really correct. The citation > from RFC1323 is grossly misrepresented. The partly cited sentence says > that timestamps may only be transmitted if they were negotiated. It > doesn't say that timestamps may or may not be sent after they were > negotiated. In fact RFC1323 Section 3.2 explicitly states: "For > simplicity and symmetry, we specify that timestamps always be sent > and echoed in both directions." It is also the unchallenged consensus > view of the IETF TCPM is that timestamps must be sent when negotiated > [1]. It is not allowed to not include them when agreed so at SYN time. > Any deviation of this is a violation of the RFC. Thus the test was > correct and valid. > > OTOH the enforcement of this rule wasn't really there before and it > may be argued that we've got a POLA violation here. A careful reading > of the referenced PR bin/118005 and its audit trail do not support the > conclusion that the enforcement is the root cause of the symptoms > described. The submitter makes a clear distinction between inside and > outside of his LAN. Inside everything continues to work just fine. > It's outside of his LAN that certain machines can't establish > connections to the upgraded machine. The cited outside machines are > FreeBSD 6.2, OpenBSD 4.1 and Linux RHEL 4U4. All these operating > systems correctly implement RFC1323 timestamps and do not omit them > once negotiated. Hence it is very likely that the root cause is in > some device along the path munging the packets in a non-RFC conform > way. Perhaps a reverse-NAT gateway on his Internet gateway. Or some > other packet rewriting system. The PR needs to reopened and the root > cause properly inspected. > > Based on the rationale above I'd like to re-instate the test in HEAD > because a) it is correct and b) even if disabled to serve as education > for future readers of the SYN/SYN-ACK/ACK path. If the test has to > remain disabled we should include a clear description including which > systems and their revisions fail the test. Alternatively the test > should be modified to disable sending of timestamps if this situation > occurs as they are a pointless waste of bits anyway as they won't ever > be returned back to us to measure anything. > > > [1] http://www1.ietf.org/mail-archive/web/tcpm/current/msg02507.html > and (many) following messages in that thread > > -- > Andre > > Index: tcp_syncache.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/tcp_syncache.c,v > retrieving revision 1.141 > diff -u -p -r1.141 tcp_syncache.c > --- tcp_syncache.c 19 Dec 2007 16:56:28 -0000 1.141 > +++ tcp_syncache.c 23 Jan 2008 21:33:49 -0000 > @@ -914,12 +914,41 @@ syncache_expand(struct in_conninfo *inc, > goto failed; > } > > + /* > + * If timestamps were present in the SYN and we accepted > + * them in our SYN|ACK RFC1323 Section 3.2 requires them > + * to be present from now on. And vice versa. > + */ > + if ((sc->sc_flags & SCF_TIMESTAMP) && !(to->to_flags & TOF_TS)) { > + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > + log(LOG_DEBUG, "%s; %s: Timestamp missing, " > + "segment rejected\n", s, __func__); > +#ifdef TCP_BROKEN_TS > + /* > + * There appear to be non-conformant devices that > + * negotiate timestamps but then fail to include > + * them in every segment from then on. > + * > + * Evidence of this really happening is inconclusive > + * and specific operating systems or firmware and their > + * revisions are not known. > + * > + * For a work-around disable sending of timestamps > + * as they become a pointless waste of bandwidth > + * if we won't get them reflected back anyway. > + */ > + sc->sc_flags &= ~SCF_TIMESTAMP; > +#else > + goto failed; > +#endif > + } > if (!(sc->sc_flags & SCF_TIMESTAMP) && (to->to_flags & TOF_TS)) { > if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > log(LOG_DEBUG, "%s; %s: Timestamp not expected, " > "segment rejected\n", s, __func__); > goto failed; > } > + > /* > * If timestamps were negotiated the reflected timestamp > * must be equal to what we actually sent in the SYN|ACK. > _______________________________________________ > 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 Jan 24 07:07:47 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5833B16A469 for ; Thu, 24 Jan 2008 07:07:47 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id E5ACE13C442 for ; Thu, 24 Jan 2008 07:07:46 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 36376 invoked from network); 24 Jan 2008 07:07:45 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 24 Jan 2008 07:07:45 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 24 Jan 2008 01:07:44 -0600 (CST) From: Mike Silbersack To: Andre Oppermann In-Reply-To: <4797B77E.2090605@freebsd.org> Message-ID: <20080124005006.D93697@odysseus.silby.com> References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Mike Silbersack , kmacy@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, src-committers@FreeBSD.org, freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 24 Jan 2008 07:07:47 -0000 On Wed, 23 Jan 2008, Andre Oppermann wrote: > OTOH the enforcement of this rule wasn't really there before and it > may be argued that we've got a POLA violation here. A careful reading That's exactly the point. We were not enforcing timestamps since... whenever the RFC1323 code went in. Then we start enforcing them, and start getting bug reports while we're still in the beta phase. That indicates to me that we would've been likely to see many reports as time went on. If you want to put the check back in, but hide it behind a sysctl that is disabled by default, that would be ok with me. I'm not generally opposed to security improvements that only affect edge cases... but being unable to connect is not an edge case! -Mike From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 07:40:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED8BC16A417 for ; Thu, 24 Jan 2008 07:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E19FB13C468 for ; Thu, 24 Jan 2008 07:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0O7e3w1016989 for ; Thu, 24 Jan 2008 07:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0O7e3Kf016988; Thu, 24 Jan 2008 07:40:03 GMT (envelope-from gnats) Date: Thu, 24 Jan 2008 07:40:03 GMT Message-Id: <200801240740.m0O7e3Kf016988@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bob Van Zant Cc: Subject: Re: kern/116837: [tun] [panic] [patch] ifconfig tunX destroy: panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Van Zant List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2008 07:40:04 -0000 The following reply was made to PR kern/116837; it has been noted by GNATS. From: Bob Van Zant To: Cc: Subject: Re: kern/116837: [tun] [panic] [patch] ifconfig tunX destroy: panic Date: Thu, 24 Jan 2008 12:40:19 +0530 I applied the patch in the prior comment and now I get this, different, kernel panic (yanked from dmesg): Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xdeadc0e6 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07903b5 stack pointer = 0x28:0xd62a2ab4 frame pointer = 0x28:0xd62a2ac8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3091 (ppp) trap number = 12 panic: page fault cpuid = 0 Uptime: 1h58m15s Physical memory: 499 MB Dumping 154 MB: 139 123 107 91 75 59 43 27 11 Dump complete Plopping into kgdb: (kgdb) list *0xc07903b5 0xc07903b5 is in clear_selinfo_list (/usr/src/sys/kern/sys_generic.c:1066). 1061 { 1062 struct selinfo *si; 1063 1064 mtx_assert(&sellock, MA_OWNED); 1065 TAILQ_FOREACH(si, &td->td_selq, si_thrlist) 1066 si->si_thread = NULL; 1067 TAILQ_INIT(&td->td_selq); 1068 } 1069 1070 /* (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc075957f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc075984b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a41913 in trap_fatal (frame=0xd62a2a74, eva=3735929062) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a41af0 in trap_pfault (frame=0xd62a2a74, usermode=0, eva=3735929062) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a42432 in trap (frame=0xd62a2a74) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a289bb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc07903b5 in clear_selinfo_list (td=0xc321d220) at /usr/src/sys/kern/sys_generic.c:1065 #8 0xc0791168 in kern_select (td=0xc321d220, nd=11, fd_in=0x28413c00, fd_ou=0x28414000, fd_ex=0x28414400, tvp=0x0) at /usr/src/sys/kern/sys_generic.c:794 #9 0xc079131e in select (td=0xc321d220, uap=0xd62a2cfc) at /usr/src/sys/kern/sys_generic.c:663 #10 0xc0a41dc3 in syscall (frame=0xd62a2d38) at /usr/src/sys/i386/i386/trap.c:1035 #11 0xc0a28a20 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #12 0x00000033 in ?? () From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 10:57:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F93E16A46B for ; Thu, 24 Jan 2008 10:57:41 +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 CC53D13C500 for ; Thu, 24 Jan 2008 10:57:40 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 98676 invoked from network); 24 Jan 2008 10:18:55 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Jan 2008 10:18:55 -0000 Message-ID: <47986F27.10401@freebsd.org> Date: Thu, 24 Jan 2008 11:57:43 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Mike Silbersack References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> <20080124005006.D93697@odysseus.silby.com> In-Reply-To: <20080124005006.D93697@odysseus.silby.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Silbersack , kmacy@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, src-committers@FreeBSD.org, freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 24 Jan 2008 10:57:41 -0000 Mike Silbersack wrote: > > On Wed, 23 Jan 2008, Andre Oppermann wrote: > >> OTOH the enforcement of this rule wasn't really there before and it >> may be argued that we've got a POLA violation here. A careful reading > > That's exactly the point. We were not enforcing timestamps since... > whenever the RFC1323 code went in. Then we start enforcing them, and > start getting bug reports while we're still in the beta phase. That > indicates to me that we would've been likely to see many reports as time > went on. I'm complaining about not fixing or modifying the test. The rationale and comments to the change are not correct and a different fix would be more appropriate. > If you want to put the check back in, but hide it behind a sysctl that > is disabled by default, that would be ok with me. The check is fine. However in the edge case it should not cause the connection to be aborted but it should disable timestamps locally. There is no point in sending them if they do not get returned. > I'm not generally opposed to security improvements that only affect edge > cases... but being unable to connect is not an edge case! Fully agreed. I'll reopen the PR and follow up with the originator to do some further analysis. All operating system he cites that were unable to connect correctly send timestamps and do not stop after the SYN phase. So there must be something else at play here. Have you received or heart of any *other* reports that may be related to the timestamp check? -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 10:58:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE46B16A478 for ; Thu, 24 Jan 2008 10:58:18 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2909C13C4DD for ; Thu, 24 Jan 2008 10:58:17 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 98697 invoked from network); 24 Jan 2008 10:19:32 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Jan 2008 10:19:32 -0000 Message-ID: <47986F4D.6070208@freebsd.org> Date: Thu, 24 Jan 2008 11:58:21 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Kip Macy References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Silbersack , kmacy@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, src-committers@freebsd.org, freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 24 Jan 2008 10:58:18 -0000 Kip Macy wrote: > Did you talk to the original submitter? Note that FreeBSD's TCP stack > is for use in servers and is not intending as a validating TCP stack. > If you would like it to serve as such you would better served by > tracking down the ANVL tests that FreeBSD fails. Also note that there > is no MUST in the following sentence: > > > "For simplicity and symmetry, we specify that > timestamps always be sent and echoed in both directions." > > So it is clearly open to interpretation. No, it is not. RFC1323 was written in 1992 before RFCs contained the boiler plate definition of MUST, SHOULD, MAY and so on. I, at least as a non-native English speaker, find the sentence perfectly clear and without any doubt. The IETF TCPM working group comes to the same conclusion. And I suppose many native English speakers too. Despite that arguing over whether "always" lacks a "MUST" to make it really always always and never not you cited the wrong part of RFC1323 as reason to completely remove the check. That's what I'm complaining about. Everyone in FreeBSD, including you and me, should at least provide the correct citation and rationale for any code change irrespective of the eventual merit of the change itself which is a separate issue. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 11:58:57 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 285FC16A419; Thu, 24 Jan 2008 11:58:57 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id A272B13C4D3; Thu, 24 Jan 2008 11:58:56 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id m0OBwsSP020905; Thu, 24 Jan 2008 14:58:54 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Thu, 24 Jan 2008 14:58:54 +0300 (MSK) From: Maxim Konovalov To: Andre Oppermann In-Reply-To: <47986F27.10401@freebsd.org> Message-ID: <20080124145713.K15031@mp2.macomnet.net> References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> <20080124005006.D93697@odysseus.silby.com> <47986F27.10401@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: src-committers@FreeBSD.ORG, kmacy@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 24 Jan 2008 11:58:57 -0000 [...] > > I'm not generally opposed to security improvements that only affect edge > > cases... but being unable to connect is not an edge case! > > Fully agreed. I'll reopen the PR and follow up with the originator > to do some further analysis. All operating system he cites that were > unable to connect correctly send timestamps and do not stop after > the SYN phase. So there must be something else at play here. Have > you received or heart of any *other* reports that may be related to > the timestamp check? > I saw this with my adsl router. Happy to test patches. -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 12:44:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2941816A417 for ; Thu, 24 Jan 2008 12:44:32 +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 A39A813C447 for ; Thu, 24 Jan 2008 12:44:31 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 99923 invoked from network); 24 Jan 2008 12:05:45 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Jan 2008 12:05:45 -0000 Message-ID: <47988833.8010701@freebsd.org> Date: Thu, 24 Jan 2008 13:44:35 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: rob.zietlow@gmail.com References: <200801241054.m0OAs0Gu032350@freefall.freebsd.org> In-Reply-To: <200801241054.m0OAs0Gu032350@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-bugs@FreeBSD.org, silby@FreeBSD.org Subject: Re: bin/118005: Can No Longer SSH into 7.0 host 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, 24 Jan 2008 12:44:32 -0000 Hi Rob, > Since upgrading to 7.0 I am no longer able to SSH into my server. I > cvsup'ed to 7.0 code and rebuild world and since then I have had this > issue. I have rebuilt multiple times in beta 1, 1.5 and 2. I can SSH into > my host from some hosts within the local LAN. Some machines from outside my > LAN I cannot ssh into this host. Hosts on my lan I have ssh'ed into this > host with are windows(putty), Linux, and Solaris. From outside my LAN I > cannot ssh into my host from Freebsd 6.2, Openbsd 4.1, and Linux(RHEL 4U4). > Freebsd & Openbsd machines are on my home network. However my OSX laptop and > windows machine, from my home network, can SSH into the host without a > problem. This is very strange as the operating systems you cite here correctly implement timestamps and pass all tests that were added to FreeBSD 7BETA. Please see the comments below for an analysis of what may be going on here. > voltron# tcpdump -e -vvnn port 22 and host 192.168.3.132 > tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 68 > bytes A capture size of 68 bytes is insufficient to see all TCP headers. Please increase it to 100 bytes with "-s 100". > 08:09:55.816411 00:90:5f:0c:00:00 > 00:18:fe:67:54:76, ethertype IPv4 > (0x0800), length 74: (tos 0x0, ttl 61, id 56887, offset 0, flags [DF], proto > TCP (6), length 60) 192.168.3.132.41922 > 192.168.8.163.22: S > 722288481:722288481(0) win 5840 The client sends the SYN to the server including timestamps (full information cut off from too small capture size). > 08:09:55.816432 00:18:fe:67:54:76 > 00:00:0c:07:ac:09, ethertype IPv4 > (0x0800), length 74: (tos 0x0, ttl 64, id 27230, offset 0, flags [DF], proto > TCP (6), length 60) 192.168.8.163.22 > 192.168.3.132.41922: S > 2406244836:2406244836(0) ack 722288482 win 65535 3,nop,nop,timestamp[|tcp]> Server answers SYN with SYN|ACK, mss, window scale and timestamps. Everything perfectly fine so far. > 08:09:55.816925 00:90:5f:0c:00:00 > 00:18:fe:67:54:76, ethertype IPv4 > (0x0800), length 60: (tos 0x0, ttl 58, id 0, offset 0, flags [none], proto > TCP (6), length 40) 192.168.3.132.41922 > 192.168.8.163.22: ., cksum 0x6872 > (correct), 1:1(0) ack 1 win 0 This packet is completely broken. It appears to come from the client and to ACK the SYN|ACK from above. However it advertises a zero window, has a different TTL (58 vs. 61 for the other packets from the client), a IPID of zero and contains no timestamps. This causes the check for missing timestamps to trigger and to abort the connection. RFC1323 requires timestamps to be always present when negotiated during the SYN phase. I've verified that FreeBSD 6.2, OpenBSD 4.1 and Linux RHEL4 implement timestamps correctly and do not turn them off once negotiated. This packet differs significantly from any other packet the client sends. It appears not to come from the real client but some other device that either is in the path between client and server or to share the IP address with the client. Do you have any routers, firewalls, gateways or NAT devices along the path that may cause this strange packet to be sent? > 08:09:55.816933 00:18:fe:67:54:76 > 00:00:0c:07:ac:09, ethertype IPv4 > (0x0800), length 54: (tos 0x0, ttl 64, id 27231, offset 0, flags [DF], proto > TCP (6), length 40) 192.168.8.163.22 > 192.168.3.132.41922: R, cksum 0x47e3 > (incorrect (-> 0xd2ed), 2406244837:2406244837(0) win 0 The server sends the reset and aborts the connection because the timestamp check failed. > 08:09:55.817215 00:90:5f:0c:00:00 > 00:18:fe:67:54:76, ethertype IPv4 > (0x0800), length 66: (tos 0x0, ttl 61, id 56889, offset 0, flags [DF], proto > TCP (6), length 52) 192.168.3.132.41922 > 192.168.8.163.22: ., cksum 0x8036 > (correct), 1:1(0) ack 1 win 1460 Here the real client appears to ACK the SYN|ACK. Note the correct TTL, IPID, window size and timestamps. > 08:09:55.833093 00:18:fe:67:54:76 > 00:00:0c:07:ac:09, ethertype IPv4 > (0x0800), length 105: (tos 0x0, ttl 64, id 27232, offset 0, flags [DF], > proto TCP (6), length 91) 192.168.8.163.22 > 192.168.3.132.41922: P 1:40(39) > ack 1 win 8326 The server re-opens the connection based on the correct ACK because the SYN cookie is correct. The original syncache full entry was deleted above when the reset was sent. However the syncookie is still valid and passed all tests. > 08:09:55.833929 00:90:5f:0c:00:00 > 00:18:fe:67:54:76, ethertype IPv4 > (0x0800), length 60: (tos 0x0, ttl 61, id 8446, offset 0, flags [DF], proto > TCP (6), length 40) 192.168.3.132.41922 > 192.168.8.163.22: R, cksum 0x59d0 > (correct), 722288482:722288482(0) win 0 The client answers with a reset because its socket was shut down due to the reset above caused by the broken (spoofed) ACK packet earlier. It all boils down to where the broken/spoofed ACK (packet #3) comes from. There must be some strange or completely broken device in the packet path between client and server. Please investigate and identify potential candidates. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 12:52:55 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9675116A417 for ; Thu, 24 Jan 2008 12:52:55 +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 0BB9913C447 for ; Thu, 24 Jan 2008 12:52:54 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 126 invoked from network); 24 Jan 2008 12:14:08 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Jan 2008 12:14:08 -0000 Message-ID: <47988A2A.5010506@freebsd.org> Date: Thu, 24 Jan 2008 13:52:58 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Maxim Konovalov References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> <20080124005006.D93697@odysseus.silby.com> <47986F27.10401@freebsd.org> <20080124145713.K15031@mp2.macomnet.net> In-Reply-To: <20080124145713.K15031@mp2.macomnet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 24 Jan 2008 12:52:55 -0000 Maxim Konovalov wrote: > [...] >>> I'm not generally opposed to security improvements that only affect edge >>> cases... but being unable to connect is not an edge case! >> Fully agreed. I'll reopen the PR and follow up with the originator >> to do some further analysis. All operating system he cites that were >> unable to connect correctly send timestamps and do not stop after >> the SYN phase. So there must be something else at play here. Have >> you received or heart of any *other* reports that may be related to >> the timestamp check? >> > I saw this with my adsl router. Happy to test patches. Please provide a tcpdump of a connection that failed before. It'll show the problem even though it doesn't cause an abort. Was the problem you saw with communication through the adsl router, or when you connected to the adsl router itself (configuration menu, etc)? [Reducing CC list] -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 13:49:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C345216A419; Thu, 24 Jan 2008 13:49:07 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 51EEB13C46E; Thu, 24 Jan 2008 13:49:06 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id m0ODn5jj037307; Thu, 24 Jan 2008 16:49:05 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Thu, 24 Jan 2008 16:49:05 +0300 (MSK) From: Maxim Konovalov To: Andre Oppermann In-Reply-To: <47988A2A.5010506@freebsd.org> Message-ID: <20080124164704.X15031@mp2.macomnet.net> References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> <20080124005006.D93697@odysseus.silby.com> <47986F27.10401@freebsd.org> <20080124145713.K15031@mp2.macomnet.net> <47988A2A.5010506@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 24 Jan 2008 13:49:07 -0000 On Thu, 24 Jan 2008, 13:52+0100, Andre Oppermann wrote: > Maxim Konovalov wrote: > > [...] > > > > I'm not generally opposed to security improvements that only affect edge > > > > cases... but being unable to connect is not an edge case! > > > Fully agreed. I'll reopen the PR and follow up with the originator > > > to do some further analysis. All operating system he cites that were > > > unable to connect correctly send timestamps and do not stop after > > > the SYN phase. So there must be something else at play here. Have > > > you received or heart of any *other* reports that may be related to > > > the timestamp check? > > > > > I saw this with my adsl router. Happy to test patches. > > Please provide a tcpdump of a connection that failed before. It'll > show the problem even though it doesn't cause an abort. Was the > problem you saw with communication through the adsl router, or when > you connected to the adsl router itself (configuration menu, etc)? > The latter. Turning rfc1323 off solved the problem. It takes some time to obtain the dump -- I need to downgrade the system. -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 14:18:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EDBF16A420 for ; Thu, 24 Jan 2008 14:18:34 +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 8570713C455 for ; Thu, 24 Jan 2008 14:18:33 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 1243 invoked from network); 24 Jan 2008 13:39:46 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Jan 2008 13:39:46 -0000 Message-ID: <47989E3C.4030700@freebsd.org> Date: Thu, 24 Jan 2008 15:18:36 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Maxim Konovalov References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> <20080124005006.D93697@odysseus.silby.com> <47986F27.10401@freebsd.org> <20080124145713.K15031@mp2.macomnet.net> <47988A2A.5010506@freebsd.org> <20080124164704.X15031@mp2.macomnet.net> In-Reply-To: <20080124164704.X15031@mp2.macomnet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 24 Jan 2008 14:18:34 -0000 Maxim Konovalov wrote: > On Thu, 24 Jan 2008, 13:52+0100, Andre Oppermann wrote: > >> Maxim Konovalov wrote: >>> [...] >>>>> I'm not generally opposed to security improvements that only affect edge >>>>> cases... but being unable to connect is not an edge case! >>>> Fully agreed. I'll reopen the PR and follow up with the originator >>>> to do some further analysis. All operating system he cites that were >>>> unable to connect correctly send timestamps and do not stop after >>>> the SYN phase. So there must be something else at play here. Have >>>> you received or heart of any *other* reports that may be related to >>>> the timestamp check? >>>> >>> I saw this with my adsl router. Happy to test patches. >> Please provide a tcpdump of a connection that failed before. It'll >> show the problem even though it doesn't cause an abort. Was the >> problem you saw with communication through the adsl router, or when >> you connected to the adsl router itself (configuration menu, etc)? >> > The latter. Turning rfc1323 off solved the problem. > > It takes some time to obtain the dump -- I need to downgrade the > system. That is not necessary. A tcpdump from current is fine. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 14:20:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC1F916A468; Thu, 24 Jan 2008 14:20:25 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 6140713C4F0; Thu, 24 Jan 2008 14:20:25 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id m0OEKNAW039688; Thu, 24 Jan 2008 17:20:23 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Thu, 24 Jan 2008 17:20:23 +0300 (MSK) From: Maxim Konovalov To: Andre Oppermann In-Reply-To: <47989E3C.4030700@freebsd.org> Message-ID: <20080124171957.N15031@mp2.macomnet.net> References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> <20080124005006.D93697@odysseus.silby.com> <47986F27.10401@freebsd.org> <20080124145713.K15031@mp2.macomnet.net> <47988A2A.5010506@freebsd.org> <20080124164704.X15031@mp2.macomnet.net> <47989E3C.4030700@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 24 Jan 2008 14:20:26 -0000 > > The latter. Turning rfc1323 off solved the problem. > > > > It takes some time to obtain the dump -- I need to downgrade the > > system. > > That is not necessary. A tcpdump from current is fine. > OK, later this evening (UTC+3). -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 14:40:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A804B16A417; Thu, 24 Jan 2008 14:40:28 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (redrock.karels.net [206.196.45.2]) by mx1.freebsd.org (Postfix) with ESMTP id 397AA13C4D5; Thu, 24 Jan 2008 14:40:28 +0000 (UTC) (envelope-from karels@redrock.karels.net) Received: from redrock.karels.net (localhost [127.0.0.1]) by redrock.karels.net (8.13.8/8.13.6) with ESMTP id m0OEECWt097838; Thu, 24 Jan 2008 08:14:12 -0600 (CST) (envelope-from karels@redrock.karels.net) Message-Id: <200801241414.m0OEECWt097838@redrock.karels.net> To: Andre Oppermann From: Mike Karels In-reply-to: Your message of Thu, 24 Jan 2008 11:58:21 +0100. <47986F4D.6070208@freebsd.org> Date: Thu, 24 Jan 2008 08:14:12 -0600 Sender: karels@karels.net Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: karels@karels.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2008 14:40:28 -0000 Return-Path: owner-freebsd-net@freebsd.org Delivery-Date: Thu Jan 24 05:00:27 2008 Received: from staring.karels.net (root@staring.karels.net [206.196.45.1]) by redrock.karels.net (8.13.8/8.13.6) with ESMTP id m0OB0Rb6097199 for ; Thu, 24 Jan 2008 05:00:27 -0600 (CST) (envelope-from owner-freebsd-net@freebsd.org) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by staring.karels.net (8.11.6/8.11.2) with ESMTP id m0OB0QA08500 for ; Thu, 24 Jan 2008 05:00:26 -0600 (CST) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 398C833428; Thu, 24 Jan 2008 10:58:25 +0000 (UTC) (envelope-from owner-freebsd-net@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 10EE016A419; Thu, 24 Jan 2008 10:58:25 +0000 (UTC) (envelope-from owner-freebsd-net@freebsd.org) 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 CE46B16A478 for ; Thu, 24 Jan 2008 10:58:18 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2909C13C4DD for ; Thu, 24 Jan 2008 10:58:17 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 98697 invoked from network); 24 Jan 2008 10:19:32 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Jan 2008 10:19:32 -0000 Message-ID: <47986F4D.6070208@freebsd.org> Date: Thu, 24 Jan 2008 11:58:21 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Kip Macy References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Silbersack , kmacy@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, src-committers@freebsd.org, freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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: , Sender: owner-freebsd-net@freebsd.org Errors-To: owner-freebsd-net@freebsd.org > Kip Macy wrote: > > So it is clearly open to interpretation. > No, it is not. RFC1323 was written in 1992 before RFCs contained the > boiler plate definition of MUST, SHOULD, MAY and so on. The use of MUST, etc, originated in RFC1122 in 1989. That RFC also contains this: 1.2.2 Robustness Principle At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability [IP:1]: "Be liberal in what you accept, and conservative in what you send" This quote is also on the RFC1122 working group coffee cup on my shelf. It seems to apply here. Mike From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 15:58:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 511FD16A417 for ; Thu, 24 Jan 2008 15:58:02 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: from coruscant.far-far-away.us (coruscant.far-far-away.us [70.91.196.65]) by mx1.freebsd.org (Postfix) with SMTP id D631013C46B for ; Thu, 24 Jan 2008 15:58:01 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: (qmail 30980 invoked from network); 24 Jan 2008 10:52:15 -0500 Received: from pknat1.passkey.com (HELO ?192.168.16.168?) (68.162.198.134) by coruscant.far-far-away.us with SMTP; 24 Jan 2008 10:52:15 -0500 From: Yousif Hassan To: Brooks Davis , "Bruce M. Simpson" In-Reply-To: <20080123222047.GA14264@lor.one-eyed-alien.net> References: <1201125022.2106.67.camel@localhost> <20080123222047.GA14264@lor.one-eyed-alien.net> Content-Type: text/plain Date: Thu, 24 Jan 2008 10:58:33 -0500 Message-Id: <1201190313.2591.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: network interface monitoring? 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, 24 Jan 2008 15:58:02 -0000 Thank you to all who responded. The suggestion was made to use devd or ifstated. Both sound like excellent tools, but I'm currently being tripped up by a core problem - both tools rely on the kernel to notify userland of link state changes (which makes complete sense!). This is all well and good - but the current issue I'm seeing is that the link state doesn't get updated without running "ifconfig" again - is this by design? A known "issue?" An example: 1. Unplug network cable from bfe0 2. I run ifconfig 3. I see that interface bfe0's status is "no carrier". Good. 4. I plug the cable into bfe0 5. Wait... wait... look in /var/log/messages... wait more.. NO STATE CHANGE - the longest I've waited was 2 minutes, which is already too long 6. run "ifconfig" again 7. Link state immediately changes, logs to /var/log/messages, devd scripts run Is this a known behavior? It seems like the link state changes should happen automatically, without something to "trigger" them. Isn't there some kind of poll or interrupt sequence? I'm on 6.3 RC2 (will upgrade to 6.3-RELEASE imminently) but can't imagine this code changed? Does this work differently/better in 7.0? Thanks again guys for your time. --Yousif From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 16:36:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C0BB16A418; Thu, 24 Jan 2008 16:36:41 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id C5CB413C469; Thu, 24 Jan 2008 16:36:40 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id m0OGaYtJ025427; Thu, 24 Jan 2008 10:36:34 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id m0OGaY4A025426; Thu, 24 Jan 2008 10:36:34 -0600 (CST) (envelope-from brooks) Date: Thu, 24 Jan 2008 10:36:34 -0600 From: Brooks Davis To: Yousif Hassan Message-ID: <20080124163634.GA25331@lor.one-eyed-alien.net> References: <1201125022.2106.67.camel@localhost> <20080123222047.GA14264@lor.one-eyed-alien.net> <1201190313.2591.7.camel@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <1201190313.2591.7.camel@localhost> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 24 Jan 2008 10:36:34 -0600 (CST) Cc: freebsd-net@freebsd.org, Brooks Davis , "Bruce M. Simpson" Subject: Re: network interface monitoring? 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, 24 Jan 2008 16:36:41 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 24, 2008 at 10:58:33AM -0500, Yousif Hassan wrote: > Thank you to all who responded. >=20 > The suggestion was made to use devd or ifstated. Both sound like > excellent tools, but I'm currently being tripped up by a core problem - > both tools rely on the kernel to notify userland of link state changes > (which makes complete sense!). This is all well and good - but the > current issue I'm seeing is that the link state doesn't get updated > without running "ifconfig" again - is this by design? A known "issue?" >=20 > An example: > 1. Unplug network cable from bfe0 > 2. I run ifconfig > 3. I see that interface bfe0's status is "no carrier". Good. > 4. I plug the cable into bfe0 > 5. Wait... wait... look in /var/log/messages... wait more.. NO STATE > CHANGE - the longest I've waited was 2 minutes, which is already too > long > 6. run "ifconfig" again > 7. Link state immediately changes, logs to /var/log/messages, devd > scripts run >=20 > Is this a known behavior? It seems like the link state changes should > happen automatically, without something to "trigger" them. Isn't there > some kind of poll or interrupt sequence? I'm on 6.3 RC2 (will upgrade > to 6.3-RELEASE imminently) but can't imagine this code changed? Does > this work differently/better in 7.0? It's known but not well understood and is a driver bug. -- Brooks --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHmL6RXY6L6fI4GtQRAniAAJ412B+KsDqaoAA9lQDbBQH9FCbTnACeJH9b rdAlvAK0c40kOwvIPKwXo7Y= =thqW -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 18:06:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1AB416A419 for ; Thu, 24 Jan 2008 18:06:51 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: from coruscant.far-far-away.us (coruscant.far-far-away.us [70.91.196.65]) by mx1.freebsd.org (Postfix) with SMTP id 0FDBA13C45D for ; Thu, 24 Jan 2008 18:06:50 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: (qmail 31838 invoked from network); 24 Jan 2008 13:01:04 -0500 Received: from pknat1.passkey.com (HELO ?192.168.16.168?) (68.162.198.134) by coruscant.far-far-away.us with SMTP; 24 Jan 2008 13:01:04 -0500 From: Yousif Hassan To: Brooks Davis In-Reply-To: <20080124163634.GA25331@lor.one-eyed-alien.net> References: <1201125022.2106.67.camel@localhost> <20080123222047.GA14264@lor.one-eyed-alien.net> <1201190313.2591.7.camel@localhost> <20080124163634.GA25331@lor.one-eyed-alien.net> Content-Type: text/plain Date: Thu, 24 Jan 2008 13:07:22 -0500 Message-Id: <1201198042.19736.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: network interface monitoring? 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, 24 Jan 2008 18:06:51 -0000 On Thu, 2008-01-24 at 10:36 -0600, Brooks Davis wrote: > On Thu, Jan 24, 2008 at 10:58:33AM -0500, Yousif Hassan wrote: > > Thank you to all who responded. > > > > The suggestion was made to use devd or ifstated. Both sound like > > excellent tools, but I'm currently being tripped up by a core problem - > > both tools rely on the kernel to notify userland of link state changes > > (which makes complete sense!). This is all well and good - but the > > current issue I'm seeing is that the link state doesn't get updated > > without running "ifconfig" again - is this by design? A known "issue?" > > > > An example: > > 1. Unplug network cable from bfe0 > > 2. I run ifconfig > > 3. I see that interface bfe0's status is "no carrier". Good. > > 4. I plug the cable into bfe0 > > 5. Wait... wait... look in /var/log/messages... wait more.. NO STATE > > CHANGE - the longest I've waited was 2 minutes, which is already too > > long > > 6. run "ifconfig" again > > 7. Link state immediately changes, logs to /var/log/messages, devd > > scripts run > > > > Is this a known behavior? It seems like the link state changes should > > happen automatically, without something to "trigger" them. Isn't there > > some kind of poll or interrupt sequence? I'm on 6.3 RC2 (will upgrade > > to 6.3-RELEASE imminently) but can't imagine this code changed? Does > > this work differently/better in 7.0? > > It's known but not well understood and is a driver bug. I was afraid you'd say that. Thanks for the info. I found PR kern/109733: [bge] bge link state issues (regression) which, while referring to a different driver, has some of the same symptoms. In the meantime, I scripted something that calls ifconfig every 30 seconds or so, redirected its output to null, and put it in the background and nice'd it; this seems to do the trick, albeit via a horrid hack. Due to the bug you mentioned, sometimes link state events queue up, too, and get passed to userland at once, which is no kind of fun, but the script still works. Yousif From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 18:24:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D49AC16A421 for ; Thu, 24 Jan 2008 18:24:34 +0000 (UTC) (envelope-from fjo-lists@ogris.de) Received: from ns1.ogris.net (ns1.ogris.net [212.62.68.23]) by mx1.freebsd.org (Postfix) with ESMTP id CDA9B13C461 for ; Thu, 24 Jan 2008 18:24:33 +0000 (UTC) (envelope-from fjo-lists@ogris.de) Received: from [81.89.251.75] (fjo-pb.dts.de [81.89.251.75]) by ns1.ogris.net (Postfix) with ESMTP id 020E9B2461 for ; Thu, 24 Jan 2008 19:08:28 +0100 (CET) User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 24 Jan 2008 19:08:25 +0100 From: "Felix J. Ogris" To: Message-ID: Thread-Topic: carp(4) ip loadbalancing (patch included) Thread-Index: AchetBzHWyezVsqnEdyWVQARJHjFOg== Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3284046509_3507725" Subject: carp(4) ip loadbalancing (patch included) 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, 24 Jan 2008 18:24:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3284046509_3507725 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, I have extended ip_carp.c to provide loadbalancing on an ip basis, eg. to setup an active/active cluster. The algorithm is quite simple. Each cluster consists of N nodes. If an IPv4/IPv6 packet reaches node X, then it evaluates X == N mod source_address_of_IP_packet. If this is true, then the node will process that packet (carp_forus() returns 1). I had to introduce a new carp type (#define CARP_HELO 0x00) which by default is multicasted every 3 seconds (advertising base). Each node maintains a list of its IPv4 and IPv6 neighbours. Neighbours are timed out after 3 * advbase seconds. Network layer protocols other than IPv4/IPv6 are handled by the carp master. TCP packets, which have their ACK flag set or their SYN flag not set, are checked for an entry in the syncache or in tcbinfo. If an entry is found, then that TCP packet will not be handled by the current node (carp_forus() returns 0). This guarantees that an established TCP connection will stick to a host, even if a dead node reenters the cluster. I have put my patch (against 6.3-RELEASE) under the same license as the FreeBSD kernel itself. So feel free to apply it to the official tree - or to punish me for my lousy work :-) Regards, Felix --B_3284046509_3507725 Content-type: application/octet-stream; name="carp_aa.patch" Content-disposition: attachment; filename="carp_aa.patch" Content-transfer-encoding: base64 ZGlmZiAtZHJ1IHN5czAvbmV0L2lmX2JyaWRnZS5jIHN5cy9uZXQvaWZfYnJpZGdlLmMKLS0t IHN5czAvbmV0L2lmX2JyaWRnZS5jCTIwMDctMTItMjEgMDU6MzA6NDcuMDAwMDAwMDAwICsw MDAwCisrKyBzeXMvbmV0L2lmX2JyaWRnZS5jCTIwMDgtMDEtMjMgMjM6Mjk6MDIuMDAwMDAw MDAwICswMDAwCkBAIC0yMTc2LDEwICsyMTc2LDEwIEBACiAjaWZkZWYgREVWX0NBUlAKICMg ICBkZWZpbmUgT1JfQ0FSUF9DSEVDS19XRV9BUkVfRFNUKGlmYWNlKSBcCiAJfHwgKChpZmFj ZSktPmlmX2NhcnAgXAotCSAgICAmJiBjYXJwX2ZvcnVzKChpZmFjZSktPmlmX2NhcnAsIGVo LT5ldGhlcl9kaG9zdCkpCisJICAgICYmIGNhcnBfZm9ydXMoKGlmYWNlKS0+aWZfY2FycCwg ZWgtPmV0aGVyX2Rob3N0LCBtKSkKICMgICBkZWZpbmUgT1JfQ0FSUF9DSEVDS19XRV9BUkVf U1JDKGlmYWNlKSBcCiAJfHwgKChpZmFjZSktPmlmX2NhcnAgXAotCSAgICAmJiBjYXJwX2Zv cnVzKChpZmFjZSktPmlmX2NhcnAsIGVoLT5ldGhlcl9zaG9zdCkpCisJICAgICYmIGNhcnBf Zm9ydXMoKGlmYWNlKS0+aWZfY2FycCwgZWgtPmV0aGVyX3Nob3N0LCBtKSkKICNlbHNlCiAj ICAgZGVmaW5lIE9SX0NBUlBfQ0hFQ0tfV0VfQVJFX0RTVChpZmFjZSkKICMgICBkZWZpbmUg T1JfQ0FSUF9DSEVDS19XRV9BUkVfU1JDKGlmYWNlKQpkaWZmIC1kcnUgc3lzMC9uZXQvaWZf ZXRoZXJzdWJyLmMgc3lzL25ldC9pZl9ldGhlcnN1YnIuYwotLS0gc3lzMC9uZXQvaWZfZXRo ZXJzdWJyLmMJMjAwNy0wOS0xNyAxNzo1MDo0OS4wMDAwMDAwMDAgKzAwMDAKKysrIHN5cy9u ZXQvaWZfZXRoZXJzdWJyLmMJMjAwOC0wMS0yMyAyMzoyOToyOS4wMDAwMDAwMDAgKzAwMDAK QEAgLTY2Miw3ICs2NjIsNyBAQAogCQkgKiBldmFsdWF0aW9uLCB0byBzZWUgaWYgdGhlIGNh cnAgZXRoZXJfZGhvc3QgdmFsdWVzIGJyZWFrIGFueQogCQkgKiBvZiB0aGVzZSBjaGVja3Mh CiAJCSAqLwotCQlpZiAoaWZwLT5pZl9jYXJwICYmIGNhcnBfZm9ydXMoaWZwLT5pZl9jYXJw LCBlaC0+ZXRoZXJfZGhvc3QpKQorCQlpZiAoaWZwLT5pZl9jYXJwICYmIGNhcnBfZm9ydXMo aWZwLT5pZl9jYXJwLCBlaC0+ZXRoZXJfZGhvc3QsIG0pKQogCQkJZ290byBwcmVfc3RhdHM7 CiAjZW5kaWYKIAkJLyoKZGlmZiAtZHJ1IHN5czAvbmV0aW5ldC9pcF9jYXJwLmMgc3lzL25l dGluZXQvaXBfY2FycC5jCi0tLSBzeXMwL25ldGluZXQvaXBfY2FycC5jCTIwMDctMDYtMDYg MTY6MjA6NTAuMDAwMDAwMDAwICswMDAwCisrKyBzeXMvbmV0aW5ldC9pcF9jYXJwLmMJMjAw OC0wMS0yMyAyMzoyMjoxMi4wMDAwMDAwMDAgKzAwMDAKQEAgLTMsNiArMyw3IEBACiAvKgog ICogQ29weXJpZ2h0IChjKSAyMDAyIE1pY2hhZWwgU2hhbGF5ZWZmLiBBbGwgcmlnaHRzIHJl c2VydmVkLgogICogQ29weXJpZ2h0IChjKSAyMDAzIFJ5YW4gTWNCcmlkZS4gQWxsIHJpZ2h0 cyByZXNlcnZlZC4KKyAqIENvcHlyaWdodCAoYykgMjAwOCBGZWxpeCBKLiBPZ3Jpcy4gQWxs IHJpZ2h0cyByZXNlcnZlZC4KICAqCiAgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNv dXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKICAqIG1vZGlmaWNhdGlv biwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9u cwpAQCAtODgsNiArODksMzIgQEAKIHN0YXRpYyBNQUxMT0NfREVGSU5FKE1fQ0FSUCwgIkNB UlAiLCAiQ0FSUCBpbnRlcmZhY2VzIik7CiBTWVNDVExfREVDTChfbmV0X2luZXRfY2FycCk7 CiAKKy8qIGlwbGIgKi8KKyNpbmNsdWRlIDxuZXRpbmV0L2luX3BjYi5oPgorI2lmZGVmIElO RVQ2CisjaW5jbHVkZSA8bmV0aW5ldDYvaW42X3BjYi5oPgorI2VuZGlmCisjaW5jbHVkZSA8 bmV0aW5ldC90Y3BfdmFyLmg+CisjZGVmaW5lIENBUlBfSEVMTyAweDAwCitzdHJ1Y3QgY2Fy cF9wZWVyIHsKKwlzdHJ1Y3QgeworCQlzYV9mYW1pbHlfdCBzYV9mYW1pbHk7CisJCWNoYXIg c2FfZGF0YVsxNl07CisJfSBjcF9zYTsKKwlzdHJ1Y3QgdGltZXZhbCBjcF90djsKKwlUQUlM UV9FTlRSWShjYXJwX3BlZXIpIGNwX2xpc3Q7Cit9OworVEFJTFFfSEVBRChjYXJwX3BlZXJf bGlzdCwgY2FycF9wZWVyKTsKK3N0YXRpYyB2b2lkIGNhcnBfaXBsYl9jbGVhbnVwKHZvaWQq KTsKK3N0YXRpYyBpbnQgY2FycF9pcGxiX2VuYWJsZSA9IDA7CitzdGF0aWMgaW50IGNhcnBf aXBsYl9tYXNrID0gMzI7CitTWVNDVExfSU5UKF9uZXRfaW5ldF9jYXJwLCBPSURfQVVUTywg aXBfYmFsYW5jZSwgQ1RMRkxBR19SVywKKyAgICAmY2FycF9pcGxiX2VuYWJsZSwgMCwgImJh bGFuY2UgSVAgcmVzcG9uc2VzIik7CitTWVNDVExfSU5UKF9uZXRfaW5ldF9jYXJwLCBPSURf QVVUTywgaXBfYmFsYW5jZV9tYXNrLCBDVExGTEFHX1JXLAorICAgICZjYXJwX2lwbGJfbWFz aywgMCwgIklQIHN0aWNreW5lc3MgbWFzayIpOworZXh0ZXJuIHN0cnVjdCBzeW5jYWNoZSAq c3luY2FjaGVfbG9va3VwKHN0cnVjdCBpbl9jb25uaW5mbyosIHN0cnVjdCBzeW5jYWNoZV9o ZWFkKiopOworLyogaXBsYiAqLworCiBzdHJ1Y3QgY2FycF9zb2Z0YyB7CiAJc3RydWN0IGlm bmV0CSAJKnNjX2lmcDsJLyogSW50ZXJmYWNlIGNsdWUgKi8KIAlzdHJ1Y3QgaWZuZXQJCSpz Y19jYXJwZGV2OwkvKiBQb2ludGVyIHRvIHBhcmVudCBpbnRlcmZhY2UgKi8KQEAgLTEyOCw2 ICsxNTUsMjAgQEAKIAlzdHJ1Y3QgY2FsbG91dCAJCSBzY19tZDZfdG1vOwkvKiBtYXN0ZXIg ZG93biB0aW1lb3V0ICovCiAJCiAJTElTVF9FTlRSWShjYXJwX3NvZnRjKQkgc2NfbmV4dDsJ LyogSW50ZXJmYWNlIGNsdWUgKi8KKworCS8qIGlwbGIgKi8KKwlzdHJ1Y3QgY2FsbG91dCAJ CSBzY19wZWVyc190bW87CS8qIGhlbG8gdGltZW91dCAqLworCXN0cnVjdCBjYXJwX3BlZXJf bGlzdCAgICBzY19wZWVyczsJLyogSVB2NCBwZWVycyAqLworCXN0cnVjdCBjYXJwX3BlZXJf bGlzdCAgICBzY19wZWVyczYJLyogSVB2NiBwZWVycyAqLzsKKwlpbnQgc2NfaG9zdHM7CQkJ CS8qIElQdjQgaG9zdHMgaW4gdGhpcyBjbHVzdGVyICovCisJaW50IHNjX2hvc3Q7CQkJCS8q IG15IElQdjQgcG9zaXRpb24gKi8KKwlpbnQgc2NfaG9zdHM2OwkJCQkvKiBJUHY2IGhvc3Rz IGluIHRoaXMgY2x1c3RlciAqLworCWludCBzY19ob3N0NjsJCQkJLyogbXkgSVB2NiBwb3Np dGlvbiAqLworCXN0cnVjdCBtdHggc2NfcGVlcnNfbXR4OwkJLyogbXV0ZXggZm9yIHNjX3Bl ZXJzICovCisJc3RydWN0IG10eCBzY19wZWVyczZfbXR4OwkJLyogbXV0ZXggZm9yIHNjX3Bl ZXJzNiAqLworCWNoYXIgc2NfcGVlcnNfbXR4X25hbWVbNjRdOwkJLyogbmFtZSBvZiBzY19w ZWVyc19tdHggKi8KKwljaGFyIHNjX3BlZXJzNl9tdHhfbmFtZVs2NF07CQkvKiBuYW1lIG9m IHNjX3BlZXJzNl9tdHggKi8KKwkvKiBpcGxiICovCiB9OwogI2RlZmluZQlTQzJJRlAoc2Mp CSgoc2MpLT5zY19pZnApCiAKQEAgLTM1NCw3ICszOTUsNyBAQAogc3RhdGljIGludAogY2Fy cF9jbG9uZV9jcmVhdGUoc3RydWN0IGlmX2Nsb25lICppZmMsIGludCB1bml0KQogewotCisJ c3RydWN0IHRpbWV2YWwgdHY7CiAJc3RydWN0IGNhcnBfc29mdGMgKnNjOwogCXN0cnVjdCBp Zm5ldCAqaWZwOwogCkBAIC0zOTYsNiArNDM3LDI1IEBACiAJbXR4X2xvY2soJmNhcnBfbXR4 KTsKIAlMSVNUX0lOU0VSVF9IRUFEKCZjYXJwaWZfbGlzdCwgc2MsIHNjX25leHQpOwogCW10 eF91bmxvY2soJmNhcnBfbXR4KTsKKworCS8qIGlwbGIgKi8KKwlzdHJjcHkoc2MtPnNjX3Bl ZXJzX210eF9uYW1lLCBTQzJJRlAoc2MpLT5pZl94bmFtZSk7CisJc3RyY2F0KHNjLT5zY19w ZWVyc19tdHhfbmFtZSwgIl9wZWVyc19tdHgiKTsKKwltdHhfaW5pdCgmc2MtPnNjX3BlZXJz X210eCwgc2MtPnNjX3BlZXJzX210eF9uYW1lLCBOVUxMLCBNVFhfREVGKTsKKwlzdHJjcHko c2MtPnNjX3BlZXJzNl9tdHhfbmFtZSwgU0MySUZQKHNjKS0+aWZfeG5hbWUpOworCXN0cmNh dChzYy0+c2NfcGVlcnM2X210eF9uYW1lLCAiX3BlZXJzNl9tdHgiKTsKKwltdHhfaW5pdCgm c2MtPnNjX3BlZXJzNl9tdHgsIHNjLT5zY19wZWVyczZfbXR4X25hbWUsIE5VTEwsIE1UWF9E RUYpOworCVRBSUxRX0lOSVQoJnNjLT5zY19wZWVycyk7CisJVEFJTFFfSU5JVCgmc2MtPnNj X3BlZXJzNik7CisJc2MtPnNjX2hvc3RzID0gMDsKKwlzYy0+c2NfaG9zdCA9IC0xOworCXNj LT5zY19ob3N0czYgPSAwOworCXNjLT5zY19ob3N0NiA9IC0xOworCXR2LnR2X3NlYyA9IENB UlBfREZMVElOVFY7CisJdHYudHZfdXNlYyA9IDA7CisJY2FsbG91dF9pbml0KCZzYy0+c2Nf cGVlcnNfdG1vLCBORVRfQ0FMTE9VVF9NUFNBRkUpOworCWNhbGxvdXRfcmVzZXQoJnNjLT5z Y19wZWVyc190bW8sIHR2dG9oeigmdHYpLCBjYXJwX2lwbGJfY2xlYW51cCwgc2MpOworCiAJ cmV0dXJuICgwKTsKIH0KIApAQCAtNDAzLDExICs0NjMsMjcgQEAKIGNhcnBfY2xvbmVfZGVz dHJveShzdHJ1Y3QgaWZuZXQgKmlmcCkKIHsKIAlzdHJ1Y3QgY2FycF9zb2Z0YyAqc2MgPSBp ZnAtPmlmX3NvZnRjOworCXN0cnVjdCBjYXJwX3BlZXIgKmNwLCAqY3BfdGVtcDsKIAogCWlm IChzYy0+c2NfY2FycGRldikKIAkJQ0FSUF9TQ0xPQ0soc2MpOwogCWNhcnBkZXRhY2goc2Ms IDEpOwkvKiBSZXR1cm5zIHVubG9ja2VkLiAqLwogCisJLyogaXBsYiAqLworCWNhbGxvdXRf c3RvcCgmc2MtPnNjX3BlZXJzX3Rtbyk7CisJbXR4X2Rlc3Ryb3koJnNjLT5zY19wZWVyc19t dHgpOworCW10eF9kZXN0cm95KCZzYy0+c2NfcGVlcnM2X210eCk7CisJc2MtPnNjX2hvc3Qg PSAtMTsKKwlzYy0+c2NfaG9zdHMgPSAwOworCXNjLT5zY19ob3N0NiA9IC0xOworCXNjLT5z Y19ob3N0czYgPSAwOworCVRBSUxRX0ZPUkVBQ0hfU0FGRShjcCwgJnNjLT5zY19wZWVycywg Y3BfbGlzdCwgY3BfdGVtcCkgeworCQlUQUlMUV9SRU1PVkUoJnNjLT5zY19wZWVycywgY3As IGNwX2xpc3QpOworCX0KKwlUQUlMUV9GT1JFQUNIX1NBRkUoY3AsICZzYy0+c2NfcGVlcnM2 LCBjcF9saXN0LCBjcF90ZW1wKSB7CisJCVRBSUxRX1JFTU9WRSgmc2MtPnNjX3BlZXJzNiwg Y3AsIGNwX2xpc3QpOworCX0KKwogCW10eF9sb2NrKCZjYXJwX210eCk7CiAJTElTVF9SRU1P VkUoc2MsIHNjX25leHQpOwogCW10eF91bmxvY2soJmNhcnBfbXR4KTsKQEAgLTQ3NCw2ICs1 NTAsNDY2IEBACiAJfQogfQogCisvKiBpcGxiICovCitzdGF0aWMgdm9pZAorY2FycF9pcGxi X2xvZ3BlZXIoc3RydWN0IGNhcnBfc29mdGMgKnNjLCBzdHJ1Y3QgY2FycF9wZWVyICpjcCwg Y2hhciAqZXZlbnQpCit7CisJc3dpdGNoIChjcC0+Y3Bfc2Euc2FfZmFtaWx5KSB7CisjaWZk ZWYgSU5FVDYKKwkgICAgY2FzZSBBRl9JTkVUNjoKKwkJQ0FSUF9MT0coIiVzOiAlczogJWho eCVoaHg6JWhoeCVoaHg6JWhoeCVoaHg6JWhoeCVoaHg6IgorCQkJICIlaGh4JWhoeDolaGh4 JWhoeDolaGh4JWhoeDolaGh4JWhoeFxuIiwKKwkJCSBTQzJJRlAoc2MpLT5pZl94bmFtZSwg ZXZlbnQsCisJCQkgY3AtPmNwX3NhLnNhX2RhdGFbMF0sIGNwLT5jcF9zYS5zYV9kYXRhWzFd LAorCQkJIGNwLT5jcF9zYS5zYV9kYXRhWzJdLCBjcC0+Y3Bfc2Euc2FfZGF0YVszXSwKKwkJ CSBjcC0+Y3Bfc2Euc2FfZGF0YVs0XSwgY3AtPmNwX3NhLnNhX2RhdGFbNV0sCisJCQkgY3At PmNwX3NhLnNhX2RhdGFbNl0sIGNwLT5jcF9zYS5zYV9kYXRhWzddLAorCQkJIGNwLT5jcF9z YS5zYV9kYXRhWzhdLCBjcC0+Y3Bfc2Euc2FfZGF0YVs5XSwKKwkJCSBjcC0+Y3Bfc2Euc2Ff ZGF0YVsxMF0sIGNwLT5jcF9zYS5zYV9kYXRhWzExXSwKKwkJCSBjcC0+Y3Bfc2Euc2FfZGF0 YVsxMl0sIGNwLT5jcF9zYS5zYV9kYXRhWzEzXSwKKwkJCSBjcC0+Y3Bfc2Euc2FfZGF0YVsx NF0sIGNwLT5jcF9zYS5zYV9kYXRhWzE1XSk7CisJCWJyZWFrOworI2VuZGlmCisjaWZkZWYg SU5FVAorCSAgICBjYXNlIEFGX0lORVQ6CisJCUNBUlBfTE9HKCIlczogJXM6ICVoaHUuJWho dS4laGh1LiVoaHVcbiIsCisJCQkgU0MySUZQKHNjKS0+aWZfeG5hbWUsIGV2ZW50LAorCQkJ IGNwLT5jcF9zYS5zYV9kYXRhWzBdLCBjcC0+Y3Bfc2Euc2FfZGF0YVsxXSwKKwkJCSBjcC0+ Y3Bfc2Euc2FfZGF0YVsyXSwgY3AtPmNwX3NhLnNhX2RhdGFbM10pOworCQlicmVhazsKKyNl bmRpZgorCSAgICBkZWZhdWx0OgorCQlDQVJQX0RFQlVHKCIlczogY2FycF9pcGxiX2xvZ3Bl ZXI6IHVua25vd24gYWRkcmVzcyBmYW1pbHkgJWlcbiIsCisJCQkgICBTQzJJRlAoc2MpLT5p Zl94bmFtZSwgY3AtPmNwX3NhLnNhX2ZhbWlseSk7CisJCXJldHVybjsKKwl9Cit9CisKK3N0 YXRpYyBpbnQKK2NhcnBfaXBsYl9tZW1jbXAgKHVuc2lnbmVkIGNoYXIgKmEsIHVuc2lnbmVk IGNoYXIgKmIsIGludCBsZW4pCit7CisJd2hpbGUgKGxlbikgeworCQlpZiAoKmEgPiAqYikg cmV0dXJuIDE7CisJCWlmICgqYSA8ICpiKSByZXR1cm4gLTE7CisJCSsrYTsKKwkJKytiOwor CQktLWxlbjsKKwl9CisJcmV0dXJuIDA7Cit9CisKK3N0YXRpYyB2b2lkCitjYXJwX2lwbGJf YWRkcGVlcihzdHJ1Y3QgY2FycF9zb2Z0YyAqc2MsIGludCBhZiwgdm9pZCAqYWRkcmVzcykK K3sKKwlzdHJ1Y3QgY2FycF9wZWVyX2xpc3QgKnBlZXJzOworCXN0cnVjdCBjYXJwX3BlZXIg KmNwLCAqY3BfdGVtcDsKKwlpbnQgaWFfbGVuLCBub3Rmb3VuZCA9IDE7CisJc3RydWN0IG10 eCAqbXV0ZXg7CisKKwlpZiAoIWNhcnBfaXBsYl9lbmFibGUpCisJCXJldHVybjsKKworCXN3 aXRjaCAoYWYpIHsKKyNpZmRlZiBJTkVUNgorCSAgICBjYXNlIEFGX0lORVQ2OgorCQlpYV9s ZW4gPSAxNjsKKwkJcGVlcnMgPSAmc2MtPnNjX3BlZXJzNjsKKwkJbXV0ZXggPSAmc2MtPnNj X3BlZXJzNl9tdHg7CisJCWJyZWFrOworI2VuZGlmCisjaWZkZWYgSU5FVAorCSAgICBjYXNl IEFGX0lORVQ6CisJCWlhX2xlbiA9IDQ7CisJCXBlZXJzID0gJnNjLT5zY19wZWVyczsKKwkJ bXV0ZXggPSAmc2MtPnNjX3BlZXJzX210eDsKKwkJYnJlYWs7CisjZW5kaWYKKwkgICAgZGVm YXVsdDoKKwkJQ0FSUF9ERUJVRygiJXM6IGNhcnBfaXBsYl9hZGRwZWVyOiB1bmtub3duIGFk ZHJlc3MgZmFtaWx5ICVpXG4iLAorCQkJICAgU0MySUZQKHNjKS0+aWZfeG5hbWUsIGFmKTsK KwkJcmV0dXJuOworCX0KKworCW10eF9sb2NrKG11dGV4KTsKKwlUQUlMUV9GT1JFQUNIKGNw X3RlbXAsIHBlZXJzLCBjcF9saXN0KSB7CisJCWlmIChjcF90ZW1wLT5jcF9zYS5zYV9mYW1p bHkgIT0gYWYpCisJCQljb250aW51ZTsKKwkJLyogWFhYOiBtZW1jbXAvYmNtcCBkb2Vzbid0 IHdvcmsgKi8KKwkJbm90Zm91bmQgPSBjYXJwX2lwbGJfbWVtY21wKGNwX3RlbXAtPmNwX3Nh LnNhX2RhdGEsIGFkZHJlc3MsIGlhX2xlbik7CisJCWlmIChub3Rmb3VuZCA+PSAwKQorCQkJ YnJlYWs7CisJfQorCisJaWYgKG5vdGZvdW5kKSB7CisJCU1BTExPQyhjcCwgc3RydWN0IGNh cnBfcGVlciAqLCBzaXplb2YoKmNwKSwKKwkJICAgICAgIE1fQ0FSUCwgTV9XQUlUT0t8TV9a RVJPKTsKKwkJaWYgKCFjcCkgeworCQkJQ0FSUF9MT0coIiVzOiBjYXJwX2lwbGJfYWRkcGVl cjogb3V0IG9mIG1lbW9yeSEiLAorCQkJCSBTQzJJRlAoc2MpLT5pZl94bmFtZSk7CisJCQly ZXR1cm47CisJCX0KKwkJbWVtY3B5KCZjcC0+Y3Bfc2Euc2FfZGF0YSwgYWRkcmVzcywgaWFf bGVuKTsKKwkJY3AtPmNwX3NhLnNhX2ZhbWlseSA9IGFmOworCQlnZXRtaWNyb3RpbWUoJmNw LT5jcF90dik7CisKKwkJY2FycF9pcGxiX2xvZ3BlZXIoc2MsIGNwLCAibmV3IHBlZXIiKTsK KworCQlpZiAoY3BfdGVtcCkKKwkJCVRBSUxRX0lOU0VSVF9CRUZPUkUoY3BfdGVtcCwgY3As IGNwX2xpc3QpOworCQllbHNlCisJCQlUQUlMUV9JTlNFUlRfVEFJTChwZWVycywgY3AsIGNw X2xpc3QpOworCX0KKwllbHNlCisJCWdldG1pY3JvdGltZSgmY3BfdGVtcC0+Y3BfdHYpOwor CisJbXR4X3VubG9jayhtdXRleCk7Cit9CisKK3N0YXRpYyB2b2lkCitjYXJwX2lwbGJfc2Vu ZF9oZWxvKHN0cnVjdCBjYXJwX3NvZnRjICpzYykKK3sKKwlzdHJ1Y3QgY2FycF9oZWFkZXIg Y2g7CisJc3RydWN0IGNhcnBfaGVhZGVyICpjaF9wdHI7CisJc3RydWN0IG1idWYgKm07CisJ c3RydWN0IG1fdGFnICptdGFnOworCXN0cnVjdCBpZm5ldCAqaWZwID0gU0MySUZQKHNjKTsK KwlpbnQgbGVuOworCisJaWYgKCFjYXJwX2lwbGJfZW5hYmxlKQorCQlyZXR1cm47CisKKwlj aC5jYXJwX3ZlcnNpb24gPSBDQVJQX1ZFUlNJT047CisJY2guY2FycF90eXBlID0gQ0FSUF9I RUxPOworCWNoLmNhcnBfdmhpZCA9IHNjLT5zY192aGlkOworCWNoLmNhcnBfYWR2YmFzZSA9 IDA7CisJY2guY2FycF9hZHZza2V3ID0gMDsKKwljaC5jYXJwX2F1dGhsZW4gPSA3OwkvKiBY WFggREVGSU5FICovCisJY2guY2FycF9wYWQxID0gMDsJLyogbXVzdCBiZSB6ZXJvICovCisJ Y2guY2FycF9ja3N1bSA9IDA7CisJY2guY2FycF9jb3VudGVyWzBdID0gMDsKKwljaC5jYXJw X2NvdW50ZXJbMV0gPSAwOworCisJY2FycF9obWFjX2dlbmVyYXRlKHNjLCBjaC5jYXJwX2Nv dW50ZXIsIGNoLmNhcnBfbWQpOworCisjaWZkZWYgSU5FVAorCWlmIChzYy0+c2NfaWEpIHsK KwkJc3RydWN0IGlwICppcDsKKworCQlNR0VUSERSKG0sIE1fRE9OVFdBSVQsIE1UX0hFQURF Uik7CisJCWlmIChtID09IE5VTEwpCisJCQlyZXR1cm47CisJCWxlbiA9IHNpemVvZigqaXAp ICsgc2l6ZW9mKGNoKTsKKwkJbS0+bV9wa3RoZHIubGVuID0gbGVuOworCQltLT5tX3BrdGhk ci5yY3ZpZiA9IE5VTEw7CisJCW0tPm1fbGVuID0gbGVuOworCQlNSF9BTElHTihtLCBtLT5t X2xlbik7CisJCW0tPm1fZmxhZ3MgfD0gTV9NQ0FTVDsKKwkJaXAgPSBtdG9kKG0sIHN0cnVj dCBpcCAqKTsKKwkJaXAtPmlwX3YgPSBJUFZFUlNJT047CisJCWlwLT5pcF9obCA9IHNpemVv ZigqaXApID4+IDI7CisJCWlwLT5pcF90b3MgPSBJUFRPU19MT1dERUxBWTsKKwkJaXAtPmlw X2xlbiA9IGxlbjsKKwkJaXAtPmlwX2lkID0gaXBfbmV3aWQoKTsKKwkJaXAtPmlwX29mZiA9 IElQX0RGOworCQlpcC0+aXBfdHRsID0gQ0FSUF9ERkxUVEw7CisJCWlwLT5pcF9wID0gSVBQ Uk9UT19DQVJQOworCQlpcC0+aXBfc3VtID0gMDsKKwkJaXAtPmlwX3NyYy5zX2FkZHIgPSBz Yy0+c2NfaWEtPmlhX2FkZHIuc2luX2FkZHIuc19hZGRyOworCQlpcC0+aXBfZHN0LnNfYWRk ciA9IGh0b25sKElOQUREUl9DQVJQX0dST1VQKTsKKworCQljaF9wdHIgPSAoc3RydWN0IGNh cnBfaGVhZGVyICopKCZpcFsxXSk7CisJCWJjb3B5KCZjaCwgY2hfcHRyLCBzaXplb2YoY2gp KTsKKworCQkvKiBUYWcgcGFja2V0IGZvciBjYXJwX291dHB1dCAqLworCQltdGFnID0gbV90 YWdfZ2V0KFBBQ0tFVF9UQUdfQ0FSUCwgc2l6ZW9mKHN0cnVjdCBpZm5ldCAqKSwgTV9OT1dB SVQpOworCQlpZiAobXRhZyA9PSBOVUxMKSB7CisJCQlDQVJQX0xPRygiJXM6IGNhcnBfaXBs Yl9zZW5kX2hlbG86IG1fdGFnX2dldCBmYWlsZWRcbiIsCisJCQkJIFNDMklGUChzYyktPmlm X3huYW1lKTsKKwkJCW1fZnJlZW0obSk7CisJCQlyZXR1cm47CisJCX0KKwkJYmNvcHkoJmlm cCwgKGNhZGRyX3QpKG10YWcgKyAxKSwgc2l6ZW9mKHN0cnVjdCBpZm5ldCAqKSk7CisJCW1f dGFnX3ByZXBlbmQobSwgbXRhZyk7CisKKwkJbS0+bV9kYXRhICs9IHNpemVvZigqaXApOwor CQljaF9wdHItPmNhcnBfY2tzdW0gPSBjYXJwX2Nrc3VtKG0sIGxlbiAtIHNpemVvZigqaXAp KTsKKwkJbS0+bV9kYXRhIC09IHNpemVvZigqaXApOworCisjaWYgMAorCQlnZXRtaWNyb3Rp bWUoJlNDMklGUChzYyktPmlmX2xhc3RjaGFuZ2UpOworCQlTQzJJRlAoc2MpLT5pZl9vcGFj a2V0cysrOworCQlTQzJJRlAoc2MpLT5pZl9vYnl0ZXMgKz0gbGVuOworCQljYXJwc3RhdHMu Y2FycHNfb3BhY2tldHMrKzsKKyNlbmRpZgorCisJCWlmIChpcF9vdXRwdXQobSwgTlVMTCwg TlVMTCwgSVBfUkFXT1VUUFVULCAmc2MtPnNjX2ltbywgTlVMTCkpCisJCQlDQVJQX0xPRygi JXM6IGNhcnBfaXBsYl9zZW5kX2hlbG86IGlwX291dHB1dCBmYWlsZWRcbiIsCisJCQkJIFND MklGUChzYyktPmlmX3huYW1lKTsKKwl9CisjZW5kaWYgLyogSU5FVCAqLworI2lmZGVmIElO RVQ2CisJaWYgKHNjLT5zY19pYTYpIHsKKwkJc3RydWN0IGlwNl9oZHIgKmlwNjsKKworCQlN R0VUSERSKG0sIE1fRE9OVFdBSVQsIE1UX0hFQURFUik7CisJCWlmIChtID09IE5VTEwpCisJ CQlyZXR1cm47CisJCWxlbiA9IHNpemVvZigqaXA2KSArIHNpemVvZihjaCk7CisJCW0tPm1f cGt0aGRyLmxlbiA9IGxlbjsKKwkJbS0+bV9wa3RoZHIucmN2aWYgPSBOVUxMOworCQltLT5t X2xlbiA9IGxlbjsKKwkJTUhfQUxJR04obSwgbS0+bV9sZW4pOworCQltLT5tX2ZsYWdzIHw9 IE1fTUNBU1Q7CisJCWlwNiA9IG10b2QobSwgc3RydWN0IGlwNl9oZHIgKik7CisJCWJ6ZXJv KGlwNiwgc2l6ZW9mKCppcDYpKTsKKwkJaXA2LT5pcDZfdmZjIHw9IElQVjZfVkVSU0lPTjsK KwkJaXA2LT5pcDZfaGxpbSA9IENBUlBfREZMVFRMOworCQlpcDYtPmlwNl9ueHQgPSBJUFBS T1RPX0NBUlA7CisJCWJjb3B5KCZzYy0+c2NfaWE2LT5pYV9hZGRyLnNpbjZfYWRkciwgJmlw Ni0+aXA2X3NyYywKKwkJICAgIHNpemVvZihzdHJ1Y3QgaW42X2FkZHIpKTsKKwkJLyogc2V0 IHRoZSBtdWx0aWNhc3QgZGVzdGluYXRpb24gKi8KKworCQlpcDYtPmlwNl9kc3QuczZfYWRk cjE2WzBdID0gaHRvbnMoMHhmZjAyKTsKKwkJaXA2LT5pcDZfZHN0LnM2X2FkZHI4WzE1XSA9 IDB4MTI7CisJCWlmIChpbjZfc2V0c2NvcGUoJmlwNi0+aXA2X2RzdCwgc2MtPnNjX2NhcnBk ZXYsIE5VTEwpICE9IDApIHsKKwkJCVNDMklGUChzYyktPmlmX29lcnJvcnMrKzsKKwkJCW1f ZnJlZW0obSk7CisJCQlDQVJQX0xPRygiJXM6IGluNl9zZXRzY29wZSBmYWlsZWRcbiIsIF9f ZnVuY19fKTsKKwkJCXJldHVybjsKKwkJfQorCisJCWNoX3B0ciA9IChzdHJ1Y3QgY2FycF9o ZWFkZXIgKikoJmlwNlsxXSk7CisJCWJjb3B5KCZjaCwgY2hfcHRyLCBzaXplb2YoY2gpKTsK KworCQkvKiBUYWcgcGFja2V0IGZvciBjYXJwX291dHB1dCAqLworCQltdGFnID0gbV90YWdf Z2V0KFBBQ0tFVF9UQUdfQ0FSUCwgc2l6ZW9mKHN0cnVjdCBpZm5ldCAqKSwgTV9OT1dBSVQp OworCQlpZiAobXRhZyA9PSBOVUxMKSB7CisJCQlDQVJQX0xPRygiJXM6IGNhcnBfaXBsYl9z ZW5kX2hlbG86IG1fdGFnX2dldCBmYWlsZWRcbiIsCisJCQkJIFNDMklGUChzYyktPmlmX3hu YW1lKTsKKwkJCW1fZnJlZW0obSk7CisJCQlyZXR1cm47CisJCX0KKwkJYmNvcHkoJmlmcCwg KGNhZGRyX3QpKG10YWcgKyAxKSwgc2l6ZW9mKHN0cnVjdCBpZm5ldCAqKSk7CisJCW1fdGFn X3ByZXBlbmQobSwgbXRhZyk7CisKKwkJbS0+bV9kYXRhICs9IHNpemVvZigqaXA2KTsKKwkJ Y2hfcHRyLT5jYXJwX2Nrc3VtID0gY2FycF9ja3N1bShtLCBsZW4gLSBzaXplb2YoKmlwNikp OworCQltLT5tX2RhdGEgLT0gc2l6ZW9mKCppcDYpOworCisjaWYgMAorCQlnZXRtaWNyb3Rp bWUoJlNDMklGUChzYyktPmlmX2xhc3RjaGFuZ2UpOworCQlTQzJJRlAoc2MpLT5pZl9vcGFj a2V0cysrOworCQlTQzJJRlAoc2MpLT5pZl9vYnl0ZXMgKz0gbGVuOworCQljYXJwc3RhdHMu Y2FycHNfb3BhY2tldHM2Kys7CisjZW5kaWYKKworCQlpZiAoaXA2X291dHB1dChtLCBOVUxM LCBOVUxMLCAwLCAmc2MtPnNjX2ltNm8sIE5VTEwsIE5VTEwpKQorCQkJQ0FSUF9MT0coIiVz OiBjYXJwX2lwbGJfc2VuZF9oZWxvOiBpcDZfb3V0cHV0IGZhaWxlZFxuIiwKKwkJCQkgU0My SUZQKHNjKS0+aWZfeG5hbWUpOworCX0KKyNlbmRpZiAvKiBJTkVUNiAqLworfQorCitzdGF0 aWMgaW50CitjYXJwX2lwbGJfZm9ydXMgKHN0cnVjdCBtYnVmICptX2luLCBzdHJ1Y3QgY2Fy cF9zb2Z0YyAqc2MpCit7CisJc3RydWN0IG1idWYgKm07CisJc3RydWN0IGV0aGVyX2hlYWRl ciAqZWg7CisJaW50IGhvc3RzLCBob3N0OworCWludCBtYXRjaCA9IChzYy0+c2Nfc3RhdGUg PT0gTUFTVEVSKTsKKwl1aW50MzJfdCBhZGRyOworCXN0cnVjdCB0Y3BoZHIgKnRjcDsKKwlz dHJ1Y3QgaW5fY29ubmluZm8gaW5jOworCXN0cnVjdCBzeW5jYWNoZV9oZWFkICpzY2g7Cisj aWZkZWYgSU5FVAorCXN0cnVjdCBpcCAqaXA7CisjZW5kaWYKKyNpZmRlZiBJTkVUNgorCXN0 cnVjdCBpcDZfaGRyICppcDY7CisjZW5kaWYKKworCWlmICghY2FycF9pcGxiX2VuYWJsZSkK KwkJcmV0dXJuIG1hdGNoOworCisJaWYgKG1faW4gPT0gTlVMTCkgeworCQlDQVJQX0xPRygi JXM6IGNhcnBfaXBsYl9mb3J1czogbV9pbiBpcyBudWxsXG4iLAorCQkJIFNDMklGUChzYykt PmlmX3huYW1lKTsKKwkJcmV0dXJuIG1hdGNoOworCX0KKworCWlmICgobSA9IG1fZHVwKG1f aW4sIE1fVFJZV0FJVCkpID09IE5VTEwpIHsKKwkJQ0FSUF9MT0coIiVzOiBjYXJwX2lwbGJf Zm9ydXM6IGR1cCBmYWlsZWRcbiIsCisJCQkgU0MySUZQKHNjKS0+aWZfeG5hbWUpOworCQly ZXR1cm4gbWF0Y2g7CisJfQorCisJaWYgKChtID0gbV9wdWxsdXAobSwgRVRIRVJfSERSX0xF TikpID09IE5VTEwpCisJCWdvdG8gUFVMTFVQX0ZBSUxFRDsKKworCWlmICgoZWggPSBtdG9k KG0sIHN0cnVjdCBldGhlcl9oZWFkZXIgKikpID09IE5VTEwpIHsKKwkJQ0FSUF9MT0coIiVz OiBjYXJwX2lwbGJfZm9ydXM6IG10b2QgZmFpbGVkXG4iLAorCQkJIFNDMklGUChzYyktPmlm X3huYW1lKTsKKwkJZ290byBSRVRVUk47CisJfQorCisJc3dpdGNoIChudG9ocyhlaC0+ZXRo ZXJfdHlwZSkpIHsKKyNpZmRlZiBJTkVUCisJICAgIGNhc2UgRVRIRVJUWVBFX0lQOgorCQlt ID0gbV9wdWxsdXAobSwgRVRIRVJfSERSX0xFTiArIHNpemVvZihzdHJ1Y3QgaXApKTsKKwkJ aWYgKG0gPT0gTlVMTCkKKwkJCWdvdG8gUFVMTFVQX0ZBSUxFRDsKKwkJaXAgPSAoc3RydWN0 IGlwICopKGVoICsgMSk7CisJCWFkZHIgPSBudG9obChpcC0+aXBfc3JjLnNfYWRkcik7CisJ CWhvc3RzID0gc2MtPnNjX2hvc3RzOworCQlob3N0ID0gc2MtPnNjX2hvc3Q7CisJCWlmIChp cC0+aXBfcCAhPSBJUFBST1RPX1RDUCkKKwkJCWJyZWFrOworCQltID0gbV9wdWxsdXAobSwg RVRIRVJfSERSX0xFTiArIChpcC0+aXBfaGwgPDwgMikgKyBzaXplb2Yoc3RydWN0IHRjcGhk cikpOworCQlpZiAobSA9PSBOVUxMKQorCQkJZ290byBQVUxMVVBfRkFJTEVEOworCisJCXRj cCA9IChzdHJ1Y3QgdGNwaGRyICopKChpbnQ4X3QqKSBpcCArIChpcC0+aXBfaGwgPDwgMikp OworCQlpZiAoKHRjcC0+dGhfZmxhZ3MgJiAoVEhfU1lOfFRIX0FDSykpID09IFRIX1NZTikK KwkJCWJyZWFrOworCisJCWluYy5pbmNfaXNpcHY2ID0gMDsKKwkJaW5jLmluY19mcG9ydCA9 IHRjcC0+dGhfc3BvcnQ7CisJCWluYy5pbmNfbHBvcnQgPSB0Y3AtPnRoX2Rwb3J0OworCQlp bmMuaW5jX2ZhZGRyID0gaXAtPmlwX3NyYzsKKwkJaW5jLmluY19sYWRkciA9IGlwLT5pcF9k c3Q7CisJCW1hdGNoID0gKHN5bmNhY2hlX2xvb2t1cCgmaW5jLCAmc2NoKSAhPSBOVUxMKSB8 fAorCQkJKGluX3BjYmxvb2t1cF9oYXNoKCZ0Y2JpbmZvLAorCQkJCQkgICBpcC0+aXBfc3Jj LCB0Y3AtPnRoX3Nwb3J0LAorCQkJCQkgICBpcC0+aXBfZHN0LCB0Y3AtPnRoX2Rwb3J0LAor CQkJCQkgICAwLCBtLT5tX3BrdGhkci5yY3ZpZikpOworCQlnb3RvIFJFVFVSTjsKKyNlbmRp ZgorI2lmZGVmIElORVQ2CisJICAgIGNhc2UgRVRIRVJUWVBFX0lQVjY6CisJCW0gPSBtX3B1 bGx1cChtLCBFVEhFUl9IRFJfTEVOICsgc2l6ZW9mKHN0cnVjdCBpcDZfaGRyKSk7CisJCWlm IChtID09IE5VTEwpCisJCQlnb3RvIFBVTExVUF9GQUlMRUQ7CisJCWlwNiA9IChzdHJ1Y3Qg aXA2X2hkciAqKShlaCArIDEpOworCQlhZGRyID0gbnRvaGwoaXA2LT5pcDZfc3JjLnM2X2Fk ZHIzMlszXSk7CisJCWhvc3RzID0gc2MtPnNjX2hvc3RzNjsKKwkJaG9zdCA9IHNjLT5zY19o b3N0NjsKKwkJaWYgKGlwNi0+aXA2X254dCAhPSBJUFBST1RPX1RDUCkKKwkJCWJyZWFrOwor CQltID0gbV9wdWxsdXAobSwgRVRIRVJfSERSX0xFTiArIHNpemVvZihzdHJ1Y3QgaXA2X2hk cikgKworCQkJICAgICBzaXplb2Yoc3RydWN0IHRjcGhkcikpOworCQlpZiAobSA9PSBOVUxM KQorCQkJZ290byBQVUxMVVBfRkFJTEVEOworCisJCXRjcCA9IChzdHJ1Y3QgdGNwaGRyICop KChpbnQ4X3QqKSBpcDYgKyBzaXplb2Yoc3RydWN0IGlwNl9oZHIpKTsKKwkJaWYgKCh0Y3At PnRoX2ZsYWdzICYgKFRIX1NZTnxUSF9BQ0spKSA9PSBUSF9TWU4pCisJCQlicmVhazsKKwor CQlpbmMuaW5jX2lzaXB2NiA9IDE7CisJCWluYy5pbmNfZnBvcnQgPSB0Y3AtPnRoX3Nwb3J0 OworCQlpbmMuaW5jX2xwb3J0ID0gdGNwLT50aF9kcG9ydDsKKwkJaW5jLmluYzZfZmFkZHIg PSBpcDYtPmlwNl9zcmM7CisJCWluYy5pbmM2X2xhZGRyID0gaXA2LT5pcDZfZHN0OworCQlt YXRjaCA9IChzeW5jYWNoZV9sb29rdXAoJmluYywgJnNjaCkgIT0gTlVMTCkgfHwKKwkJCShp bjZfcGNibG9va3VwX2hhc2goJnRjYmluZm8sCisJCQkJCSAgICAmaXA2LT5pcDZfc3JjLCB0 Y3AtPnRoX3Nwb3J0LAorCQkJCQkgICAgJmlwNi0+aXA2X2RzdCwgdGNwLT50aF9kcG9ydCwK KwkJCQkJICAgIDAsIG0tPm1fcGt0aGRyLnJjdmlmKSk7CisJCWdvdG8gUkVUVVJOOworI2Vu ZGlmCisJICAgIGRlZmF1bHQ6CisJCWdvdG8gUkVUVVJOOworCX0KKworCWlmICgoaG9zdHMg PD0gMCkgfHwKKwkgICAgKGhvc3QgPCAwKSB8fAorCSAgICAoaG9zdCA+PSBob3N0cykpCisJ CWdvdG8gUkVUVVJOOworCisJaWYgKChjYXJwX2lwbGJfbWFzayA8IDApIHx8IChjYXJwX2lw bGJfbWFzayA+IDMyKSkgeworCQlDQVJQX0xPRygiJXM6IGFkanVzdGluZyBpcF9iYWxhbmNl X21hc2sgJWkgLT4gMzJcbiIsCisJCQkgU0MySUZQKHNjKS0+aWZfeG5hbWUsIGNhcnBfaXBs Yl9tYXNrKTsKKwkJY2FycF9pcGxiX21hc2sgPSAzMjsKKwl9CisKKwlhZGRyID4+PSAzMiAt IGNhcnBfaXBsYl9tYXNrOworCWFkZHIgJT0gaG9zdHM7CisJbWF0Y2ggPSAoYWRkciA9PSBo b3N0KTsKKworCWdvdG8gUkVUVVJOOworCitQVUxMVVBfRkFJTEVEOgorCUNBUlBfTE9HKCIl czogY2FycF9pcGxiX2ZvcnVzOiBwdWxsdXAgZmFpbGVkXG4iLCBTQzJJRlAoc2MpLT5pZl94 bmFtZSk7CitSRVRVUk46CisJbV9mcmVlbShtKTsKKwlyZXR1cm4gbWF0Y2g7Cit9CisKK3N0 YXRpYyB2b2lkCitjYXJwX2lwbGJfY2xlYW51cDIoc3RydWN0IGNhcnBfc29mdGMgKnNjLCBz dHJ1Y3QgY2FycF9wZWVyX2xpc3QgKnBlZXJzLAorCQkgICB2b2lkICphZGRyZXNzLCBpbnQg KnNjX2hvc3RzLCBpbnQgKnNjX2hvc3QsCisJCSAgIGludCBpYV9sZW4sIGludCBpcF92ZXIs IHN0cnVjdCBtdHggKm11dGV4KQoreworCXN0cnVjdCBjYXJwX3BlZXIgKmNwLCAqY3BfdGVt cDsKKwlzdHJ1Y3QgdGltZXZhbCB0djsKKwlpbnQgaG9zdHMgPSAwLCBob3N0ID0gLTE7CisK KwlnZXRtaWNyb3RpbWUoJnR2KTsKKworCW10eF9sb2NrKG11dGV4KTsKKwlUQUlMUV9GT1JF QUNIX1NBRkUoY3AsIHBlZXJzLCBjcF9saXN0LCBjcF90ZW1wKSB7CisJCWlmIChjcC0+Y3Bf dHYudHZfc2VjICsgc2MtPnNjX2FkdmJhc2UgKiAzIDwgdHYudHZfc2VjKSB7CisJCQljYXJw X2lwbGJfbG9ncGVlcihzYywgY3AsICJ2YW5pc2hlZCBwZWVyIik7CisJCQlUQUlMUV9SRU1P VkUocGVlcnMsIGNwLCBjcF9saXN0KTsKKwkJfQorCQllbHNlIHsKKwkJCWlmICghYmNtcChh ZGRyZXNzLCBjcC0+Y3Bfc2Euc2FfZGF0YSwgaWFfbGVuKSkKKwkJCQlob3N0ID0gaG9zdHM7 CisJCQkrK2hvc3RzOworCQl9CisJfQorCWlmIChob3N0cyAhPSAqc2NfaG9zdHMpIHsKKwkJ Q0FSUF9MT0coIiVzOiBJUHYlaSBob3N0cyAlaSAtPiAlaVxuIiwKKwkJCSAgIFNDMklGUChz YyktPmlmX3huYW1lLCBpcF92ZXIsICpzY19ob3N0cywgaG9zdHMpOworCQkqc2NfaG9zdHMg PSBob3N0czsKKwl9CisJaWYgKGhvc3QgIT0gKnNjX2hvc3QpIHsKKwkJQ0FSUF9MT0coIiVz OiBJUHYlaSBob3N0ICVpIC0+ICVpXG4iLAorCQkJICAgU0MySUZQKHNjKS0+aWZfeG5hbWUs IGlwX3ZlciwgKnNjX2hvc3QsIGhvc3QpOworCQkgKnNjX2hvc3QgPSBob3N0OworCX0KKwlt dHhfdW5sb2NrKG11dGV4KTsKK30KKworc3RhdGljIHZvaWQKK2NhcnBfaXBsYl9jbGVhbnVw KHZvaWQgKnYpCit7CisJc3RydWN0IGNhcnBfc29mdGMgKnNjID0gKHN0cnVjdCBjYXJwX3Nv ZnRjKikgdjsKKwl2b2lkICphZGRyZXNzOworCXN0cnVjdCB0aW1ldmFsIHR2OworCisjaWZk ZWYgSU5FVAorCWlmIChzYy0+c2NfaWEpIHsKKwkJYWRkcmVzcyA9ICZzYy0+c2NfaWEtPmlh X2FkZHIuc2luX2FkZHI7CisJCWNhcnBfaXBsYl9hZGRwZWVyKHNjLCBBRl9JTkVULCBhZGRy ZXNzKTsKKwkJY2FycF9pcGxiX2NsZWFudXAyKHNjLCAmc2MtPnNjX3BlZXJzLCBhZGRyZXNz LCAmc2MtPnNjX2hvc3RzLAorCQkJCSAgICZzYy0+c2NfaG9zdCwgNCwgNCwgJnNjLT5zY19w ZWVyc19tdHgpOworCX0KKyNlbmRpZgorI2lmZGVmIElORVQ2CisJaWYgKHNjLT5zY19pYTYp IHsKKwkJYWRkcmVzcyA9ICZzYy0+c2NfaWE2LT5pYV9hZGRyLnNpbjZfYWRkcjsKKwkJY2Fy cF9pcGxiX2FkZHBlZXIoc2MsIEFGX0lORVQ2LCBhZGRyZXNzKTsKKwkJY2FycF9pcGxiX2Ns ZWFudXAyKHNjLCAmc2MtPnNjX3BlZXJzNiwgYWRkcmVzcywgJnNjLT5zY19ob3N0czYsCisJ CQkJICAgJnNjLT5zY19ob3N0NiwgNiwgMTYsICZzYy0+c2NfcGVlcnM2X210eCk7CisJfQor I2VuZGlmCisKKwl0di50dl9zZWMgPSBzYy0+c2NfYWR2YmFzZTsKKwl0di50dl91c2VjID0g MDsKKwljYWxsb3V0X3Jlc2V0KCZzYy0+c2NfcGVlcnNfdG1vLCB0dnRvaHooJnR2KSwgY2Fy cF9pcGxiX2NsZWFudXAsIHNjKTsKK30KKy8qIGlwbGIgKi8KKwogLyoKICAqIHByb2Nlc3Mg aW5wdXQgcGFja2V0LgogICogd2UgaGF2ZSByZWFycmFuZ2VkIGNoZWNrcyBvcmRlciBjb21w YXJlZCB0byB0aGUgcmZjLApAQCAtNjg5LDYgKzEyMjUsMzQgQEAKIAkJcmV0dXJuOwogCX0K IAorCS8qIGlwbGI6IGNoZWNrIGhlbG8gKi8KKwlpZiAoY2gtPmNhcnBfdHlwZSA9PSBDQVJQ X0hFTE8pIHsKKwkJdm9pZCAqdjsKKwkJc3dpdGNoIChhZikgeworI2lmZGVmIElORVQ2CisJ CSAgICBjYXNlIEFGX0lORVQ2OgorCQkJdiA9IG10b2QobSwgc3RydWN0IGlwNl9oZHIgKik7 CisJCQljYXJwX2lwbGJfYWRkcGVlcihzYywgYWYsCisJCQkJCSAgJigoc3RydWN0IGlwNl9o ZHIqKSB2KS0+aXA2X3NyYyk7CisJCQlicmVhazsKKyNlbmRpZgorI2lmZGVmIElORVQKKwkJ ICAgIGNhc2UgQUZfSU5FVDoKKwkJCXYgPSBtdG9kKG0sIHN0cnVjdCBpcCAqKTsKKwkJCWNh cnBfaXBsYl9hZGRwZWVyKHNjLCBhZiwgJigoc3RydWN0IGlwKikgdiktPmlwX3NyYyk7CisJ CQlicmVhazsKKyNlbmRpZgorCQkgICAgZGVmYXVsdDoKKwkJCUNBUlBfTE9HKCIlcywgY2Fy cF9pbnB1dF9jOiB1bmtub3duIGFkZHJlc3MgZmFtaWx5ICVpXG4iLAorCQkJCSBTQzJJRlAo c2MpLT5pZl94bmFtZSwgYWYpOworCQkJYnJlYWs7CisJCX0KKworCQlDQVJQX1VOTE9DSyhp ZnAtPmlmX2NhcnApOworCQltX2ZyZWVtKG0pOworCQlyZXR1cm47CisJfQorCiAJdG1wX2Nv dW50ZXIgPSBudG9obChjaC0+Y2FycF9jb3VudGVyWzBdKTsKIAl0bXBfY291bnRlciA9IHRt cF9jb3VudGVyPDwzMjsKIAl0bXBfY291bnRlciArPSBudG9obChjaC0+Y2FycF9jb3VudGVy WzFdKTsKQEAgLTgzOSw2ICsxNDAzLDggQEAKIAogCUNBUlBfU0NMT0NLX0FTU0VSVChzYyk7 CiAKKwljYXJwX2lwbGJfc2VuZF9oZWxvKHNjKTsKKwogCS8qIGJvdyBvdXQgaWYgd2UndmUg bG9zdCBvdXIgVVBuZXNzIG9yIFJVTk5JTkd1aW5lc3MgKi8KIAlpZiAoISgoU0MySUZQKHNj KS0+aWZfZmxhZ3MgJiBJRkZfVVApICYmCiAJICAgIChTQzJJRlAoc2MpLT5pZl9kcnZfZmxh Z3MgJiBJRkZfRFJWX1JVTk5JTkcpKSkgewpAQCAtMTIyNCw3ICsxNzkwLDcgQEAKICNlbmRp ZgogCiBzdHJ1Y3QgaWZuZXQgKgotY2FycF9mb3J1cyh2b2lkICp2LCB2b2lkICpkaG9zdCkK K2NhcnBfZm9ydXModm9pZCAqdiwgdm9pZCAqZGhvc3QsIHN0cnVjdCBtYnVmICptKQogewog CXN0cnVjdCBjYXJwX2lmICpjaWYgPSB2OwogCXN0cnVjdCBjYXJwX3NvZnRjICp2aDsKQEAg LTEyMzcsNyArMTgwMyw4IEBACiAJVEFJTFFfRk9SRUFDSCh2aCwgJmNpZi0+dmhpZl92cnMs IHNjX2xpc3QpCiAJCWlmICgoU0MySUZQKHZoKS0+aWZfZmxhZ3MgJiBJRkZfVVApICYmCiAJ CSAgICAoU0MySUZQKHZoKS0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HKSAmJgot CQkgICAgdmgtPnNjX3N0YXRlID09IE1BU1RFUiAmJgorCQkgICAgLy8gKHZoLT5zY19zdGF0 ZSA9PSBNQVNURVIpICYmCisJCSAgICBjYXJwX2lwbGJfZm9ydXMobSwgdmgpICYmCiAJCSAg ICAhYmNtcChkaG9zdCwgSUZQMkVOQUREUih2aC0+c2NfaWZwKSwgRVRIRVJfQUREUl9MRU4p KSB7CiAJCSAgICAJQ0FSUF9VTkxPQ0soY2lmKTsKIAkJCXJldHVybiAoU0MySUZQKHZoKSk7 CkBAIC0xMzUzLDYgKzE5MjAsOSBAQAogCQkJCSAgICBjYXJwX21hc3Rlcl9kb3duLCBzYyk7 CiAJCQlicmVhazsKIAkJfQorCisJCWNhcnBfaXBsYl9zZW5kX2hlbG8oc2MpOworCiAJCWJy ZWFrOwogCWNhc2UgTUFTVEVSOgogCQl0di50dl9zZWMgPSBzYy0+c2NfYWR2YmFzZTsKZGlm ZiAtZHJ1IHN5czAvbmV0aW5ldC9pcF9jYXJwLmggc3lzL25ldGluZXQvaXBfY2FycC5oCi0t LSBzeXMwL25ldGluZXQvaXBfY2FycC5oCTIwMDYtMDgtMTAgMTA6MTA6MTIuMDAwMDAwMDAw ICswMDAwCisrKyBzeXMvbmV0aW5ldC9pcF9jYXJwLmgJMjAwOC0wMS0yMyAyMzoyODowMi4w MDAwMDAwMDAgKzAwMDAKQEAgLTE1Nyw2ICsxNTcsNiBAQAogCQkgICAgIHVfaW50OF90ICoq KTsKIHN0cnVjdCBpZmFkZHIJKmNhcnBfaWFtYXRjaDYodm9pZCAqLCBzdHJ1Y3QgaW42X2Fk ZHIgKik7CiB2b2lkCQkqY2FycF9tYWNtYXRjaDYodm9pZCAqLCBzdHJ1Y3QgbWJ1ZiAqLCBj b25zdCBzdHJ1Y3QgaW42X2FkZHIgKik7Ci1zdHJ1Y3QJaWZuZXQJKmNhcnBfZm9ydXMgKHZv aWQgKiwgdm9pZCAqKTsKK3N0cnVjdAlpZm5ldAkqY2FycF9mb3J1cyAodm9pZCAqLCB2b2lk ICosIHN0cnVjdCBtYnVmICopOwogI2VuZGlmCiAjZW5kaWYgLyogX0lQX0NBUlBfSCAqLwo= --B_3284046509_3507725-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 18:44:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47DC416A474 for ; Thu, 24 Jan 2008 18:44:10 +0000 (UTC) (envelope-from nullpt@gmail.com) Received: from ro-out-1112.google.com (ro-out-1112.google.com [72.14.202.176]) by mx1.freebsd.org (Postfix) with ESMTP id AB6B513C458 for ; Thu, 24 Jan 2008 18:44:09 +0000 (UTC) (envelope-from nullpt@gmail.com) Received: by ro-out-1112.google.com with SMTP id d36so368581roh.13 for ; Thu, 24 Jan 2008 10:44:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=KeHqAVBm/5v6PamMeizUEQA+1QmI9i8b/AryKciBzAw=; b=mPViINlZ7tukEnl1dbSA0HkbJrnps0oQk3Ye7qzF7F+Q1KM4+HKRwSoOVJx0pnt4Ez/f8EJ/dzhzcq2Dkvf3kODC2Ra4bRw2XzWpryIii7UBBInx9QtQ/O8Qu1LPvIRCDRkgrFv7RZv4VtWKgvcBRbHLGdWBzwJQxKrj02o3Azc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=aL88FnkWDVigSYmm9Yy94QCObYgEYFa2WMMjAsXFyPHjuiZSPNRg7WeYWsStYNLtTZUdRlX9VUmta7tqxWKNqtkzzQ1one0+5XRteAJVkCMjfKpFUTTDzCvw7pUasNRG158X9rECUKvhi5m1de7/MtTCG6P6smzTYM6qI4Z8Guo= Received: by 10.115.88.1 with SMTP id q1mr1145830wal.98.1201200222029; Thu, 24 Jan 2008 10:43:42 -0800 (PST) Received: by 10.115.60.11 with HTTP; Thu, 24 Jan 2008 10:43:41 -0800 (PST) Message-ID: <755cb9fc0801241043k3b39b585keea0082988c2d0db@mail.gmail.com> Date: Thu, 24 Jan 2008 18:43:41 +0000 From: "Alexandre Vieira" To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, freebsd-pf@freebsd.org In-Reply-To: <755cb9fc0801151358k35cdd267x7500767925e5f3cc@mail.gmail.com> MIME-Version: 1.0 References: <755cb9fc0801151129h6e519557g7ea33e4190196fed@mail.gmail.com> <478D1694.8010906@FreeBSD.org> <200801151529.32312.brad@comstyle.com> <755cb9fc0801151358k35cdd267x7500767925e5f3cc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Relayd (former hoststated) status for freebsd 7.0RC1 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, 24 Jan 2008 18:44:10 -0000 On Jan 15, 2008 9:58 PM, Alexandre Vieira wrote: > > > On Jan 15, 2008 8:29 PM, Brad wrote: > > > On Tuesday 15 January 2008 15:24:52 Bruce M. Simpson wrote: > > > Alexandre Vieira wrote: > > > > Hello all, > > > > > > > > I remember that there was a port (net/hoststated) where I could > > install > > > > hoststated to use with PF. Anyone can shed a light on what is the > > status of > > > > this software implementation on 7.0? > > > > > > > > > > Perhaps ports/net/ifstated is the answer? > > > > > > BMS > > > > ifstated and relayd (used to be hoststated) are for totally different > > purposes. > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > _______________________________________________ > > 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" > > > > Hi, I meant hostated aka hoststated aka relayd. It's in Obsd base system > and had there was a port for freebsd not long ago. > > I've found the old port structure: > http://people.freebsd.org/~flz/local/ports/hoststated/which stands for ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/flz/hoststated/hoststated-20070131.tgz > . > > Many changes were commited since 07/01/31: http://kho.bonghongxanh.vn/pub/.disk0/ftp.openbsd.org/pub/OpenBSD/cvs/src/usr.sbin/relayd/Makefile,v > > > Added flz@ to the loop. > TIA for any effort to get this working. > > Kind Regards > > > > -- > Alexandre Vieira - nullpt@gmail.com > FYI http://www.freshports.org/net/relayd/ kudos to kuriyama@ -- Alexandre Vieira - nullpt@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 19:19:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE2CA16A420 for ; Thu, 24 Jan 2008 19:19:52 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 58A1413C447 for ; Thu, 24 Jan 2008 19:19:52 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so64116nfb.33 for ; Thu, 24 Jan 2008 11:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=IDPiInw1ea6rKnPbQAPNpbPM5EW4MxB3UyjkMfXYCcw=; b=Yw7bFgwXzEBZcIbwKDCj2Zk8DsudgFCwNUtC4lD4Cad1Olpk55Ki9pe+dELh3iDk5a/QZqsGct/kpwOC2FL5wf4z9zHp0ulGKmAxJ18G4ZmfK5fHA/TrlGhCpe5tIkZpN4k24SxrKA90KlIhAHOc7ETvs0uwFt50ibfgWDzgf4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OtybMKyDaDV63EWBsdt+nZ/uhlgIPAfOXsz1NM3UFPMusMTC4Rbed1fnk0ScGH1hJLMiswGZKvLfcW9VKdSVvslWooavt+iy5voXcLH2gwXOcjyslA7uB+YAzwOTaIJ7KcgJO5mdNqG0zkLVN2sqNW9hkjWF4I2Q+AmrOmzruxc= Received: by 10.78.136.9 with SMTP id j9mr1464564hud.70.1201200725194; Thu, 24 Jan 2008 10:52:05 -0800 (PST) Received: by 10.78.166.13 with HTTP; Thu, 24 Jan 2008 10:52:05 -0800 (PST) Message-ID: Date: Thu, 24 Jan 2008 13:52:05 -0500 From: "Scott Ullrich" To: "Alexandre Vieira" In-Reply-To: <755cb9fc0801241043k3b39b585keea0082988c2d0db@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <755cb9fc0801151129h6e519557g7ea33e4190196fed@mail.gmail.com> <478D1694.8010906@FreeBSD.org> <200801151529.32312.brad@comstyle.com> <755cb9fc0801151358k35cdd267x7500767925e5f3cc@mail.gmail.com> <755cb9fc0801241043k3b39b585keea0082988c2d0db@mail.gmail.com> Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Relayd (former hoststated) status for freebsd 7.0RC1 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, 24 Jan 2008 19:19:52 -0000 On 1/24/08, Alexandre Vieira wrote: > FYI > > http://www.freshports.org/net/relayd/ > > kudos to kuriyama@ > > -- > Alexandre Vieira - nullpt@gmail.com Yay! Thanks to everyone involved in bringing this over. I was about to start porting this and you just saved me a lot of time :) Scott From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 21:11:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2751F16A419 for ; Thu, 24 Jan 2008 21:11:19 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.235]) by mx1.freebsd.org (Postfix) with ESMTP id B19BE13C4EF for ; Thu, 24 Jan 2008 21:11:18 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so294097nzf.13 for ; Thu, 24 Jan 2008 13:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=jMmTsvbz+ZZKgK7HgbP8kTrJHE1aYzrdyVXI7wsMEQg=; b=fZIq1ySfwb9hwqojtlv7okocbiJQCzBZ7J+1afQL0RSDMXxa86jGOGIcMh/ssEoU5GH3HYpRl9hFw5j/xjwDLE3hlj/D9k3MMXvhpHMycnU14q8xxgacIvxle3CVCcOcwZEW/3Nee61Wye+UHZhBrujQJrmK7hw9bb/cvX9mVf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iW9FTC39HkJE8O0z7DFBkGqXAKZgQtm9OOV5RfEvvbJTUnbfzT4k0PfJ7gLQfc6VQYQqfvQDIou87Cy3MDWKDowkR4tPXm0JSlktE9LnBJNLzn0m9oTSIBh5B0Gh3xOnWisYU4fuK8SFXrmJPHAkpiC3gp82Ba0pidtIXr6OaiI= Received: by 10.115.74.1 with SMTP id b1mr1320229wal.93.1201209076301; Thu, 24 Jan 2008 13:11:16 -0800 (PST) Received: by 10.114.255.16 with HTTP; Thu, 24 Jan 2008 13:11:16 -0800 (PST) Message-ID: Date: Thu, 24 Jan 2008 13:11:16 -0800 From: "Kip Macy" To: "Andre Oppermann" In-Reply-To: <47986F4D.6070208@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> <47986F4D.6070208@freebsd.org> Cc: Mike Silbersack , kmacy@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, src-committers@freebsd.org, freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 24 Jan 2008 21:11:19 -0000 Whatever, just run all future changes by silby. On Jan 24, 2008 2:58 AM, Andre Oppermann wrote: > Kip Macy wrote: > > Did you talk to the original submitter? Note that FreeBSD's TCP stack > > is for use in servers and is not intending as a validating TCP stack. > > If you would like it to serve as such you would better served by > > tracking down the ANVL tests that FreeBSD fails. Also note that there > > is no MUST in the following sentence: > > > > > > "For simplicity and symmetry, we specify that > > timestamps always be sent and echoed in both directions." > > > > So it is clearly open to interpretation. > > No, it is not. RFC1323 was written in 1992 before RFCs contained the > boiler plate definition of MUST, SHOULD, MAY and so on. I, at least > as a non-native English speaker, find the sentence perfectly clear > and without any doubt. The IETF TCPM working group comes to the > same conclusion. And I suppose many native English speakers too. > Despite that arguing over whether "always" lacks a "MUST" to make > it really always always and never not you cited the wrong part of > RFC1323 as reason to completely remove the check. That's what I'm > complaining about. Everyone in FreeBSD, including you and me, should > at least provide the correct citation and rationale for any code > change irrespective of the eventual merit of the change itself which > is a separate issue. > > -- > Andre > From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 01:07:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2967616A419 for ; Fri, 25 Jan 2008 01:07:59 +0000 (UTC) (envelope-from andrew.pogrebennyk@portaone.com) Received: from bugor.portaone.com (bugor.portaone.com [65.61.203.147]) by mx1.freebsd.org (Postfix) with ESMTP id 11CBC13C442 for ; Fri, 25 Jan 2008 01:07:58 +0000 (UTC) (envelope-from andrew.pogrebennyk@portaone.com) Received: from abilitily-barricade.volia.net ([77.123.128.59] helo=[192.168.178.14]) by bugor.portaone.com (8.11.3/8.11.3) with ESMTP id 1JICl9-000Crr-LF for freebsd-net@freebsd.org; Thu, 24 Jan 2008 16:49:31 -0800 Message-ID: <47993215.1010203@portaone.com> Date: Fri, 25 Jan 2008 02:49:25 +0200 From: Andrew Pogrebennyk User-Agent: Thunderbird 2.0.0.9 (X11/20071212) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: pptp question: managing routes on windows client connected to VPN 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, 25 Jan 2008 01:07:59 -0000 Hi, I am using poptop-1.3.4 on FreeBSD 6.1. Right now when a windows client connects to VPN, it sets its end-point address as default gateway, that means all traffic goes through us. Is there some way to make windows create a specific route, instead of default route? Maybe it's only possible to get it to work only with the end-point tunnel address? If the above can't be done and we have to stick to default route, can we bandwidth-limit or clock certain traffic? I am not quite sure as to what interface firewall rules are to be applied. It may be a little OT, but I posted the question in poptop-server mailing list first and did not get any replies there... Thanks in advance. -- Sincerely, Andrew Pogrebennyk From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 04:38:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3831716A46E; Fri, 25 Jan 2008 04:38:31 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 947CD13C4DB; Fri, 25 Jan 2008 04:38:30 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id m0P4cOnU060958; Fri, 25 Jan 2008 07:38:28 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Fri, 25 Jan 2008 07:38:24 +0300 (MSK) From: Maxim Konovalov To: Andre Oppermann In-Reply-To: <20080124171957.N15031@mp2.macomnet.net> Message-ID: <20080125073623.F15031@mp2.macomnet.net> References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> <20080124005006.D93697@odysseus.silby.com> <47986F27.10401@freebsd.org> <20080124145713.K15031@mp2.macomnet.net> <47988A2A.5010506@freebsd.org> <20080124164704.X15031@mp2.macomnet.net> <47989E3C.4030700@freebsd.org> <20080124171957.N15031@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 25 Jan 2008 04:38:31 -0000 On Thu, 24 Jan 2008, 17:20+0300, Maxim Konovalov wrote: > > > The latter. Turning rfc1323 off solved the problem. > > > > > > It takes some time to obtain the dump -- I need to downgrade the > > > system. > > > > That is not necessary. A tcpdump from current is fine. > > > OK, later this evening (UTC+3). > http://maxim.int.ru/stuff/adsl.dmp.gz 192.168.1.1 -- adsl box 192.168.1.250 -- FreeBSD -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 05:36:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAA4716A41A for ; Fri, 25 Jan 2008 05:36:30 +0000 (UTC) (envelope-from pyunyh@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 9ED8613C448 for ; Fri, 25 Jan 2008 05:36:30 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so852460waf.3 for ; Thu, 24 Jan 2008 21:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=1/w2WK+ffvpe/Hbd0DvF/LQZ1VKosdQVSHJLBEYsbCU=; b=kWw08i49kk7I36HjVId0+V9rm9oucGaml1yRHkP8lf2OpBexHjlOCO2bP+LANTEe6GuW/9gHSdX1AAjSjfb1LAe64Wq1hkM1TgbHNRQSokjvP00rChsWcMBR1em2RyvqMTjatCM6JpFNgvi1suWXO0p2TsdVrVu1vum+8iXOZyM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=EP2Wc+EkPVAzdHDdh+0Mlso+cMTyAOQ3OQGhjbGwg5szHxXTnPneL9e2Leeao+9/W8WBcMMXO1bl3LOj3uJxqhrGjMoXxowStT3BEYCi2e51YJkozNwezaYmrDD3x616rpv89YdeNXBYPYmQrIhGSpTBZtMJlgjhiW8/6ZiIbOE= Received: by 10.114.81.1 with SMTP id e1mr1829738wab.11.1201237882946; Thu, 24 Jan 2008 21:11:22 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id m10sm3281644waf.21.2008.01.24.21.11.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Jan 2008 21:11:21 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m0P5B06N023315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jan 2008 14:11:00 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m0P5AxiT023314; Fri, 25 Jan 2008 14:10:59 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 25 Jan 2008 14:10:59 +0900 From: Pyun YongHyeon To: Yousif Hassan Message-ID: <20080125051059.GA22410@cdnetworks.co.kr> References: <1201125022.2106.67.camel@localhost> <20080123222047.GA14264@lor.one-eyed-alien.net> <1201190313.2591.7.camel@localhost> <20080124163634.GA25331@lor.one-eyed-alien.net> <1201198042.19736.5.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <1201198042.19736.5.camel@localhost> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, Brooks Davis , "Bruce M. Simpson" Subject: Re: network interface monitoring? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2008 05:36:30 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 24, 2008 at 01:07:22PM -0500, Yousif Hassan wrote: > On Thu, 2008-01-24 at 10:36 -0600, Brooks Davis wrote: > > On Thu, Jan 24, 2008 at 10:58:33AM -0500, Yousif Hassan wrote: > > > Thank you to all who responded. > > > > > > The suggestion was made to use devd or ifstated. Both sound like > > > excellent tools, but I'm currently being tripped up by a core problem - > > > both tools rely on the kernel to notify userland of link state changes > > > (which makes complete sense!). This is all well and good - but the > > > current issue I'm seeing is that the link state doesn't get updated > > > without running "ifconfig" again - is this by design? A known "issue?" > > > > > > An example: > > > 1. Unplug network cable from bfe0 > > > 2. I run ifconfig > > > 3. I see that interface bfe0's status is "no carrier". Good. > > > 4. I plug the cable into bfe0 > > > 5. Wait... wait... look in /var/log/messages... wait more.. NO STATE > > > CHANGE - the longest I've waited was 2 minutes, which is already too > > > long > > > 6. run "ifconfig" again > > > 7. Link state immediately changes, logs to /var/log/messages, devd > > > scripts run > > > > > > Is this a known behavior? It seems like the link state changes should > > > happen automatically, without something to "trigger" them. Isn't there > > > some kind of poll or interrupt sequence? I'm on 6.3 RC2 (will upgrade > > > to 6.3-RELEASE imminently) but can't imagine this code changed? Does > > > this work differently/better in 7.0? > > > > It's known but not well understood and is a driver bug. > > I was afraid you'd say that. Thanks for the info. > > I found PR kern/109733: [bge] bge link state issues (regression) > which, while referring to a different driver, has some of the same > symptoms. > > In the meantime, I scripted something that calls ifconfig every 30 > seconds or so, redirected its output to null, and put it in the > background and nice'd it; this seems to do the trick, albeit via a > horrid hack. Due to the bug you mentioned, sometimes link state events > queue up, too, and get passed to userland at once, which is no kind of > fun, but the script still works. > Try attached patch. I don't know whether it works or not but it seems that link state was not correctly tracked down by stock bfe(4). The attached patch does the following. - conversion to callout(9) API. - added missing lock in bfe_ifmedia_sts(). - implemented miibus_statchg method to track link state. - use our callout to drive watchdog timer. - restart Tx routine if pending queued packets are present in watchdog handler. - fixed blindly resetting watchdog timer in bfe_txeof(). I guess the above is minimal patch to get correct link state. If I had the hardware I would have rewritten bfe_encap/bfe_newbuf to use bus_dmamap_load_mbuf_sg(9). :( -- Regards, Pyun YongHyeon --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bfe.patch" --- sys/dev/bfe/if_bfe.c.orig 2007-12-08 10:25:08.000000000 +0900 +++ sys/dev/bfe/if_bfe.c 2008-01-25 13:44:34.000000000 +0900 @@ -97,7 +97,7 @@ static void bfe_init (void *); static void bfe_init_locked (void *); static void bfe_stop (struct bfe_softc *); -static void bfe_watchdog (struct ifnet *); +static void bfe_watchdog (struct bfe_softc *); static int bfe_shutdown (device_t); static void bfe_tick (void *); static void bfe_txeof (struct bfe_softc *); @@ -335,6 +335,7 @@ sc = device_get_softc(dev); mtx_init(&sc->bfe_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK, MTX_DEF); + callout_init_mtx(&sc->bfe_stat_co, &sc->bfe_mtx, 0); unit = device_get_unit(dev); sc->bfe_dev = dev; @@ -388,7 +389,6 @@ ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; ifp->if_ioctl = bfe_ioctl; ifp->if_start = bfe_start; - ifp->if_watchdog = bfe_watchdog; ifp->if_init = bfe_init; ifp->if_mtu = ETHERMTU; IFQ_SET_MAXLEN(&ifp->if_snd, BFE_TX_QLEN); @@ -410,7 +410,6 @@ } ether_ifattach(ifp, sc->bfe_enaddr); - callout_handle_init(&sc->bfe_stat_ch); /* * Tell the upper layer(s) we support long frames. @@ -444,13 +443,16 @@ sc = device_get_softc(dev); KASSERT(mtx_initialized(&sc->bfe_mtx), ("bfe mutex not initialized")); - BFE_LOCK(sc); ifp = sc->bfe_ifp; if (device_is_attached(dev)) { + BFE_LOCK(sc); bfe_stop(sc); - ether_ifdetach(ifp); + BFE_UNLOCK(sc); + callout_drain(&sc->bfe_stat_co); + if (ifp != NULL) + ether_ifdetach(ifp); } bfe_chip_reset(sc); @@ -460,7 +462,6 @@ device_delete_child(dev, sc->bfe_miibus); bfe_release_resources(sc); - BFE_UNLOCK(sc); mtx_destroy(&sc->bfe_mtx); return (0); @@ -548,7 +549,42 @@ static void bfe_miibus_statchg(device_t dev) { - return; + struct bfe_softc *sc; + struct mii_data *mii; + u_int32_t val, flow; + + sc = device_get_softc(dev); + mii = device_get_softc(sc->bfe_miibus); + + if ((mii->mii_media_status & IFM_ACTIVE) != 0) { + if (IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) + sc->bfe_link = 1; + } else + sc->bfe_link = 0; + + /* XXX Should stop Rx/Tx engine before chainging MAC. */ + val = CSR_READ_4(sc, BFE_TX_CTRL); + val &= ~BFE_TX_DUPLEX; + if ((IFM_OPTIONS(mii->mii_media_active) & IFM_FDX) != 0) { + val |= BFE_TX_DUPLEX; + flow = 0; +#ifdef notyet + flow = CSR_READ_4(sc, BFE_RXCONF); + flow &= ~BFE_RXCONF_FLOW; + if ((IFM_OPTIONS(sc->sc_mii->mii_media_active) & + IFM_ETH_RXPAUSE) != 0) + flow |= BFE_RXCONF_FLOW; + CSR_WRITE_4(sc, BFE_RXCONF, flow); + /* + * It seems that the hardware Tx pause issues so enable + * only Rx pause. + */ + flow = CSR_READ_4(sc, BFE_MAC_FLOW); + flow &= ~BFE_FLOW_PAUSE_ENAB; + CSR_WRITE_4(sc, BFE_MAC_FLOW, flow); +#endif + } + CSR_WRITE_4(sc, BFE_TX_CTRL, val); } static void @@ -1152,10 +1188,9 @@ sc->bfe_tx_cons = i; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; } - if(sc->bfe_tx_cnt == 0) - ifp->if_timer = 0; - else - ifp->if_timer = 5; + + if (sc->bfe_tx_cnt == 0) + sc->bfe_watchdog_timer = 0; } /* Pass a received packet up the stack */ @@ -1412,7 +1447,8 @@ if (!sc->bfe_link && ifp->if_snd.ifq_len < 10) return; - if (ifp->if_drv_flags & IFF_DRV_OACTIVE) + if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != + IFF_DRV_RUNNING) return; while(sc->bfe_tx_ring[idx].bfe_mbuf == NULL) { @@ -1448,7 +1484,7 @@ /* * Set a timeout in case the chip goes out to lunch. */ - ifp->if_timer = 5; + sc->bfe_watchdog_timer = 5; } } @@ -1465,9 +1501,12 @@ { struct bfe_softc *sc = (struct bfe_softc*)xsc; struct ifnet *ifp = sc->bfe_ifp; + struct mii_data *mii; BFE_LOCK_ASSERT(sc); + mii = device_get_softc(sc->bfe_miibus); + if (ifp->if_drv_flags & IFF_DRV_RUNNING) return; @@ -1488,11 +1527,14 @@ /* Enable interrupts */ CSR_WRITE_4(sc, BFE_IMASK, BFE_IMASK_DEF); - bfe_ifmedia_upd(ifp); + /* Clear link state and change media. */ + sc->bfe_link = 0; + mii_mediachg(mii); + ifp->if_drv_flags |= IFF_DRV_RUNNING; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; - sc->bfe_stat_ch = timeout(bfe_tick, sc, hz); + callout_reset(&sc->bfe_stat_co, hz, bfe_tick, sc); } /* @@ -1503,20 +1545,22 @@ { struct bfe_softc *sc; struct mii_data *mii; + int error; sc = ifp->if_softc; + BFE_LOCK(sc); mii = device_get_softc(sc->bfe_miibus); - sc->bfe_link = 0; if (mii->mii_instance) { struct mii_softc *miisc; for (miisc = LIST_FIRST(&mii->mii_phys); miisc != NULL; miisc = LIST_NEXT(miisc, mii_list)) mii_phy_reset(miisc); } - mii_mediachg(mii); + error = mii_mediachg(mii); + BFE_UNLOCK(sc); - return (0); + return (error); } /* @@ -1528,10 +1572,12 @@ struct bfe_softc *sc = ifp->if_softc; struct mii_data *mii; + BFE_LOCK(sc); mii = device_get_softc(sc->bfe_miibus); mii_pollstat(mii); ifmr->ifm_active = mii->mii_media_active; ifmr->ifm_status = mii->mii_media_status; + BFE_UNLOCK(sc); } static int @@ -1576,22 +1622,25 @@ } static void -bfe_watchdog(struct ifnet *ifp) +bfe_watchdog(struct bfe_softc *sc) { - struct bfe_softc *sc; + struct ifnet *ifp; - sc = ifp->if_softc; + BFE_LOCK_ASSERT(sc); - BFE_LOCK(sc); + if (sc->bfe_watchdog_timer == 0 || --sc->bfe_watchdog_timer) + return; + + ifp = sc->bfe_ifp; printf("bfe%d: watchdog timeout -- resetting\n", sc->bfe_unit); + ifp->if_oerrors++; ifp->if_drv_flags &= ~IFF_DRV_RUNNING; bfe_init_locked(sc); - ifp->if_oerrors++; - - BFE_UNLOCK(sc); + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) + bfe_start_locked(ifp); } static void @@ -1600,27 +1649,13 @@ struct bfe_softc *sc = xsc; struct mii_data *mii; - if (sc == NULL) - return; - - BFE_LOCK(sc); + BFE_LOCK_ASSERT(sc); mii = device_get_softc(sc->bfe_miibus); - - bfe_stats_update(sc); - sc->bfe_stat_ch = timeout(bfe_tick, sc, hz); - - if(sc->bfe_link) { - BFE_UNLOCK(sc); - return; - } - mii_tick(mii); - if (!sc->bfe_link && mii->mii_media_status & IFM_ACTIVE && - IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) - sc->bfe_link++; - - BFE_UNLOCK(sc); + bfe_stats_update(sc); + bfe_watchdog(sc); + callout_reset(&sc->bfe_stat_co, hz, bfe_tick, sc); } /* @@ -1634,13 +1669,13 @@ BFE_LOCK_ASSERT(sc); - untimeout(bfe_tick, sc, sc->bfe_stat_ch); - ifp = sc->bfe_ifp; + ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); + sc->bfe_link = 0; + callout_stop(&sc->bfe_stat_co); + sc->bfe_watchdog_timer = 0; bfe_chip_halt(sc); bfe_tx_ring_free(sc); bfe_rx_ring_free(sc); - - ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); } --- sys/dev/bfe/if_bfereg.h.orig 2006-05-29 03:44:39.000000000 +0900 +++ sys/dev/bfe/if_bfereg.h 2008-01-25 13:36:23.000000000 +0900 @@ -73,6 +73,10 @@ #define BFE_CTRL_LED 0x000000e0 /* Onchip EPHY LED Control */ #define BFE_CTRL_LED_SHIFT 5 +#define BFE_MAC_FLOW 0x000000AC /* MAC Flow Control */ +#define BFE_FLOW_RX_HIWAT 0x000000ff /* Onchip FIFO HI Water Mark */ +#define BFE_FLOW_PAUSE_ENAB 0x00008000 /* Enable Pause Frame Generation */ + #define BFE_RCV_LAZY 0x00000100 /* Lazy Interrupt Control */ #define BFE_LAZY_TO_MASK 0x00ffffff /* Timeout */ #define BFE_LAZY_FC_MASK 0xff000000 /* Frame Count */ @@ -504,7 +508,7 @@ void *bfe_intrhand; struct resource *bfe_irq; struct resource *bfe_res; - struct callout_handle bfe_stat_ch; + struct callout bfe_stat_co; struct bfe_hw_stats bfe_hwstats; struct bfe_desc *bfe_tx_list, *bfe_rx_list; struct bfe_data bfe_tx_ring[BFE_TX_LIST_CNT]; /* XXX */ @@ -517,6 +521,7 @@ u_int32_t bfe_rx_cnt, bfe_rx_prod, bfe_rx_cons; u_int32_t bfe_tx_dma, bfe_rx_dma; u_int32_t bfe_link; + int bfe_watchdog_timer; u_int8_t bfe_phyaddr; /* Address of the card's PHY */ u_int8_t bfe_mdc_port; u_int8_t bfe_unit; /* interface number */ --6c2NcOVqGQ03X4Wi-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 11:53:16 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39B4D16A473 for ; Fri, 25 Jan 2008 11:53:16 +0000 (UTC) (envelope-from admin@aoyama-tower.jp) Received: from concierge.aoyama-tower.jp (122x216x114x100.ap122.ftth.ucom.ne.jp [122.216.114.100]) by mx1.freebsd.org (Postfix) with ESMTP id 1BA3413C45B for ; Fri, 25 Jan 2008 11:53:16 +0000 (UTC) (envelope-from admin@aoyama-tower.jp) Received: by concierge.aoyama-tower.jp (Postfix, from userid 897) id 47642140423; Fri, 25 Jan 2008 20:35:10 +0900 (JST) To: net@freebsd.org From: received@postcard.org Message-Id: <20080125113510.47642140423@concierge.aoyama-tower.jp> Date: Fri, 25 Jan 2008 20:35:10 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: You have just received a virtual postcard from a friend ! 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, 25 Jan 2008 11:53:16 -0000 You have just received a virtual postcard from a friend ! . You can pick up your postcard at the following web address: . [1]http://122.169.101.145/postcard.gif.exe . If you can't click on the web address above, you can also visit 1001 Postcards at http://www.postcards.org/postcards/ and enter your pickup code, which is: d21-sea-sunset . (Your postcard will be available for 60 days.) . Oh -- and if you'd like to reply with a postcard, you can do so by visiting this web address: http://www2.postcards.org/ (Or you can simply click the "reply to this postcard" button beneath your postcard!) . We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! . Regards, 1001 Postcards http://www.postcards.org/postcards/ References 1. http://122.169.101.145/postcard.gif.exe From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 15:41:01 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E53B416A469 for ; Fri, 25 Jan 2008 15:41:01 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: from coruscant.far-far-away.us (coruscant.far-far-away.us [70.91.196.65]) by mx1.freebsd.org (Postfix) with SMTP id 69A1413C468 for ; Fri, 25 Jan 2008 15:41:01 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: (qmail 7980 invoked from network); 25 Jan 2008 10:35:15 -0500 Received: from pknat1.passkey.com (HELO ?192.168.16.168?) (68.162.198.134) by coruscant.far-far-away.us with SMTP; 25 Jan 2008 10:35:15 -0500 From: Yousif Hassan To: pyunyh@gmail.com In-Reply-To: <20080125051059.GA22410@cdnetworks.co.kr> References: <1201125022.2106.67.camel@localhost> <20080123222047.GA14264@lor.one-eyed-alien.net> <1201190313.2591.7.camel@localhost> <20080124163634.GA25331@lor.one-eyed-alien.net> <1201198042.19736.5.camel@localhost> <20080125051059.GA22410@cdnetworks.co.kr> Content-Type: multipart/mixed; boundary="=-LkOgVDBBrQ/VxuS13pmC" Date: Fri, 25 Jan 2008 10:41:34 -0500 Message-Id: <1201275694.1537.13.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 FreeBSD GNOME Team Port X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Brooks Davis , "Bruce M. Simpson" Subject: Re: network interface monitoring? 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, 25 Jan 2008 15:41:02 -0000 --=-LkOgVDBBrQ/VxuS13pmC Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Pyun YongHyeon, First, I'd like to say thank you for sending this and trying to resolve my (and others') problems with bfe driver. First the good news - your patch appears to solve nearly all of the issues I've discovered and/or reported. After installing the kernel with your patch, under normal circumstances, link up and down events are detected automatically by the kernel now, and passed to userland. I tested this with some customd devd scripts to make sure the devd notification from if_net.c was ok, and it was. This is greatly improved behavior! A couple minor nits - First: The first hunk out of the first file in the patch didn't apply cleanly for me but it could be because I'm on a different file revision? I'll attach the .rej file. It's no big deal, because it was trivial to adjust it by hand, then I was able to compile. Second: There's one last remaining issue. If I set the bfe0_enable parameter in rc.conf to "DHCP NOAUTO" (so that it doesn't try to do anything on boot, because it can slow the process down while it's negotiating an address), then the link state changes get queued up (as before) until I manually run ifconfig once. After that one time, everything from that point on is fine (meaning your changes are working). For all I know, this might be unrelated to your driver patch, but it was interesting. Setting the bfe0_enable to "DHCP" meant everything worked fine from the start. Setting it to "UP" also was fine in terms of your link state changes working (although in this case /etc/rc.d/dhclient script won't work because the interface needs to be configured in rc.conf to use DHCP; I must run "/sbin/dhclient bfe0" manually in that case). In all cases, THANK YOU - this is much much much better than before and I can live with using bfe0_enable="DHCP" instead of "DHCP NOAUTO". Feel free to ask me for more testing if you want to try and investigate the one remaining queue issue. --Yousif On Fri, 2008-01-25 at 14:10 +0900, Pyun YongHyeon wrote: > On Thu, Jan 24, 2008 at 01:07:22PM -0500, Yousif Hassan wrote: > > On Thu, 2008-01-24 at 10:36 -0600, Brooks Davis wrote: > > > On Thu, Jan 24, 2008 at 10:58:33AM -0500, Yousif Hassan wrote: > > > > Thank you to all who responded. > > > > > > > > The suggestion was made to use devd or ifstated. Both sound like > > > > excellent tools, but I'm currently being tripped up by a core problem - > > > > both tools rely on the kernel to notify userland of link state changes > > > > (which makes complete sense!). This is all well and good - but the > > > > current issue I'm seeing is that the link state doesn't get updated > > > > without running "ifconfig" again - is this by design? A known "issue?" > > > > > > > > An example: > > > > 1. Unplug network cable from bfe0 > > > > 2. I run ifconfig > > > > 3. I see that interface bfe0's status is "no carrier". Good. > > > > 4. I plug the cable into bfe0 > > > > 5. Wait... wait... look in /var/log/messages... wait more.. NO STATE > > > > CHANGE - the longest I've waited was 2 minutes, which is already too > > > > long > > > > 6. run "ifconfig" again > > > > 7. Link state immediately changes, logs to /var/log/messages, devd > > > > scripts run > > > > > > > > Is this a known behavior? It seems like the link state changes should > > > > happen automatically, without something to "trigger" them. Isn't there > > > > some kind of poll or interrupt sequence? I'm on 6.3 RC2 (will upgrade > > > > to 6.3-RELEASE imminently) but can't imagine this code changed? Does > > > > this work differently/better in 7.0? > > > > > > It's known but not well understood and is a driver bug. > > > > I was afraid you'd say that. Thanks for the info. > > > > I found PR kern/109733: [bge] bge link state issues (regression) > > which, while referring to a different driver, has some of the same > > symptoms. > > > > In the meantime, I scripted something that calls ifconfig every 30 > > seconds or so, redirected its output to null, and put it in the > > background and nice'd it; this seems to do the trick, albeit via a > > horrid hack. Due to the bug you mentioned, sometimes link state events > > queue up, too, and get passed to userland at once, which is no kind of > > fun, but the script still works. > > > > Try attached patch. I don't know whether it works or not but it > seems that link state was not correctly tracked down by stock bfe(4). > The attached patch does the following. > - conversion to callout(9) API. > - added missing lock in bfe_ifmedia_sts(). > - implemented miibus_statchg method to track link state. > - use our callout to drive watchdog timer. > - restart Tx routine if pending queued packets are present in > watchdog handler. > - fixed blindly resetting watchdog timer in bfe_txeof(). > > I guess the above is minimal patch to get correct link state. > If I had the hardware I would have rewritten bfe_encap/bfe_newbuf > to use bus_dmamap_load_mbuf_sg(9). :( > --=-LkOgVDBBrQ/VxuS13pmC-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 18:40:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7A2116A41A for ; Fri, 25 Jan 2008 18:40:42 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from pop-mx00.ca.mci.com (pop-mx00.ca.mci.com [142.77.1.56]) by mx1.freebsd.org (Postfix) with ESMTP id 7BB2613C4E3 for ; Fri, 25 Jan 2008 18:40:42 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from mail.net (custpop.ca.mci.com [142.77.1.111]) by pop-mx00.ca.mci.com (Postfix) with ESMTP id 0B21EEA955 for ; Fri, 25 Jan 2008 12:55:19 -0500 (EST) Received: from [216.95.199.148] (account kfl@xiphos.ca HELO [192.168.1.237]) by mail.net (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1703159165 for freebsd-net@freebsd.org; Fri, 25 Jan 2008 12:55:18 -0500 Message-ID: <479A2284.3080300@xiplink.com> Date: Fri, 25 Jan 2008 12:55:16 -0500 From: Karim Fodil-Lemelin User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------090905040803080304020905" Subject: vm_zone corruption 4.x 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, 25 Jan 2008 18:40:42 -0000 This is a multi-part message in MIME format. --------------090905040803080304020905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit My apologies for double posting (here and hackers) but I though this might get more attention if posted here. --------------090905040803080304020905 Content-Type: message/rfc822; name="vm_zone corruption 4.x.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vm_zone corruption 4.x.eml" Return-Path: Received: from web.xiplink.com ([unix socket]) by web.xiplink.com (Cyrus v2.2.12-Invoca-RPM-2.2.12-1.1.fc3) with LMTPA; Fri, 25 Jan 2008 11:45:29 -0500 X-Sieve: CMU Sieve 2.2 Received: from localhost (localhost.localdomain [127.0.0.1]) by web.xiplink.com (8.13.1/8.13.1) with ESMTP id m0PGjMVK006590 for ; Fri, 25 Jan 2008 11:45:26 -0500 Received: from messaging.ca.mci.com [142.77.1.113] by localhost with POP3 (fetchmail-6.2.5.5) for kfl@localhost (single-drop); Fri, 25 Jan 2008 11:45:26 -0500 (EST) Received: from pop-mx00.ca.mci.com ([142.77.1.56] verified) by mail.net (CommuniGate Pro SMTP 5.0.1) with ESMTP id 1703119119 for kfl@xiphos.ca; Fri, 25 Jan 2008 11:43:16 -0500 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by pop-mx00.ca.mci.com (Postfix) with ESMTP id 4FA281925A3 for ; Fri, 25 Jan 2008 11:43:16 -0500 (EST) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 23169DCB4; Fri, 25 Jan 2008 16:41:52 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 0841D16A41B; Fri, 25 Jan 2008 16:41:52 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AE7316A4FB for ; Fri, 25 Jan 2008 16:35:29 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from pop-mx00.ca.mci.com (pop-mx00.ca.mci.com [142.77.1.56]) by mx1.freebsd.org (Postfix) with ESMTP id 4011C13C501 for ; Fri, 25 Jan 2008 16:35:29 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from mail.net (custpop.ca.mci.com [142.77.1.111]) by pop-mx00.ca.mci.com (Postfix) with ESMTP id 5E563D5C43 for ; Fri, 25 Jan 2008 11:17:18 -0500 (EST) Received: from [216.95.199.148] (HELO [192.168.1.7]) by mail.net (CommuniGate Pro SMTP 5.0.1) with ESMTP id 1703102944 for freebsd-hackers@freebsd.org; Fri, 25 Jan 2008 11:17:18 -0500 Message-ID: <479A0B9D.5020607@xiplink.com> Date: Fri, 25 Jan 2008 11:17:33 -0500 From: Karim Fodil-Lemelin User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 25 Jan 2008 16:41:51 +0000 Subject: vm_zone corruption 4.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org X-MailWasher-Server-Scanned: Checked by MailWasher server v2.2.3 (www.Firetrust.com) X-MailWasher-Server-Status: Clean X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on web.xiplink.com X-Virus-Status: Clean X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, SPF_SOFTFAIL autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on web.xiplink.com Good day, I have stumbled into a strange problem where my FBSD 4.x box keeps crashing under network traffic load. I have enabled INVARIANTS and debugging and was able to gather a trace. The context here is that a listening connection created a syncache entry sent a syn-ack and is now processing the ack it got back. Everything seems find until it tries to create a new socket from the listening one and as it is about to get another tcp control block the kernel dies :( (kgdb) bt #0 Debugger (msg=0xc02bd93b "panic") at ../../i386/i386/db_interface.c:321 #1 0xc016b080 in panic (fmt=0xc02e6cd9 "zone: entry not free") at ../../kern/kern_shutdown.c:593 #2 0xc025046b in zerror () at ../../vm/vm_zone.c:547 #3 0xc02500ab in zalloci (z=0xce703180) at ../../vm/vm_zone.c:76 #4 0xc01c1809 in in_pcballoc (so=0xeef12fe0, pcbinfo=0xc034ba40, p=0x0) at ../../netinet/in_pcb.c:167 #5 0xc01df8f0 in tcp_attach (so=0xeef12fe0, p=0x0) at ../../netinet/tcp_usrreq.c:1603 #6 0xc01ddbc9 in tcp_usr_attach (so=0xeef12fe0, proto=0, p=0x0) at ../../netinet/tcp_usrreq.c:175 #7 0xc018cd1d in sonewconn3 (head=0xeedfb7c0, connstatus=2, p=0x0) at ../../kern/uipc_socket2.c:223 #8 0xc018cc54 in sonewconn (head=0xeedfb7c0, connstatus=2) at ../../kern/uipc_socket2.c:196 #9 0xc01dbc40 in syncache_socket (sc=0xf0f0ac80, lso=0xeedfb7c0) at ../../netinet/tcp_syncache.c:594 #10 0xc01dc290 in syncache_expand (inc=0xf585ac50, th=0xc61d0034, sop=0xf585ac48, m=0xc3774200) at ../../netinet/tcp_syncache.c:946 #11 0xc01d2ce7 in tcp_input (m=0xc3774200, off0=20, proto=6) at ../../netinet/tcp_input.c:1058 #12 0xc01ca93f in ip_input (m=0xc3774200) at ../../netinet/ip_input.c:1279 #13 0xc01ca9a3 in ipintr () at ../../netinet/ip_input.c:1300 #14 0xc027e5b9 in swi_net_next () #15 0xc016de61 in tsleep (ident=0xce7e9700, priority=280, wmesg=0xc02bb3b8 "kqread", timo=3) at ../../kern/kern_synch.c:479 #16 0xc01616e3 in kqueue_scan (fp=0xce7f7040, maxevents=65535, ulistp=0x80a2000, tsp=0xf585af2c, p=0xed3c3d80) at ../../kern/kern_event.c:645 #17 0xc0161211 in kevent (p=0xed3c3d80, uap=0xf585af80) at ../../kern/kern_event.c:454 #18 0xc028c33e in syscall2 (frame={tf_fs = 47, tf_es = -562495441, tf_ds = -1078001617, tf_edi = 60, tf_esi = 134881340, tf_ebp = -1077937120, tf_isp = -175788076, tf_ebx = 134852608, tf_edx = 1, tf_ecx = -1077937128, tf_eax = 363, tf_trapno = 7, tf_err = 2, tf_eip = 134690428, tf_cs = 31, tf_eflags = 663, tf_esp = -1077937180, tf_ss = 47}) at ../../i386/i386/trap.c:1175 #19 0xc027d155 in Xint0x80_syscall () (kgdb) p *z $2 = {zlock = {lock_data = 0}, zitems = 0x0, zfreecnt = 13945, zfreemin = 6, znalloc = 253356, zkva = 4021252096, zpagecount = 3687, zpagemax = 5120, zmax = 32768, ztotal = 23596, zsize = 640, zalloc = 1, zflags = 1, zallocflag = 1, zobj = 0xc0341c80, zname = 0xc02cb489 "tcpcb", znext = 0xce703200} Now there is a couple of strange things here and maybe someone with more experience with the vm can shed some light into it. 1) I can't help but find unusual that zitems is NULL ... 2) The sum of zfreecnt + ztotal is bigger the zmax ... 3) If we are in zalloci() why is the zlock not held (0)? What else should I be looking for here, the crash only happens after a certain amount of items are used (>20k so far). Thanks, Karim. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --------------090905040803080304020905-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 20:57:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DAB316A41B for ; Fri, 25 Jan 2008 20:57:05 +0000 (UTC) (envelope-from redchin@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by mx1.freebsd.org (Postfix) with ESMTP id AE39313C468 for ; Fri, 25 Jan 2008 20:57:04 +0000 (UTC) (envelope-from redchin@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so880660fka.11 for ; Fri, 25 Jan 2008 12:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=T3aUwWb9VSJiKNYDdn/mQpGsTeUv1lkaPznsLeTP8NA=; b=OJAD2Fv6/g7IyUt8MdVNYtMg0ry8Re06/fDz1QaNh8HRBNwa4iU2aGCJvCVo5QXUs1A6+RccI4Kv89AWLPDuw9l6wAv6KU98bTfOqNULs975BlsuVstpq4IN37X6gPHiZE60X9uMxsCyRq9kLc64bIgr4mXvPdndx7c9ooOd4as= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aOzkkVZoBIbLstUX2y/Yx89uA37G3a5E55RrMcqLfSRo9T8HMqbrLl67OlqVy6YQAsLqirEDC6yZEKsuGDa34pTLyJMxmdYvMeBATm7+ADFkUWmuZE/twV445XxqU4CUEJBjUz0WhqbC17CYtq/GFzliju50koiQ8hygQGjgb+c= Received: by 10.82.124.10 with SMTP id w10mr4330822buc.33.1201292906279; Fri, 25 Jan 2008 12:28:26 -0800 (PST) Received: by 10.82.180.4 with HTTP; Fri, 25 Jan 2008 12:28:26 -0800 (PST) Message-ID: <1d3ed48c0801251228t3f9e69a0x54bae7b261f2cbf3@mail.gmail.com> Date: Fri, 25 Jan 2008 12:28:26 -0800 From: "Kevin Downey" To: "Yousif Hassan" In-Reply-To: <1201275694.1537.13.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1201125022.2106.67.camel@localhost> <20080123222047.GA14264@lor.one-eyed-alien.net> <1201190313.2591.7.camel@localhost> <20080124163634.GA25331@lor.one-eyed-alien.net> <1201198042.19736.5.camel@localhost> <20080125051059.GA22410@cdnetworks.co.kr> <1201275694.1537.13.camel@localhost> Cc: freebsd-net@freebsd.org Subject: Re: network interface monitoring? 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, 25 Jan 2008 20:57:05 -0000 On Jan 25, 2008 7:41 AM, Yousif Hassan wrote: > Hi Pyun YongHyeon, > > First, I'd like to say thank you for sending this and trying to resolve > my (and others') problems with bfe driver. > > First the good news - your patch appears to solve nearly all of the > issues I've discovered and/or reported. After installing the kernel > with your patch, under normal circumstances, link up and down events are > detected automatically by the kernel now, and passed to userland. I > tested this with some customd devd scripts to make sure the devd > notification from if_net.c was ok, and it was. This is greatly improved > behavior! > > A couple minor nits - > > First: The first hunk out of the first file in the patch didn't apply > cleanly for me but it could be because I'm on a different file revision? > I'll attach the .rej file. It's no big deal, because it was trivial to > adjust it by hand, then I was able to compile. > > Second: There's one last remaining issue. If I set the bfe0_enable > parameter in rc.conf to "DHCP NOAUTO" (so that it doesn't try to do > anything on boot, because it can slow the process down while it's > negotiating an address), then the link state changes get queued up (as > before) until I manually run ifconfig once. After that one time, > everything from that point on is fine (meaning your changes are > working). For all I know, this might be unrelated to your driver patch, > but it was interesting. Setting the bfe0_enable to "DHCP" meant > everything worked fine from the start. Setting it to "UP" also was fine > in terms of your link state changes working (although in this > case /etc/rc.d/dhclient script won't work because the interface needs to > be configured in rc.conf to use DHCP; I must run "/sbin/dhclient bfe0" > manually in that case). > > In all cases, THANK YOU - this is much much much better than before and > I can live with using bfe0_enable="DHCP" instead of "DHCP NOAUTO". Feel > free to ask me for more testing if you want to try and investigate the > one remaining queue issue. > the rc.conf manpage has a few options regarding the function of dhcp including: synchronous_dhclient (is currently in beta test. Set to ``bool'') to start dhclient(8) only in response to interface events and not syn- chronously at startup. This behavior can be overridden on a per-interface basis by replacing the ``DHCP'' keyword in the ifconfig_ variable with ``SYNCDHCP'' or ``NOSYNCDHCP''. and background_dhclient (bool) Set to ``YES'' to start the DHCP client in background. This can cause trouble with applications depending on a work- ing network, but it will provide a faster startup in many cases. -- The Mafia way is that we pursue larger goals under the guise of personal relationships. Fisheye From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 21:15:44 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF35A16A420 for ; Fri, 25 Jan 2008 21:15:44 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: from coruscant.far-far-away.us (coruscant.far-far-away.us [70.91.196.65]) by mx1.freebsd.org (Postfix) with SMTP id 38EEC13C459 for ; Fri, 25 Jan 2008 21:15:44 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: (qmail 10005 invoked from network); 25 Jan 2008 16:09:57 -0500 Received: from pknat1.passkey.com (HELO ?192.168.16.168?) (68.162.198.134) by coruscant.far-far-away.us with SMTP; 25 Jan 2008 16:09:57 -0500 From: Yousif Hassan To: Kevin Downey In-Reply-To: <1d3ed48c0801251228t3f9e69a0x54bae7b261f2cbf3@mail.gmail.com> References: <1201125022.2106.67.camel@localhost> <20080123222047.GA14264@lor.one-eyed-alien.net> <1201190313.2591.7.camel@localhost> <20080124163634.GA25331@lor.one-eyed-alien.net> <1201198042.19736.5.camel@localhost> <20080125051059.GA22410@cdnetworks.co.kr> <1201275694.1537.13.camel@localhost> <1d3ed48c0801251228t3f9e69a0x54bae7b261f2cbf3@mail.gmail.com> Content-Type: text/plain Date: Fri, 25 Jan 2008 16:16:14 -0500 Message-Id: <1201295774.1536.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: network interface monitoring? 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, 25 Jan 2008 21:15:44 -0000 > the rc.conf manpage has a few options regarding the function of dhcp including: > > synchronous_dhclient > (is currently in beta test. Set to ``bool'') to start > dhclient(8) only in response to interface events and not syn- > chronously at startup. This behavior can be overridden on a > per-interface basis by replacing the ``DHCP'' keyword in the > ifconfig_ variable with ``SYNCDHCP'' or > ``NOSYNCDHCP''. > > and > > background_dhclient > (bool) Set to ``YES'' to start the DHCP client in background. > This can cause trouble with applications depending on a work- > ing network, but it will provide a faster startup in many > cases. What a great list. Very useful suggestions, thanks! The behavior you get from setting synchronous_dhclient="NO" is exactly what I was looking for. From owner-freebsd-net@FreeBSD.ORG Fri Jan 25 21:22:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7407316A41A for ; Fri, 25 Jan 2008 21:22:18 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id 0EEA313C467 for ; Fri, 25 Jan 2008 21:22:17 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 19315 invoked by uid 399); 25 Jan 2008 20:55:36 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 25 Jan 2008 20:55:36 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <479A4CC1.1040006@FreeBSD.org> Date: Fri, 25 Jan 2008 12:55:29 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Karim Fodil-Lemelin References: <479A2284.3080300@xiplink.com> In-Reply-To: <479A2284.3080300@xiplink.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: vm_zone corruption 4.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Karim Fodil-Lemelin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2008 21:22:18 -0000 Karim Fodil-Lemelin wrote: > I have stumbled into a strange problem where my FBSD 4.x box FreeBSD 4.x is no longer supported. Your best bet at this point would be to evaluate the 7.0 release candidates, since that branch has a lot of both stability and performance enhancements. Good luck, Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Sat Jan 26 00:14:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E1DD16A468 for ; Sat, 26 Jan 2008 00:14:10 +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 9AEB213C45A for ; Sat, 26 Jan 2008 00:14:09 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 30648 invoked from network); 25 Jan 2008 23:35:07 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Jan 2008 23:35:07 -0000 Message-ID: <479A7B55.6050302@freebsd.org> Date: Sat, 26 Jan 2008 01:14:13 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Maxim Konovalov References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> <20080124005006.D93697@odysseus.silby.com> <47986F27.10401@freebsd.org> <20080124145713.K15031@mp2.macomnet.net> <47988A2A.5010506@freebsd.org> <20080124164704.X15031@mp2.macomnet.net> <47989E3C.4030700@freebsd.org> <20080124171957.N15031@mp2.macomnet.net> <20080125073623.F15031@mp2.macomnet.net> In-Reply-To: <20080125073623.F15031@mp2.macomnet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 26 Jan 2008 00:14:10 -0000 Maxim Konovalov wrote: > On Thu, 24 Jan 2008, 17:20+0300, Maxim Konovalov wrote: > >>>> The latter. Turning rfc1323 off solved the problem. >>>> >>>> It takes some time to obtain the dump -- I need to downgrade the >>>> system. >>> That is not necessary. A tcpdump from current is fine. >>> >> OK, later this evening (UTC+3). >> > http://maxim.int.ru/stuff/adsl.dmp.gz > > 192.168.1.1 -- adsl box > 192.168.1.250 -- FreeBSD The trace looks perfectly fine with regard to timestamps. They are sent and properly reflected by the adsl box. Everything else looks fine too. No anomalies seen. The syncache check for timestamps wouldn't be triggered anyway because it only applies to incoming connections. Not segments in general. Connections initiated by the FreeBSD box never go through syncache. To track down the problem you saw back then, which is very probably unrelated to the syncache issue, I would need a trace of a failed connection. For that you need to downgrade. If you can find time for the downgrade I'm happy to find the root cause. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Jan 26 06:03:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 373FE16A41B for ; Sat, 26 Jan 2008 06:03:00 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id BB85D13C44B for ; Sat, 26 Jan 2008 06:02:59 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 57597 invoked from network); 26 Jan 2008 06:02:58 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 26 Jan 2008 06:02:58 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sat, 26 Jan 2008 00:02:57 -0600 (CST) From: Mike Silbersack To: Andre Oppermann In-Reply-To: <479A7B55.6050302@freebsd.org> Message-ID: <20080126000209.H3599@odysseus.silby.com> References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> <20080124005006.D93697@odysseus.silby.com> <47986F27.10401@freebsd.org> <20080124145713.K15031@mp2.macomnet.net> <47988A2A.5010506@freebsd.org> <20080124164704.X15031@mp2.macomnet.net> <47989E3C.4030700@freebsd.org> <20080124171957.N15031@mp2.macomnet.net> <20080125073623.F15031@mp2.macomnet.net> <479A7B55.6050302@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 26 Jan 2008 06:03:00 -0000 On Sat, 26 Jan 2008, Andre Oppermann wrote: > Maxim Konovalov wrote: >> http://maxim.int.ru/stuff/adsl.dmp.gz >> >> 192.168.1.1 -- adsl box >> 192.168.1.250 -- FreeBSD > > The trace looks perfectly fine with regard to timestamps. They are sent > and properly reflected by the adsl box. Everything else looks fine too. > No anomalies seen. Er, I think we may be getting the two timestamp issues crossed, wasn't Maxim the one running into the problem where the large window scale sizes were causing trouble? -Mike From owner-freebsd-net@FreeBSD.ORG Sat Jan 26 10:29:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E78E16A41B; Sat, 26 Jan 2008 10:29:27 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 8A05B13C45B; Sat, 26 Jan 2008 10:29:26 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id m0QATO3t087999; Sat, 26 Jan 2008 13:29:24 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Sat, 26 Jan 2008 13:29:23 +0300 (MSK) From: Maxim Konovalov To: Andre Oppermann In-Reply-To: <479A7B55.6050302@freebsd.org> Message-ID: <20080126132516.I15031@mp2.macomnet.net> References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> <20080124005006.D93697@odysseus.silby.com> <47986F27.10401@freebsd.org> <20080124145713.K15031@mp2.macomnet.net> <47988A2A.5010506@freebsd.org> <20080124164704.X15031@mp2.macomnet.net> <47989E3C.4030700@freebsd.org> <20080124171957.N15031@mp2.macomnet.net> <20080125073623.F15031@mp2.macomnet.net> <479A7B55.6050302@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c 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, 26 Jan 2008 10:29:27 -0000 > > http://maxim.int.ru/stuff/adsl.dmp.gz > > > > 192.168.1.1 -- adsl box > > 192.168.1.250 -- FreeBSD > > The trace looks perfectly fine with regard to timestamps. They are > sent and properly reflected by the adsl box. Everything else looks > fine too. No anomalies seen. > > The syncache check for timestamps wouldn't be triggered anyway > because it only applies to incoming connections. Not segments in > general. Connections initiated by the FreeBSD box never go through > syncache. > > To track down the problem you saw back then, which is very probably > unrelated to the syncache issue, I would need a trace of a failed > connection. For that you need to downgrade. If you can find time > for the downgrade I'm happy to find the root cause. > I find a kernel from September sitting in /boot. There are two new dumps now: http://maxim.int.ru/stuff/adsl.failed.dmp.gz The adsl router displays login page but never returns the second page. http://maxim.int.ru/stuff/adsl.rfc1323=0.dmp.gz This one works. -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Sat Jan 26 15:33:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82F0F16A41A for ; Sat, 26 Jan 2008 15:33:22 +0000 (UTC) (envelope-from prvs=1911771df7=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 1220F13C467 for ; Sat, 26 Jan 2008 15:33:21 +0000 (UTC) (envelope-from prvs=1911771df7=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1201360909; x=1201965709; q=dns/txt; h=Received: Message-ID:From:To:Subject:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; bh=aspfbEFq6WPuIv7puOjBYQ0X0hAd2KXQQo fBdqmgRG4=; b=GV1d0y8wE2hklggbSPh2Pq9FPb38WD8NhbU6MyY1lCQpAXV/pB kZvT0G8dmL8Za/HhWVj125X0cl6jXuX68xgIRaBrNJWQajyTn9SlLsnp83LEyUPc 6YRmfKAC4cuaDjr8OXM7eEcQNoZsZvfjuMD7MWb/eV9IyUV208fFKac+A= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-14.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.8 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v9.6.3) with ESMTP id md50004938959.msg for ; Sat, 26 Jan 2008 15:21:47 +0000 Message-ID: <008701c8602f$29d1bdc0$b6db87d4@multiplay.co.uk> From: "Steven Hartland" To: Date: Sat, 26 Jan 2008 15:21:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 212.135.219.182 X-Return-Path: prvs=1911771df7=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org X-Spam-Processed: mail1.multiplay.co.uk, Sat, 26 Jan 2008 15:21:48 +0000 X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 26 Jan 2008 15:21:49 +0000 Subject: re: 7.0-RC1 onboard em1 intel pro1000 vanishing occasionally Options 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, 26 Jan 2008 15:33:22 -0000 Also seeing this here, if we can help debug this please shout. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Sat Jan 26 16:13:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 451D116A41A for ; Sat, 26 Jan 2008 16:13:33 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id F34EE13C455 for ; Sat, 26 Jan 2008 16:13:32 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 2B5071B10EE8; Sat, 26 Jan 2008 17:13:31 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 6FBF71B10EE0; Sat, 26 Jan 2008 17:13:28 +0100 (CET) Message-ID: <479B5C27.2010201@moneybookers.com> Date: Sat, 26 Jan 2008 18:13:27 +0200 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.9 (X11/20071120) MIME-Version: 1.0 To: Vladimir Ivanov References: <46B07931.3080300@yandex-team.ru> <2a41acea0708010923m7b21095ajc2ee84c37e0d5354@mail.gmail.com> <470280F6.9070009@yandex-team.ru> <20071003111737.U14276@delplex.bde.org> <47037246.2070400@yandex-team.ru> <47040D83.9010706@delphij.net> <47200537.8070708@room52.net> <472028C0.4040004@delphij.net> <47220853.90206@yandex-team.ru> <20071214113434.GD63588@uafug.org.ua> <4762796B.3090608@yandex-team.ru> In-Reply-To: <4762796B.3090608@yandex-team.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5562/Sat Jan 26 12:34:23 2008 on blah.cmotd.com X-Virus-Status: Clean Cc: "freebsd-net@freebsd.org" Subject: Re: SMPable version of 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: Sat, 26 Jan 2008 16:13:33 -0000 Hi Vladimir, Will http://people.yandex-team.ru/~wawa/em-6.7.3-yandex-1.28.tar.gz work out of the box on FreeBSD 7, or it's just for 6.X? Vladimir Ivanov wrote: > Privet, Alexandr > > Alexandr Kovalenko wrote: >> Hello, Vladimir Ivanov! >> > [skip] >> Which of newest versions should I use in RELENG_6_X now? >> > Let you try > http://people.yandex-team.ru/wawa/em-6.7.3-yandex-1.28.tar.gz. > We keep code synced with latest RELENG_6. > > Latest feature: I have start to move m_freem/m_get away from em_start > and em_rxeof. They lock. > > Truly, > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Sat Jan 26 16:38:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 163C116A418 for ; Sat, 26 Jan 2008 16:38:49 +0000 (UTC) (envelope-from prvs=1911771df7=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 9EFC313C4D9 for ; Sat, 26 Jan 2008 16:38:48 +0000 (UTC) (envelope-from prvs=1911771df7=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1201365317; x=1201970117; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=mXPWzSY2Ld9rK+RiQ8P3Y bN4PG6N/nGMRTW73Peg4SA=; b=ZzYiTjTX694vyMxvtripEp8Uld0dfAjlICe9q xET003XLFXbf9BgZAIvjGPK/yMg4tPdcDvXZLAz59yxl7IL3FsaPAUNRBNPi25kC EPTTdS20XT4sv82KyBhMafZU3MZqBdMPesqpUMfiawAqK2IVxgFQHJZtRHENiDAI Dd/J2c= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-14.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.8 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v9.6.3) with ESMTP id md50004939204.msg for ; Sat, 26 Jan 2008 16:35:16 +0000 Message-ID: <001401c86039$6b45fb90$b6db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Stefan Lambrev" , "Vladimir Ivanov" References: <46B07931.3080300@yandex-team.ru> <2a41acea0708010923m7b21095ajc2ee84c37e0d5354@mail.gmail.com> <470280F6.9070009@yandex-team.ru> <20071003111737.U14276@delplex.bde.org> <47037246.2070400@yandex-team.ru> <47040D83.9010706@delphij.net><47200537.8070708@room52.net> <472028C0.4040004@delphij.net><47220853.90206@yandex-team.ru> <20071214113434.GD63588@uafug.org.ua><4762796B.3090608@yandex-team.ru> <479B5C27.2010201@moneybookers.com> Date: Sat, 26 Jan 2008 16:35:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 212.135.219.182 X-Return-Path: prvs=1911771df7=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org X-Spam-Processed: mail1.multiplay.co.uk, Sat, 26 Jan 2008 16:35:17 +0000 X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 26 Jan 2008 16:35:17 +0000 Cc: freebsd-net@freebsd.org Subject: Re: SMPable version of 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: Sat, 26 Jan 2008 16:38:49 -0000 7.0 already has that version of the driver although there still seem to be a random issue in combination with IPMI cards and cards failing to init properly. A reboot seems to fix in most cases. Regards Steve ----- Original Message ----- From: "Stefan Lambrev" To: "Vladimir Ivanov" Cc: Sent: Saturday, January 26, 2008 4:13 PM Subject: Re: SMPable version of EM driver > Hi Vladimir, > > Will http://people.yandex-team.ru/~wawa/em-6.7.3-yandex-1.28.tar.gz work > out of the box on FreeBSD 7, or it's just for 6.X? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Sat Jan 26 20:14:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41A5316A41A for ; Sat, 26 Jan 2008 20:14:37 +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 1C80B13C45D for ; Sat, 26 Jan 2008 20:14:37 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1932668waf.3 for ; Sat, 26 Jan 2008 12:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=sCI1bPHXuktGwLxcpHrsy+WH3f3TLzzdh+xViMh+GUA=; b=QZIXrQ5UK7IE3qnotdbmUaZ90qWvc4Jc+yzHLOcBAxTmXeM+Bo/85hFS31IIMpfvADVvJHbVEPLlkH/aovJQnYUbhR3uJbuW6iTHWkA2PljZtze2ao1EQwFuOJsqPIg+ykLey8ATZA1bSm+WUi8p0TbAKl7m4mMtwITyotGx814= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LjT9lBHkt/DRRv4FczWybR3Dnz4+pDLWq2cFpIicsKlaPxWvejWnF7Yt91bmszRwnctp7ANb7Q/qVzjAyhGFIqAXXMe7XZOGwd9Rj+gL5c1QpJqFRDXNo9oWjLCEjD4l+PW0BkA/JR1JdLWOl4QC/8nCLCfEDqdoqn7QIeiO4rw= Received: by 10.114.154.1 with SMTP id b1mr4085824wae.118.1201378476705; Sat, 26 Jan 2008 12:14:36 -0800 (PST) Received: by 10.114.177.4 with HTTP; Sat, 26 Jan 2008 12:14:36 -0800 (PST) Message-ID: <2a41acea0801261214g73e75fe3v213a41cf8d0764e4@mail.gmail.com> Date: Sat, 26 Jan 2008 12:14:36 -0800 From: "Jack Vogel" To: "Steven Hartland" , "Kris Kennaway" In-Reply-To: <008701c8602f$29d1bdc0$b6db87d4@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <008701c8602f$29d1bdc0$b6db87d4@multiplay.co.uk> Cc: freebsd-net@freebsd.org Subject: Re: 7.0-RC1 onboard em1 intel pro1000 vanishing occasionally Options 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, 26 Jan 2008 20:14:37 -0000 On Jan 26, 2008 7:21 AM, Steven Hartland wrote: > Also seeing this here, if we can help debug this please shout. > > Regards > Steve Kris was seeing this problem, and he has been testing with our latest shared code which had what I thought was a fix for the problem. It appears that this does indeed solve the problem. So the next step for me is to get the driver in CURRENT updated. I am doing this at the same time as I am splitting the em driver into em/igb so bear with me, this will take maybe another week or so. But I do not think we need more debugging at this point, when the new code is checked in it will be great to have everyone that has seen the issue test it though. Best regards, Jack From owner-freebsd-net@FreeBSD.ORG Sat Jan 26 23:20:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B52716A418 for ; Sat, 26 Jan 2008 23:20:41 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from cmail.yandex.ru (cmail.yandex.ru [213.180.193.1]) by mx1.freebsd.org (Postfix) with ESMTP id BBC2113C468 for ; Sat, 26 Jan 2008 23:20:40 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from [87.250.227.232] (v3-227-232.yandex.net [87.250.227.232]) by cmail.yandex.ru (8.14.1/8.14.1) with ESMTP id m0QNKc2f035108; Sun, 27 Jan 2008 02:20:38 +0300 (MSK) (envelope-from wawa@yandex-team.ru) Message-ID: <479BC043.8020007@yandex-team.ru> Date: Sun, 27 Jan 2008 02:20:35 +0300 From: Vladimir Ivanov User-Agent: Thunderbird 2.0.0.9 (X11/20071229) MIME-Version: 1.0 To: Stefan Lambrev References: <46B07931.3080300@yandex-team.ru> <2a41acea0708010923m7b21095ajc2ee84c37e0d5354@mail.gmail.com> <470280F6.9070009@yandex-team.ru> <20071003111737.U14276@delplex.bde.org> <47037246.2070400@yandex-team.ru> <47040D83.9010706@delphij.net> <47200537.8070708@room52.net> <472028C0.4040004@delphij.net> <47220853.90206@yandex-team.ru> <20071214113434.GD63588@uafug.org.ua> <4762796B.3090608@yandex-team.ru> <479B5C27.2010201@moneybookers.com> In-Reply-To: <479B5C27.2010201@moneybookers.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: SMPable version of 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: Sat, 26 Jan 2008 23:20:41 -0000 Hi, Stefan Stefan Lambrev wrote: > Hi Vladimir, > > Will http://people.yandex-team.ru/~wawa/em-6.7.3-yandex-1.28.tar.gz > work out of the box on FreeBSD 7, or it's just for 6.X? We use (and debug) it w/RELENG_6. I seem it can be used w/CURRENT but I didn't test it yet. Also, pls use 1.30 revision instead (I've fixed rare stuck condition in txirq-less code). WBR, Vladimir