From owner-freebsd-net@FreeBSD.ORG Sun Jul 5 05:53:28 2009 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 8F19B106566C; Sun, 5 Jul 2009 05:53:28 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (unknown [IPv6:2001:2f0:104:80a0:21b:78ff:fe37:f1cf]) by mx1.freebsd.org (Postfix) with ESMTP id 053888FC1A; Sun, 5 Jul 2009 05:53:27 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (ns1.ninth-nine.com [219.127.74.121] (may be forged)) (authenticated bits=0) by sakura.ninth-nine.com (8.14.3/8.14.3/NinthNine) with ESMTP id n655rLMh041355; Sun, 5 Jul 2009 14:53:26 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sun, 5 Jul 2009 14:53:20 +0900 From: Norikatsu Shigemura To: freebsd-net@FreeBSD.org Message-Id: <20090705145320.fdd081ef.nork@FreeBSD.org> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.2; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sun__5_Jul_2009_14_53_20_+0900_y8D5l2IG6XLuZe3b" Cc: Norikatsu Shigemura Subject: pcap(bpf) packet injection not-acceptable on FreeBSD 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: Sun, 05 Jul 2009 05:53:28 -0000 This is a multi-part message in MIME format. --Multipart=_Sun__5_Jul_2009_14_53_20_+0900_y8D5l2IG6XLuZe3b Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi. I have a trouble that an application packet-injecting by pcap(bpf)'s pcap_sendpacket function doesn't communicate to FreeBSD host, but can communicate to other machine. So I researched, and I noticed that sys/net/if_ethersubr.c has a structured issue(?)(I didn't know). Do you have any idea? I made a test program (attached file, fake-arp-reply.c). Do 'gcc fake-arp-reply -lpcap'. I tested 2 case (8-current self, 8-current -> 7-stable): test platform (I tested on 8-current, 7.2-stable) on 8-current: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ ifconfig rl0 rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:0b:97:33:1c:30 inet 192.168.36.6 netmask 0xffffff00 broadcast 192.168.36.255 media: Ethernet autoselect (100baseTX ) status: active $ arp -an ? (192.168.36.6) at 00:0b:97:33:1c:30 on rl0 permanent [ethernet] ? (192.168.36.1) at 00:1b:78:37:f1:cf on rl0 [ethernet] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - on 7-stable: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ ifconfig bge0 bge0: flags=8843 metric 0 mtu 1500 options=98 ether 00:1b:78:37:f1:cf inet 192.168.36.1 netmask 0xffffff00 broadcast 192.168.36.255 inet6 fe80::21b:78ff:fe37:f1cf%bge0 prefixlen 64 scopeid 0x1 media: Ethernet autoselect (1000baseTX ) status: active $ arp -an ? (192.168.36.1) at 00:1b:78:37:f1:cf on bge0 permanent [ethernet] ? (192.168.36.6) at 00:0b:97:33:1c:30 on bge0 [ethernet] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TEST 1: 8-current self (same 7-stable self, too) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # ./a.out -d rl0 -i 192.168.36.64 -m 10-20-30-40-50-60 rl0, 192.168.36.64 10:20:30:40:50:60 (on other console, ping 192.168.36.64) arp request catched, arp replyed and done. # arp -an ? (192.168.36.6) at 00:0b:97:33:1c:30 on rl0 permanent [ethernet] ? (192.168.36.1) at 00:1b:78:37:f1:cf on rl0 [ethernet] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TEST 2: 8-current -> 7-stable(same 8-current -> 7-stable, too) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # ./a.out -d rl0 -i 192.168.36.64 -m 10-20-30-40-50-60 rl0, 192.168.36.64 10:20:30:40:50:60 (on other machine's console, ping 192.168.36.64...) arp request catched, arp replyed and done. On other machine: $ ping 192.168.36.64 PING 192.168.36.64 (192.168.36.64): 56 data bytes ^C --- 192.168.36.64 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss $ arp -an ? (192.168.36.1) at 00:1b:78:37:f1:cf on bge0 permanent [ethernet] ? (192.168.36.6) at 00:0b:97:33:1c:30 on bge0 [ethernet] ? (192.168.36.64) at 10:20:30:40:50:60 on bge0 [ethernet] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --Multipart=_Sun__5_Jul_2009_14_53_20_+0900_y8D5l2IG6XLuZe3b Content-Type: text/plain; name="fake-arp-reply.c" Content-Disposition: attachment; filename="fake-arp-reply.c" Content-Transfer-Encoding: 7bit #include #include #include #include #include struct sendpkt { u_char dmac[6]; u_char smac[6]; u_char etype[2]; u_char htype[2]; u_char ptype[2]; u_char hlen[1]; u_char plen[1]; u_char op[2]; u_char src_mac[6]; u_char src_ipv4[4]; u_char dst_mac[6]; u_char dst_ipv4[4]; u_char trailer[18]; } __packed; struct sendpkt sendpkt = { { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, }, /* overwrite live packet */ { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, }, /* overwrite argument */ { 0x08, 0x06, }, /* constant */ { 0x00, 0x01, }, /* constant */ { 0x08, 0x00, }, /* constant */ { 0x06, }, /* constant */ { 0x04, }, /* constant */ { 0x00, 0x02, }, /* constant */ { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, }, /* overwrite live packet */ { 0x00, 0x00, 0x00, 0x00, }, /* overwrite live packet */ { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, }, /* overwrite argument */ { 0xff, 0xff, 0xff, 0xff, }, /* overwrite argument */ { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* constant */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, }, }; int main(int argc, char *argv[]) { int ch; u_char dev[30] = "lo0", mac[6] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, }, ipv4[4] = { 0, 0, 0, 0, }; pcap_t *p; static char errbuf[PCAP_ERRBUF_SIZE]; while( (ch = getopt(argc, argv, "d:i:m:")) != -1 ) { switch (ch) { case 'd': strlcpy(dev, optarg, sizeof(dev)); break; case 'i': sscanf(optarg, "%hhd%*[.]%hhd%*[.]%hhd%*[.]%hhd", &ipv4[0], &ipv4[1], &ipv4[2], &ipv4[3]); break; case 'm': sscanf(optarg, "%hhx%*[:.-]%hhx%*[:.-]%hhx%*[:.-]%hhx%*[:.-]%hhx%*[:.-]%hhx", &mac[0], &mac[1], &mac[2], &mac[3], &mac[4], &mac[5]); break; default: fprintf(stderr, "-d Device Name -i IPv4 Address -m MAC Addresss\n"); exit(0); /* NOT REACHABLE */ } } printf("%s, %d.%d.%d.%d %02x:%02x:%02x:%02x:%02x:%02x\n", dev, ipv4[0], ipv4[1], ipv4[2], ipv4[3], mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]); memcpy(&sendpkt.smac, mac, sizeof(sendpkt.smac)); memcpy(&sendpkt.src_mac, mac, sizeof(sendpkt.src_mac)); memcpy(&sendpkt.src_ipv4, ipv4, sizeof(sendpkt.src_ipv4)); if( (p = pcap_open_live(dev, 1500/*bytes*/, 1/*TRUE*/, 10/*msec*/, errbuf)) ) { int in_loop = 1; while( in_loop ) { struct pcap_pkthdr pkt_info; u_char *recvpkt; if( (recvpkt = (u_char *)pcap_next(p, &pkt_info)) ) { if( recvpkt[12] == 0x08 && recvpkt[13] == 0x06 && recvpkt[20] == 0x00 && recvpkt[21] == 0x01 && recvpkt[38] == ipv4[0] && recvpkt[39] == ipv4[1] && recvpkt[40] == ipv4[2] && recvpkt[41] == ipv4[3] ) { memcpy(sendpkt.dmac, &recvpkt[6], sizeof(sendpkt.dmac)); memcpy(sendpkt.dst_mac, &recvpkt[22], sizeof(sendpkt.dst_mac)); memcpy(sendpkt.dst_ipv4, &recvpkt[28], sizeof(sendpkt.dst_ipv4)); pcap_sendpacket(p, (u_char *)&sendpkt, sizeof(sendpkt)); printf("arp request catched, arp replyed and done.\n"); in_loop = 0; } else { printf("len=%d \r", pkt_info.caplen); if( recvpkt[12] == 0x08 && recvpkt[13] == 0x06 && recvpkt[20] == 0x00 && recvpkt[21] == 0x01 ) { printf("arp? recv=%d.%d.%d.%d / argv=%d.%d.%d.%d\n", recvpkt[38], recvpkt[39], recvpkt[40], recvpkt[41], ipv4[0], ipv4[1], ipv4[2], ipv4[3]); } fflush(stdout); } } usleep(100); } pcap_close(p); } else { fprintf(stderr, "pcap_open_live: error '%s'\n", errbuf); } return 0; } --Multipart=_Sun__5_Jul_2009_14_53_20_+0900_y8D5l2IG6XLuZe3b-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 6 04:37:52 2009 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 B4A961065670 for ; Mon, 6 Jul 2009 04:37:52 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id 7BBBB8FC14 for ; Mon, 6 Jul 2009 04:37:52 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0506.google.com with SMTP id f9so1215910rvb.43 for ; Sun, 05 Jul 2009 21:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=C41TkvbOz138w1FTdwnJKqVlbrsWNn9F8AnuOCDXUG8=; b=oHx91v4TCV5KfwdbWZlcB4eaqAlsIqHLpyiXaCapbsO5iLz4zaPa+2Xi/1xYDfm4gW jLsW/4U14S+vyOBq7+ZUgmMfXlE1g2tz7Z/nXKvrWbZ2rWbFXTtXWArkW+9aY6WlBW0P 5XcCOdTLTrh5iy+RGyDNNdeP/Htu079OUgHtg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=vthXEb9bq5mex1raOsBIhCjvLme7xqpRgIEU1SqynAC4WVmNqmGxje8xrm8Edd0UJJ 3JHYSMypcQIaEXBh1+GSB0o1LmcBE/kGQ0ZkLuf6XnfIoBPRwwnaXTG4lQDoW0fQZqqx YBmOIw/qDwGFSgqe8h72HUUhgFLdk74uXijhg= Received: by 10.141.29.8 with SMTP id g8mr2071553rvj.94.1246855072165; Sun, 05 Jul 2009 21:37:52 -0700 (PDT) Received: from weongyo ([114.111.62.249]) by mx.google.com with ESMTPS id f42sm10168311rvb.10.2009.07.05.21.37.49 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Jul 2009 21:37:50 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Mon, 6 Jul 2009 13:37:47 +0900 From: Weongyo Jeong Date: Mon, 6 Jul 2009 13:37:47 +0900 To: Nikos Vassiliadis Message-ID: <20090706043747.GD1138@weongyo.cdnetworks.kr> Mail-Followup-To: Nikos Vassiliadis , freebsd-net@freebsd.org References: <4A43386D.80500@gmx.com> <20090625103420.GD31161@weongyo.cdnetworks.kr> <4A436A8A.1000405@gmx.com> <20090626041246.GE31161@weongyo.cdnetworks.kr> <4A461AF9.7040900@gmx.com> <20090629032520.GA1138@weongyo.cdnetworks.kr> <4A4880EF.5010206@gmx.com> <4A4E2873.3010501@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4E2873.3010501@gmx.com> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-net@freebsd.org Subject: Re: ndis and USB wirelless ethernet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 04:37:52 -0000 On Fri, Jul 03, 2009 at 06:49:07PM +0300, Nikos Vassiliadis wrote: > Hello Weongyo & net, > > I did some tests with an AP. The bad news is that I am > getting random crashes. At least I cannot relate them > to something... It just stops responding, I cannot break > to the debugger. Would I try another driver? there are > 3 versions if I recall correctly on the vendor's site. I'm happy to see your device is successfully associated with AP. However it seems it's a bad news that you sometimes meet crashes. Does a random crash mean a OS hang (e.g. could not type any keys) or no more work of network operations? Frankly speaking, for both cases it looks I could not provide any solutions without backtraces unless I encountered same problems on my environment. It'd better if we can reproduce its problem easily. One thing to hang as far as I know is that try to execute `ifconfig down && ifconfig up' multiple times. In NDIS USB support it's recommended that `ifconfig up' is executed once. I think you can try another drivers. > Something strange I've noticed, is that if I set the ssid > before setting the interface to "up" state, it does not > associate with the AP. > > ifconfig wlan0 down > ifconfig wlan0 ssid barba > ifconfig wlan0 up > > > Setting BSSID to 00:1b:2f:be:78:aa > > ndis_newstate: INIT -> SCAN > > ndis0: link state changed to DOWN > > ndis0: link state changed to UP > > ndis_scan_results: 4 results > > scan: bssid 00:1c:a2:b2:4e:e5 chan 2412MHz (1/1152) rssi 25 > > scan: bssid 00:13:33:07:90:90 chan 2442MHz (7/1152) rssi 75 > > scan: bssid 00:05:59:0a:b7:c1 chan 2437MHz (6/1152) rssi 60 > > scan: bssid 00:1a:4f:20:dc:4a chan 2437MHz (6/1152) rssi 6 > > wlan0: ieee80211_new_state_locked: pending SCAN -> RUN transition lost > > ndis_newstate: SCAN -> AUTH > > Setting BSSID to 00:1b:2f:be:78:aa > > Setting BSSID to ff:ff:ff:ff:ff:ff > > Setting ESSID to "barba" > > ndis_newstate: AUTH -> ASSOC > > If if delete the ssid, and "up" the interface, it > associates: > > > Setting BSSID to 00:1b:2f:be:78:aa > > ndis_newstate: INIT -> SCAN > > ndis0: link state changed to DOWN > > ndis_scan_results: 4 results > > scan: bssid 00:13:33:07:90:90 chan 2442MHz (7/1152) rssi 73 > > scan: bssid 00:1c:a2:b2:4e:e5 chan 2412MHz (1/1152) rssi 15 > > scan: bssid 00:1a:4f:20:dc:4a chan 2437MHz (6/1152) rssi 7 > > scan: bssid 00:05:59:0a:b7:c1 chan 2437MHz (6/1152) rssi 54 > > ndis_newstate: SCAN -> AUTH > > Setting BSSID to 00:1b:2f:be:78:aa > > Setting BSSID to ff:ff:ff:ff:ff:ff > > Setting ESSID to "barba" > > ndis_newstate: AUTH -> ASSOC > > ndis_newstate: ASSOC -> RUN > > ndis0: link state changed to UP > > If you have some idea, I would be happy to test it. AFAIK this behavior (ASSOC -> RUN) depends on the routine of the link status change on NDIS driver that in private experience, some drivers doesn't call the link status handler even if it's ready to use or call the handler too early which is one of the abnormal. So don't know what's going on in NDIS driver currently. regards, Weongyo Jeong From owner-freebsd-net@FreeBSD.ORG Mon Jul 6 11:00:10 2009 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 01D931065673 for ; Mon, 6 Jul 2009 11:00:10 +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 E341B8FC18 for ; Mon, 6 Jul 2009 11:00:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n66B090H002936 for ; Mon, 6 Jul 2009 11:00:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n66B09AP002935; Mon, 6 Jul 2009 11:00:09 GMT (envelope-from gnats) Date: Mon, 6 Jul 2009 11:00:09 GMT Message-Id: <200907061100.n66B09AP002935@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Andrew Bliznak Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Bliznak List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 11:00:10 -0000 The following reply was made to PR kern/124127; it has been noted by GNATS. From: Andrew Bliznak To: bug-followup@FreeBSD.org, skylord@linkline.ru Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Mon, 6 Jul 2009 13:20:12 +0300 Same problem with Asus P5BV-C/4L in production. I found desktop with Asus P5LD2 MB and use it for experimental setup. Three host is same gig switch, msk0 configured with vlans and ipforwarding For tests I run iperf -c 192.168.4.21 -t 60000 -w 128k -P 4 between hosts on different vlans. 7.2-RELEASE kernel with if_msk* from head +patch. Need to specify ifconfig -vlanhwtag to run without input errors, after 30 minutes card locked, down/up interface not help, need to reboot. Next I connect disk witch Ubuntu 9.04, setup vlans, test run ok, little lover forwarding rate. After, boot again freebsd, run test. Hmm, test run ok... Reboot with stock 7.2-REL GENERIC kernel. Box running well over weekend... From owner-freebsd-net@FreeBSD.ORG Mon Jul 6 11:07:03 2009 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 D77111065673 for ; Mon, 6 Jul 2009 11:07:03 +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 C30158FC16 for ; Mon, 6 Jul 2009 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n66B73At010871 for ; Mon, 6 Jul 2009 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n66B73Cu010867 for freebsd-net@FreeBSD.org; Mon, 6 Jul 2009 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Jul 2009 11:07:03 GMT Message-Id: <200907061107.n66B73Cu010867@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, 06 Jul 2009 11:07:04 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem o kern/132984 net [netgraph] swi1: net 100% cpu usage f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 305 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 6 15:01:18 2009 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 C07131065675 for ; Mon, 6 Jul 2009 15:01:18 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) by mx1.freebsd.org (Postfix) with ESMTP id 775AE8FC21 for ; Mon, 6 Jul 2009 15:01:18 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-07-z2.arcor-online.net (mail-in-07-z2.arcor-online.net [151.189.8.19]) by mx.arcor.de (Postfix) with ESMTP id 3CAE32AEEA5 for ; Mon, 6 Jul 2009 16:30:20 +0200 (CEST) Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mail-in-07-z2.arcor-online.net (Postfix) with ESMTP id 35B9C2C826A for ; Mon, 6 Jul 2009 16:30:20 +0200 (CEST) Received: from lorvorc.mips.inka.de (dslb-092-075-198-166.pools.arcor-ip.net [92.75.198.166]) by mail-in-04.arcor-online.net (Postfix) with ESMTPS id DCD7933A942 for ; Mon, 6 Jul 2009 16:30:19 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-04.arcor-online.net DCD7933A942 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.3/8.14.3) with ESMTP id n66EUJ8o074456 for ; Mon, 6 Jul 2009 16:30:19 +0200 (CEST) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.3/8.14.3/Submit) id n66EUJv1074455 for freebsd-net@freebsd.org; Mon, 6 Jul 2009 16:30:19 +0200 (CEST) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Mon, 6 Jul 2009 14:30:19 +0000 (UTC) Message-ID: References: <20090702084608.GA59311@roberto-al.eurocontrol.fr> <200907020955.aa73037@walton.maths.tcd.ie> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-net@freebsd.org Subject: Re: NTP - default /etc/ntp.conf 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, 06 Jul 2009 15:01:19 -0000 David Malone wrote: > (Also, we probably really want people to run in orphan mode rather > than local clock mode, but we can wait a little longer until orphan > mode is more commonly deployed, IMHO...) I didn't know about orphan mode, so I had to try it right away. $ cat /etc/ntp.conf server 127.127.8.0 mode 14 fudge 127.127.8.0 time1 0.236 tos orphan 5 $ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *GENERIC(0) .DCFa. 0 l 27h 64 0 0.000 -1.255 0.793 Shouldn't ntpd have figured out by now that the clock is gone (I unplugged it yesterday) and have switched into orphan mode? -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-net@FreeBSD.ORG Mon Jul 6 23:37:02 2009 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 7D7551065672 for ; Mon, 6 Jul 2009 23:37:02 +0000 (UTC) (envelope-from louie@transsys.com) Received: from ringworld.transsys.com (ringworld.transsys.com [144.202.0.15]) by mx1.freebsd.org (Postfix) with ESMTP id 577EF8FC27 for ; Mon, 6 Jul 2009 23:37:02 +0000 (UTC) (envelope-from louie@transsys.com) Received: by ringworld.transsys.com (Postfix, from userid 1001) id 8A3565C5A; Mon, 6 Jul 2009 19:37:01 -0400 (EDT) Date: Mon, 6 Jul 2009 19:37:01 -0400 From: Louis Mamakos To: Christian Weisgerber Message-ID: <20090706233701.GA30824@ringworld.transsys.com> References: <20090702084608.GA59311@roberto-al.eurocontrol.fr> <200907020955.aa73037@walton.maths.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-net@freebsd.org Subject: Re: NTP - default /etc/ntp.conf 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, 06 Jul 2009 23:37:02 -0000 On Mon, Jul 06, 2009 at 02:30:19PM +0000, Christian Weisgerber wrote: > David Malone wrote: > > > (Also, we probably really want people to run in orphan mode rather > > than local clock mode, but we can wait a little longer until orphan > > mode is more commonly deployed, IMHO...) > > I didn't know about orphan mode, so I had to try it right away. > > $ cat /etc/ntp.conf > server 127.127.8.0 mode 14 > fudge 127.127.8.0 time1 0.236 > tos orphan 5 > $ ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > *GENERIC(0) .DCFa. 0 l 27h 64 0 0.000 -1.255 0.793 > > Shouldn't ntpd have figured out by now that the clock is gone (I > unplugged it yesterday) and have switched into orphan mode? > > -- > Christian "naddy" Weisgerber naddy@mips.inka.de It seems like orphan mode is something that you'd run on an ensemble of local machines to ensure that they continue to be synchronized with each other because that's deemed important for some application need. I don't understand why you'd go to all this trouble on a single host to simulate NTP clock synchronization when in fact the local clock isn't synchronized to anything? If you're concerned about keeping the local clock synchronized to UTC in the event that your NTP process is partitioned from it's external NTP peers, then you don't need to do anything. Once NTP has determined what you're clock's intrinsic frequency error is, the local clock model will contnue to apply this frequency correction even in the absence of external peers providing offset/delay samples. (This is the magic number squirreled away in /var/db/ntp.drift, or wherever it gets put these days.) louie From owner-freebsd-net@FreeBSD.ORG Tue Jul 7 03:46:17 2009 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 CBA091065672 for ; Tue, 7 Jul 2009 03:46:17 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 6C8AF8FC08 for ; Tue, 7 Jul 2009 03:46:17 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from fuzz.geek.sh (unknown [196.209.244.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id 924E83B580 for ; Tue, 7 Jul 2009 05:30:07 +0200 (SAST) Message-ID: <4A52C132.5080106@phat.za.net> Date: Tue, 07 Jul 2009 05:29:54 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.22 (X11/20090628) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: iwn(4) doesn't like hardware RF switches 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, 07 Jul 2009 03:46:18 -0000 Hi, Is it just me, or does the iwn driver in -CURRENT not play well with hardware RF switches on notebooks? For me the only resemblence of an event I see is when I switch off RF - the kernel sends a log to syslog. wpa_supplicant doesn't pick it up, and neither does devd. The result is that I can't keep wpa_supplicant running and let it reassociate when I turn off/on, and neither can I start/stop wpa_supplicant from devd when I turn on/off. I guess I could leave the RF switch on and just bind a key shortcut in Xorg to start/stop wpa_supplicant, but a standard approach would be nice... :) Thanks, Aragon From owner-freebsd-net@FreeBSD.ORG Tue Jul 7 09:51:29 2009 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 6D3D610656C3 for ; Tue, 7 Jul 2009 09:51:29 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: from mail.gmx.com (unknown [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id CC7578FC1C for ; Tue, 7 Jul 2009 09:51:28 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: (qmail invoked by alias); 07 Jul 2009 09:51:26 -0000 Received: from ipa49.88.91.tellas.gr (EHLO [192.168.1.5]) [91.140.88.49] by mail.gmx.com (mp-eu004) with SMTP; 07 Jul 2009 11:51:26 +0200 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX194xic7lQF4Oi5Ugrv78cVmnCb8RB8qS+8V7OMKKw /TH7TlTR3lP8Fd Message-ID: <4A531A94.40701@gmx.com> Date: Tue, 07 Jul 2009 12:51:16 +0300 From: Nikos Vassiliadis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Nikos Vassiliadis , freebsd-net@freebsd.org, weongyo.jeong@gmail.com References: <4A43386D.80500@gmx.com> <20090625103420.GD31161@weongyo.cdnetworks.kr> <4A436A8A.1000405@gmx.com> <20090626041246.GE31161@weongyo.cdnetworks.kr> <4A461AF9.7040900@gmx.com> <20090629032520.GA1138@weongyo.cdnetworks.kr> <4A4880EF.5010206@gmx.com> <4A4E2873.3010501@gmx.com> <20090706043747.GD1138@weongyo.cdnetworks.kr> In-Reply-To: <20090706043747.GD1138@weongyo.cdnetworks.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: Subject: Re: ndis and USB wirelless ethernet 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, 07 Jul 2009 09:51:29 -0000 Weongyo Jeong wrote: > I'm happy to see your device is successfully associated with AP. > However it seems it's a bad news that you sometimes meet crashes. Does > a random crash mean a OS hang (e.g. could not type any keys) or no more > work of network operations? It hangs, I cannot use the keyboard and I have to power-cycle it. It can happen after some time downloading and uploading. It hangs after 5 to 30 minutes of heavy traffic. By heavy traffic, I mean the maximum I can get from this device, which is 50KBytes/sec. I am not sure what will happen if I let it idle for, let's say one day, but I haven't had a single crash during times with low activity, such as ssh traffic. > Frankly speaking, for both cases it looks I could not provide any > solutions without backtraces unless I encountered same problems on my > environment. It'd better if we can reproduce its problem easily. Unfortunately, I have no solid facts to show you. The only strange thing I've seen and is consistent, is this: speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev USBdev 53 4K - 267579 16,32,128,1024 USBdev 53 4K - 267612 16,32,128,1024 USBdev 53 4K - 267642 16,32,128,1024 speed# speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev USBdev 53 4K - 268071 16,32,128,1024 USBdev 53 4K - 268101 16,32,128,1024 USBdev 53 4K - 268140 16,32,128,1024 And then with some traffic: speed# ping -i 0.01 192.168.1.1 > /dev/null & [1] 1777 speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev USBdev 53 4K - 270249 16,32,128,1024 USBdev 58 4K - 271095 16,32,128,1024 USBdev 56 4K - 272008 16,32,128,1024 speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev USBdev 54 4K - 279649 16,32,128,1024 USBdev 57 4K - 280544 16,32,128,1024 USBdev 54 4K - 281423 16,32,128,1024 I don't know how relevant is the above, but it seemed strange, so I am posting it... > One thing to hang as far as I know is that try to execute `ifconfig down > && ifconfig up' multiple times. In NDIS USB support it's recommended > that `ifconfig up' is executed once. OK, noted and avoided. > I think you can try another drivers. Will do. > AFAIK this behavior (ASSOC -> RUN) depends on the routine of the link > status change on NDIS driver that in private experience, some drivers > doesn't call the link status handler even if it's ready to use or call > the handler too early which is one of the abnormal. > > So don't know what's going on in NDIS driver currently. I see. Thanks again Weongyo for your help, I'll report again when I'll find some more useful bits about the problem. Regards, Nikos From owner-freebsd-net@FreeBSD.ORG Tue Jul 7 10:09:01 2009 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 709BF106564A for ; Tue, 7 Jul 2009 10:09:01 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: from mail.bindone.de (mail.bindone.de [80.190.134.51]) by mx1.freebsd.org (Postfix) with SMTP id B4D218FC20 for ; Tue, 7 Jul 2009 10:09:00 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: (qmail 96311 invoked by uid 89); 7 Jul 2009 10:08:59 -0000 Received: from unknown (HELO ufo.bindone.de) (mg@bindone.de@87.152.182.110) by mail.bindone.de with ESMTPA; 7 Jul 2009 10:08:59 -0000 Message-ID: <4A531E96.4060005@bindone.de> Date: Tue, 07 Jul 2009 12:08:22 +0200 From: Michael Gmelin User-Agent: Thunderbird 2.0.0.17pre (X11/20090202) MIME-Version: 1.0 To: Aragon Gouveia References: <4A52C132.5080106@phat.za.net> In-Reply-To: <4A52C132.5080106@phat.za.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: iwn(4) doesn't like hardware RF switches 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, 07 Jul 2009 10:09:01 -0000 Aragon Gouveia wrote: > Hi, > > Is it just me, or does the iwn driver in -CURRENT not play well with > hardware RF switches on notebooks? For me the only resemblence of an > event I see is when I switch off RF - the kernel sends a log to syslog. > wpa_supplicant doesn't pick it up, and neither does devd. The result > is that I can't keep wpa_supplicant running and let it reassociate when > I turn off/on, and neither can I start/stop wpa_supplicant from devd > when I turn on/off. > > I guess I could leave the RF switch on and just bind a key shortcut in > Xorg to start/stop wpa_supplicant, but a standard approach would be > nice... :) > > > Thanks, > Aragon > > > _______________________________________________ > 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" I can confirm this behaviour (+ sometimes iwn gets totally confused by that). What laptop are you using? From owner-freebsd-net@FreeBSD.ORG Tue Jul 7 12:42:35 2009 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 1584710656A7 for ; Tue, 7 Jul 2009 12:42:35 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id A64358FC12 for ; Tue, 7 Jul 2009 12:42:33 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from igor.geek.sh (unknown [196.209.244.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id 3DD683A465; Tue, 7 Jul 2009 14:42:32 +0200 (SAST) Message-ID: <4A5342B4.5080704@phat.za.net> Date: Tue, 07 Jul 2009 14:42:28 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.21 (X11/20090331) MIME-Version: 1.0 To: "Paul B. Mahol" , freebsd-net@freebsd.org References: <4A52C132.5080106@phat.za.net> <3a142e750907070115x737bb9edl7eb1d53708b845d0@mail.gmail.com> In-Reply-To: <3a142e750907070115x737bb9edl7eb1d53708b845d0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: iwn(4) doesn't like hardware RF switches 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, 07 Jul 2009 12:42:35 -0000 Paul B. Mahol wrote: > The only way to handle hardware RF switch is via devd(8). > ACPI notify devd(8) about state change and devd than can react on that change. > iwn(8) can do nothing about this. > What notebook do you have? Dell XPS M1330 Thanks, Aragon From owner-freebsd-net@FreeBSD.ORG Tue Jul 7 15:54:07 2009 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 32C0B1065672 for ; Tue, 7 Jul 2009 15:54:07 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-14.arcor-online.net (mail-in-14.arcor-online.net [151.189.21.54]) by mx1.freebsd.org (Postfix) with ESMTP id B041C8FC13 for ; Tue, 7 Jul 2009 15:54:06 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-19-z2.arcor-online.net (mail-in-19-z2.arcor-online.net [151.189.8.36]) by mx.arcor.de (Postfix) with ESMTP id 47D4B28ADFD for ; Tue, 7 Jul 2009 17:54:05 +0200 (CEST) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) by mail-in-19-z2.arcor-online.net (Postfix) with ESMTP id 535146BFBD for ; Tue, 7 Jul 2009 17:54:05 +0200 (CEST) Received: from lorvorc.mips.inka.de (dslb-092-075-193-151.pools.arcor-ip.net [92.75.193.151]) by mail-in-09.arcor-online.net (Postfix) with ESMTPS id 073401AF793 for ; Tue, 7 Jul 2009 17:54:04 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-09.arcor-online.net 073401AF793 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.3/8.14.3) with ESMTP id n67Fs4IJ077296 for ; Tue, 7 Jul 2009 17:54:04 +0200 (CEST) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.3/8.14.3/Submit) id n67Fs4jR077295 for freebsd-net@freebsd.org; Tue, 7 Jul 2009 17:54:04 +0200 (CEST) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Tue, 7 Jul 2009 15:54:04 +0000 (UTC) Message-ID: References: <20090702084608.GA59311@roberto-al.eurocontrol.fr> <200907020955.aa73037@walton.maths.tcd.ie> <20090706233701.GA30824@ringworld.transsys.com> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-net@freebsd.org Subject: Re: NTP - default /etc/ntp.conf 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, 07 Jul 2009 15:54:07 -0000 Louis Mamakos wrote: > > Shouldn't ntpd have figured out by now that the clock is gone (I > > unplugged it yesterday) and have switched into orphan mode? > > It seems like orphan mode is something that you'd run on an ensemble > of local machines to ensure that they continue to be synchronized with > each other because that's deemed important for some application need. > I don't understand why you'd go to all this trouble on a single host > to simulate NTP clock synchronization when in fact the local clock > isn't synchronized to anything? This particular setup is a single server with a bunch of clients. Even if the server loses its reference clock, the clients should all continue to have the same time. If the server reports that it is unsynchronized, the clients will ignore it and drift apart. Now, in my test case the server keeps thinking that it is synchronized to a dead refclock, which is fine for the clients. But I still wonder why it didn't switch into orphan mode. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-net@FreeBSD.ORG Tue Jul 7 16:34:54 2009 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 4E3EC106567D; Tue, 7 Jul 2009 16:34:54 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3422C8FC12; Tue, 7 Jul 2009 16:34:53 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n67GKJlO016282; Tue, 7 Jul 2009 09:20:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jul 2009 09:21:31 -0700 Message-ID: In-Reply-To: <4A4DF0BC.6090207@freebsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slow local TCP transfers on -CURRENT Thread-Index: Acn72fY87L7p95pxSAq8XABIgyUtVwDRPVkw References: <20090505160145.8C8F18FC15@mx1.freebsd.org> <4A4DF0BC.6090207@freebsd.org> From: "Li, Qing" To: "Lawrence Stewart" Cc: freebsd-net@freebsd.org, qingli@freebsd.org Subject: RE: Slow local TCP transfers on -CURRENT 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, 07 Jul 2009 16:34:55 -0000 Yes, this was fixed a couple of months ago. -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Lawrence Stewart > Sent: Friday, July 03, 2009 4:51 AM > To: Qing Li > Cc: freebsd-net@freebsd.org; qingli@freebsd.org > Subject: Re: Slow local TCP transfers on -CURRENT >=20 > Hi Qing, >=20 > Qing Li wrote: > >> Qing (added to CC) is aware of the problem. Not sure how far > >> off the fix is. > >> > > > > I am resuming the work on it, hoping to get it verified and > > finalized in a day or so. Sorry about the delay. >=20 > Did this ever get fixed? I don't think I saw a follow up to this thread > so just thought I'd check. >=20 > Cheers, > Lawrence > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Jul 8 00:22:46 2009 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 82F511065672 for ; Wed, 8 Jul 2009 00:22:46 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.216.172]) by mx1.freebsd.org (Postfix) with ESMTP id 522348FC0C for ; Wed, 8 Jul 2009 00:22:46 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by pxi2 with SMTP id 2so877773pxi.3 for ; Tue, 07 Jul 2009 17:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Q0/b8Ak3/3zux85sRKapMkhEKxOlaLr6hw+Ft4Xsmc8=; b=ouXd2iK6Xew+zpKRJEsb7XFd3qaDbUI/nuto1i+N+oBEnD+/p3ka5Op2TJZ6DSS1Fc MjlZF9518JJq2mHLi+5hCnpySbv0s+K2gjD1RHv7JoQ1cTP9U0/REjElq6ujRL+9KuAl vC/QXrdIM0tj4FHPagjgVqQuw7m9BhpEW3zIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=J0cFWTFRVYDSm6lE6k33qF11QlEZ9ZCj/sCGuvya5l1lN6oSfZ/H5pLtwlin0C1D5O LsyVaDvC8LUZawjVpD7HfmgJotil9e24EyGKwyci+FLzzpCjHmRuJf3+IwMs6Twb+Bb9 NHbhx1zXAMWNydnXGclArvIEuaPOHHhe8zQpA= MIME-Version: 1.0 Received: by 10.143.165.19 with SMTP id s19mr2102214wfo.187.1247012565910; Tue, 07 Jul 2009 17:22:45 -0700 (PDT) In-Reply-To: <2a41acea0906280952s23d6553ep42fcfd4671561c3a@mail.gmail.com> References: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> <2a41acea0906261725x57e6903br9f3f42b55f3a3d30@mail.gmail.com> <688430.20427.qm@web37906.mail.mud.yahoo.com> <2a41acea0906280952s23d6553ep42fcfd4671561c3a@mail.gmail.com> Date: Tue, 7 Jul 2009 17:22:45 -0700 Message-ID: <2a41acea0907071722p7992bea0s281399cb0baecd90@mail.gmail.com> From: Jack Vogel To: Mark Atkinson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Regression: em driver in -CURRENT, "Invalid MAC address" 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, 08 Jul 2009 00:22:46 -0000 In case you hadn't seen it, the code that fixes this is now checked into the tip, so the latest em driver should work for you. Jack On Sun, Jun 28, 2009 at 9:52 AM, Jack Vogel wrote: > Sigh.. both windows and linux have frozen drivers for this old hardware, > therefore they never see the regressions they cause in the current code :( > > I will make a patch for you to test on Monday Mark, it will do the same > thing > that I did in the e1000_82540.c, basically change the read_mac function > back > to the older way of doing it. > > Regards, > > Jack > > > > > On Sat, Jun 27, 2009 at 10:36 PM, Mark Atkinson wrote: > >> >> >> ________________________________ >> >From: Jack Vogel >> >Oh, hmmm, so this card is completely broken with the new driver then? >> >> Completely, unfortunately (they don't show up in ifconfig, only in >> dmesg/pciconf). >> >> >What was the last working version you used? >> >> I was running a kernel from -current May 27th, 2009. I don't recall >> any significant em updates between then and when the new driver went >> in. >> >> On Fri, Jun 26, 2009 at 11:36 AM, Mark Atkinson >> wrote: >> Jack Vogel wrote: >> > I'm willing to bet that its in fact the same problem that VMWare is >> > having. Our method of getting the mac address changed, and the >> emulations >> > seem to be unprepared for it. >> > >> > This was done for a real customer requirement to allow support of >> > alternate mac addressing in firmware. What happens now is a warm reset >> of >> > the hardware is done, followed by reading the RAR[0] register. In a real >> > Intel NIC the mac >> > address will be valid in that register, but in VMWare, and I'm willing >> to >> > bet in >> > VirtualBox as well, its 0. >> > >> > VMWare also has 3 choices of device (wow, amazing coincidence :), can >> > you tell me when you pick e1000 what real adapter it claims to emulate? >> > >> > I am considering options for this problem. The one I lean toward right >> now >> > is to make a "legacy" em driver, it will have support for ONLY pre-PCI >> > Express >> > hardware, it will be frozen as it were, the idea is that with no new >> work >> > on it >> > it will not suffer from any regression type failures. If I do this, >> there >> > are some >> > strategy issues, and its those I'm thinking about. >> > >> > In any case, I intend to have this problem resolved for 8's release. >> Stay >> > tuned. >> >> Just FYI. this is a real machine with real cards. Older fiber cards. >> >> em0: mem >> 0xdb000000-0xdb01ffff >> irq 28 at device 4.0 on pci19 >> em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb000000 >> >> em0: Invalid MAC address >> device_attach: em0 attach returned 5 >> em1: mem >> 0xdb020000-0xdb03ffff >> irq 29 at device 9.0 on pci19 >> em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb020000 >> >> em1: Invalid MAC address >> device_attach: em1 attach returned 5 >> >> >> $ pciconf -v -l |grep -A4 -e "^em" >> em0@pci0:19:4:0: class=0x020000 card=0x10008086 chip=0x10008086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82542 Gigabit Ethernet Controller' >> class = network >> subclass = ethernet >> em1@pci0:19:9:0: class=0x020000 card=0x10008086 chip=0x10008086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82542 Gigabit Ethernet Controller' >> class = network >> subclass = ethernet >> >> >> >> -- >> Mark Atkinson >> atkin901@yahoo.com >> (!wired)?(coffee++):(wired); >> >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> >> >> > From owner-freebsd-net@FreeBSD.ORG Wed Jul 8 05:00:15 2009 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 6389B1065673 for ; Wed, 8 Jul 2009 05:00:15 +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 369E38FC13 for ; Wed, 8 Jul 2009 05:00:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n6850F6E036720 for ; Wed, 8 Jul 2009 05:00:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n6850FAp036717; Wed, 8 Jul 2009 05:00:15 GMT (envelope-from gnats) Date: Wed, 8 Jul 2009 05:00:15 GMT Message-Id: <200907080500.n6850FAp036717@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Pyun YongHyeon Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pyun YongHyeon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 05:00:15 -0000 The following reply was made to PR kern/124127; it has been noted by GNATS. From: Pyun YongHyeon To: "Dmitry A.Deineka" Cc: bug-followup@freebsd.org Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Wed, 8 Jul 2009 13:58:02 +0900 On Wed, Jul 01, 2009 at 03:59:22PM +0300, Dmitry A.Deineka wrote: > Hi, > > have same problem, motherboard Asus P5K-VM with marvell yukon onboard: > mskc0: port 0xd800-0xd8ff mem > 0xfeafc000-0xfeafffff irq 17 at device 0.0 on pci1 > msk0: on > mskc0 > msk0: Ethernet address: 00:1e:8c:5e:f8:92 > > > Problem confirmed with FreeBSD 7.x, now installed 8.0-CURRENT-200906 > with the same problem (and the same msk driver, as I see in source). > > Patch from Pyun YongHyeon in this PR applied, but it not fix problem. > Downloading large file by ftp from another server causes following: > > Jul 1 15:43:58 msktest kernel: msk0: watchdog timeout > Jul 1 15:43:58 msktest kernel: msk0: link state changed to DOWN > Jul 1 15:44:00 msktest kernel: msk0: link state changed to UP > Jul 1 15:44:38 msktest kernel: msk0: watchdog timeout > Jul 1 15:44:38 msktest kernel: msk0: link state changed to DOWN > Jul 1 15:44:40 msktest kernel: msk0: link state changed to UP > Jul 1 15:45:03 msktest kernel: msk0: watchdog timeout > Jul 1 15:45:03 msktest kernel: msk0: link state changed to DOWN > Jul 1 15:45:05 msktest kernel: msk0: link state changed to UP > Jul 1 15:45:28 msktest kernel: msk0: watchdog timeout > Jul 1 15:45:28 msktest kernel: msk0: link state changed to DOWN > Jul 1 15:45:30 msktest kernel: msk0: link state changed to UP > Jul 1 15:46:07 msktest kernel: msk0: watchdog timeout > Jul 1 15:46:07 msktest kernel: msk0: link state changed to DOWN > Jul 1 15:46:09 msktest kernel: msk0: link state changed to UP > Jul 1 15:46:24 msktest kernel: msk0: watchdog timeout > Jul 1 15:46:24 msktest kernel: msk0: link state changed to DOWN > Jul 1 15:46:26 msktest kernel: msk0: link state changed to UP > Jul 1 15:47:07 msktest kernel: msk0: watchdog timeout > Jul 1 15:47:07 msktest kernel: msk0: link state changed to DOWN > Jul 1 15:47:09 msktest kernel: msk0: link state changed to UP > Jul 1 15:48:33 msktest kernel: msk0: watchdog timeout > Jul 1 15:48:33 msktest kernel: msk0: link state changed to DOWN > Jul 1 15:48:35 msktest kernel: msk0: link state changed to UP > > > Hope this helps. > I guess you're suffering from difference issues. Support for Yukon Ultra was known to be unstable. I had tried hard to address the issue but lack of the hardware was major bottle-neck. Original submitter' hardware is not Yukon Ultra and looks like some timing issues related with interrupt level timer, Tx threshold. It would be great if original submitter can test previous patch. > With best regards, > Dmitry From owner-freebsd-net@FreeBSD.ORG Wed Jul 8 05:10:06 2009 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 0F130106564A for ; Wed, 8 Jul 2009 05:10:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F09168FC18 for ; Wed, 8 Jul 2009 05:10:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n685A51D048655 for ; Wed, 8 Jul 2009 05:10:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n685A5o7048654; Wed, 8 Jul 2009 05:10:05 GMT (envelope-from gnats) Date: Wed, 8 Jul 2009 05:10:05 GMT Message-Id: <200907080510.n685A5o7048654@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Pyun YongHyeon Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pyun YongHyeon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 05:10:06 -0000 The following reply was made to PR kern/124127; it has been noted by GNATS. From: Pyun YongHyeon To: Andrew Bliznak Cc: bug-followup@FreeBSD.org, skylord@linkline.ru Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Wed, 8 Jul 2009 14:03:58 +0900 On Mon, Jul 06, 2009 at 11:00:09AM +0000, Andrew Bliznak wrote: > The following reply was made to PR kern/124127; it has been noted by GNATS. > > From: Andrew Bliznak > To: bug-followup@FreeBSD.org, skylord@linkline.ru > Cc: > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- > recovering > Date: Mon, 6 Jul 2009 13:20:12 +0300 > > Same problem with Asus P5BV-C/4L in production. > Show me dmesg output (msk(4) and e1000phy(4) part) to see what controller you have. Due to the diverse Yukon controllers and their silicon bugs for each revision it's really hard to tell you're seeing the same issue of this PR. Please show me more information. > I found desktop with Asus P5LD2 MB and use it for experimental setup. > Three host is same gig switch, msk0 configured with vlans and > ipforwarding > For tests I run iperf -c 192.168.4.21 -t 60000 -w 128k -P 4 between > hosts on different vlans. > 7.2-RELEASE kernel with if_msk* from head +patch. Need to specify > ifconfig -vlanhwtag to run without input errors, > after 30 minutes card locked, down/up interface not help, need to reboot. Need to know which controller you have. > Next I connect disk witch Ubuntu 9.04, setup vlans, test run ok, > little lover forwarding rate. > After, boot again freebsd, run test. Hmm, test run ok... > Reboot with stock 7.2-REL GENERIC kernel. Box running well over weekend... This confuse me. So you don't see issues any more? From owner-freebsd-net@FreeBSD.ORG Wed Jul 8 12:43:11 2009 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 DDE221065670 for ; Wed, 8 Jul 2009 12:43:11 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 2FF558FC18 for ; Wed, 8 Jul 2009 12:43:10 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: (qmail 31986 invoked from network); 8 Jul 2009 12:16:30 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 8 Jul 2009 12:16:30 -0000 Date: Wed, 08 Jul 2009 14:16:30 +0200 (CEST) Message-Id: <20090708.141630.78743642.sthaug@nethelp.no> To: freebsd-net@freebsd.org From: sthaug@nethelp.no X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Missing MFC of Silbersack/Klein IP id generation? 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, 08 Jul 2009 12:43:12 -0000 According to the comments for rev. 1.10 of netinet/ip_id.c, from http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_id.c this is to be MFCed after 2 weeks (i.e. 2 weeks after 6. February 2008). And yet here we are in July 2009, and 7-STABLE shows no sign of this version of the IP id generation code but instead has the version that Amit Klein showed had problems, http://www.trusteer.com/docs/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf Is this a deliberate choice? Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Wed Jul 8 20:50:51 2009 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 776E2106566C; Wed, 8 Jul 2009 20:50:51 +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 4DC2A8FC08; Wed, 8 Jul 2009 20:50:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n68KopbC090542; Wed, 8 Jul 2009 20:50:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n68KopEm090538; Wed, 8 Jul 2009 20:50:51 GMT (envelope-from linimon) Date: Wed, 8 Jul 2009 20:50:51 GMT Message-Id: <200907082050.n68KopEm090538@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/136482: [age] Attansic L1 Gigabit Ethernet recieves multicasts only in promisc mode 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, 08 Jul 2009 20:50:52 -0000 Synopsis: [age] Attansic L1 Gigabit Ethernet recieves multicasts only in promisc mode Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 8 20:50:44 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=136482 From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 03:47:09 2009 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 390DA10656C2 for ; Thu, 9 Jul 2009 03:47:09 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.216.172]) by mx1.freebsd.org (Postfix) with ESMTP id F3F978FC0A for ; Thu, 9 Jul 2009 03:47:08 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by mail-px0-f172.google.com with SMTP id 2so1496230pxi.3 for ; Wed, 08 Jul 2009 20:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=aJ9jvt1pEK+0Z7EqIAfByQkkGRD1bwJARifdtMBIO7s=; b=rf4Sx4u+/suzrVT6ED89TzgWxX1NFuiIC60B+tYfX/aeiIetFHK8U7ZmdFE6YP+Pfl 6LBNt3frsQbI13MMtxKy6Pk6QulI2I5oWlHa6+pLxWqN627ZsUBHbXDU8OIrbn4Kw0a9 e0ph3v+hpIdpWWFqcntJDJAfif8GWAuwisufI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=rEzudAiEVF4ueJrOLsI6cqxPfclBnfDOehHF+qhOs7fYqsyI0yFUPJqFyO3M+kojBH KNAjtz41zIT3/H/KmmJFd23lnqY6K9xwiDLNTN1++zZWopUx3NoPQbU3akaG7UBGA2Gn ySF1pNIyWa7hqGe1RfR+pFTolnkUwIyEcYtjA= Received: by 10.140.141.21 with SMTP id o21mr141837rvd.92.1247107016851; Wed, 08 Jul 2009 19:36:56 -0700 (PDT) Received: from weongyo ([114.111.62.249]) by mx.google.com with ESMTPS id c20sm3384365rvf.31.2009.07.08.19.36.54 (version=SSLv3 cipher=RC4-MD5); Wed, 08 Jul 2009 19:36:55 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Thu, 9 Jul 2009 11:36:51 +0900 From: Weongyo Jeong Date: Thu, 9 Jul 2009 11:36:51 +0900 To: Nikos Vassiliadis Message-ID: <20090709023651.GA1553@weongyo.cdnetworks.kr> Mail-Followup-To: Nikos Vassiliadis , freebsd-net@freebsd.org References: <4A43386D.80500@gmx.com> <20090625103420.GD31161@weongyo.cdnetworks.kr> <4A436A8A.1000405@gmx.com> <20090626041246.GE31161@weongyo.cdnetworks.kr> <4A461AF9.7040900@gmx.com> <20090629032520.GA1138@weongyo.cdnetworks.kr> <4A4880EF.5010206@gmx.com> <4A4E2873.3010501@gmx.com> <20090706043747.GD1138@weongyo.cdnetworks.kr> <4A531A94.40701@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A531A94.40701@gmx.com> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-net@freebsd.org Subject: Re: ndis and USB wirelless ethernet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 03:47:09 -0000 On Tue, Jul 07, 2009 at 12:51:16PM +0300, Nikos Vassiliadis wrote: > Weongyo Jeong wrote: > >I'm happy to see your device is successfully associated with AP. > >However it seems it's a bad news that you sometimes meet crashes. Does > >a random crash mean a OS hang (e.g. could not type any keys) or no more > >work of network operations? > > It hangs, I cannot use the keyboard and I have to power-cycle it. > It can happen after some time downloading and uploading. It hangs > after 5 to 30 minutes of heavy traffic. By heavy traffic, I mean > the maximum I can get from this device, which is 50KBytes/sec. > > I am not sure what will happen if I let it idle for, let's say > one day, but I haven't had a single crash during times with > low activity, such as ssh traffic. > > >Frankly speaking, for both cases it looks I could not provide any > >solutions without backtraces unless I encountered same problems on my > >environment. It'd better if we can reproduce its problem easily. > > Unfortunately, I have no solid facts to show you. The only strange > thing I've seen and is consistent, is this: > > speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; > sleep 1 ; vmstat -m | grep USBdev > USBdev 53 4K - 267579 16,32,128,1024 > USBdev 53 4K - 267612 16,32,128,1024 > USBdev 53 4K - 267642 16,32,128,1024 > speed# > speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; > sleep 1 ; vmstat -m | grep USBdev > USBdev 53 4K - 268071 16,32,128,1024 > USBdev 53 4K - 268101 16,32,128,1024 > USBdev 53 4K - 268140 16,32,128,1024 > > And then with some traffic: > speed# ping -i 0.01 192.168.1.1 > /dev/null & > [1] 1777 > speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; > sleep 1 ; vmstat -m | grep USBdev > USBdev 53 4K - 270249 16,32,128,1024 > USBdev 58 4K - 271095 16,32,128,1024 > USBdev 56 4K - 272008 16,32,128,1024 > speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; > sleep 1 ; vmstat -m | grep USBdev > USBdev 54 4K - 279649 16,32,128,1024 > USBdev 57 4K - 280544 16,32,128,1024 > USBdev 54 4K - 281423 16,32,128,1024 > > I don't know how relevant is the above, but it seemed strange, > so I am posting it... It's a normal case that in implementation it allocates a memory buffer for transactions. So if it increases without any reduction it'd be a problem. regards, Weongyo Jeong From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 04:27:50 2009 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 1578510656EB for ; Thu, 9 Jul 2009 04:27:50 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (mail.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id C3DDF8FC28 for ; Thu, 9 Jul 2009 04:27:49 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id n68N1ZZM049585; Wed, 8 Jul 2009 17:01:35 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.3/8.14.3) with ESMTP id n68N1ZXj008411; Wed, 8 Jul 2009 17:01:35 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.3/8.14.3/Submit) id n68N1ZBQ008408; Wed, 8 Jul 2009 17:01:35 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19029.9551.628427.146587@gromit.timing.com> Date: Wed, 8 Jul 2009 17:01:35 -0600 From: John Hein To: net@freebsd.org In-Reply-To: <19029.5367.534192.928426@gromit.timing.com> References: <19029.4145.296260.915327@gromit.timing.com> <19029.5367.534192.928426@gromit.timing.com> X-Mailer: VM 7.19 under Emacs 22.3.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: Subject: Re: network lock manager (lockd) deadlocked in 'rpcrecv' 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, 09 Jul 2009 04:27:51 -0000 John Hein wrote at 15:51 -0600 on Jul 8, 2009: > John Hein wrote at 15:31 -0600 on Jul 8, 2009: > > I have a home directory on FreeBSD 7.2-stable (20090705), amd64. > > It is serving up the directory over nfs (v3, tcp), and now > > I'm seeing lots of 'lockd not responding' on Fedora 10 & 11 systems. . . > Also in dmesg: > > NLM: failed to contact remote rpcbind, stat = 5, port = 28416 . . Here's some good information. This seems to happen when there are 2 or more Fedora systems trying to access locks via lockd. Rebooting the Fedora box that has 'lockd not responding' frees up the deadlocked freebsd lockd. But _also_ disabling the firewall on the Fedora boxes helps, too. This doesn't necessarily completely implicate or exonerate lockd. But what should lockd do when the remote box asks for a lock, but doesn't complete the RPC dialog? Is there a way we can deal with this problem and not have lockd deadlock? From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 04:27:51 2009 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 9BF1910656FC for ; Thu, 9 Jul 2009 04:27:50 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (mail.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id 52DD38FC17 for ; Thu, 9 Jul 2009 04:27:50 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id n68LVVpB041218 for ; Wed, 8 Jul 2009 15:31:31 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.3/8.14.3) with ESMTP id n68LVTwp007108; Wed, 8 Jul 2009 15:31:29 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.3/8.14.3/Submit) id n68LVTjL007105; Wed, 8 Jul 2009 15:31:29 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19029.4145.296260.915327@gromit.timing.com> Date: Wed, 8 Jul 2009 15:31:29 -0600 From: John Hein To: net@freebsd.org X-Mailer: VM 7.19 under Emacs 22.3.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: Subject: network lock manager (lockd) deadlocked in 'rpcrecv' 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, 09 Jul 2009 04:27:53 -0000 I have a home directory on FreeBSD 7.2-stable (20090705), amd64. It is serving up the directory over nfs (v3, tcp), and now I'm seeing lots of 'lockd not responding' on Fedora 10 & 11 systems. USER PID PPID SID NI %CPU %MEM VSZ RSS TT WCHAN STAT STARTED TIME COMMAND root 791 1 791 0 0.0 0.0 6748 1500 ?? rpcrec Ds 2:45PM 0:05.80 /usr/sbin/rpc.lockd Once lockd gets in this state, doing a test lock on a file from a FreeBSD box locks with 'lockd not responding', too (and ctrl-c and kill -9 does nothing). USER PID PPID SID NI %CPU %MEM VSZ RSS TT WCHAN STAT STARTED TIME COMMAND jhein 6297 3491 3491 0 0.0 0.0 1412 604 p5 nlmrcv T+ 3:18PM 0:00.00 /h/jhein/nfslocktest /nfs/locktest I see this on an i386 6.4-stable, too. From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 04:27:53 2009 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 3396D1065707 for ; Thu, 9 Jul 2009 04:27:51 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (mail.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id CA2B18FC2D for ; Thu, 9 Jul 2009 04:27:50 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id n68Lprar043237 for ; Wed, 8 Jul 2009 15:51:53 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.3/8.14.3) with ESMTP id n68LppuT007333; Wed, 8 Jul 2009 15:51:51 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.3/8.14.3/Submit) id n68Lpp8U007330; Wed, 8 Jul 2009 15:51:51 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19029.5367.534192.928426@gromit.timing.com> Date: Wed, 8 Jul 2009 15:51:51 -0600 From: John Hein To: net@freebsd.org In-Reply-To: <19029.4145.296260.915327@gromit.timing.com> References: <19029.4145.296260.915327@gromit.timing.com> X-Mailer: VM 7.19 under Emacs 22.3.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: Subject: Re: network lock manager (lockd) deadlocked in 'rpcrecv' 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, 09 Jul 2009 04:27:54 -0000 John Hein wrote at 15:31 -0600 on Jul 8, 2009: > I have a home directory on FreeBSD 7.2-stable (20090705), amd64. > It is serving up the directory over nfs (v3, tcp), and now > I'm seeing lots of 'lockd not responding' on Fedora 10 & 11 systems. > > USER PID PPID SID NI %CPU %MEM VSZ RSS TT WCHAN STAT STARTED TIME COMMAND > root 791 1 791 0 0.0 0.0 6748 1500 ?? rpcrec Ds 2:45PM 0:05.80 /usr/sbin/rpc.lockd > > Once lockd gets in this state, doing a test lock on a file > from a FreeBSD box locks with 'lockd not responding', too > (and ctrl-c and kill -9 does nothing). > > USER PID PPID SID NI %CPU %MEM VSZ RSS TT WCHAN STAT STARTED TIME COMMAND > jhein 6297 3491 3491 0 0.0 0.0 1412 604 p5 nlmrcv T+ 3:18PM 0:00.00 /h/jhein/nfslocktest /nfs/locktest > > > I see this on an i386 6.4-stable, too. Also in dmesg: NLM: failed to contact remote rpcbind, stat = 5, port = 28416 And from ddb... Tracing command rpc.lockd pid 791 tid 100176 td 0xffffff00069dd720 sched_switch() at 0xffffffff8037df95 = sched_switch+0x1d5 mi_switch() at 0xffffffff803656fb = mi_switch+0x18b sleepq_timedwait() at 0xffffffff80390aeb = sleepq_timedwait+0x3b _sleep() at 0xffffffff80365cd4 = _sleep+0x324 clnt_dg_call() at 0xffffffff80504a0b = clnt_dg_call+0x4fb nlm_get_rpc() at 0xffffffff804f3ef7 = nlm_get_rpc+0x147 nlm_host_get_rpc() at 0xffffffff804f430e = nlm_host_get_rpc+0x10e nlm_do_lock() at 0xffffffff804f58be = nlm_do_lock+0x1ce nlm4_lock_4_svc() at 0xffffffff804f6c91 = nlm4_lock_4_svc+0x11 nlm_prog_4() at 0xffffffff804f8098 = nlm_prog_4+0x308 svc_run() at 0xffffffff8050c1f3 = svc_run+0x293 nlm_syscall() at 0xffffffff804f675c = nlm_syscall+0x79c syscall() at 0xffffffff805818f4 = syscall+0x1b4 Xfast_syscall() at 0xffffffff8056d35b = Xfast_syscall+0xab --- syscall (154, FreeBSD ELF64, nlm_syscall), rip = 0x8008a91ec, rsp = 0x7fffffffed08, rbp = 0x7fffffffe e20 --- From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 09:20:41 2009 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 8AF221065673; Thu, 9 Jul 2009 09:20:41 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id D011C8FC28; Thu, 9 Jul 2009 09:20:40 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 9 Jul 2009 10:20:32 +0100 (BST) Received: from localhost ([127.0.0.1] helo=maths.tcd.ie) by walton.maths.tcd.ie with SMTP id ; 9 Jul 2009 10:20:30 +0100 (BST) To: Ollivier Robert In-reply-to: Your message of "Thu, 02 Jul 2009 10:46:08 +0200." <20090702084608.GA59311@roberto-al.eurocontrol.fr> Date: Thu, 09 Jul 2009 10:20:29 +0100 From: David Malone Message-ID: <200907091020.aa42546@walton.maths.tcd.ie> Cc: freebsd-net@freebsd.org, Edwin Groothuis Subject: Re: NTP - default /etc/ntp.conf 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, 09 Jul 2009 09:20:41 -0000 The NTP pool guys have set up our vendor domain. I'd like to commit the patch below to ntp.conf. It does the following: 1) Uses our vendor domain at the pool. 2) Points people at the pool website and encourages people to provide a server in the pool (as a courtesy to the pool guys). 3) Fixes a spelling. 4) Comments out the local clock and includes a link to documentation for use of the local clock on the ntp.org site. If there are no objections, I'll ask re@ for permission to commit this. David. Index: ntp.conf =================================================================== --- ntp.conf (revision 195484) +++ ntp.conf (working copy) @@ -13,19 +13,22 @@ # # The following three servers will give you a random set of three # NTP servers geographically close to you. -# See http://en.wikipedia.org/wiki/NTP_pool for details. +# See http://www.pool.ntp.org/ for details. Note, the pool encourages +# users with a static IP and good upstream NTP servers to add a server +# to the pool. See http://www.pool.ntp.org/join.html if you are interested. # # The option `iburst' is used for faster initial synchronisation. # The option `maxpoll 9' is used to prevent PLL/FLL flipping on FreeBSD. # -server 0.pool.ntp.org iburst maxpoll 9 -server 1.pool.ntp.org iburst maxpoll 9 -server 2.pool.ntp.org iburst maxpoll 9 +server 0.freebsd.pool.ntp.org iburst maxpoll 9 +server 1.freebsd.pool.ntp.org iburst maxpoll 9 +server 2.freebsd.pool.ntp.org iburst maxpoll 9 +#server 3.freebsd.pool.ntp.org iburst maxpoll 9 # # If you want to pick yourself which country's public NTP server # you want sync against, comment out the above servers, uncomment -# the next ones and replace CC with the country's abbrevation. +# the next ones and replace CC with the country's abbreviation. # Make sure that the hostnames resolve to a proper IP address! # # server 0.CC.pool.ntp.org iburst maxpoll 9 @@ -50,10 +53,12 @@ #restrict 127.127.1.0 # -# If we lose sync against all configured servers, the NTP clients -# syncing against this server will lose sync too. To overcome this, -# we will act as a stratum 10 server with our own internal clock -# so that everybody at least will have the same time as we have. +# If a server loses sync with all upstream servers, NTP clients +# no longer follow that server. The local clock can be configured +# to provide a time source when this happens, but it should usually +# be configured on just one server on a network. For more details see +# http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock +# The use of Orphan Mode may be preferable. # -server 127.127.1.0 -fudge 127.127.1.0 stratum 10 +#server 127.127.1.0 +#fudge 127.127.1.0 stratum 10 From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 09:27:08 2009 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 CBD9F1065670; Thu, 9 Jul 2009 09:27:08 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id 551688FC0C; Thu, 9 Jul 2009 09:27:08 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 315C639E10; Thu, 9 Jul 2009 11:27:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czRoBp0vrcm2; Thu, 9 Jul 2009 11:27:05 +0200 (CEST) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id 019C939E0D; Thu, 9 Jul 2009 11:27:04 +0200 (CEST) Date: Thu, 9 Jul 2009 11:27:00 +0200 From: Ollivier Robert To: David Malone Message-ID: <20090709092700.GA64721@roberto-al.eurocontrol.fr> References: <20090702084608.GA59311@roberto-al.eurocontrol.fr> <200907091020.aa42546@walton.maths.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907091020.aa42546@walton.maths.tcd.ie> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org, Edwin Groothuis Subject: Re: NTP - default /etc/ntp.conf 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, 09 Jul 2009 09:27:09 -0000 According to David Malone: > The NTP pool guys have set up our vendor domain. I'd like to commit > the patch below to ntp.conf. It does the following: Approval from me, thanks. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 11:50:03 2009 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 886D3106564A for ; Thu, 9 Jul 2009 11: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 75D548FC0A for ; Thu, 9 Jul 2009 11: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.3/8.14.3) with ESMTP id n69Bo3Zp069460 for ; Thu, 9 Jul 2009 11:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n69Bo385069459; Thu, 9 Jul 2009 11:50:03 GMT (envelope-from gnats) Date: Thu, 9 Jul 2009 11:50:03 GMT Message-Id: <200907091150.n69Bo385069459@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Andrew Bliznak Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Bliznak List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 11:50:03 -0000 The following reply was made to PR kern/124127; it has been noted by GNATS. From: Andrew Bliznak To: pyunyh@gmail.com Cc: bug-followup@freebsd.org Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Thu, 9 Jul 2009 14:48:12 +0300 2009/7/8 Pyun YongHyeon : > On Mon, Jul 06, 2009 at 11:00:09AM +0000, Andrew Bliznak wrote: >> The following reply was made to PR kern/124127; it has been noted by GNA= TS. >> >> From: Andrew Bliznak >> To: bug-followup@FreeBSD.org, skylord@linkline.ru >> Cc: >> Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) = -- >> =A0 =A0 =A0 recovering >> Date: Mon, 6 Jul 2009 13:20:12 +0300 >> >> =A0Same problem with Asus P5BV-C/4L in production. >> > > Show me dmesg output (msk(4) and e1000phy(4) part) to see what > controller you have. Due to the diverse Yukon controllers and their > silicon bugs for each revision it's really hard to tell you're > seeing the same issue of this PR. Please show me more information. > mskc0: port 0xd800-0xd8ff mem 0xfbefc000-0xfbefffff irq 18 at device 0.0 on pci5 msk0: on ms= kc0 msk0: Ethernet address: 00:22:15:ef:02:06 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX,= auto mskc0: [FILTER] Huh, yes, it's different problem, which bug number for this? >> =A0I found desktop with Asus P5LD2 MB and use it for experimental setup. >> =A0Three host is same gig switch, msk0 configured with vlans and >> =A0ipforwarding >> =A0For tests I run iperf -c 192.168.4.21 -t 60000 -w 128k -P 4 between >> =A0hosts on different vlans. >> =A07.2-RELEASE kernel with if_msk* from head +patch. Need to specify >> =A0ifconfig -vlanhwtag =A0to run without input errors, >> =A0after 30 minutes card locked, =A0down/up interface not help, need to = reboot. > > Need to know which controller you have. > mskc0: port 0xc800-0xc8ff mem 0xcbffc000-0xcbffffff irq 19 at device 0.0 on pci2 mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xcbffc000 mskc0: MSI count : 2 mskc0: attempting to allocate 2 MSI vectors (2 supported) mskc0: using IRQs 256-257 for MSI mskc0: RAM buffer size : 48KB mskc0: Port 0 : Rx Queue 32KB(0x00000000:0x00007fff) mskc0: Port 0 : Tx Queue 16KB(0x00008000:0x0000bfff) msk0: on mskc0 msk0: bpf attached msk0: Ethernet address: 00:17:31:bd:1a:64 miibus0: on msk0 mskc0: [MPSAFE] mskc0: [FILTER] mskc0: Uncorrectable PCI Express error msk0: link state changed to UP >> =A0Next I connect disk witch Ubuntu 9.04, setup vlans, test run ok, >> =A0little lover forwarding rate. >> =A0After, boot again freebsd, run test. Hmm, test run ok... >> =A0Reboot with stock 7.2-REL GENERIC kernel. Box running well over weeke= nd... > > This confuse me. So you don't see issues any more? > Yes. I instaled 8.0-BETA1-amd64 on this box, rerun tests, all ok. Also try clear CMOS from BIOS - no change. Next, I reflash BIOS from disket= te and problem returns. Build new kernel with patch-2.diff, now test run ok. Rebuild kernel without patch, and this time msk works. Look like very strange HW, but patch obviously helped. From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 12:09:34 2009 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 260CA1065674 for ; Thu, 9 Jul 2009 12:09:34 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: from mail.gmx.com (unknown [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 710158FC1A for ; Thu, 9 Jul 2009 12:09:33 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: (qmail invoked by alias); 09 Jul 2009 12:09:31 -0000 Received: from unknown (EHLO [192.168.1.5]) [79.107.65.122] by mail.gmx.com (mp-eu001) with SMTP; 09 Jul 2009 14:09:31 +0200 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX19NzE01Vm5NKFH/uiD33vO+AhQ9ciTyu6DjQl2Thr saRCF12ke8fokh Message-ID: <4A55DDE8.9090808@gmx.com> Date: Thu, 09 Jul 2009 15:09:12 +0300 From: Nikos Vassiliadis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Subject: localhost routes are not displayed when using multiple routing tables 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, 09 Jul 2009 12:09:34 -0000 Hello, I noticed this: > speed# netstat -rnfinet > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > 127.0.0.1 link#4 UH 0 0 lo0 > 192.168.1.0/24 link#6 U 1 193 wlan0 > 192.168.1.6 link#4 UHS 0 0 lo0 > speed# setfib 1 netstat -rnfinet > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > 127.0.0.1 link#4 UH 0 0 lo0 > 192.168.1.0/24 link#6 U 0 0 wlan0 > speed# The routing entry for 192.168.1.6 is missing from the second routing table. 192.168.1.6 is actually routed through lo0 on every FIB. But, for formality reasons, shouldn't it be there, appearing when one examines the routing table? Nikos From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 14:19:12 2009 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 615141065679 for ; Thu, 9 Jul 2009 14:19:12 +0000 (UTC) (envelope-from lconrad@Go2France.com) Received: from mgw1.MEIway.com (mgw1.meiway.com [81.255.84.75]) by mx1.freebsd.org (Postfix) with ESMTP id E6C2F8FC0C for ; Thu, 9 Jul 2009 14:19:11 +0000 (UTC) (envelope-from lconrad@Go2France.com) Received: from VirusGate.MEIway.com (virusgate.meiway.com [81.255.84.76]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 21874471DA1 for ; Thu, 9 Jul 2009 15:59:16 +0200 (CEST) Received: from mail.Go2France.com (ms1.meiway.com [81.255.84.73]) by VirusGate.MEIway.com (Postfix) with ESMTP id 399B43865D0 for ; Thu, 9 Jul 2009 15:59:17 +0200 (CEST) (envelope-from lconrad@Go2France.com) Date: Thu, 9 Jul 2009 15:40:36 +0200 Message-Id: <200907091540.AA316473920@mail.Go2France.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Len Conrad" X-Sender: To: X-Mailer: Subject: (no subject) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lconrad@Go2France.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:19:12 -0000 uname -a FreeBSD xxx 7.1-RELEASE FreeBSD 7.1-RELEASE #0 kldstat Id Refs Address Size Name 1 5 0xc0400000 97f830 kernel 2 1 0xc0d80000 ff18 iscsi_initiator.ko 3 1 0xc0d90000 6a2c4 acpi.ko iscontrol doesn't have -V version and strings doesn't find anything that looks like a version. iscontrol -d -v -t 192.168.78.5 port = 3260 tags = 0 maxluns = 0 iqn = iqn.2005-01.il.ac.huji.cs: maxConnections = 1 maxRecvDataSegmentLength = 65536 maxXmitDataSegmentLength = 65536 maxBurstLength = 131072 firstBurstLength = 65536 defaultTime2Wait = 0 defaultTime2Retain = 0 maxOutstandingR2T = 1 errorRecoveryLevel = 0 targetPortalGroupTag = 0 headerDigest = None,CRC32C dataDigest = None,CRC32C initialR2T = 1 immediateData = 1 dataPDUInOrder = 1 dataSequenceInOrder = 1 sessionType = Normal targetAddress = (null) targetAlias = (null) targetName = (null) initiatorName = (null) initiatorAlias = (null) authMethod = None chapSecret = (null) chapIName = (null) tgtChapName = (null) tgtChapSecret = (null) tgttgtChallengeLen = 0 I-: cmd=0x3 len=301 SessionType=Discovery InitiatorName=iqn.2005-01.il.ac.huji.cs::mr1.xxxx.net MaxBurstLength=131072 HeaderDigest=None,CRC32C DataDigest=None,CRC32C MaxRecvDataSegmentLength=65536 ErrorRecoveryLevel=0 DefaultTime2Wait=0 DefaultTime2Retain=0 DataPDUInOrder=Yes DataSequenceInOrder=Yes MaxOutstandingR2T=1 T-: cmd=0x23 len=281 TargetPortalGroupTag=0 TargetAlias=1576.b3 HeaderDigest=None DataDigest=None MaxRecvDataSegmentLength=65536 MaxBurstLength=Irrelevant DefaultTime2Wait=0 DefaultTime2Retain=0 MaxOutstandingR2T=Irrelevant DataPDUInOrder=Irrelevant DataSequenceInOrder=Irrelevant ErrorRecoveryLevel=0 I-: cmd=0x4 len=16 SendTargets=All recvpdu: Socket is not connected recvpdu failed I-: cmd=0x6 len=0 recvpdu: Socket is not connected recvpdu failed ========== initatator does work into a FreeBSD/iscsi-target: # iscontrol -c /etc/iscsi.conf -n target0 iscontrol[817]: running iscontrol[817]: (pass3:iscsi0:0:0:0): tagged openings now 0 iscontrol[817]: cam_open_btl: no passthrough device found at 2:0:1 iscontrol[817]: cam_open_btl: no passthrough device found at 2:0:2 iscontrol[817]: cam_open_btl: no passthrough device found at 2:0:3 iscontrol: supervise starting main loop #ll /dev/is* crw------- 1 root wheel 0, 27 Jul 8 13:29 /dev/iscsi crw------- 1 root wheel 0, 103 Jul 8 13:29 /dev/iscsi0 #ll /dev/da* crw-r----- 1 root operator 0, 90 Jul 8 13:29 /dev/da0 crw-r----- 1 root operator 0, 91 Jul 8 13:29 /dev/da0s1 crw-r----- 1 root operator 0, 92 Jul 8 08:30 /dev/da0s1a crw-r----- 1 root operator 0, 93 Jul 8 13:30 /dev/da0s1b crw-r----- 1 root operator 0, 94 Jul 8 13:29 /dev/da0s1c crw-r----- 1 root operator 0, 95 Jul 8 08:29 /dev/da0s1d crw-r----- 1 root operator 0, 96 Jul 8 08:29 /dev/da0s1e crw-r----- 1 root operator 0, 105 Jul 8 13:29 /dev/da1 crw-r----- 1 root operator 0, 106 Jul 8 13:29 /dev/da1s1 crw-r----- 1 root operator 0, 107 Jul 8 13:29 /dev/da1s1c crw-r----- 1 root operator 0, 108 Jul 8 13:29 /dev/da1s1d #mount /dev/da1s1 /iscsitest/ #df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1a 10154158 141662 9200164 2% / devfs 1 1 0 100% /dev /dev/da0s1d 20308398 1393604 17290124 7% /usr /dev/da0s1e 40622090 292054 37080270 1% /var /dev/da1s1 9907690 2990276 6124800 33% /iscsitest ========= Red Hat Enterprise iscsi initiator connects to EMC SAN target reliably. If we can't get the FreeBSD iniatator working, we'll have to convert several machines from FreeBSD to Linux. Len From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 15:23:13 2009 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 4B4581065674; Thu, 9 Jul 2009 15:23:13 +0000 (UTC) (envelope-from sam@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 21F2C8FC0A; Thu, 9 Jul 2009 15:23:13 +0000 (UTC) (envelope-from sam@FreeBSD.org) Received: from freefall.freebsd.org (sam@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n69FNDtF038287; Thu, 9 Jul 2009 15:23:13 GMT (envelope-from sam@freefall.freebsd.org) Received: (from sam@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n69FNDf6038283; Thu, 9 Jul 2009 15:23:13 GMT (envelope-from sam) Date: Thu, 9 Jul 2009 15:23:13 GMT Message-Id: <200907091523.n69FNDf6038283@freefall.freebsd.org> To: sam@FreeBSD.org, freebsd-net@FreeBSD.org, jfv@FreeBSD.org From: sam@FreeBSD.org Cc: Subject: Re: kern/132715: [lagg] [panic] Panic when creating vlan's on lagg interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 15:23:13 -0000 Synopsis: [lagg] [panic] Panic when creating vlan's on lagg interface Responsible-Changed-From-To: freebsd-net->jfv Responsible-Changed-By: sam Responsible-Changed-When: Thu Jul 9 15:22:48 UTC 2009 Responsible-Changed-Why: this is really a driver issue http://www.freebsd.org/cgi/query-pr.cgi?pr=132715 From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 16:38:12 2009 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 8222C10656AD for ; Thu, 9 Jul 2009 16:38:12 +0000 (UTC) (envelope-from silby@silby.com) Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by mx1.freebsd.org (Postfix) with SMTP id F12358FC25 for ; Thu, 9 Jul 2009 16:38:10 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 93488 invoked by uid 3193); 9 Jul 2009 16:11:26 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Jul 2009 16:11:26 -0000 Date: Thu, 9 Jul 2009 12:11:26 -0400 (EDT) From: Mike Silbersack X-X-Sender: silby@niwun.pair.com To: sthaug@nethelp.no In-Reply-To: <20090708.141630.78743642.sthaug@nethelp.no> Message-ID: References: <20090708.141630.78743642.sthaug@nethelp.no> User-Agent: Alpine 1.00 (BSF 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, robert Subject: Re: Missing MFC of Silbersack/Klein IP id generation? 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, 09 Jul 2009 16:38:15 -0000 On Wed, 8 Jul 2009, sthaug@nethelp.no wrote: > According to the comments for rev. 1.10 of netinet/ip_id.c, from > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_id.c > > this is to be MFCed after 2 weeks (i.e. 2 weeks after 6. February 2008). > > And yet here we are in July 2009, and 7-STABLE shows no sign of this > version of the IP id generation code but instead has the version that > Amit Klein showed had problems, > > http://www.trusteer.com/docs/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf > > Is this a deliberate choice? > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no This is a case of me losing track of time and not getting around to the merge. As far as I know the code in question works properly. I will try to merge it soon. If another committer would like to handle the merge for me to get it done sooner, please speak up. :) Sorry for the delay, Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 16:38:41 2009 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 D9D24106568E for ; Thu, 9 Jul 2009 16:38:41 +0000 (UTC) (envelope-from bounces+305227.47129461.578549@icpbounce.com) Received: from smtp2.icpbounce.com (smtp2.icpbounce.com [216.27.93.124]) by mx1.freebsd.org (Postfix) with ESMTP id 204FE8FC1F for ; Thu, 9 Jul 2009 16:38:40 +0000 (UTC) (envelope-from bounces+305227.47129461.578549@icpbounce.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp2.icpbounce.com (Postfix) with ESMTP id E05F9F87C0 for ; Thu, 9 Jul 2009 12:15:45 -0400 (EDT) Date: Thu, 9 Jul 2009 12:15:45 -0400 To: freebsd-net@freebsd.org From: Global Access Travel Message-ID: <4160ebbac2875aa5a278057632084b8f@localhost.localdomain> X-Priority: 3 X-Mailer: PHPMailer [version 1.72] Errors-To: bounces+305227.47129461.578549@icpbounce.com X-List-Unsubscribe: X-Unsubscribe-Web: X-ICPINFO: X-Return-Path-Hint: bounces+305227.47129461.578549@icpbounce.com MIME-Version: 1.0 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fam Trip to TURKEY for $999 (Refundable) 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, 09 Jul 2009 16:38:42 -0000 [http://www.turkeycallingus.com/] Exclusive Boutique Enterprise Turkey FAM ISTANBUL - CAPPADOCIA - KONYA - ANTALYA - PAMUKKALE - KUSADASI 9 Nights / 11 Days $999 • 5 Continents • 150 Countries Worldwide • 100.000 Hotels • Instant Confirmation [http://www.turkeycallingus.com] [http://www.turkeycallingus.com/turkey-fam/TurkeyFam.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamItinerary.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamRates.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamServices.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamHotels.htm] Global Access proudly presents the biggest FAM Trip of the year, teaming with Turkish Airlines and Turkish Ministry of Tourism and Culture. As the host of ASTA IDE 2010 and European Capital of Culture 2010, Turkey is likely to be the one of the most popular destinations in 2010. Those who act early and get to know this beautiful country better will be able to give a better insight to their clients and secure more bookings. Our specially selected travel agents will stay in best hotels in each town, be escorted by professional, top tour guides, taste exceptionally good examples of Turkish Cuisine, and get to know Turkey in elegant way. Join us for a luxury FAM adventure and be our special guest in our beautiful country! COMBINE WITH World Travel Market! One of the biggest travel shows of Europe and the world, WTM, will be held in London between 9-12 November 2009. Combine your London trip with Turkey and benefit from great agent rates to see one of the most popular tourist destinations from USA and Canada. WE WILL REFUND YOUR MONEY BACK ! Upon booking your 20th passenger on a Global Access Travel Service, we will refund you the whole tour price that you’ve paid for the FAM Trip. If you book 20 or more people on a Global Access Travel Service before the FAM Trip starts, then you will travel for free! About Us Global Access Travel (GA) was founded in Turkey by a group of tourism professionals and marketing experts who recognized the needs to offer online services for accommodations, car rentals, and other travel related services to travel agencies. Through its sophisticated online reservation services, GA offers more than 100,000 hotels, motels, resorts, clubs and apartments all around the world. Other services of GA include car rentals, transfers, special tours, luxury services, city breaks, flight tickets and other services such as tailor made tour packages, exhibition organizations, incentives and other travel related services around the globe at competitive rates. [http://www.TurkeyCallingus.com] www.TurkeyCalling.us [http://www.turkeycallingus.com/turkey-calling-contact-us.htm] Global Access Travel Tel: +90 212 258 58 29 Fax: +90 212 258 34 47 E-mail : [mailto:incoming@gaturkey.com] incoming@gaturkey.com Website: [http://www.turkeycallingus.com/] www.TurkeyCalling.Us This message was sent by: FamTrit turkey, Nüzhetiye Cad., istanbul, besiktas 34357, Turkey To be removed click here: http://app.icontact.com/icp/mmail-mprofile.pl?r=47129461&l=82243&s=V4MA&m=578549&c=305227 Forward to a friend: http://app.icontact.com/icp/sub/forward?m=578549&s=47129461&c=V4MA&cid=305227 From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 16:49:17 2009 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 230FD106566C for ; Thu, 9 Jul 2009 16:49:17 +0000 (UTC) (envelope-from bounces+305227.47130731.578549@icpbounce.com) Received: from smtp13.icpbounce.com (smtp13.icpbounce.com [216.27.93.113]) by mx1.freebsd.org (Postfix) with ESMTP id C7A378FC1E for ; Thu, 9 Jul 2009 16:49:16 +0000 (UTC) (envelope-from bounces+305227.47130731.578549@icpbounce.com) Received: from localhost.localdomain (localhost [127.0.0.1]) by smtp13.icpbounce.com (Postfix) with ESMTP id A175B6F02DD for ; Thu, 9 Jul 2009 12:19:14 -0400 (EDT) Date: Thu, 9 Jul 2009 12:19:14 -0400 To: net@freebsd.org From: Global Access Travel Message-ID: X-Priority: 3 X-Mailer: PHPMailer [version 1.72] Errors-To: bounces+305227.47130731.578549@icpbounce.com X-List-Unsubscribe: X-Unsubscribe-Web: X-ICPINFO: X-Return-Path-Hint: bounces+305227.47130731.578549@icpbounce.com MIME-Version: 1.0 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Fam Trip to TURKEY for $999 (Refundable) 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, 09 Jul 2009 16:49:18 -0000 [http://www.turkeycallingus.com/] Exclusive Boutique Enterprise Turkey FAM ISTANBUL - CAPPADOCIA - KONYA - ANTALYA - PAMUKKALE - KUSADASI 9 Nights / 11 Days $999 • 5 Continents • 150 Countries Worldwide • 100.000 Hotels • Instant Confirmation [http://www.turkeycallingus.com] [http://www.turkeycallingus.com/turkey-fam/TurkeyFam.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamItinerary.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamRates.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamServices.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamHotels.htm] Global Access proudly presents the biggest FAM Trip of the year, teaming with Turkish Airlines and Turkish Ministry of Tourism and Culture. As the host of ASTA IDE 2010 and European Capital of Culture 2010, Turkey is likely to be the one of the most popular destinations in 2010. Those who act early and get to know this beautiful country better will be able to give a better insight to their clients and secure more bookings. Our specially selected travel agents will stay in best hotels in each town, be escorted by professional, top tour guides, taste exceptionally good examples of Turkish Cuisine, and get to know Turkey in elegant way. Join us for a luxury FAM adventure and be our special guest in our beautiful country! COMBINE WITH World Travel Market! One of the biggest travel shows of Europe and the world, WTM, will be held in London between 9-12 November 2009. Combine your London trip with Turkey and benefit from great agent rates to see one of the most popular tourist destinations from USA and Canada. WE WILL REFUND YOUR MONEY BACK ! Upon booking your 20th passenger on a Global Access Travel Service, we will refund you the whole tour price that you’ve paid for the FAM Trip. If you book 20 or more people on a Global Access Travel Service before the FAM Trip starts, then you will travel for free! About Us Global Access Travel (GA) was founded in Turkey by a group of tourism professionals and marketing experts who recognized the needs to offer online services for accommodations, car rentals, and other travel related services to travel agencies. Through its sophisticated online reservation services, GA offers more than 100,000 hotels, motels, resorts, clubs and apartments all around the world. Other services of GA include car rentals, transfers, special tours, luxury services, city breaks, flight tickets and other services such as tailor made tour packages, exhibition organizations, incentives and other travel related services around the globe at competitive rates. [http://www.TurkeyCallingus.com] www.TurkeyCalling.us [http://www.turkeycallingus.com/turkey-calling-contact-us.htm] Global Access Travel Tel: +90 212 258 58 29 Fax: +90 212 258 34 47 E-mail : [mailto:incoming@gaturkey.com] incoming@gaturkey.com Website: [http://www.turkeycallingus.com/] www.TurkeyCalling.Us This message was sent by: FamTrit turkey, Nüzhetiye Cad., istanbul, besiktas 34357, Turkey To be removed click here: http://app.icontact.com/icp/mmail-mprofile.pl?r=47130731&l=82243&s=F9IT&m=578549&c=305227 Forward to a friend: http://app.icontact.com/icp/sub/forward?m=578549&s=47130731&c=F9IT&cid=305227 From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 18:27:00 2009 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 861BA1065686; Thu, 9 Jul 2009 18:27:00 +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 5A9BE8FC18; Thu, 9 Jul 2009 18:27:00 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n69IR0hr084734; Thu, 9 Jul 2009 18:27:00 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n69IR0Sl084730; Thu, 9 Jul 2009 18:27:00 GMT (envelope-from linimon) Date: Thu, 9 Jul 2009 18:27:00 GMT Message-Id: <200907091827.n69IR0Sl084730@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/136618: [pf][stf] panic on cloning interface without unit number, e.g. `stf' 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, 09 Jul 2009 18:27:01 -0000 Synopsis: [pf][stf] panic on cloning interface without unit number, e.g. `stf' Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 9 18:26:44 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=136618 From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 18:33:20 2009 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 AA1011065693; Thu, 9 Jul 2009 18:33:20 +0000 (UTC) (envelope-from prvs=1434654274=brian@Awfulhak.org) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 623C18FC0C; Thu, 9 Jul 2009 18:33:20 +0000 (UTC) (envelope-from prvs=1434654274=brian@Awfulhak.org) Received: from pd4ml2so-ssvc.prod.shaw.ca ([10.0.141.136]) by pd2mo1so-svcs.prod.shaw.ca with ESMTP; 09 Jul 2009 12:04:54 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=4Z0QP1WVBuUwHZGQKe2N1A==:17 a=85N1-lAfAAAA:8 a=8pif782wAAAA:8 a=MMwg4So0AAAA:8 a=6I5d2MoRAAAA:8 a=pLs50JeHo0lRBKzncFcA:9 a=DQ_Xb_9UxnLdEZxVoNwA:7 a=1fBJIe8b65rIWibaRHQE_u0F38MA:4 a=EQTM5Oi4JLsA:10 a=u1lCIr8n24MA:10 a=WJ3hkfHDukgA:10 a=SV7veod9ZcQA:10 Received: from unknown (HELO store.lan.Awfulhak.org) ([174.7.23.140]) by pd4ml2so-dmz.prod.shaw.ca with ESMTP; 09 Jul 2009 12:04:50 -0600 Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 81B19C433AC_A56317DB; Thu, 9 Jul 2009 18:05:49 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Sophos Email Appliance) with ESMTP id 007B1C460F8_A563177F; Thu, 9 Jul 2009 18:05:42 +0000 (GMT) Received: from localhost (brian@gw.lan.Awfulhak.org [172.16.0.1]) by gw.Awfulhak.org (8.14.3/8.14.3) with ESMTP id n69I3A80021271; Thu, 9 Jul 2009 11:03:11 -0700 (PDT) (envelope-from brian@Awfulhak.org) Date: Thu, 9 Jul 2009 11:03:23 -0700 From: Brian Somers To: David Malone Message-ID: <20090709110323.6106a0f3@Awfulhak.org> In-Reply-To: <200907091020.aa42546@walton.maths.tcd.ie> References: <20090702084608.GA59311@roberto-al.eurocontrol.fr> <200907091020.aa42546@walton.maths.tcd.ie> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Edwin Groothuis , freebsd-net@freebsd.org Subject: Re: NTP - default /etc/ntp.conf 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, 09 Jul 2009 18:33:21 -0000 On Thu, 09 Jul 2009 10:20:29 +0100, David Malone wrote: > The NTP pool guys have set up our vendor domain. I'd like to commit > the patch below to ntp.conf. It does the following: > > 1) Uses our vendor domain at the pool. > 2) Points people at the pool website and encourages > people to provide a server in the pool (as a > courtesy to the pool guys). > 3) Fixes a spelling. > 4) Comments out the local clock and includes a link > to documentation for use of the local clock on > the ntp.org site. > > If there are no objections, I'll ask re@ for permission to commit > this. > > David. > > Index: ntp.conf > =================================================================== > --- ntp.conf (revision 195484) > +++ ntp.conf (working copy) > @@ -13,19 +13,22 @@ > # > # The following three servers will give you a random set of three > # NTP servers geographically close to you. > -# See http://en.wikipedia.org/wiki/NTP_pool for details. > +# See http://www.pool.ntp.org/ for details. Note, the pool encourages > +# users with a static IP and good upstream NTP servers to add a server > +# to the pool. See http://www.pool.ntp.org/join.html if you are interested. > # > # The option `iburst' is used for faster initial synchronisation. > # The option `maxpoll 9' is used to prevent PLL/FLL flipping on FreeBSD. > # > -server 0.pool.ntp.org iburst maxpoll 9 > -server 1.pool.ntp.org iburst maxpoll 9 > -server 2.pool.ntp.org iburst maxpoll 9 > +server 0.freebsd.pool.ntp.org iburst maxpoll 9 > +server 1.freebsd.pool.ntp.org iburst maxpoll 9 > +server 2.freebsd.pool.ntp.org iburst maxpoll 9 > +#server 3.freebsd.pool.ntp.org iburst maxpoll 9 > > # > # If you want to pick yourself which country's public NTP server > # you want sync against, comment out the above servers, uncomment > -# the next ones and replace CC with the country's abbrevation. > +# the next ones and replace CC with the country's abbreviation. > # Make sure that the hostnames resolve to a proper IP address! > # > # server 0.CC.pool.ntp.org iburst maxpoll 9 > @@ -50,10 +53,12 @@ > #restrict 127.127.1.0 > > # > -# If we lose sync against all configured servers, the NTP clients > -# syncing against this server will lose sync too. To overcome this, > -# we will act as a stratum 10 server with our own internal clock > -# so that everybody at least will have the same time as we have. > +# If a server loses sync with all upstream servers, NTP clients > +# no longer follow that server. The local clock can be configured > +# to provide a time source when this happens, but it should usually > +# be configured on just one server on a network. For more details see > +# http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock > +# The use of Orphan Mode may be preferable. > # > -server 127.127.1.0 > -fudge 127.127.1.0 stratum 10 > +#server 127.127.1.0 > +#fudge 127.127.1.0 stratum 10 I'd tend to suggest stratum 13 so that the inattentive admin doesn't spread his potentially dodgy clock info too far when he tries uncommenting the above.... otherwise I (rather subjectively) agree with this change :) -- Brian Somers Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 20:15:05 2009 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 D864E1065674; Thu, 9 Jul 2009 20:15:05 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (mail.farley.org [IPv6:2001:470:1f0f:20:2::11]) by mx1.freebsd.org (Postfix) with ESMTP id 322668FC0A; Thu, 9 Jul 2009 20:15:05 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (HPooka@thor.farley.org [IPv6:2001:470:1f0f:20:1::5]) by mail.farley.org (8.14.3/8.14.3) with ESMTP id n69KF3RB079797; Thu, 9 Jul 2009 15:15:03 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Thu, 9 Jul 2009 15:15:03 -0500 (CDT) From: "Sean C. Farley" To: David Malone In-Reply-To: <200907091020.aa42546@walton.maths.tcd.ie> Message-ID: References: <200907091020.aa42546@walton.maths.tcd.ie> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.farley.org Cc: Edwin Groothuis , freebsd-net@FreeBSD.org Subject: Re: NTP - default /etc/ntp.conf 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, 09 Jul 2009 20:15:06 -0000 On Thu, 9 Jul 2009, David Malone wrote: > The NTP pool guys have set up our vendor domain. I'd like to commit > the patch below to ntp.conf. It does the following: > > 1) Uses our vendor domain at the pool. > 2) Points people at the pool website and encourages > people to provide a server in the pool (as a > courtesy to the pool guys). > 3) Fixes a spelling. > 4) Comments out the local clock and includes a link > to documentation for use of the local clock on > the ntp.org site. > > If there are no objections, I'll ask re@ for permission to commit > this. Is 3.freebsd.pool.ntp.org intentionally commented? It does resolve. Reminder: if you do uncomment it, remember to change the "three servers" to four. Otherwise, it looks good to me. > David. > > Index: ntp.conf > =================================================================== > --- ntp.conf (revision 195484) > +++ ntp.conf (working copy) > @@ -13,19 +13,22 @@ > # > # The following three servers will give you a random set of three > # NTP servers geographically close to you. > -# See http://en.wikipedia.org/wiki/NTP_pool for details. > +# See http://www.pool.ntp.org/ for details. Note, the pool encourages > +# users with a static IP and good upstream NTP servers to add a server > +# to the pool. See http://www.pool.ntp.org/join.html if you are interested. > # > # The option `iburst' is used for faster initial synchronisation. > # The option `maxpoll 9' is used to prevent PLL/FLL flipping on FreeBSD. > # > -server 0.pool.ntp.org iburst maxpoll 9 > -server 1.pool.ntp.org iburst maxpoll 9 > -server 2.pool.ntp.org iburst maxpoll 9 > +server 0.freebsd.pool.ntp.org iburst maxpoll 9 > +server 1.freebsd.pool.ntp.org iburst maxpoll 9 > +server 2.freebsd.pool.ntp.org iburst maxpoll 9 > +#server 3.freebsd.pool.ntp.org iburst maxpoll 9 > > # > # If you want to pick yourself which country's public NTP server > # you want sync against, comment out the above servers, uncomment > -# the next ones and replace CC with the country's abbrevation. > +# the next ones and replace CC with the country's abbreviation. > # Make sure that the hostnames resolve to a proper IP address! > # > # server 0.CC.pool.ntp.org iburst maxpoll 9 > @@ -50,10 +53,12 @@ > #restrict 127.127.1.0 > > # > -# If we lose sync against all configured servers, the NTP clients > -# syncing against this server will lose sync too. To overcome this, > -# we will act as a stratum 10 server with our own internal clock > -# so that everybody at least will have the same time as we have. > +# If a server loses sync with all upstream servers, NTP clients > +# no longer follow that server. The local clock can be configured > +# to provide a time source when this happens, but it should usually > +# be configured on just one server on a network. For more details see > +# http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock > +# The use of Orphan Mode may be preferable. > # > -server 127.127.1.0 > -fudge 127.127.1.0 stratum 10 > +#server 127.127.1.0 > +#fudge 127.127.1.0 stratum 10 > > _______________________________________________ > 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" > Sean -- scf@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 22:30:39 2009 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 77A18106566B; Thu, 9 Jul 2009 22:30:39 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 09CDD8FC0A; Thu, 9 Jul 2009 22:30:39 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=lk9bilrsR8He8c76y0vL54XHWPaqx2xhfVH+VfSZEc4WwPLHlABK8yjhmc5z3ZOSj43g4L/EtW09fxp53c1hMP2q9TdWdW6A5fawyYirNUiz8yyjD3qP8G2g70ZfI5D/z2qHUyFQg6JTXhV695WC+DiEdECmQlpZDf67dNSWOg0=; Received: from phoenix.codelabs.ru (ppp91-77-175-113.pppoe.mtu-net.ru [91.77.175.113]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MP28T-0005Ah-2Z; Fri, 10 Jul 2009 02:30:37 +0400 Date: Fri, 10 Jul 2009 02:30:34 +0400 From: Eygene Ryabinkin To: linimon@FreeBSD.org Message-ID: References: <200907091827.n69IR0Sl084730@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <200907091827.n69IR0Sl084730@freefall.freebsd.org> Sender: rea-fbsd@codelabs.ru Cc: freebsd-net@FreeBSD.org, mlaier@freebsd.org, artis.caune@gmail.com, bug-followup@FreeBSD.org Subject: Re: kern/136618: [pf][stf] panic on cloning interface without unit number, e.g. `stf' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 22:30:39 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable // Sorry for a long letter ;)) In fact, stf(4) problem will be healed with the attached patch: it works for me and should provide absolutely sane pf rules, because stf(4) is essentially a singleton interface, so there won't be ambiguities: 'stf' as the interface name will have the same effect as the 'stf' being treated as the interface group name. In fact, the problem is rather simple: when cloned interface is created, interface group with the interface family name (e.g. "vlan" or "carp") is created prior to the interface creation. So, when we create (with pure creation or rename) the interface with the name of the "family", pf will pick up the kif (via pfi_attach_ifnet) that already exists and correspond to the interface group name and thus the loop will be created: one of interface's groups will be its "family" group and this group's ifg_pf_kif will be equal to the kif. Recursive functions like pfi_kif_update() won't be happy with this. With my patch it shouldn't be a problem for any interface type -- infinite recursion will be avoided. But another problem exists for non-singleton interfaces: when we have, for example, interfaces carp1, carp2 and carp3 and some of them (say, carp2) is renamed to just "carp", then the rules for "carp" will really correspond to the whole family of carp interfaces and not just to the former "carp2". Of course, this is a kind of shooting yourself to your feet, but this can be left unnoticed and will produce a big headache; moreover, interface groups are hardly well-documented now, so a person should learn from the experience or =66rom sources. There is kern/127042 (rather old one, but it essentially the same as the current PR) that addresses this aspect of the problem: it - refuses to add new group whose name coincides with the name of existing interface (first hunk); - additionally, it refuses to rename interface to the name that coincides with one of existing group names (second and third hunks of the patch in the said PR, by the way, last hunk misses '{' after 'if' and has 'groupname' instead of 'new_name'). The first part makes singletons to be real singletons and there will be no groups of their name (in contrast with the current behaviour) as long as these interfaces aren't renamed. I mean that for the 'stf' case, there will be no group named 'stf'. But if I'll rename 'stf' -> 'foo', then I'll be able to create the 'stf' group: 'ifconfig lo0 group stf' will work happily. This is the weird example, but it shows that the behaviour here isn't very consistent with the notion of singletons. Perhaps, interfaces such as 'stf' shouldn't be allowed to be renamed at all -- this will close this issue. Thus, this second patch (slightly reworked one from kern/127042) should eliminate the foot-shooting problem: there will be no iface renames and group creation that will result in the described foot-shooting. And since interface cloning when the "family" name is used (e.g. 'ifconfig tun create') will create tunX with X being the first available digit, we should be safe with this as long as all cloned interfaces (but singleton ones) will refuse to create interface with the "family" name. If there will be general consensus that singleton interfaces shouldn't be allowed to be renamed, then I can try to implement such functionality. Going the other way and allowing creation of the 'stf' group shouldn't also be hard -- just an additional test inside if_addgroup() and a new interface flag that will be tested inside if_addgroup(). And may be a special function for allocation of singleton interface units -- just for simplicity and to avoid code duplication. Any views on this? Perhaps I am missing something important here? It is already deep night here, so I can produce some bad ideas :(( Thanks for your patience! --- pf_if.c-avoid-infinite-recursion.diff begins here --- begin 600 pf_if.c-avoid-infinite-recursion.diff M+2TM('-Y'0I"BT)"0EP9FE?:VEF7W5P9&%T92@H2!O;F4@:6YS=3D&%N8V4@86YD(&ET3H@:6YT97)F86-E)W,**PD) M"2`J(')U;&5S('=3DI;&P@87!P;'D@=3D&\@=3D&AE('=3DH;VQE(&=3DR;W5P+@HK"0D) M("HO"BL)"0EI9B`H:VEF("$](&=3DR7VMI9BD**PD)"0EP9FE?:VEF7W5P9&%T ?92AG7,O;F5T+VEF+F,),C`P.2TP-RTQ,"`P,CHP M,#HQ,RXP,#`P,#`P,#`@*S`T,#`*0$`@+3DV-2PV("LY-C4L.2!`0`H@"2`@ M("!G'0I"B`)"6EF("@API`0"`M,3DP-RPV("LQ.3$P+#<@0$`*(`EC M:&%R(&YE=3DU]N86UE6TE&3D%-4TE:73L*(`ES=3D')U8W0@:69A9&1R("II9F$[ M"B`)pfik_ifp != NULL) - TAILQ_FOREACH(ifgl, &kif->pfik_ifp->if_groups, ifgl_next) - pfi_kif_update((struct pfi_kif *) - ifgl->ifgl_group->ifg_pf_kif); + if (kif->pfik_ifp != NULL) { + struct pfi_kif *gr_kif; + TAILQ_FOREACH(ifgl, &kif->pfik_ifp->if_groups, ifgl_next) { + gr_kif = + (struct pfi_kif *)ifgl->ifgl_group->ifg_pf_kif; + /* + * Avoid infinite recursion: if interface name is + * the same as the interface group name (for example, + * stf(4) has only one instance and its kif will be + * named "stf", as the group's "kif". Another case + * is the interface renamed to it's family name + * (e.g., "vlanX" -> "vlan"). In fact, the latter + * case must be prohibited, since it makes pf + * rules to behave non-intuitively: interface's + * rules will apply to the whole group. + */ + if (kif != gr_kif) + pfi_kif_update(gr_kif); + } + } } void --W/nzBZO5zC0uMSeA-- From owner-freebsd-net@FreeBSD.ORG Thu Jul 9 22:40:03 2009 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 D02D5106566B for ; Thu, 9 Jul 2009 22: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 BCC3A8FC12 for ; Thu, 9 Jul 2009 22: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.3/8.14.3) with ESMTP id n69Me34L082981 for ; Thu, 9 Jul 2009 22:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n69Me3fg082980; Thu, 9 Jul 2009 22:40:03 GMT (envelope-from gnats) Date: Thu, 9 Jul 2009 22:40:03 GMT Message-Id: <200907092240.n69Me3fg082980@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Eygene Ryabinkin Cc: Subject: Re: kern/136618: [pf][stf] panic on cloning interface without unit number, e.g. `stf' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eygene Ryabinkin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 22:40:04 -0000 The following reply was made to PR kern/136618; it has been noted by GNATS. From: Eygene Ryabinkin To: linimon@FreeBSD.org Cc: bug-followup@FreeBSD.org, freebsd-net@FreeBSD.org, mlaier@freebsd.org, artis.caune@gmail.com Subject: Re: kern/136618: [pf][stf] panic on cloning interface without unit number, e.g. `stf' Date: Fri, 10 Jul 2009 02:30:34 +0400 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable // Sorry for a long letter ;)) In fact, stf(4) problem will be healed with the attached patch: it works for me and should provide absolutely sane pf rules, because stf(4) is essentially a singleton interface, so there won't be ambiguities: 'stf' as the interface name will have the same effect as the 'stf' being treated as the interface group name. In fact, the problem is rather simple: when cloned interface is created, interface group with the interface family name (e.g. "vlan" or "carp") is created prior to the interface creation. So, when we create (with pure creation or rename) the interface with the name of the "family", pf will pick up the kif (via pfi_attach_ifnet) that already exists and correspond to the interface group name and thus the loop will be created: one of interface's groups will be its "family" group and this group's ifg_pf_kif will be equal to the kif. Recursive functions like pfi_kif_update() won't be happy with this. With my patch it shouldn't be a problem for any interface type -- infinite recursion will be avoided. But another problem exists for non-singleton interfaces: when we have, for example, interfaces carp1, carp2 and carp3 and some of them (say, carp2) is renamed to just "carp", then the rules for "carp" will really correspond to the whole family of carp interfaces and not just to the former "carp2". Of course, this is a kind of shooting yourself to your feet, but this can be left unnoticed and will produce a big headache; moreover, interface groups are hardly well-documented now, so a person should learn from the experience or =66rom sources. There is kern/127042 (rather old one, but it essentially the same as the current PR) that addresses this aspect of the problem: it - refuses to add new group whose name coincides with the name of existing interface (first hunk); - additionally, it refuses to rename interface to the name that coincides with one of existing group names (second and third hunks of the patch in the said PR, by the way, last hunk misses '{' after 'if' and has 'groupname' instead of 'new_name'). The first part makes singletons to be real singletons and there will be no groups of their name (in contrast with the current behaviour) as long as these interfaces aren't renamed. I mean that for the 'stf' case, there will be no group named 'stf'. But if I'll rename 'stf' -> 'foo', then I'll be able to create the 'stf' group: 'ifconfig lo0 group stf' will work happily. This is the weird example, but it shows that the behaviour here isn't very consistent with the notion of singletons. Perhaps, interfaces such as 'stf' shouldn't be allowed to be renamed at all -- this will close this issue. Thus, this second patch (slightly reworked one from kern/127042) should eliminate the foot-shooting problem: there will be no iface renames and group creation that will result in the described foot-shooting. And since interface cloning when the "family" name is used (e.g. 'ifconfig tun create') will create tunX with X being the first available digit, we should be safe with this as long as all cloned interfaces (but singleton ones) will refuse to create interface with the "family" name. If there will be general consensus that singleton interfaces shouldn't be allowed to be renamed, then I can try to implement such functionality. Going the other way and allowing creation of the 'stf' group shouldn't also be hard -- just an additional test inside if_addgroup() and a new interface flag that will be tested inside if_addgroup(). And may be a special function for allocation of singleton interface units -- just for simplicity and to avoid code duplication. Any views on this? Perhaps I am missing something important here? It is already deep night here, so I can produce some bad ideas :(( Thanks for your patience! --- pf_if.c-avoid-infinite-recursion.diff begins here --- begin 600 pf_if.c-avoid-infinite-recursion.diff M+2TM('-Y'0I"BT)"0EP9FE?:VEF7W5P9&%T92@H2!O;F4@:6YS=3D&%N8V4@86YD(&ET3H@:6YT97)F86-E)W,**PD) M"2`J(')U;&5S('=3DI;&P@87!P;'D@=3D&\@=3D&AE('=3DH;VQE(&=3DR;W5P+@HK"0D) M("HO"BL)"0EI9B`H:VEF("$](&=3DR7VMI9BD**PD)"0EP9FE?:VEF7W5P9&%T ?92AG7,O;F5T+VEF+F,),C`P.2TP-RTQ,"`P,CHP M,#HQ,RXP,#`P,#`P,#`@*S`T,#`*0$`@+3DV-2PV("LY-C4L.2!`0`H@"2`@ M("!G'0I"B`)"6EF("@API`0"`M,3DP-RPV("LQ.3$P+#<@0$`*(`EC M:&%R(&YE=3DU]N86UE6TE&3D%-4TE:73L*(`ES=3D')U8W0@:69A9&1R("II9F$[ M"B`)pfik_ifp != NULL) - TAILQ_FOREACH(ifgl, &kif->pfik_ifp->if_groups, ifgl_next) - pfi_kif_update((struct pfi_kif *) - ifgl->ifgl_group->ifg_pf_kif); + if (kif->pfik_ifp != NULL) { + struct pfi_kif *gr_kif; + TAILQ_FOREACH(ifgl, &kif->pfik_ifp->if_groups, ifgl_next) { + gr_kif = + (struct pfi_kif *)ifgl->ifgl_group->ifg_pf_kif; + /* + * Avoid infinite recursion: if interface name is + * the same as the interface group name (for example, + * stf(4) has only one instance and its kif will be + * named "stf", as the group's "kif". Another case + * is the interface renamed to it's family name + * (e.g., "vlanX" -> "vlan"). In fact, the latter + * case must be prohibited, since it makes pf + * rules to behave non-intuitively: interface's + * rules will apply to the whole group. + */ + if (kif != gr_kif) + pfi_kif_update(gr_kif); + } + } } void --W/nzBZO5zC0uMSeA-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 05:40:17 2009 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 F09E11065680; Fri, 10 Jul 2009 05:40:17 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 414768FC0C; Fri, 10 Jul 2009 05:40:17 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id ABC9A33CB7; Fri, 10 Jul 2009 07:40:14 +0200 (SAST) Date: Fri, 10 Jul 2009 07:40:14 +0200 From: John Hay To: David Malone Message-ID: <20090710054014.GA57163@zibbi.meraka.csir.co.za> References: <20090702084608.GA59311@roberto-al.eurocontrol.fr> <200907091020.aa42546@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907091020.aa42546@walton.maths.tcd.ie> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Edwin Groothuis Subject: Re: NTP - default /etc/ntp.conf 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, 10 Jul 2009 05:40:18 -0000 Hi David, On Thu, Jul 09, 2009 at 10:20:29AM +0100, David Malone wrote: > The NTP pool guys have set up our vendor domain. I'd like to commit > the patch below to ntp.conf. It does the following: > > 1) Uses our vendor domain at the pool. > 2) Points people at the pool website and encourages > people to provide a server in the pool (as a > courtesy to the pool guys). > 3) Fixes a spelling. > 4) Comments out the local clock and includes a link > to documentation for use of the local clock on > the ntp.org site. > > If there are no objections, I'll ask re@ for permission to commit > this. This looks fine to me. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org > > David. > > Index: ntp.conf > =================================================================== > --- ntp.conf (revision 195484) > +++ ntp.conf (working copy) > @@ -13,19 +13,22 @@ > # > # The following three servers will give you a random set of three > # NTP servers geographically close to you. > -# See http://en.wikipedia.org/wiki/NTP_pool for details. > +# See http://www.pool.ntp.org/ for details. Note, the pool encourages > +# users with a static IP and good upstream NTP servers to add a server > +# to the pool. See http://www.pool.ntp.org/join.html if you are interested. > # > # The option `iburst' is used for faster initial synchronisation. > # The option `maxpoll 9' is used to prevent PLL/FLL flipping on FreeBSD. > # > -server 0.pool.ntp.org iburst maxpoll 9 > -server 1.pool.ntp.org iburst maxpoll 9 > -server 2.pool.ntp.org iburst maxpoll 9 > +server 0.freebsd.pool.ntp.org iburst maxpoll 9 > +server 1.freebsd.pool.ntp.org iburst maxpoll 9 > +server 2.freebsd.pool.ntp.org iburst maxpoll 9 > +#server 3.freebsd.pool.ntp.org iburst maxpoll 9 > > # > # If you want to pick yourself which country's public NTP server > # you want sync against, comment out the above servers, uncomment > -# the next ones and replace CC with the country's abbrevation. > +# the next ones and replace CC with the country's abbreviation. > # Make sure that the hostnames resolve to a proper IP address! > # > # server 0.CC.pool.ntp.org iburst maxpoll 9 > @@ -50,10 +53,12 @@ > #restrict 127.127.1.0 > > # > -# If we lose sync against all configured servers, the NTP clients > -# syncing against this server will lose sync too. To overcome this, > -# we will act as a stratum 10 server with our own internal clock > -# so that everybody at least will have the same time as we have. > +# If a server loses sync with all upstream servers, NTP clients > +# no longer follow that server. The local clock can be configured > +# to provide a time source when this happens, but it should usually > +# be configured on just one server on a network. For more details see > +# http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock > +# The use of Orphan Mode may be preferable. > # > -server 127.127.1.0 > -fudge 127.127.1.0 stratum 10 > +#server 127.127.1.0 > +#fudge 127.127.1.0 stratum 10 From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 05:53:59 2009 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 24619106566C; Fri, 10 Jul 2009 05:53:59 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id 290FB8FC14; Fri, 10 Jul 2009 05:53:58 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 10 Jul 2009 06:53:57 +0100 (BST) Received: from localhost ([127.0.0.1] helo=maths.tcd.ie) by walton.maths.tcd.ie with SMTP id ; 10 Jul 2009 06:53:56 +0100 (BST) To: "Sean C. Farley" In-reply-to: Your message of "Thu, 09 Jul 2009 15:15:03 CDT." X-Request-Do: Date: Fri, 10 Jul 2009 06:53:56 +0100 From: David Malone Message-ID: <200907100653.aa52216@walton.maths.tcd.ie> Cc: Edwin Groothuis , freebsd-net@FreeBSD.org Subject: Re: NTP - default /etc/ntp.conf 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, 10 Jul 2009 05:53:59 -0000 > Is 3.freebsd.pool.ntp.org intentionally commented? It does resolve. > Reminder: if you do uncomment it, remember to change the "three > servers" to four. The pool set up 4 groups (0, 1, 2, 3) for us, but since we only had three in the original file (and three is a commonly recommended number of servers), I thought I'd only three of the four. I did think that we might rotate which subset of the 4 we use over time. I've no problem commenting in all 4 if people think that's a better config. David. From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 05:56:10 2009 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 C4C12106566B; Fri, 10 Jul 2009 05:56:10 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id F23BF8FC12; Fri, 10 Jul 2009 05:56:09 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 10 Jul 2009 06:56:09 +0100 (BST) Received: from localhost ([127.0.0.1] helo=maths.tcd.ie) by walton.maths.tcd.ie with SMTP id ; 10 Jul 2009 06:56:07 +0100 (BST) To: Brian Somers In-reply-to: Your message of "Thu, 09 Jul 2009 11:03:23 PDT." <20090709110323.6106a0f3@Awfulhak.org> X-Request-Do: Date: Fri, 10 Jul 2009 06:56:07 +0100 From: David Malone Message-ID: <200907100656.aa52257@walton.maths.tcd.ie> Cc: Edwin Groothuis , freebsd-net@freebsd.org Subject: Re: NTP - default /etc/ntp.conf 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, 10 Jul 2009 05:56:11 -0000 > I'd tend to suggest stratum 13 so that the inattentive admin > doesn't spread his potentially dodgy clock info too far when > he tries uncommenting the above.... otherwise I (rather > subjectively) agree with this change :) I'll change the commented version, as it shouldn't do any harm. As I said, I usually use 14, which is probably almost too low. David. From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 06:14:15 2009 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 23E32106566C; Fri, 10 Jul 2009 06:14:15 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: from mail-fx0-f205.google.com (mail-fx0-f205.google.com [209.85.220.205]) by mx1.freebsd.org (Postfix) with ESMTP id 269888FC0A; Fri, 10 Jul 2009 06:14:13 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: by fxm1 with SMTP id 1so594755fxm.19 for ; Thu, 09 Jul 2009 23:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zRLmI1dvkcNPIXimSa7+D+/CgnEULCLKK4hvdt/aXRY=; b=EX1Yi7fl+hK9wKHJHI7sTvUutgXifYvZmxEg8lg7vmq8RaqnJGsZOyZTp4gnxl0MZF PDpvNuq7CvVcsSP6CBD25Sj6DfNtmYqUfvUbyBDQfKdjMQ7tsUJUchmOtCOEh23Wf45V 91Ni3E/B4W6hvjW+WjcCcqOwIiAtzXiuJs7xY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=S7FLkeZBih+vz/ay/zyLMwRpJ1Ntnd9og5SL5kiLr12bmKy/j31oxS/oMBfr03Qp92 ehmHF5dJD3reXbofhfqNnwhGCOz+JeXx8FUa17rqj5SWgubXEQv2TX4A8gfQskfL1K75 wLzVlsN7vICQJosfO1p2Z20eVpEUxb8cwMv0k= MIME-Version: 1.0 Received: by 10.103.197.14 with SMTP id z14mr869086mup.1.1247205187562; Thu, 09 Jul 2009 22:53:07 -0700 (PDT) In-Reply-To: References: <200907091827.n69IR0Sl084730@freefall.freebsd.org> Date: Fri, 10 Jul 2009 08:53:07 +0300 Message-ID: <9e20d71e0907092253m69346b0nde7095f7de9bc36f@mail.gmail.com> From: Artis Caune To: rea-fbsd@codelabs.ru Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, mlaier@freebsd.org, bug-followup@freebsd.org, linimon@freebsd.org Subject: Re: kern/136618: [pf][stf] panic on cloning interface without unit number, e.g. `stf' 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, 10 Jul 2009 06:14:15 -0000 2009/7/10 Eygene Ryabinkin : > There is kern/127042 (rather old one, but it essentially the same as the > current PR) that addresses this aspect of the problem: it > > =C2=A0- additionally, it refuses to rename interface to the name that > =C2=A0 coincides with one of existing group names (second and third hunks= of > =C2=A0 the patch in the said PR, by the way, last hunk misses '{' after '= if' > =C2=A0 and has 'groupname' instead of 'new_name'). sorry for bad patch, my bad s/copy/coffee/ thanks for working on this. --=20 Artis Caune Everything should be made as simple as possible, but not simpler. From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 06:20:03 2009 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 717F6106566B for ; Fri, 10 Jul 2009 06:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC6C8FC18 for ; Fri, 10 Jul 2009 06:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n6A6K31f040551 for ; Fri, 10 Jul 2009 06:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n6A6K3nO040550; Fri, 10 Jul 2009 06:20:03 GMT (envelope-from gnats) Date: Fri, 10 Jul 2009 06:20:03 GMT Message-Id: <200907100620.n6A6K3nO040550@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Artis Caune Cc: Subject: Re: kern/136618: [pf][stf] panic on cloning interface without unit number, e.g. `stf' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Artis Caune List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 06:20:03 -0000 The following reply was made to PR kern/136618; it has been noted by GNATS. From: Artis Caune To: rea-fbsd@codelabs.ru Cc: linimon@freebsd.org, bug-followup@freebsd.org, freebsd-net@freebsd.org, mlaier@freebsd.org Subject: Re: kern/136618: [pf][stf] panic on cloning interface without unit number, e.g. `stf' Date: Fri, 10 Jul 2009 08:53:07 +0300 2009/7/10 Eygene Ryabinkin : > There is kern/127042 (rather old one, but it essentially the same as the > current PR) that addresses this aspect of the problem: it > > =C2=A0- additionally, it refuses to rename interface to the name that > =C2=A0 coincides with one of existing group names (second and third hunks= of > =C2=A0 the patch in the said PR, by the way, last hunk misses '{' after '= if' > =C2=A0 and has 'groupname' instead of 'new_name'). sorry for bad patch, my bad s/copy/coffee/ thanks for working on this. --=20 Artis Caune Everything should be made as simple as possible, but not simpler. From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 07:43:54 2009 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 70B79106564A; Fri, 10 Jul 2009 07:43:54 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id ED7DB8FC23; Fri, 10 Jul 2009 07:43:53 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 65B723A23F; Fri, 10 Jul 2009 09:43:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAFXauuPaJFk; Fri, 10 Jul 2009 09:43:51 +0200 (CEST) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id 3F82539E10; Fri, 10 Jul 2009 09:43:51 +0200 (CEST) Date: Fri, 10 Jul 2009 09:43:46 +0200 From: Ollivier Robert To: David Malone Message-ID: <20090710074346.GA67742@roberto-al.eurocontrol.fr> References: <20090709110323.6106a0f3@Awfulhak.org> <200907100656.aa52257@walton.maths.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907100656.aa52257@walton.maths.tcd.ie> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Brian Somers , Edwin Groothuis , freebsd-net@freebsd.org Subject: Re: NTP - default /etc/ntp.conf 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, 10 Jul 2009 07:43:54 -0000 According to David Malone: > I'll change the commented version, as it shouldn't do any harm. > As I said, I usually use 14, which is probably almost too low. I don't see any real added value having 14 instead of 10. At these levels it can be only a "faked" one. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 10:27:14 2009 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 8F82C106564A; Fri, 10 Jul 2009 10:27:14 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6508FC0A; Fri, 10 Jul 2009 10:27:14 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:Content-Transfer-Encoding:In-Reply-To:Sender; b=glv9zrfSIG3Jn+rk2JzVdrx9SgDvW262dbMIsA1l+k1vzREyHGTC4k4Gdao04qIlVKLuqAx4Q1BI17x5B7cAJE98Uz+VP6e39a24p+1d6URUTCF3K4f2QUVRh7gns6d9VEFH8cXc/iRg3EwOYqXdHP+DhNFpaYMU6gMw3dJN+Vc=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MPDJk-0006vR-0J; Fri, 10 Jul 2009 14:27:00 +0400 Date: Fri, 10 Jul 2009 14:26:57 +0400 From: Eygene Ryabinkin To: Artis Caune Message-ID: References: <200907091827.n69IR0Sl084730@freefall.freebsd.org> <9e20d71e0907092253m69346b0nde7095f7de9bc36f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9e20d71e0907092253m69346b0nde7095f7de9bc36f@mail.gmail.com> Sender: rea-fbsd@codelabs.ru Cc: freebsd-net@freebsd.org, mlaier@freebsd.org, bug-followup@freebsd.org, linimon@freebsd.org Subject: Re: kern/136618: [pf][stf] panic on cloning interface without unit number, e.g. `stf' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 10:27:14 -0000 Artis, good day. Fri, Jul 10, 2009 at 08:53:07AM +0300, Artis Caune wrote: > 2009/7/10 Eygene Ryabinkin : > > There is kern/127042 (rather old one, but it essentially the same as the > > current PR) that addresses this aspect of the problem: it > > > > š- additionally, it refuses to rename interface to the name that > > š coincides with one of existing group names (second and third hunks of > > š the patch in the said PR, by the way, last hunk misses '{' after 'if' > > š and has 'groupname' instead of 'new_name'). > > sorry for bad patch, my bad s/copy/coffee/ No problems. Care to test both patches? If yes, please, report back any findings of any type. > thanks for working on this. You're welcome ;)) -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 10:30:04 2009 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 202DC106564A for ; Fri, 10 Jul 2009 10:30: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 0D6578FC14 for ; Fri, 10 Jul 2009 10:30: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.3/8.14.3) with ESMTP id n6AAU3Vu050681 for ; Fri, 10 Jul 2009 10:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n6AAU3Ar050676; Fri, 10 Jul 2009 10:30:03 GMT (envelope-from gnats) Date: Fri, 10 Jul 2009 10:30:03 GMT Message-Id: <200907101030.n6AAU3Ar050676@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Eygene Ryabinkin Cc: Subject: Re: kern/136618: [pf][stf] panic on cloning interface without unit number, e.g. `stf' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eygene Ryabinkin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 10:30:04 -0000 The following reply was made to PR kern/136618; it has been noted by GNATS. From: Eygene Ryabinkin To: Artis Caune Cc: linimon@freebsd.org, bug-followup@freebsd.org, freebsd-net@freebsd.org, mlaier@freebsd.org Subject: Re: kern/136618: [pf][stf] panic on cloning interface without unit number, e.g. `stf' Date: Fri, 10 Jul 2009 14:26:57 +0400 Artis, good day. Fri, Jul 10, 2009 at 08:53:07AM +0300, Artis Caune wrote: > 2009/7/10 Eygene Ryabinkin : > > There is kern/127042 (rather old one, but it essentially the same as the > > current PR) that addresses this aspect of the problem: it > > > > š- additionally, it refuses to rename interface to the name that > > š coincides with one of existing group names (second and third hunks of > > š the patch in the said PR, by the way, last hunk misses '{' after 'if' > > š and has 'groupname' instead of 'new_name'). > > sorry for bad patch, my bad s/copy/coffee/ No problems. Care to test both patches? If yes, please, report back any findings of any type. > thanks for working on this. You're welcome ;)) -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 11:10:18 2009 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 0332A1065678; Fri, 10 Jul 2009 11:10:18 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id 2E6A68FC0A; Fri, 10 Jul 2009 11:10:17 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 10 Jul 2009 12:10:16 +0100 (BST) Received: from localhost ([127.0.0.1] helo=maths.tcd.ie) by walton.maths.tcd.ie with SMTP id ; 10 Jul 2009 12:10:15 +0100 (BST) To: Ollivier Robert In-reply-to: Your message of "Fri, 10 Jul 2009 09:43:46 +0200." <20090710074346.GA67742@roberto-al.eurocontrol.fr> X-Request-Do: Date: Fri, 10 Jul 2009 12:10:14 +0100 From: David Malone Message-ID: <200907101210.aa53747@walton.maths.tcd.ie> Cc: Brian Somers , Edwin Groothuis , freebsd-net@freebsd.org Subject: Re: NTP - default /etc/ntp.conf 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, 10 Jul 2009 11:10:18 -0000 > > I'll change the commented version, as it shouldn't do any harm. > > As I said, I usually use 14, which is probably almost too low. > I don't see any real added value having 14 instead of 10. At these levels it > can be only a "faked" one. Grand - let's leave it at 10 then. David. From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 11:30:14 2009 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 ACC6D106564A for ; Fri, 10 Jul 2009 11:30:14 +0000 (UTC) (envelope-from LConrad@Go2France.com) Received: from mgw1.MEIway.com (mgw1.meiway.com [81.255.84.75]) by mx1.freebsd.org (Postfix) with ESMTP id 39DE78FC19 for ; Fri, 10 Jul 2009 11:30:14 +0000 (UTC) (envelope-from LConrad@Go2France.com) Received: from VirusGate.MEIway.com (virusgate.meiway.com [81.255.84.76]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id D3AF0471DBD for ; Fri, 10 Jul 2009 13:30:14 +0200 (CEST) Received: from mail.Go2France.com (ms1.meiway.com [81.255.84.73]) by VirusGate.MEIway.com (Postfix) with ESMTP id 2EDC73865BB for ; Fri, 10 Jul 2009 13:30:15 +0200 (CEST) (envelope-from LConrad@Go2France.com) Received: from W500.Go2France.com [66.90.254.224] by mail.Go2France.com with ESMTP (SMTPD32-7.07) id A1EA624022E; Fri, 10 Jul 2009 13:11:38 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Jul 2009 06:30:10 -0500 To: freebsd-net@freebsd.org From: Len Conrad Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <200907101311781.SM01728@W500.Go2France.com> Subject: FreeBSD/iSCSI initiator into EMC Clarion target 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, 10 Jul 2009 11:30:15 -0000 uname -a FreeBSD xxx 7.1-RELEASE FreeBSD 7.1-RELEASE #0 kldstat Id Refs Address Size Name 1 5 0xc0400000 97f830 kernel 2 1 0xc0d80000 ff18 iscsi_initiator.ko 3 1 0xc0d90000 6a2c4 acpi.ko iscontrol doesn't have -V version and strings doesn't find anything that looks like a version. iscontrol -d -v -t 192.168.78.5 port = 3260 tags = 0 maxluns = 0 iqn = iqn.2005-01.il.ac.huji.cs: maxConnections = 1 maxRecvDataSegmentLength = 65536 maxXmitDataSegmentLength = 65536 maxBurstLength = 131072 firstBurstLength = 65536 defaultTime2Wait = 0 defaultTime2Retain = 0 maxOutstandingR2T = 1 errorRecoveryLevel = 0 targetPortalGroupTag = 0 headerDigest = None,CRC32C dataDigest = None,CRC32C initialR2T = 1 immediateData = 1 dataPDUInOrder = 1 dataSequenceInOrder = 1 sessionType = Normal targetAddress = (null) targetAlias = (null) targetName = (null) initiatorName = (null) initiatorAlias = (null) authMethod = None chapSecret = (null) chapIName = (null) tgtChapName = (null) tgtChapSecret = (null) tgttgtChallengeLen = 0 I-: cmd=0x3 len=301 SessionType=Discovery InitiatorName=iqn.2005-01.il.ac.huji.cs::mr1.xxxx.net MaxBurstLength=131072 HeaderDigest=None,CRC32C DataDigest=None,CRC32C MaxRecvDataSegmentLength=65536 ErrorRecoveryLevel=0 DefaultTime2Wait=0 DefaultTime2Retain=0 DataPDUInOrder=Yes DataSequenceInOrder=Yes MaxOutstandingR2T=1 T-: cmd=0x23 len=281 TargetPortalGroupTag=0 TargetAlias=1576.b3 HeaderDigest=None DataDigest=None MaxRecvDataSegmentLength=65536 MaxBurstLength=Irrelevant DefaultTime2Wait=0 DefaultTime2Retain=0 MaxOutstandingR2T=Irrelevant DataPDUInOrder=Irrelevant DataSequenceInOrder=Irrelevant ErrorRecoveryLevel=0 I-: cmd=0x4 len=16 SendTargets=All recvpdu: Socket is not connected recvpdu failed I-: cmd=0x6 len=0 recvpdu: Socket is not connected recvpdu failed ========== initatator does work into a FreeBSD/iscsi-target: # iscontrol -c /etc/iscsi.conf -n target0 iscontrol[817]: running iscontrol[817]: (pass3:iscsi0:0:0:0): tagged openings now 0 iscontrol[817]: cam_open_btl: no passthrough device found at 2:0:1 iscontrol[817]: cam_open_btl: no passthrough device found at 2:0:2 iscontrol[817]: cam_open_btl: no passthrough device found at 2:0:3 iscontrol: supervise starting main loop #ll /dev/is* crw------- 1 root wheel 0, 27 Jul 8 13:29 /dev/iscsi crw------- 1 root wheel 0, 103 Jul 8 13:29 /dev/iscsi0 #ll /dev/da* crw-r----- 1 root operator 0, 90 Jul 8 13:29 /dev/da0 crw-r----- 1 root operator 0, 91 Jul 8 13:29 /dev/da0s1 crw-r----- 1 root operator 0, 92 Jul 8 08:30 /dev/da0s1a crw-r----- 1 root operator 0, 93 Jul 8 13:30 /dev/da0s1b crw-r----- 1 root operator 0, 94 Jul 8 13:29 /dev/da0s1c crw-r----- 1 root operator 0, 95 Jul 8 08:29 /dev/da0s1d crw-r----- 1 root operator 0, 96 Jul 8 08:29 /dev/da0s1e crw-r----- 1 root operator 0, 105 Jul 8 13:29 /dev/da1 crw-r----- 1 root operator 0, 106 Jul 8 13:29 /dev/da1s1 crw-r----- 1 root operator 0, 107 Jul 8 13:29 /dev/da1s1c crw-r----- 1 root operator 0, 108 Jul 8 13:29 /dev/da1s1d #mount /dev/da1s1 /iscsitest/ #df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1a 10154158 141662 9200164 2% / devfs 1 1 0 100% /dev /dev/da0s1d 20308398 1393604 17290124 7% /usr /dev/da0s1e 40622090 292054 37080270 1% /var /dev/da1s1 9907690 2990276 6124800 33% /iscsitest ========= Red Hat Enterprise iscsi initiator connects to EMC SAN target reliably. If we can't get the FreeBSD iniatator working, we'll have to convert several machines from FreeBSD to Linux. Len From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 03:43:43 2009 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 A851A1065673 for ; Fri, 10 Jul 2009 03:43:43 +0000 (UTC) (envelope-from realliukai@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4918FC1C for ; Fri, 10 Jul 2009 03:43:43 +0000 (UTC) (envelope-from realliukai@gmail.com) Received: by rv-out-0506.google.com with SMTP id f9so160491rvb.43 for ; Thu, 09 Jul 2009 20:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=nLMebcUM7GxlAGN7oq3FS3Nupo4WREWWK1HAuRd2bMc=; b=I9QNAIp/LvM4MHbNkMbxUj34hqL+dkNRMmHvksUVmliv93CzVhL9BEia3J5vqJqk/x GP7BCqmZn4f6by+9W0smLWpRdYkQZpWCLuSehqQE4DS9NewYFsSc4cKuoPZMisgdx8mr qC1IBI0OtT3mMOKdg1FZr2gzRLzZu2vfpLn5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HhOe3/QCNMtCs34dYqOZcYZmUZJg/EUlml5/ok0poE51Xocqri+PHI2lqH/EDFY59F VgwBxU540uULB4uN5LYZ9mG3wOw0lyCd2ZRakgFm689iYUtPM8RZUyvb93TuP0Zp7moq YhBm8oE1HBxJ5brXTWf50Z28VrCZghN/p2MDY= MIME-Version: 1.0 Received: by 10.140.226.6 with SMTP id y6mr1005603rvg.223.1247197423288; Thu, 09 Jul 2009 20:43:43 -0700 (PDT) Date: Fri, 10 Jul 2009 11:43:43 +0800 Message-ID: <7237120a0907092043ld8a3325mcf1458ef4aab3bf8@mail.gmail.com> From: =?GB2312?B?wfW/rQ==?= To: freebsd-net@freebsd.org X-Mailman-Approved-At: Fri, 10 Jul 2009 12:00:07 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: system panic when i use ath without swap,some advice? 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, 10 Jul 2009 03:43:43 -0000 Hi all My system is atom n270 1G RAM, freebsd 7.2 release .without swap. When my ath is associated with an AP, and the traffic is high, the system will panic and reboot. this happened many times. Can you give me some advice please. thanks Micheal Kevin From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 12:35:33 2009 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 C71F3106566C; Fri, 10 Jul 2009 12:35:33 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2BC8FC19; Fri, 10 Jul 2009 12:35:33 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id CCB084D53; Fri, 10 Jul 2009 14:35:32 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n6ACZTK8055297; Fri, 10 Jul 2009 14:35:29 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1247229332; bh=yPMyJBmWtRvc4He6EP6dBDK6HLp9l9++4rz067/EBaY=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=LTr+3h4OW9aPvIKpMip8CtXMqRCaXOv+S0okutnJ0/Zwc1dBjw0Ps31Y6lNGbK4/D InMIHj9MNnX26Pmd716dA== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:content-type:content-transfer-encoding:x-scanned-by; b=lRJOv3pdq14gPH9pRCYEUX7T9ZHIGlBgMBJCfno0utNdb7s4vH13fQbN960S92thO yyUHYH9M8r/CGtsoBLNyw== Message-ID: <4A573591.1000506@restart.be> Date: Fri, 10 Jul 2009 14:35:29 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.22 (X11/20090627) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections 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, 10 Jul 2009 12:35:34 -0000 Hello, After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when connecting with firefox to a local apache server using the global unicast IPv6 address of the local machine. pf.conf must be updated! My configuration: [root@avoriaz ~]# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:1d:60:ad:2a:ce inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255 inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 media: Ethernet 100baseTX (100baseTX ) status: active [root@avoriaz ~]# host www.restart.bel www.restart.bel is an alias for avoriaz.restart.bel. avoriaz.restart.bel has address 192.168.24.1 avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: pf.conf: int_if="em0" block in log all block out log all set skip on lo0 antispoof quick for $int_if inet # Allow trafic with physical internal network pass in quick on $int_if from ($int_if:network) to ($int_if) keep state pass out quick on $int_if from ($int_if) to ($int_if:network) keep state The problem: [root@avoriaz ~]# telnet -4 www.restart.bel 80 Trying 192.168.24.1... Connected to avoriaz.restart.bel. Escape character is '^]'. ^] telnet> quit Connection closed. [root@avoriaz ~]# telnet -6 www.restart.bel 80 Trying 2001:41d0:2:2d29:1:1::... --->Never connect and get a timeout! tcpdump and logging in pf show me that For a IPv4 connection: the packet from telnet to apache pass 2 times on lo0 (out and in) the answer packet from apache to telnet pass 2 times on lo0 (out and in) So no problem, there is `set skip on lo0' For a IPv6 connection: The first packet from telnet to apache pass 2 times on lo0 (out and in) The answer packet from apache to telnet path on em0 and is rejected due to the default flags S/SA. So I have to change pf.conf and replace the last line: pass out quick on $int_if from ($int_if) to ($int_if:network) \ keep state flags any Then all is OK By the way, on 7.2 netstat -rn display 192.168.24.1 00:1d:60:ad:2a:ce .... 2001:41d0:2:2d29:1:1:: 00:1d:60:ad:2a:ce On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 .... no entry for 2001:41d0:2:2d29:1:1:: Hope it may help someone Henri From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 16:13:24 2009 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 2C28D1065670 for ; Fri, 10 Jul 2009 16:13:24 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id ACA078FC14 for ; Fri, 10 Jul 2009 16:13:23 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz21 with SMTP id 21so798462bwz.43 for ; Fri, 10 Jul 2009 09:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Z5wVUnZBvxtKpfTCC0R5KxrogJ9BrBN/ZPK5ksVSjyo=; b=Wx+jTPu+d9AWBhxV5MmW+xP38cPgZ/aezqpPehEreLHm++LcieRLgy172NlzBjQd4V a3zYseorcxYiAYWUZadRbTIKrSz+hamt4H1lizB4gmVvI8s0VjQCq3bX5x/vQeiOSfZX nVngG4A6PF8J3PCpcLgXQKD1ZgFYqVhubWvRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=ZwGpPAWjKJmWqUAu03cZQSy1QqE3K2z+hFtKndwXg1x5HMDGiNRqHborShyzQOCg6p HRKPoSjSj4JbPyHa7jS2NjKDxZES7kQwL20ynVrj39Ylfxb3LDXS6698xa9CGtHPIUtj IM1cr9+a1ax93Qk3OdZ3z8i0t9iMoMzHyoMDA= MIME-Version: 1.0 Received: by 10.204.56.4 with SMTP id w4mr2069036bkg.25.1247242402691; Fri, 10 Jul 2009 09:13:22 -0700 (PDT) Date: Fri, 10 Jul 2009 20:13:22 +0400 Message-ID: From: pluknet To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: aliases on lo0: SIOCDIFADDR gives EADDRNOTAVAIL 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, 10 Jul 2009 16:13:24 -0000 Hi. I have the next string in rc.conf: ifconfig_lo0_alias0="inet 192.168.193.193/32" /etc/rc.d/netif restart lo0 prints an error: Stopping network:ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address lo0. lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 inet 192.168.193.193 netmask 0xffffffff Can someone comment on this? Thanks. -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 16:24:29 2009 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 0DEC4106566C for ; Fri, 10 Jul 2009 16:24:29 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC4A8FC14 for ; Fri, 10 Jul 2009 16:24:28 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz21 with SMTP id 21so803826bwz.43 for ; Fri, 10 Jul 2009 09:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ttyFEMpKBUlM1o/w4a9AYvdJPS1aoI/JwGb2QtYw+vE=; b=mpiwUpJoPBWsEuwHhJZPAPKvBcRJn8GSKzXHnlbPGKFT4RkxFXsOyXIkCAkjAMZAPX xkygG7QLj85i2zwepw9mpnJjm9XB/4lKD4x+noK34VjH0FoZUdTII3xbnY0qWHx0GFqj WLzX0PkWcaVFDnxdl9W/l6StJbNIN7cahOyck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=A99akH83h5HR7IzIDF7r/cVrT8IYACLoPuzEJqUv+GIaMu5Lr1qTmXFSvJbXdJ4IyE CVIcIb6/rmbKiTNeb1ME1/vkbT008WjipVC/yhOW2+qFstlFA4oT4+mPVemprIruhGLx Rwo1TPNChMAGNYBS8oPsh0fwyvJ7L33BuSTh4= MIME-Version: 1.0 Received: by 10.204.102.14 with SMTP id e14mr2076371bko.183.1247243067412; Fri, 10 Jul 2009 09:24:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Jul 2009 20:24:27 +0400 Message-ID: From: pluknet To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: aliases on lo0: SIOCDIFADDR gives EADDRNOTAVAIL 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, 10 Jul 2009 16:24:29 -0000 2009/7/10 pluknet : > Hi. > > I have the next string in rc.conf: > ifconfig_lo0_alias0=3D"inet 192.168.193.193/32" > > /etc/rc.d/netif restart lo0 prints an error: > > Stopping network:ifconfig: ioctl (SIOCDIFADDR): Can't assign requested ad= dress > =A0lo0. > lo0: flags=3D8049 mtu 16384 > =A0 =A0 =A0 =A0inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > =A0 =A0 =A0 =A0inet6 ::1 prefixlen 128 > =A0 =A0 =A0 =A0inet 127.0.0.1 netmask 0xff000000 > =A0 =A0 =A0 =A0inet 192.168.193.193 netmask 0xffffffff > > Can someone comment on this? > P.S. AFAICS from sh -x this equvalents to: ifconfig lo0 inet 192.168.193.193/32 -alias ifconfig lo0 inet 192.168.193.193 delete $ sudo ifconfig lo0 inet 192.168.193.193/32 -alias $ ifconfig lo0 lo0: flags=3D8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 $ sudo ifconfig lo0 inet 192.168.193.193 delete ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Fri Jul 10 20:25:43 2009 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 7372C106564A for ; Fri, 10 Jul 2009 20:25:43 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id F14178FC1B for ; Fri, 10 Jul 2009 20:25:42 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz21 with SMTP id 21so904681bwz.43 for ; Fri, 10 Jul 2009 13:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=44TlrfNg0cpRwecGQupxHKR2sVX/GJbczkGAz7CHFG8=; b=pOP/LW14NIV4vgwiwiILSN2Ks7szMnUJ8FkYNPqli7DMHohHfP2pvjj6vGiymBsnKs UJzV+tB0KMwLCQorUBQcwJd8l9L1hwovuO1GvaDOi1TwcDkmDU5zEYeWdL7PeDlk+hdp O4+ja+FcEYNZHrkUVRUSUcbgFroXz+rMYZozE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OZWkwKpua6LAAqAtdM6+yTGSMxUbm2Q+VcxBWT+IhA78U2rOotP5OQfeEaacnVBvTr A+Z0eSrHgLdKIxHm61vIWWzDlSgOkqpBgRrdwbIZPMwk0c0+5DZXNB/y9kaNg7Z3kOFC W7nyIdJZxTtxMyo6Io60caGqAZSihMC55lK2A= MIME-Version: 1.0 Received: by 10.204.76.199 with SMTP id d7mr2268950bkk.74.1247257541128; Fri, 10 Jul 2009 13:25:41 -0700 (PDT) In-Reply-To: <7237120a0907092043ld8a3325mcf1458ef4aab3bf8@mail.gmail.com> References: <7237120a0907092043ld8a3325mcf1458ef4aab3bf8@mail.gmail.com> Date: Fri, 10 Jul 2009 22:25:41 +0200 Message-ID: <3a142e750907101325l318a8854q6c75dd7b94dfcc3a@mail.gmail.com> From: "Paul B. Mahol" To: "******" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: system panic when i use ath without swap,some advice? 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, 10 Jul 2009 20:25:43 -0000 On 7/10/09, ****** wrote: > Hi all > > My system is atom n270 1G RAM, freebsd 7.2 release .without swap. > When my ath is associated with an AP, and the traffic is high, the > system will panic and reboot. this happened many times. > Can you give me some advice please. > thanks > > Micheal Kevin > _______________________________________________ > 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" > Provide backtrace from crash, and "vmstat -m" output. -- Paul From owner-freebsd-net@FreeBSD.ORG Sat Jul 11 04:13:52 2009 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 2671C106566C for ; Sat, 11 Jul 2009 04:13:51 +0000 (UTC) (envelope-from kbrint@rufus.net) Received: from hamachi.rufus.net (hamachi.rufus.net [209.181.236.65]) by mx1.freebsd.org (Postfix) with ESMTP id BA7A08FC0C for ; Sat, 11 Jul 2009 04:13:51 +0000 (UTC) (envelope-from kbrint@rufus.net) Received: by hamachi.rufus.net (Postfix, from userid 100) id 31CDC1FFDBF; Fri, 10 Jul 2009 22:54:35 -0500 (CDT) Date: Fri, 10 Jul 2009 22:54:35 -0500 From: kevin brintnall To: freebsd-net@freebsd.org Message-ID: <20090711035435.GA18298@rufus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: panic on ip_input, ip_len byte ordering 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: Sat, 11 Jul 2009 04:13:52 -0000 Hi, Here is my system: FreeBSD fw.rufus.net 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #1: Wed Jun 10 11:32:28 CDT 2009 root@hamachi.rufus.net:/usr/obj/usr/src/sys/SOEKRIS i386 I am seeing occasional panics in ip_input when forwarding IP traffic at low rates (<100pkt/sec). Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc0872228 stack pointer = 0x28:0xc17f2b20 frame pointer = 0x28:0xc17f2b3c 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 = 20 (irq10: sis0 sis1+) trap number = 12 panic: page fault cpuid = 0 Uptime: 12d10h48m45s Physical memory: 115 MB Dumping 49 MB: 34 18 2 Dump complete The stack trace is as follows: #5 0xc0b502cc in trap (frame=0xc17f2ae0) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0b342bb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc0872228 in m_copydata (m=0x0, off=0, len=88, cp=0xc1aeb6a8 "some garbage") at /usr/src/sys/kern/uipc_mbuf.c:815 #8 0xc090a728 in ip_forward (m=0xc19f0700, srcrt=0) at /usr/src/sys/netinet/ip_input.c:1307 #9 0xc090bf0c in ip_input (m=0xc19f0700) at /usr/src/sys/netinet/ip_input.c:609 #10 0xc08c9fa5 in netisr_dispatch (num=2, m=0xc19f0700) at /usr/src/sys/net/netisr.c:185 m_copydata is walking off the end of the mbuf chain.. It turns out that the IP header length is incorrect. Here is the code from frame 8: 1304 if (mcopy != NULL) { 1305 mcopy->m_len = min(ip->ip_len, M_TRAILINGSPACE(mcopy)); 1306 mcopy->m_pkthdr.len = mcopy->m_len; 1307 m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); 1308 } The packet is 116 bytes, which is correctly reflected in the mbuf header. However, the IP packet length appears to be in network byte order rather than host byte order. Note that 29696=ntohs(116). (kgdb) p m->m_hdr->mh_len $55 = 116 (kgdb) p mcopy->m_hdr->mh_len $56 = 204 (kgdb) p ip->ip_len $57 = 29696 <<-- should be 116! The rest of the IP header looks correct: $58 = {ip_hl = 5, ip_v = 4, ip_tos = 16 '\020', ip_len = 29696, ip_id = 38700, ip_off = 64, ip_ttl = 58 ':', ip_p = 6 '\006', ip_sum = 5172, ip_src = { s_addr = X}, ip_dst = {s_addr = 1139586513}} When ip_input is initially called, I think the ip_len must be right.. Otherwise, the "tooshort" block around ip_input.c:383 would stop processing. if (m->m_pkthdr.len < ip->ip_len) { tooshort: ipstat.ips_tooshort++; goto bad; } Any ideas? My best guess is that there exists a code path in PF somewhere that is doing an uneven number of ntohs() and htons(). Thanks in advance! -- kevin brintnall =~ /kbrint@rufus.net/ From owner-freebsd-net@FreeBSD.ORG Sat Jul 11 07:59:20 2009 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 B721E106564A for ; Sat, 11 Jul 2009 07:59:20 +0000 (UTC) (envelope-from iprebeg@freebsd.org) Received: from maja.zesoi.fer.hr (maja.zesoi.fer.hr [161.53.64.3]) by mx1.freebsd.org (Postfix) with ESMTP id 771218FC1B for ; Sat, 11 Jul 2009 07:59:20 +0000 (UTC) (envelope-from iprebeg@freebsd.org) Received: from localhost (localhost [127.0.0.1]) by maja.zesoi.fer.hr (Postfix) with ESMTP id 8055E42F7D for ; Sat, 11 Jul 2009 09:41:59 +0200 (CEST) Received: from maja.zesoi.fer.hr ([127.0.0.1]) by localhost (maja.zesoi.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43uXyln92rlr for ; Sat, 11 Jul 2009 09:41:53 +0200 (CEST) Received: from valeria.zesoi.fer.hr (valeria.zesoi.fer.hr [161.53.64.29]) by maja.zesoi.fer.hr (Postfix) with ESMTP id 3F38A42F7A for ; Sat, 11 Jul 2009 09:41:32 +0200 (CEST) Date: Sat, 11 Jul 2009 09:36:47 +0200 From: iprebeg@freebsd.org To: freebsd-net@freebsd.org Message-ID: <20090711073647.GA1824@valeria.zesoi.fer.hr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Subject: em driver doesn't set multicast ethernet address 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, 11 Jul 2009 07:59:21 -0000 While testing -CURRENT in VMWare environment, I discovered that em driver doesn't properly set destination address in Ethernet header. In the other words, when I start listening multicast session with mcastread (mcast-tools), kernel triggers IGMPv3 packet. Its destionation IP is 224.0.0.22, but its destionation Ethernet address doesn't look like 01:00:5e:... Other machines that I run in same environment (like FreeBSD-7) behave in good manner. From owner-freebsd-net@FreeBSD.ORG Sat Jul 11 08:17:11 2009 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 244BA106566B for ; Sat, 11 Jul 2009 08:17:11 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id E82A48FC08 for ; Sat, 11 Jul 2009 08:17:10 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 5F4203B0974; Sat, 11 Jul 2009 04:17:10 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 11 Jul 2009 04:17:10 -0400 X-Sasl-enc: IyJmwHAT7qnaENQ/WG1ZSeWVNg2Obt0hpoBY1xZIqNJi 1247300230 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id CD44A56A9; Sat, 11 Jul 2009 04:17:09 -0400 (EDT) Message-ID: <4A5849E5.90909@incunabulum.net> Date: Sat, 11 Jul 2009 09:14:29 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: iprebeg@freebsd.org References: <20090711073647.GA1824@valeria.zesoi.fer.hr> In-Reply-To: <20090711073647.GA1824@valeria.zesoi.fer.hr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jfv@FreeBSD.org, freebsd-net@freebsd.org Subject: Re: em driver doesn't set multicast ethernet address 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, 11 Jul 2009 08:17:11 -0000 iprebeg@freebsd.org wrote: > While testing -CURRENT in VMWare environment, I discovered that em > driver doesn't properly set destination address in Ethernet header. In > the other words, when I start listening multicast session with mcastread > (mcast-tools), kernel triggers IGMPv3 packet. Its destionation IP is > 224.0.0.22, but its destionation Ethernet address doesn't look like > 01:00:5e:... Other machines that I run in same environment (like > FreeBSD-7) behave in good manner. > It seems that the introduction of IGMPv3 may have exposed some driver/hardware issues, where certain network interfaces are not able to transmit on groups which haven't been joined for receive. This is a bug, and would likely break production use of IPv6, which makes heavier use of link-scope groups than IPv4 does. Can you provide the following information please, so that someone can better help you: 1) the date of the -CURRENT code you are using; 2) tcpdump or wireshark capture output, containing the actual output generated by em(4). Does this issue occur if you use the 'mtest' tool to join 224.0.0.22 inside the guest? The kernel will *not* listen to 224.0.0.22, unless you're running a multicast routing daemon -- as it doesn't have to; that link-scope group is for reports only. This issue doesn't appear with IGMPv2, because it only ever transmits its reports on the group thus joined. This has the disadvantage that multicast routers have to have functioning promiscuous multicast receive, just to proxy or forward traffic. Can you force the use of IGMPv2 using the sysctls as defined in the igmp(4) man page as a workaround? thanks, BMS From owner-freebsd-net@FreeBSD.ORG Sat Jul 11 09:33:02 2009 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 502C91065670 for ; Sat, 11 Jul 2009 09:33:02 +0000 (UTC) (envelope-from iprebeg@freebsd.org) Received: from maja.zesoi.fer.hr (maja.zesoi.fer.hr [161.53.64.3]) by mx1.freebsd.org (Postfix) with ESMTP id A416B8FC0A for ; Sat, 11 Jul 2009 09:33:01 +0000 (UTC) (envelope-from iprebeg@freebsd.org) Received: from localhost (localhost [127.0.0.1]) by maja.zesoi.fer.hr (Postfix) with ESMTP id 9D24942F7D; Sat, 11 Jul 2009 11:32:58 +0200 (CEST) Received: from maja.zesoi.fer.hr ([127.0.0.1]) by localhost (maja.zesoi.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oas29aospidd; Sat, 11 Jul 2009 11:32:52 +0200 (CEST) Received: from valeria.zesoi.fer.hr (valeria.zesoi.fer.hr [161.53.64.29]) by maja.zesoi.fer.hr (Postfix) with ESMTP id 403BB42FBC; Sat, 11 Jul 2009 11:32:37 +0200 (CEST) Date: Sat, 11 Jul 2009 11:27:53 +0200 From: iprebeg@freebsd.org To: Bruce Simpson Message-ID: <20090711092753.GA9630@valeria.zesoi.fer.hr> References: <20090711073647.GA1824@valeria.zesoi.fer.hr> <4A5849E5.90909@incunabulum.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <4A5849E5.90909@incunabulum.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org Subject: Re: em driver doesn't set multicast ethernet address 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, 11 Jul 2009 09:33:02 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jul 11, 2009 at 09:14:29AM +0100, Bruce Simpson wrote: > iprebeg@freebsd.org wrote: >> While testing -CURRENT in VMWare environment, I discovered that em >> driver doesn't properly set destination address in Ethernet header. In >> the other words, when I start listening multicast session with mcastread >> (mcast-tools), kernel triggers IGMPv3 packet. Its destionation IP is >> 224.0.0.22, but its destionation Ethernet address doesn't look like >> 01:00:5e:... Other machines that I run in same environment (like >> FreeBSD-7) behave in good manner. >> > > It seems that the introduction of IGMPv3 may have exposed some > driver/hardware issues, where certain network interfaces are not able to > transmit on groups which haven't been joined for receive. This is a bug, > and would likely break production use of IPv6, which makes heavier use of > link-scope groups than IPv4 does. > > Can you provide the following information please, so that someone can > better help you: > 1) the date of the -CURRENT code you are using; > 2) tcpdump or wireshark capture output, containing the actual output > generated by em(4). 1) Problem emerged after I upgraded to BETA1 and stayed there after I upgraded to p4 version dated 10th of July. Before that I used few months old snapshot (can't exactly tell the date). 2) dump file generated by wireshark is attached > > Does this issue occur if you use the 'mtest' tool to join 224.0.0.22 inside > the guest? The kernel will *not* listen to 224.0.0.22, unless you're > running a multicast routing daemon -- as it doesn't have to; that > link-scope group is for reports only. There is no difference, ethernet destination is still usual unicast address. > > This issue doesn't appear with IGMPv2, because it only ever transmits its > reports on the group thus joined. This has the disadvantage that multicast > routers have to have functioning promiscuous multicast receive, just to > proxy or forward traffic. > > Can you force the use of IGMPv2 using the sysctls as defined in the igmp(4) > man page as a workaround? Well, now, something really interesting happened. I changed default IGMP version via sysctl # sysctl net.inet.igmp.default_version=2 but, then I tested it with mtest and generated packets were still IGMPv3 Membership reports, but first two of them had proper mcast ethernet address. They generated sent by mtest. > > thanks, > BMS > _______________________________________________ > 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" --lrZ03NoBR/3+SXJZ Content-Type: application/octet-stream Content-Disposition: attachment; filename="igmp.dump" Content-Transfer-Encoding: base64 1MOyoQIABAAAAAAAAAAAAP//AAABAAAA+IxWSoYBAAA8AAAAPAAAAAAhKZNVTAAMKeHMCwgA RsAALAahQAABAvFSCgACAuAAABaUBAAAIgDi+gAAAAEDAAAB6wAAAQoAAwEAAPiMVkpH1g0A PAAAADwAAAAAISmTVUwADCnhzAsIAEbAACwGokAAAQLxUQoAAgLgAAAWlAQAACIA4voAAAAB AwAAAesAAAEKAAMBAABxjVZKghsMADwAAAA8AAAAACEpk1VMAAwp4cwLCABGwAAoBqZAAAEC 8VEKAAIC4AAAFpQEAAAiAO/8AAAAAQMAAADrAAABAAAAAAAAco1WSke4BwA8AAAAPAAAAAAh KZNVTAAMKeHMCwgARsAAKAanQAABAvFQCgACAuAAABaUBAAAIgDv/AAAAAEDAAAA6wAAAQAA AAAAANqPVkpNRAwALgAAAC4AAAABAF4AAAEADClqfhsIAEYAACBRAQAAAQLb0woAAwLrAAAB lAQAABYA/v3rAAAB249WSt94CQAuAAAALgAAAAEAXgAAAQAMKWp+GwgARgAAIFIBAAABAtrT CgADAusAAAGUBAAAFgD+/esAAAG5kFZKqMgMAC4AAAAuAAAAAQBeAAACAAwpan4bCABGAAAg UwEAAAEC5NIKAAMC4AAAApQEAAAXAP396wAAARGjVko3EAUALgAAAC4AAAABAF4AAAEADClq fhsIAEYAACCPAQAAAQKd0woAAwLrAAABlAQAABYA/v3rAAABE6NWSu1eAQAuAAAALgAAAAEA XgAAAgAMKWp+GwgARgAAIJABAAABAqfSCgADAuAAAAKUBAAAFwD9/esAAAEUo1ZKRzIBAC4A AAAuAAAAAQBeAAABAAwpan4bCABGAAAglQEAAAECl9MKAAMC6wAAAZQEAAAWAP796wAAARqj VkpCCwkALgAAAC4AAAABAF4AAAEADClqfhsIAEYAACCWAQAAAQKW0woAAwLrAAABlAQAABYA /v3rAAABHqNWSlRmBAAuAAAALgAAAAEAXgAAAgAMKWp+GwgARgAAIJcBAAABAqDSCgADAuAA AAKUBAAAFwD9/esAAAEio1ZKeP8CAC4AAAAuAAAAAQBeAAABAAwpan4bCABGAAAgnAEAAAEC kNMKAAMC6wAAAZQEAAAWAP796wAAASKjVkp1ZAQALgAAAC4AAAABAF4AAAIADClqfhsIAEYA ACCdAQAAAQKa0goAAwLgAAAClAQAABcA/f3rAAABIqNWSi4TCQAuAAAALgAAAAEAXgAAAQAM KWp+GwgARgAAIKIBAAABAorTCgADAusAAAGUBAAAFgD+/esAAAEjo1ZKC+YIAC4AAAAuAAAA AQBeAAACAAwpan4bCABGAAAgowEAAAEClNIKAAMC4AAAApQEAAAXAP396wAAASajVkqgQAcA LgAAAC4AAAABAF4AAAEADClqfhsIAEYAACCzAQAAAQJ50woAAwLrAAABlAQAABYA/v3rAAAB JqNWSizIDAAuAAAALgAAAAEAXgAAAgAMKWp+GwgARgAAILQBAAABAoPSCgADAuAAAAKUBAAA FwD9/esAAAEno1ZKwn0CAC4AAAAuAAAAAQBeAAABAAwpan4bCABGAAAgxwEAAAECZdMKAAMC 6wAAAZQEAAAWAP796wAAASejVkpM3AkALgAAAC4AAAABAF4AAAEADClqfhsIAEYAACDSAQAA AQJa0woAAwLrAAABlAQAABYA/v3rAAABKKNWSkPbAAAuAAAALgAAAAEAXgAAAgAMKWp+GwgA RgAAINwBAAABAlvSCgADAuAAAAKUBAAAFwD9/esAAAEoo1ZKM5ADAC4AAAAuAAAAAQBeAAAB AAwpan4bCABGAAAg4wEAAAECSdMKAAMC6wAAAZQEAAAWAP796wAAASmjVkrLogAALgAAAC4A AAABAF4AAAIADClqfhsIAEYAACD5AQAAAQIz0goAAwLrAAAClAQAABYA/vzrAAACKaNWSppS CwAuAAAALgAAAAEAXgAAAgAMKWp+GwgARgAAIAMCAAABAjTSCgADAuAAAAKUBAAAFwD9/esA AAEpo1ZKmXkNAC4AAAAuAAAAAQBeAAACAAwpan4bCABGAAAgCgIAAAECLdIKAAMC4AAAApQE AAAXAP386wAAAnGkVkqUAAYALgAAAC4AAAABAF4AAAEADClqfhsIAEYAACAvAgAAAQL90goA AwLrAAABlAQAABYA/v3rAAABdaRWSocmBgAuAAAALgAAAAEAXgAAAQAMKWp+GwgARgAAIDAC AAABAvzSCgADAusAAAGUBAAAFgD+/esAAAF6pFZKY54CAC4AAAAuAAAAAQBeAAACAAwpan4b CABGAAAgMQIAAAECBtIKAAMC4AAAApQEAAAXAP396wAAAX6kVkqoegUAKgAAACoAAAD///// //8ADClqfhsIBgABCAAGBAABAAwpan4bCgACAgAAAAAAAAoAAgJ+pFZK7vMFADwAAAA8AAAA AAwpan4bAAwp4cwLCAYAAQgABgQAAgAMKeHMCwoAAgIADClqfhsKAAICAAAAAAAAAAAAAAAA AAAAAAAAf6RWSu3/BgA8AAAAPAAAAP///////wAMKeHMCwgGAAEIAAYEAAEADCnhzAsKAAIC AAAAAAAACgACAgAAAAAAAAAAAAAAAAAAAAAAAH+kVkosAAcAKgAAACoAAAAADCnhzAsADClq fhsIBgABCAAGBAACAAwpan4bCgACAgAMKeHMCwoAAgJ/pFZK77cLADwAAAA8AAAA//////// AAwp4cwLCAYAAQgABgQAAQAMKeHMCwoAAQIAAAAAAAAKAAECAAAAAAAAAAAAAAAAAAAAAAAA f6RWSvf8DQAqAAAAKgAAAP///////wAMKWp+GwgGAAEIAAYEAAEADClqfhsKAAICAAAAAAAA CgACAoGkVkpZwQoAPAAAADwAAAAAISmTVUwADCnhzAsIAEbAACzyF0AAAQIG3AoAAQLgAAAW lAQAACIA5foAAAABAwAAAesAAAEKAAABAACBpFZKy2YLADwAAAA8AAAAACEpk1VMAAwp4cwL CABGwAAs8hhAAAECBtsKAAEC4AAAFpQEAAAiAOX6AAAAAQMAAAHrAAABCgAAAQAAgaRWSqaX CwA8AAAAPAAAAAAhKZNVTAAMKeHMCwgARsAAKPIcQAABAgbbCgABAuAAABaUBAAAIgDv/AAA AAEDAAAA6wAAAQAAAAAAAIGkVko54AsAPAAAADwAAAAAISmTVUwADCnhzAsIAEbAACjyHUAA AQIG2goAAQLgAAAWlAQAACIA7/wAAAABAwAAAOsAAAEAAAAAAACCpFZKzBsAAC4AAAAuAAAA AQBeAAABAAwpan4bCABGAAAgYAIAAAECzdIKAAIC6wAAAZQEAAAWAP796wAAAYOkVkou+AMA LgAAAC4AAAABAF4AAAEADClqfhsIAEYAACBhAgAAAQLM0goAAgLrAAABlAQAABYA/v3rAAAB S6lWSoFSCQAuAAAALgAAAAEAXgAAAgAMKWp+GwgARgAAII0CAAABAqvRCgACAuAAAAKUBAAA FwD9/esAAAHNuFZKrSQDADwAAAA8AAAA////////AAwp4cwLCAYAAQgABgQAAQAMKeHMCwoA AgIAAAAAAAAKAAICAAAAAAAAAAAAAAAAAAAAAAAAzbhWSv0lAwAqAAAAKgAAAAAMKeHMCwAM KWp+GwgGAAEIAAYEAAIADClqfhsKAAICAAwp4cwLCgACAs+4VkrcJQYAPAAAADwAAAAAISmT VUwADCnhzAsIAEbAACwAuEAAAQL3OwoAAgLgAAAWlAQAACIA4voAAAABAwAAAesAAAEKAAMB AADQuFZKSqwDADwAAAA8AAAAACEpk1VMAAwp4cwLCABGwAAsALlAAAEC9zoKAAIC4AAAFpQE AAAiAOL6AAAAAQMAAAHrAAABCgADAQAA4LhWSrkKAwA8AAAAPAAAAAAhKZNVTAAMKeHMCwgA RsAAKAC7QAABAvc8CgACAuAAABaUBAAAIgDv/AAAAAEDAAAA6wAAAQAAAAAAAOG4VkpNQwEA PAAAADwAAAAAISmTVUwADCnhzAsIAEbAACgAvkAAAQL3OQoAAgLgAAAWlAQAACIA7/wAAAAB AwAAAOsAAAEAAAAAAADxwVZK0C4MADwAAAA8AAAAACEpk1VMAAwp4cwLCABGwAAoHvBAAAEC 2QcKAAIC4AAAFpQEAAAiAO78AAAAAQQAAADrAAABAAAAAAAA88FWSkyxBwA8AAAAPAAAAAAh KZNVTAAMKeHMCwgARsAAKB7xQAABAtkGCgACAuAAABaUBAAAIgDu/AAAAAEEAAAA6wAAAQAA AAAAAADCVkrQrQUAPAAAADwAAAAAISmTVUwADCnhzAsIAEbAACgfA0AAAQLY9AoAAgLgAAAW lAQAACIA7fwAAAABBAAAAOwAAAEAAAAAAAABwlZK/mQHADwAAAA8AAAAACEpk1VMAAwp4cwL CABGwAAoHwRAAAEC2PMKAAIC4AAAFpQEAAAiAO38AAAAAQQAAADsAAABAAAAAAAAQsJWSjSb BAA+AAAAPgAAAAEAXgAAFgAMKeHMCwgARsAAMB8IQAABAtjnCgACAuAAABaUBAAAIgAA+gAA AAIDAAAA7AAAAQMAAADrAAABQsJWSqVQCwA+AAAAPgAAAAEAXgAAFgAMKeHMCwgARsAAMB8N QAABAtjiCgACAuAAABaUBAAAIgAA+gAAAAIDAAAA7AAAAQMAAADrAAABXsJWSuokBwA8AAAA PAAAAAEAXgAAFgAMKeHMCwgARsAAKB9SQAABAtilCgACAuAAABaUBAAAIgDu/AAAAAEEAAAA 6wAAAQAAAAAAAGDCVkqzcQAAPAAAADwAAAABAF4AABYADCnhzAsIAEbAACgfU0AAAQLYpAoA AgLgAAAWlAQAACIA7vwAAAABBAAAAOsAAAEAAAAAAACCwlZKKMoAADwAAAA8AAAAAQBeAAAW AAwp4cwLCABGwAAoH1dAAAEC2KAKAAIC4AAAFpQEAAAiAO/8AAAAAQMAAADrAAABAAAAAAAA gsJWSgPcBQA8AAAAPAAAAAEAXgAAFgAMKeHMCwgARsAAKB9ZQAABAtieCgACAuAAABaUBAAA IgDv/AAAAAEDAAAA6wAAAQAAAAAAAJLCVkrg/QwAPAAAADwAAAABAF4AABYADCnhzAsIAEbA ACgff0AAAQLYeAoAAgLgAAAWlAQAACIA7vwAAAABBAAAAOoAAQEAAAAAAACTwlZKDZYOADwA AAA8AAAAAQBeAAAWAAwp4cwLCABGwAAoH4BAAAEC2HcKAAIC4AAAFpQEAAAiAO78AAAAAQQA AADqAAEBAAAAAAAAtsJWSu2eCwA8AAAAPAAAAAAhKZNVTAAMKeHMCwgARsAAKB+KQAABAtht CgACAuAAABaUBAAAIgDv/AAAAAEDAAAA6gABAQAAAAAAALfCVkrgPAEAPAAAADwAAAAAISmT VUwADCnhzAsIAEbAACgfkEAAAQLYZwoAAgLgAAAWlAQAACIA7/wAAAABAwAAAOoAAQEAAAAA AADjwlZKBNMJADwAAAA8AAAAACEpk1VMAAwp4cwLCABGwAAsILVAAAEC1z4KAAIC4AAAFpQE AAAiAOL6AAAAAQMAAAHrAAABCgADAQAA5MJWSjCOCwA8AAAAPAAAAAAhKZNVTAAMKeHMCwgA RsAALCC2QAABAtc9CgACAuAAABaUBAAAIgDi+gAAAAEDAAAB6wAAAQoAAwEAAO3CVkrZPAYA PAAAADwAAAAAISmTVUwADCnhzAsIAEbAACggukAAAQLXPQoAAgLgAAAWlAQAACIA7/wAAAAB AwAAAOsAAAEAAAAAAADtwlZK1Y0LADwAAAA8AAAAACEpk1VMAAwp4cwLCABGwAAoILtAAAEC 1zwKAAIC4AAAFpQEAAAiAO/8AAAAAQMAAADrAAABAAAAAAAA8sJWSvUFBQA8AAAAPAAAAAAh KZNVTAAMKeHMCwgARsAAKCDXQAABAtcgCgACAuAAABaUBAAAIgDu/AAAAAEEAAAA6wAAAQAA AAAAAPLCVkrJJwoAPAAAADwAAAAAISmTVUwADCnhzAsIAEbAACgg2EAAAQLXHwoAAgLgAAAW lAQAACIA7vwAAAABBAAAAOsAAAEAAAAAAADzwlZKDdkFADwAAAA8AAAAACEpk1VMAAwp4cwL CABGwAAoINxAAAEC1xsKAAIC4AAAFpQEAAAiAO/8AAAAAQMAAADrAAABAAAAAAAA88JWSgXr DQA8AAAAPAAAAAAhKZNVTAAMKeHMCwgARsAAKCDdQAABAtcaCgACAuAAABaUBAAAIgDv/AAA AAEDAAAA6wAAAQAAAAAAAOXEVko+OgMAPAAAADwAAAD///////8ADCnhzAsIBgABCAAGBAAB AAwp4cwLCgACAgAAAAAAAAqWEAQAAAAAAAAAAAAAAAAAAAAAAADlxFZKijsDACoAAAAqAAAA AAwp4cwLAAwpan4bCAYAAQgABgQAAgAMKWp+GwoAAgIADCnhzAsKAAIC5sRWSicQDwA8AAAA PAAAAP///////wAMKeHMCwgGAAEIAAYEAAEADCnhzAsKAAICAAAAAAAACpYQBAAAAAAAAAAA AAAAAAAAAAAAAObEVkp/EQ8AKgAAACoAAAAADCnhzAsADClqfhsIBgABCAAGBAACAAwpan4b CgACAgAMKeHMCwoAAgLpxFZKbPoBADwAAAA8AAAA////////AAwp4cwLCAYAAQgABgQAAQAM KeHMCwoAAgIAAAAAAAAKlgoEAAAAAAAAAAAAAAAAAAAAAAAA6cRWSsH6AQAqAAAAKgAAAAAM KeHMCwAMKWp+GwgGAAEIAAYEAAIADClqfhsKAAICAAwp4cwLCgACAurEVkp3WA4APAAAADwA AAD///////8ADCnhzAsIBgABCAAGBAABAAwp4cwLCgACAgAAAAAAAAqWCgQAAAAAAAAAAAAA AAAAAAAAAADqxFZK4VkOACoAAAAqAAAAAAwp4cwLAAwpan4bCAYAAQgABgQAAgAMKWp+GwoA AgIADCnhzAsKAAIC7MRWSkegDQA8AAAAPAAAAP///////wAMKeHMCwgGAAEIAAYEAAEADCnh zAsKAAICAAAAAAAACpYKBAAAAAAAAAAAAAAAAAAAAAAAAOzEVkphog0AKgAAACoAAAAADCnh zAsADClqfhsIBgABCAAGBAACAAwpan4bCgACAgAMKeHMCwoAAgLuxFZKQjQKADwAAAA8AAAA ////////AAwp4cwLCAYAAQgABgQAAQAMKeHMCwoAAgIAAAAAAAAKlgoEAAAAAAAAAAAAAAAA AAAAAAAA7sRWSns1CgAqAAAAKgAAAAAMKeHMCwAMKWp+GwgGAAEIAAYEAAIADClqfhsKAAIC AAwp4cwLCgACAu/EVkrVEQ4APAAAADwAAAD///////8ADCnhzAsIBgABCAAGBAABAAwp4cwL CgACAgAAAAAAAAqWCgQAAAAAAAAAAAAAAAAAAAAAAADvxFZKDhIOACoAAAAqAAAAAAwp4cwL AAwpan4bCAYAAQgABgQAAgAMKWp+GwoAAgIADCnhzAsKAAIC8cRWSlAgCQA8AAAAPAAAAP// /////wAMKeHMCwgGAAEIAAYEAAEADCnhzAsKAAICAAAAAAAACpYKBAAAAAAAAAAAAAAAAAAA AAAAAPHEVkqVIQkAKgAAACoAAAAADCnhzAsADClqfhsIBgABCAAGBAACAAwpan4bCgACAgAM KeHMCwoAAgL0xFZKBDgNADwAAAA8AAAA////////AAwp4cwLCAYAAQgABgQAAQAMKeHMCwoA AgIAAAAAAAAKlgoEAAAAAAAAAAAAAAAAAAAAAAAA9MRWSpo5DQAqAAAAKgAAAAAMKeHMCwAM KWp+GwgGAAEIAAYEAAIADClqfhsKAAICAAwp4cwLCgACAvvEVkrMNwYAPAAAADwAAAD///// //8ADCnhzAsIBgABCAAGBAABAAwp4cwLCgACAgAAAAAAAAqWCgQAAAAAAAAAAAAAAAAAAAAA AAD7xFZKBjgGACoAAAAqAAAAAAwp4cwLAAwpan4bCAYAAQgABgQAAgAMKWp+GwoAAgIADCnh zAsKAAICrsdWSrbWAwA8AAAAPAAAAAAhKZNVTAAMKeHMCwgARsAALEJDQAABArWwCgACAuAA ABaUBAAAIgDi+gAAAAEDAAAB6wAAAQoAAwEAAK/HVkqcDwwAPAAAADwAAAAAISmTVUwADCnh zAsIAEbAACxCREAAAQK1rwoAAgLgAAAWlAQAACIA4voAAAABAwAAAesAAAEKAAMBAAC5x1ZK HPYHADwAAAA8AAAAACEpk1VMAAwp4cwLCABGwAAoQkhAAAECta8KAAIC4AAAFpQEAAAiAO/8 AAAAAQMAAADrAAABAAAAAAAAusdWSvy/DgA8AAAAPAAAAAAhKZNVTAAMKeHMCwgARsAAKEJJ QAABArWuCgACAuAAABaUBAAAIgDv/AAAAAEDAAAA6wAAAQAAAAAAANHHVkpVTgwAPAAAADwA AAAAISmTVUwADCnhzAsIAEbAAChCzkAAAQK1KQoAAgLgAAAWlAQAACIA+PwAAAABBAAAAOEA AAEAAAAAAADTx1ZKIdIBADwAAAA8AAAAACEpk1VMAAwp4cwLCABGwAAoQs9AAAECtSgKAAIC 4AAAFpQEAAAiAPj8AAAAAQQAAADhAAABAAAAAAAA --lrZ03NoBR/3+SXJZ-- From owner-freebsd-net@FreeBSD.ORG Sat Jul 11 10:09:48 2009 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 6D205106566C; Sat, 11 Jul 2009 10:09:48 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id E99C78FC0A; Sat, 11 Jul 2009 10:09:47 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 1106349EC; Sat, 11 Jul 2009 12:09:47 +0200 (CEST) Received: from avoriaz.restart.bel (avoriaz.restart.be [IPv6:2001:41d0:2:2d29:1:1::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n6BA9WFF002010; Sat, 11 Jul 2009 12:09:44 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1247306986; bh=ohZzOiiDOclM9ju3h+ps/X/cNm82mYLSLdB0v1b9nm4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=zduN8S5MpQBGMK8EG4q9yYtnIWoK6a8dG2eWJGTmDsZqRlJTxMZcSjGZZqzjQUzXM jF2ApULFOOa19pU2kCxxg== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=FqlBW87rw1hbX+XOTru7+xqPdq2MXEBitcIYu/SBfF2LgFN7+gg+2uoxLJ8xlLGt8 s/iVMnxKbvjikV17MtQ0g== Message-ID: <4A5864DC.1070106@restart.be> Date: Sat, 11 Jul 2009 12:09:32 +0200 From: Henri Hennebert User-Agent: Thunderbird 2.0.0.22 (X11/20090710) MIME-Version: 1.0 To: "Li, Qing" References: <4A5734C3.3000806@restart.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections 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, 11 Jul 2009 10:09:50 -0000 Li, Qing wrote: > Hi, > > Please try patch-7-10 in my home directory http://people.freebsd.org/~qingli/ > and let me know how it works out for you. I thought I had committed the patch > but turned out I didn't. I apply the patch, reset my pf.conf to its previous content and all is running smoothly. By the way, I discover after my post that my "solution" was not working for long (many bytes) connections and this is solved too. Many thank for your time Henri PS please commit as soon as possible > >> On 8.0-BETA1 there is an assymetry: >> >> netstat -rn display >> >> 192.168.24.1 link#3 >> .... >> no entry for 2001:41d0:2:2d29:1:1:: >> > > This is by design as part of the new architecture in 8.0, which maintains > the L2 ARP/ND6 and L3 routing tables separately. > > -- Qing > > > > -----Original Message----- > From: owner-freebsd-stable@freebsd.org on behalf of Henri Hennebert > Sent: Fri 7/10/2009 5:32 AM > To: freebsd-stable@freebsd.org; freebsd-st@freebsd.org > Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections > > Hello, > > After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when > connecting with firefox to a local apache server using the global > unicast IPv6 address of the local machine. pf.conf must be updated! > > My configuration: > > [root@avoriaz ~]# ifconfig em0 > > em0: flags=8843 metric 0 mtu 1500 > options=19b > ether 00:1d:60:ad:2a:ce > inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255 > inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 > inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 > media: Ethernet 100baseTX (100baseTX ) > status: active > > [root@avoriaz ~]# host www.restart.bel > www.restart.bel is an alias for avoriaz.restart.bel. > avoriaz.restart.bel has address 192.168.24.1 > avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: > > pf.conf: > > int_if="em0" > block in log all > block out log all > set skip on lo0 > antispoof quick for $int_if inet > # Allow trafic with physical internal network > pass in quick on $int_if from ($int_if:network) to ($int_if) keep state > pass out quick on $int_if from ($int_if) to ($int_if:network) keep state > > The problem: > > [root@avoriaz ~]# telnet -4 www.restart.bel 80 > Trying 192.168.24.1... > Connected to avoriaz.restart.bel. > Escape character is '^]'. > ^] > telnet> quit > Connection closed. > [root@avoriaz ~]# telnet -6 www.restart.bel 80 > Trying 2001:41d0:2:2d29:1:1::... > --->Never connect and get a timeout! > > tcpdump and logging in pf show me that > > For a IPv4 connection: > the packet from telnet to apache pass 2 times on lo0 (out and in) > the answer packet from apache to telnet pass 2 times on lo0 (out and in) > > So no problem, there is `set skip on lo0' > > For a IPv6 connection: > The first packet from telnet to apache pass 2 times on lo0 (out and in) > The answer packet from apache to telnet path on em0 and is rejected > due to the default flags S/SA. > > So I have to change pf.conf and replace the last line: > pass out quick on $int_if from ($int_if) to ($int_if:network) \ > keep state flags any > > Then all is OK > > By the way, on 7.2 > > netstat -rn display > > 192.168.24.1 00:1d:60:ad:2a:ce > .... > 2001:41d0:2:2d29:1:1:: 00:1d:60:ad:2a:ce > > > On 8.0-BETA1 there is an assymetry: > > netstat -rn display > > 192.168.24.1 link#3 > .... > no entry for 2001:41d0:2:2d29:1:1:: > > Hope it may help someone > > Henri > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Jul 11 10:10:08 2009 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 D61B2106568F for ; Sat, 11 Jul 2009 10:10:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4ACA48FC13 for ; Sat, 11 Jul 2009 10:10: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.3/8.14.3) with ESMTP id n6BAA6aq077946 for ; Sat, 11 Jul 2009 10:10:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n6BAA6C3077941; Sat, 11 Jul 2009 10:10:06 GMT (envelope-from gnats) Date: Sat, 11 Jul 2009 10:10:06 GMT Message-Id: <200907111010.n6BAA6C3077941@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: =?ISO-8859-1?Q?Angelo_H=F6ngens?= Cc: Subject: Re: kern/127050: [carp] ipv6 does not work on carp interfaces [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-1?Q?Angelo_H=F6ngens?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 10:10:09 -0000 The following reply was made to PR kern/127050; it has been noted by GNATS. From: =?ISO-8859-1?Q?Angelo_H=F6ngens?= To: bug-followup@FreeBSD.org, maddog2k@maddog2k.net Cc: Subject: Re: kern/127050: [carp] ipv6 does not work on carp interfaces [regression] Date: Sat, 11 Jul 2009 12:06:30 +0200 A few months ago I could not ping any virtual ipv6 addresses. However, I'm running 7.2 now, and decided to pick up this issue. Something seems to have changed, and I can ping at least the first ipv6 address of a carp interface (just not the others) Some more info: I have four reverse cache machines (simple Dell R300's), running Squid. The four machines are balanced by round robin DNS. The DNS publishes 4 virtual carp addresses, and each node has 4 carp interfaces, but is always the master over its own one. This way, up to three nodes can fail, and the other takes over. Works like a charm, but of course I want to enable ipv6 over the same infrastructure. I've configured ipv6 aliases on all interfaces, and rebooted all nodes. Now the funny thing is, I can ping all ipv4 ip's (it's been running in production for months), I can ping6 the the dedicated ip's of all nodes (2001:81:82::206:113 for the node below), and I can ping to all the FIRST ipv6 addresses of the carp interfaces. Could very well be something I'm doing wrong, but I think it's a bug in carp. (Of course I could work around it by creating 16 carp interfaces on each machine, but I don't know what's the best solution.) So: I can ping6 to 2001:81:82::206:81 I can ping6 to 2001:81:82::206:82 I can ping6 to 2001:81:82::206:83 I can ping6 to 2001:81:82::206:84 I can NOT ping6 to 2001:81:82::206:85 I can NOT ping6 to 2001:81:82::206:86 I can NOT ping6 to 2001:81:82::206:87 I can NOT ping6 to 2001:81:82::206:88 I can NOT ping6 to 2001:81:82::206:121 I can NOT ping6 to 2001:81:82::206:122 I can NOT ping6 to 2001:81:82::206:123 I can NOT ping6 to 2001:81:82::206:124 Here you see pings on the cluster node. Pings to :81 get answered, but the node does not answer of neighbor solicitaions to :85: $ sudo tcpdump -ni nic0 icmp6 listening on nic0, link-type EN10MB (Ethernet), capture size 96 bytes 11:54:09.846489 IP6 2001:610:6a8:0:223:6cff:fe8d:6775 > 2001:81:82::206:81: ICMP6, echo request, seq 0, length 16 11:54:09.846524 IP6 2001:81:82::206:81 > 2001:610:6a8:0:223:6cff:fe8d:6775: ICMP6, echo reply, seq 0, length 16 11:54:10.845796 IP6 2001:610:6a8:0:223:6cff:fe8d:6775 > 2001:81:82::206:81: ICMP6, echo request, seq 1, length 16 11:54:10.845829 IP6 2001:81:82::206:81 > 2001:610:6a8:0:223:6cff:fe8d:6775: ICMP6, echo reply, seq 1, length 16 11:54:11.848522 IP6 2001:610:6a8:0:223:6cff:fe8d:6775 > 2001:81:82::206:81: ICMP6, echo request, seq 2, length 16 11:54:11.848539 IP6 2001:81:82::206:81 > 2001:610:6a8:0:223:6cff:fe8d:6775: ICMP6, echo reply, seq 2, length 16 11:54:13.949889 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6, neighbor solicitation, who has 2001:81:82::206:85, length 32 11:54:14.846703 IP6 2001:81:82::206:113 > 2001:81:82::1: ICMP6, neighbor solicitation, who has 2001:81:82::1, length 32 11:54:14.847034 IP6 2001:81:82::1 > 2001:81:82::206:113: ICMP6, neighbor advertisement, tgt is 2001:81:82::1, length 24 11:54:14.948194 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6, neighbor solicitation, who has 2001:81:82::206:85, length 32 11:54:15.948203 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6, neighbor solicitation, who has 2001:81:82::206:85, length 32 11:54:16.954932 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6, neighbor solicitation, who has 2001:81:82::206:85, length 32 11:54:17.952257 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6, neighbor solicitation, who has 2001:81:82::206:85, length 32 11:54:18.952558 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6, neighbor solicitation, who has 2001:81:82::206:85, length 32 I am running: $ uname -a FreeBSD balancer3.domain.local 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Tue Jun 16 12:08:00 CEST 2009 root@balancer3.domain.local:/usr/obj/usr/src/sys/GENERIC-CARP amd64 IP's below are scrambled and are not the real addresses: -- /etc/rc.conf ------------------------- ifconfig_bge0_name="nic0" ifconfig_bge1_name="nic1" ipv6_enable="YES" ifconfig_nic0="inet 81.82.206.113 netmask 255.255.255.192" ifconfig_nic0_alias0="inet6 2001:81:82::206:113 prefixlen 48" ifconfig_nic1="inet 10.82.20.113 netmask 255.255.255.0" defaultrouter="81.82.206.65" ipv6_defaultrouter="2001:81:82::1" cloned_interfaces="carp0 carp1 carp2 carp3" ifconfig_carp0="vhid 103 pass blabla 81.82.206.81/26 advskew 0" ifconfig_carp0_alias0="inet6 2001:81:82::206:81 prefixlen 48" ifconfig_carp0_alias1="inet 81.82.206.85 netmask 255.255.255.192" ifconfig_carp0_alias2="inet6 2001:81:82::206:85 prefixlen 48" ifconfig_carp0_alias3="inet 81.82.206.121 netmask 255.255.255.192" ifconfig_carp0_alias4="inet6 2001:81:82::206:121 prefixlen 48" ifconfig_carp1="vhid 104 pass blabla 81.82.206.82/26 advskew 100" ifconfig_carp1_alias0="inet6 2001:81:82::206:82 prefixlen 48" ifconfig_carp1_alias1="inet 81.82.206.86 netmask 255.255.255.192" ifconfig_carp1_alias2="inet6 2001:81:82::206:86 prefixlen 48" ifconfig_carp1_alias3="inet 81.82.206.122 netmask 255.255.255.192" ifconfig_carp1_alias4="inet6 2001:81:82::206:122 prefixlen 48" fconfig_carp2="vhid 105 pass blabla 81.82.206.83/26 advskew 100" ifconfig_carp2_alias0="inet6 2001:81:82::206:83 prefixlen 48" ifconfig_carp2_alias1="inet 81.82.206.87 netmask 255.255.255.192" ifconfig_carp2_alias2="inet6 2001:81:82::206:87 prefixlen 48" ifconfig_carp2_alias3="inet 81.82.206.123 netmask 255.255.255.192" ifconfig_carp2_alias4="inet6 2001:81:82::206:123 prefixlen 48" ifconfig_carp3="vhid 106 pass blabla 81.82.206.84/26 advskew 100" ifconfig_carp3_alias0="inet6 2001:81:82::206:84 prefixlen 48" ifconfig_carp3_alias1="inet 81.82.206.88 netmask 255.255.255.192" ifconfig_carp3_alias2="inet6 2001:81:82::206:88 prefixlen 48" ifconfig_carp3_alias3="inet 81.82.206.124 netmask 255.255.255.192" ifconfig_carp3_alias4="inet6 2001:81:82::206:124 prefixlen 48" ----------------------------------------- -- ifconfig output ---------------------- nic0: flags=8943 metric 0 mtu 1500 options=9b ether 00:22:19:cd:5c:e0 inet6 fe80::222:19ff:fecd:5ce0%nic0 prefixlen 64 scopeid 0x1 inet 81.82.206.113 netmask 0xffffffc0 broadcast 81.82.206.127 inet6 2001:81:82::206:113 prefixlen 48 media: Ethernet autoselect (1000baseTX ) status: active nic1: flags=8843 metric 0 mtu 1500 options=9b ether 00:22:19:cd:5c:e1 inet6 fe80::222:19ff:fecd:5ce1%nic1 prefixlen 64 scopeid 0x2 inet 10.82.20.113 netmask 0xffffff00 broadcast 10.82.20.255 media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 carp0: flags=49 metric 0 mtu 1500 inet 81.82.206.81 netmask 0xffffffc0 inet6 2001:81:82::206:81 prefixlen 48 inet 81.82.206.85 netmask 0xffffffc0 inet6 2001:81:82::206:85 prefixlen 48 inet 81.82.206.121 netmask 0xffffffc0 inet6 2001:81:82::206:121 prefixlen 48 carp: MASTER vhid 103 advbase 1 advskew 0 carp1: flags=49 metric 0 mtu 1500 inet 81.82.206.82 netmask 0xffffffc0 inet6 2001:81:82::206:82 prefixlen 48 inet 81.82.206.86 netmask 0xffffffc0 inet6 2001:81:82::206:86 prefixlen 48 inet 81.82.206.122 netmask 0xffffffc0 inet6 2001:81:82::206:122 prefixlen 48 carp: BACKUP vhid 104 advbase 1 advskew 100 carp2: flags=49 metric 0 mtu 1500 inet 81.82.206.83 netmask 0xffffffc0 inet6 2001:81:82::206:83 prefixlen 48 inet 81.82.206.87 netmask 0xffffffc0 inet6 2001:81:82::206:87 prefixlen 48 inet 81.82.206.123 netmask 0xffffffc0 inet6 2001:81:82::206:123 prefixlen 48 carp: BACKUP vhid 105 advbase 1 advskew 100 carp3: flags=49 metric 0 mtu 1500 inet 81.82.206.84 netmask 0xffffffc0 inet6 2001:81:82::206:84 prefixlen 48 inet 81.82.206.88 netmask 0xffffffc0 inet6 2001:81:82::206:88 prefixlen 48 inet 81.82.206.124 netmask 0xffffffc0 inet6 2001:81:82::206:124 prefixlen 48 carp: BACKUP vhid 106 advbase 1 advskew 100 -- With kind regards, Angelo Höngens Systems Administrator ------------------------------------------ NetMatch tourism internet software solutions Ringbaan Oost 2b 5013 CA Tilburg T: +31 (0)13 5811088 F: +31 (0)13 5821239 mailto:A.Hongens@netmatch.nl http://www.netmatch.nl ------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Sat Jul 11 13:01:14 2009 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 F2C31106566B; Sat, 11 Jul 2009 13:01:13 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id C68488FC08; Sat, 11 Jul 2009 13:01:13 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 5A3763B0847; Sat, 11 Jul 2009 09:01:13 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 11 Jul 2009 09:01:13 -0400 X-Sasl-enc: 9AGYnpfYMBYqW2NmVN8M5d9X5V2vblqNuwJugZs03Btr 1247317273 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id DB25311DC7; Sat, 11 Jul 2009 09:01:12 -0400 (EDT) Message-ID: <4A588C4D.4060805@incunabulum.net> Date: Sat, 11 Jul 2009 13:57:49 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: iprebeg@freebsd.org References: <20090711073647.GA1824@valeria.zesoi.fer.hr> <4A5849E5.90909@incunabulum.net> <20090711092753.GA9630@valeria.zesoi.fer.hr> In-Reply-To: <20090711092753.GA9630@valeria.zesoi.fer.hr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: em driver doesn't set multicast ethernet address 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, 11 Jul 2009 13:01:14 -0000 Hi, Thanks for the feedback. iprebeg@freebsd.org wrote: > Well, now, something really interesting happened. I changed default IGMP > version via sysctl > > # sysctl net.inet.igmp.default_version=2 > > but, then I tested it with mtest and generated packets were still IGMPv3 > Membership reports, but first two of them had proper mcast ethernet > address. They generated sent by mtest. > Sorry, forgot to mention -- this sysctl won't take effect immediately. It needs to be set before the interface's driver is loaded and IPv4 is attached to the interface. Do you have any unusual ARP table entries or routing setup? That would be where to look next. There haven't been any other reports of this issue as far as I know. The IGMP code does not fill out the Ethernet address field -- it leaves it up to ip_output() to do that. Do you see this with other multicast traffic, or just IGMP reports? thanks, BMS From owner-freebsd-net@FreeBSD.ORG Sat Jul 11 13:44:33 2009 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 C31B1106564A for ; Sat, 11 Jul 2009 13:44:33 +0000 (UTC) (envelope-from iprebeg@freebsd.org) Received: from maja.zesoi.fer.hr (maja.zesoi.fer.hr [161.53.64.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7F6818FC14 for ; Sat, 11 Jul 2009 13:44:33 +0000 (UTC) (envelope-from iprebeg@freebsd.org) Received: from localhost (localhost [127.0.0.1]) by maja.zesoi.fer.hr (Postfix) with ESMTP id 3B03B42F7E; Sat, 11 Jul 2009 15:44:29 +0200 (CEST) Received: from maja.zesoi.fer.hr ([127.0.0.1]) by localhost (maja.zesoi.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT6uwGkb4CQ9; Sat, 11 Jul 2009 15:44:22 +0200 (CEST) Received: from valeria.zesoi.fer.hr (valeria.zesoi.fer.hr [161.53.64.29]) by maja.zesoi.fer.hr (Postfix) with ESMTP id A1AF442F7A; Sat, 11 Jul 2009 15:43:59 +0200 (CEST) Date: Sat, 11 Jul 2009 15:39:17 +0200 From: iprebeg@freebsd.org To: Bruce Simpson Message-ID: <20090711133917.GA10001@valeria.zesoi.fer.hr> References: <20090711073647.GA1824@valeria.zesoi.fer.hr> <4A5849E5.90909@incunabulum.net> <20090711092753.GA9630@valeria.zesoi.fer.hr> <4A588C4D.4060805@incunabulum.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A588C4D.4060805@incunabulum.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org Subject: Re: em driver doesn't set multicast ethernet address 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, 11 Jul 2009 13:44:34 -0000 On Sat, Jul 11, 2009 at 01:57:49PM +0100, Bruce Simpson wrote: > Hi, > > Thanks for the feedback. > > iprebeg@freebsd.org wrote: >> Well, now, something really interesting happened. I changed default IGMP >> version via sysctl >> >> # sysctl net.inet.igmp.default_version=2 >> >> but, then I tested it with mtest and generated packets were still IGMPv3 >> Membership reports, but first two of them had proper mcast ethernet >> address. They generated sent by mtest. >> > > Sorry, forgot to mention -- this sysctl won't take effect immediately. > It needs to be set before the interface's driver is loaded and IPv4 is > attached to the interface. > I placed config in sysctl.conf and rebooted but mcastread still generates IGMPv3 membership report. Am I missing something? > Do you have any unusual ARP table entries or routing setup? That would be > where to look next. > Nope. > There haven't been any other reports of this issue as far as I know. The > IGMP code does not fill out the Ethernet address field -- it leaves it up > to ip_output() to do that. > > Do you see this with other multicast traffic, or just IGMP reports? > I generated multicast traffic with nc and examined packets still have wrong ether dest address. So, it seems that no IGMP code is wrong. Can someone please try to reproduce this with different hardware? I have no other configuration but this in VMWare environment. > thanks, > BMS > From owner-freebsd-net@FreeBSD.ORG Sat Jul 11 13:59:14 2009 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 C0835106578D; Sat, 11 Jul 2009 13:59:14 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 936D88FC1A; Sat, 11 Jul 2009 13:59:14 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id BBF443B0286; Sat, 11 Jul 2009 09:59:13 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 11 Jul 2009 09:59:13 -0400 X-Sasl-enc: RqInajSPY+Qh/MW9q4u1pziW5KKT/Smlbwg0AJta2MlA 1247320753 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4FB13BD60; Sat, 11 Jul 2009 09:59:13 -0400 (EDT) Message-ID: <4A5899DC.7080804@incunabulum.net> Date: Sat, 11 Jul 2009 14:55:40 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: iprebeg@freebsd.org References: <20090711073647.GA1824@valeria.zesoi.fer.hr> <4A5849E5.90909@incunabulum.net> <20090711092753.GA9630@valeria.zesoi.fer.hr> <4A588C4D.4060805@incunabulum.net> <20090711133917.GA10001@valeria.zesoi.fer.hr> In-Reply-To: <20090711133917.GA10001@valeria.zesoi.fer.hr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: em driver doesn't set multicast ethernet address 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, 11 Jul 2009 13:59:15 -0000 iprebeg@freebsd.org wrote: > I placed config in sysctl.conf and rebooted but mcastread still generates IGMPv3 > membership report. Am I missing something? > Only other thing I can think of right now: Are any multicast queriers/routers present on the virtual subnet? I'm tied up, so probably can't look at the sysctl in detail, until in the week. cheers, BMS From owner-freebsd-net@FreeBSD.ORG Sat Jul 11 14:18:23 2009 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 2A86A106566C for ; Sat, 11 Jul 2009 14:18:23 +0000 (UTC) (envelope-from iprebeg@freebsd.org) Received: from maja.zesoi.fer.hr (maja.zesoi.fer.hr [161.53.64.3]) by mx1.freebsd.org (Postfix) with ESMTP id D9FA68FC0C for ; Sat, 11 Jul 2009 14:18:22 +0000 (UTC) (envelope-from iprebeg@freebsd.org) Received: from localhost (localhost [127.0.0.1]) by maja.zesoi.fer.hr (Postfix) with ESMTP id A65F942F7E; Sat, 11 Jul 2009 16:18:18 +0200 (CEST) Received: from maja.zesoi.fer.hr ([127.0.0.1]) by localhost (maja.zesoi.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eseCOEC1SygA; Sat, 11 Jul 2009 16:18:12 +0200 (CEST) Received: from valeria.zesoi.fer.hr (valeria.zesoi.fer.hr [161.53.64.29]) by maja.zesoi.fer.hr (Postfix) with ESMTP id E338B42F7A; Sat, 11 Jul 2009 16:17:46 +0200 (CEST) Date: Sat, 11 Jul 2009 16:13:05 +0200 From: iprebeg@freebsd.org To: Bruce Simpson Message-ID: <20090711141305.GA26848@valeria.zesoi.fer.hr> References: <20090711073647.GA1824@valeria.zesoi.fer.hr> <4A5849E5.90909@incunabulum.net> <20090711092753.GA9630@valeria.zesoi.fer.hr> <4A588C4D.4060805@incunabulum.net> <20090711133917.GA10001@valeria.zesoi.fer.hr> <4A5899DC.7080804@incunabulum.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A5899DC.7080804@incunabulum.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org Subject: Re: em driver doesn't set multicast ethernet address 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, 11 Jul 2009 14:18:23 -0000 On Sat, Jul 11, 2009 at 02:55:40PM +0100, Bruce Simpson wrote: > iprebeg@freebsd.org wrote: >> I placed config in sysctl.conf and rebooted but mcastread still generates >> IGMPv3 >> membership report. Am I missing something? >> > > Only other thing I can think of right now: > Are any multicast queriers/routers present on the virtual subnet? > > I'm tied up, so probably can't look at the sysctl in detail, until in the > week. > There is no such. I'm implementing IGMP snooping extensions in ng_bridge and luckily, they are based on IPv4 addresses, so I can probably temporarly disable preliminary {multi/other}cast discrimination based on ethernet address and stick to IPv4 until bug is fixed. In a meantime, I'll try to figure out some different hardware configuration to make sure this is not "feature" of VMWare, even everything worked fine until now. > cheers, > BMS From owner-freebsd-net@FreeBSD.ORG Sat Jul 11 15:07:14 2009 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 8863E106566C for ; Sat, 11 Jul 2009 15:07:14 +0000 (UTC) (envelope-from ricky.packetlogic@gmail.com) Received: from wombat.diezmil.com (aa.81.b6.static.xlhost.com [207.182.129.170]) by mx1.freebsd.org (Postfix) with ESMTP id 3B11E8FC0A for ; Sat, 11 Jul 2009 15:07:13 +0000 (UTC) (envelope-from ricky.packetlogic@gmail.com) Received: from wombat (wombat [127.0.0.1]) by wombat.diezmil.com (8.14.2/8.14.2) with ESMTP id n6BEksAX031097 for ; Sat, 11 Jul 2009 10:46:54 -0400 Date: Sat, 11 Jul 2009 10:46:54 -0400 From: ricky.packetlogic@gmail.com To: freebsd-net@freebsd.org Message-ID: <16045747.41247323614497.JavaMail.root@wombat> In-Reply-To: <4A399C7F.4000203@modulus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Re: kern/135222: [igb] low speed routing between two igb interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ricky.packetlogic@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 15:07:14 -0000 >>Intel 82575EB (and friends) are *the* premier ethernet controllers to >>use with FreeBSD in a server. igb should be the most stable and >>supported driver in the whole kernel. I can't think of any other driver >>and series of controllers I would rather use in a server like this. Well, the good NIC is no good at all without good driver, sadly, it's the case with stock igb driver shipped with FB. I hate to say this, but igb driver sucks, there're many obvious issue in the code like wrong DMA allocation etc. You just have to re-write completely to get igb work, i.e., to support msi-x with multiqueue. >>If the drivers for these chips are now "bad", this is a very sad day for >>people who wanted to use FreeBSD in their dual socket servers. Either stick to em or re-write the igb driver. It's just funny that everybody keeps quite on this, is it too difficulty to let people know it's the known issue with igb driver? Ricky _______________________________________________ freebsd-net@free... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@free..." -- This message was sent on behalf of ricky.packetlogic@gmail.com at openSubscriber.com http://www.opensubscriber.com/message/freebsd-net@freebsd.org/12445915.html From owner-freebsd-net@FreeBSD.ORG Sat Jul 11 16:51:23 2009 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 3E0C11065670 for ; Sat, 11 Jul 2009 16:51:23 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id D70FC8FC1A for ; Sat, 11 Jul 2009 16:51:22 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 51796 invoked by uid 60001); 11 Jul 2009 16:51:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247331082; bh=2CBYTveX9bO8lPRNAXD6MW/xzLNZA8SATFT81K1w4+M=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=W7ZFdeK2+/fLXKHdC6KopYL4cO2LQrjZa+oLyHNcnnwtEL/CbfeMPp1XrW+fzEAOOA42n4Vt93NP/6QmKEPJqp9Pw6mwbGi57PciQorzFliKiyseHMr7Z0aH+eTQj8if+rbn8uZiif2L3roIgBhTEScK0rbn4KIE4k/lTHbnGUg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BjRIBAG0aRrBaKuOlMFthqBceaAhvDYVvkkgLrbmkBS47G8FDHFWiq3Iuz0XB3FSn4hYbkSi5OScK1ldzvi4iHX0m29zi1zadUyTCP+VCMRdCrx9ridl0xeD8lInBS8uUz+jGYowWVe7bLElW/pgkfdlXwqdBdSN7waXhNVY1Bc=; Message-ID: <370660.51527.qm@web63906.mail.re1.yahoo.com> X-YMail-OSG: 8HB8FL8VM1k9x3dpilRifczSu.HmtG_hwWV8VCniaWkQNgnoDOxD1RB54uSj8xbvKdt1MckHjFsdUknpS0iJ3FatV09dCxg_FNSEQ1Jb4M3rDQwD.QfqfexbKpYfWvx.w0zLi22QJhMsu05oqn.5HcIKgtD3Ci8wiADdTUAeKGTzwfGiH5wrVVNiy4SfPXl8PVWV9ZOERzGeHcGFYI_EgKmGjE0QeCrJR3VaEyFBPKxmodMOdf_cH_N3wxY2aI1mg5IUgg5xjV0Az5e.P5k2G487_cHEELiIigHZ8Q60hziY7CpOqS3oOWQ- Received: from [66.176.162.245] by web63906.mail.re1.yahoo.com via HTTP; Sat, 11 Jul 2009 09:51:22 PDT X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Sat, 11 Jul 2009 09:51:22 -0700 (PDT) From: Barney Cordoba To: freebsd-net@freebsd.org, ricky.packetlogic@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Re: kern/135222: [igb] low speed routing between two igb interfaces 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, 11 Jul 2009 16:51:23 -0000 =0A=0A--- On Sat, 7/11/09, ricky.packetlogic@gmail.com wrote:=0A=0A> From: ricky.packetlogic@gmail.com =0A> Subject: Re: Re: kern/135222: [igb] low speed routing betw= een two igb interfaces=0A> To: freebsd-net@freebsd.org=0A> Date: Saturday, = July 11, 2009, 10:46 AM=0A> >>Intel 82575EB (and=0A> friends)=A0 are *the* = premier ethernet controllers to =0A> >>use with FreeBSD in a server.=A0 igb= should be=0A> the most stable and =0A> >>supported driver in the whole ker= nel.=A0 I can't=0A> think of any other driver =0A> >>and series of controll= ers I would rather use in a=0A> server like this.=0A> =0A> Well, the good N= IC is no good at all without good driver,=0A> sadly, it's the case with sto= ck igb driver shipped with FB.=0A> =0A> I hate to say this, but igb driver = sucks, there're many=0A> obvious issue in the code like wrong DMA allocatio= n etc. You=0A> just have to re-write completely to get igb work, i.e., to= =0A> support msi-x with multiqueue.=0A> =0A> >>If the drivers for these chi= ps are now "bad", this=0A> is a very sad day for =0A> >>people who wanted t= o use FreeBSD in their dual=0A> socket servers.=0A> Either stick to em or r= e-write the igb driver.=0A> =0A> It's just funny that everybody keeps quite= on this, is it=0A> too difficulty to let people know it's the known issue = with=0A> igb driver?=0A> =0A> Ricky=0A=0AI thought packetlogic ran on Linux= , have you finally abandoned that pig?=0A=0ABarney=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Sat Jul 11 22:23:45 2009 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 901011065678 for ; Sat, 11 Jul 2009 22:23:45 +0000 (UTC) (envelope-from stuartb@4gh.net) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4A7E38FC23 for ; Sat, 11 Jul 2009 22:23:45 +0000 (UTC) (envelope-from stuartb@4gh.net) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 11 Jul 2009 17:55:21 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.10.6-GA) with ESMTP id QAO50053; Sat, 11 Jul 2009 17:55:20 -0400 (EDT) X-Auth-ID: stuartb.4gh@starpower.net Received: from 208-59-174-205.c3-0.slvr-ubr1.lnh-slvr.md.cable.rcn.com (HELO freeman.4gh.net) ([208.59.174.205]) by smtp01.lnh.mail.rcn.net with ESMTP; 11 Jul 2009 17:55:21 -0400 Received: by freeman.4gh.net (Postfix, from userid 1001) id 0E5485C944; Sat, 11 Jul 2009 17:55:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by freeman.4gh.net (Postfix) with ESMTP id 07EBF5C1E3 for ; Sat, 11 Jul 2009 17:55:19 -0400 (EDT) Date: Sat, 11 Jul 2009 17:55:18 -0400 (EDT) From: Stuart Barkley To: freebsd-net@FreeBSD.org In-Reply-To: <200907100653.aa52216@walton.maths.tcd.ie> Message-ID: References: <200907100653.aa52216@walton.maths.tcd.ie> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Junkmail-Status: score=10/50, host=mr02.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A010208.4A590A48.01CB,ss=1,fgs=0, ip=207.172.4.11, so=2009-06-02 17:34:35, dmn=5.7.1/2009-06-05, mode=single engine X-Junkmail-IWF: false Cc: Subject: Re: NTP - default /etc/ntp.conf 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, 11 Jul 2009 22:23:45 -0000 On Fri, 10 Jul 2009 at 01:53 -0000, David Malone wrote: > > Is 3.freebsd.pool.ntp.org intentionally commented? It does > > resolve. Reminder: if you do uncomment it, remember to change the > > "three servers" to four. > > I've no problem commenting in all 4 if people think that's a better > config. 4 ntp servers are usually recommended. If one is down and one is wacky the remaining two can out vote the wacky one. Kinda like using raid-5 with a hot spare. Stuart -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone