From owner-freebsd-net@FreeBSD.ORG Sun Dec 27 01:27:37 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 85420106566B for ; Sun, 27 Dec 2009 01:27:37 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf00.insightbb.com (mxsf00.insightbb.com [74.128.0.70]) by mx1.freebsd.org (Postfix) with ESMTP id 535DA8FC08 for ; Sun, 27 Dec 2009 01:27:37 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.47,457,1257138000"; d="scan'208";a="729092823" Received: from unknown (HELO asav00.insightbb.com) ([172.31.249.123]) by mxsf00.insightbb.com with ESMTP; 26 Dec 2009 20:27:36 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEAHdGNkvQLicL/2dsb2JhbACBSdJQhDME X-IronPort-AV: E=Sophos;i="4.47,457,1257138000"; d="scan'208";a="2385798" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout00.insightbb.com with ESMTP; 26 Dec 2009 20:27:36 -0500 From: Steven Friedrich To: freebsd-net@freebsd.org Date: Sat, 26 Dec 2009 20:27:34 -0500 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; i386; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200912262027.34338.freebsd@insightbb.com> Subject: Do any of the wireless ethernet drivers support higher than 54Mbps rates X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2009 01:27:37 -0000 It's not a big deal, but I'd like to find a wireless driver that outperforms hard-wired ethernet (not gigabit, just standard 100TX or whatever it's called) Is there a spreadsheet or database that shows what caps each driver has? From owner-freebsd-net@FreeBSD.ORG Sun Dec 27 02:35: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 B59E1106566B for ; Sun, 27 Dec 2009 02:35:17 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8B75C8FC14 for ; Sun, 27 Dec 2009 02:35:17 +0000 (UTC) Received: by pwi15 with SMTP id 15so6365909pwi.3 for ; Sat, 26 Dec 2009 18:35:13 -0800 (PST) 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; bh=svCKDhtp4WZOiWQ0lZgTloENwSXaIPj4SV5GQwXOhYg=; b=cm2ahI1dZUNDLuKy+oGdTKxDefzdqADRhz082anfOsoDPDnzk++gxoN9AQmRBlq5lL u/Lg6fpBn8ATSDWqfjpy2KWzSFV7EM0+AQu5ckirBcUjXcvrqheFzW6+RTAAS69J1sIo QI3NlMT/zvJAQIVG3Ti/zLxRouCycdbFiB4B0= 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; b=xJz7uj+mLeZGIPOpUJdilcirHtFABSjlEBZ/0gyH9vmy46uKqu0FMoDbWEvmWGFZrx RFIO4chaEmKPw/tGuUJY9Y3wJnMpI901RvLKHTdgZJpLC87cWnpTBqBZYbHn3tRpX26v mAUaRbOuJjeWo9gAOiLmx4rkhNZ2qLIBWGTDA= MIME-Version: 1.0 Received: by 10.143.20.37 with SMTP id x37mr8886559wfi.208.1261881313029; Sat, 26 Dec 2009 18:35:13 -0800 (PST) In-Reply-To: <200912262027.34338.freebsd@insightbb.com> References: <200912262027.34338.freebsd@insightbb.com> Date: Sat, 26 Dec 2009 18:35:13 -0800 Message-ID: From: Freddie Cash To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Do any of the wireless ethernet drivers support higher than 54Mbps rates X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2009 02:35:17 -0000 On Sat, Dec 26, 2009 at 5:27 PM, Steven Friedrich wrote: > It's not a big deal, but I'd like to find a wireless driver that > outperforms > hard-wired ethernet (not gigabit, just standard 100TX or whatever it's > called) > > Is there a spreadsheet or database that shows what caps each driver has? > ath(4) supports SuperG, aka 108 Mbps, when connecting to SuperG access points. I've used it successfully with the Atheros chipset in the D-Link DWL-G650 (rev B), NetGEAR WG511T, and the onboard Atheros chipsets in a handful of different laptops. Not sure which drivers support 802.11n (up to 480 Mbps or something like that), though, as I don't have access to any 802.11n hardware. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Sun Dec 27 10:36:25 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 71D4010657C5 for ; Sun, 27 Dec 2009 10:36:25 +0000 (UTC) (envelope-from hyama99@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id C74C08FC16 for ; Sun, 27 Dec 2009 10:36:24 +0000 (UTC) Received: by fxm27 with SMTP id 27so9557840fxm.3 for ; Sun, 27 Dec 2009 02:36:17 -0800 (PST) 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=6PDi/S9WfbawJ3SJgfMI9ZNdnq/vvHngcNGEpRRDCqU=; b=JAOniwUnOztlXoi9JW2AnRzQ9iP1MCumjeOdCCQgNYv6Xm1P8QIo41D43l7bQLg5x0 57gT3qL+vAWM9RLIwN+p5FCh60hRqhONsocXtw/Vua+fCgkkAeA51rlQ2anjjNdg5typ GyO+3iLqvgT8o1w+7y3cvHpT3PhtJgzMfUH0c= 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=ibp0fzekgvp/cQG3YtDynZsg0CPYedbB3HlSMkJbq4MPdGC6J7LD2os5DciVtGOUqv hUKa+S7wes2Qd7hZQIPcoEtGHf6cLN5F3lReEaeicWZEWiWtl0MHmQe7K+0f45r0ev7F XarbV36oTcKjiXrLy4TktiCgLBg+k4zUrfCvE= MIME-Version: 1.0 Received: by 10.239.190.227 with SMTP id y35mr1547743hbh.212.1261910176830; Sun, 27 Dec 2009 02:36:16 -0800 (PST) In-Reply-To: <4B3691FF.3050402@elischer.org> References: <90dbee150912261333l602c4161nccaf1995dc83699a@mail.gmail.com> <4B3691FF.3050402@elischer.org> Date: Sun, 27 Dec 2009 19:36:16 +0900 Message-ID: <90dbee150912270236k3be6e530r80d9e7576274137c@mail.gmail.com> From: Hideki Yamamoto To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: GIF MTU parmeter is needed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2009 10:36:25 -0000 Hi, Thank you for your replies. I have tested again. And I found that extension of gif MTU depends on the command sequence. After waking up gif0 and then changing gif MTU, packets on gif are fragmented by MMTU, 1280. However, when I changed the command sequence as changing gif0 MTU and then waking up gif0, packets on gif are not fragmented by MMTU. They are fragmented by new MTU. When I wrote the previous mail, I had not noticed the successful command sequence. For the time being, I found the successful command sequence when using gif tunnel. To say briefly, successful command sequence is # ifconfig gif0 mtu 1400 # ifconfig gif0 up and unsuccessful command sequence is # ifconfig gif0 up # ifconfig gif0 mtu 1400 The below of this mail is my test result. However, I have several questions and requests as follows: (1) I do not understand why ping6 with DF is not fragmented when another application packets are fragmented with unsuccessful command sequence. (2) I think ifconfig command should say something when changing MTU after the interface was waken up, because ifconfig shows the incorrect MTU in this situation. (3) Why MMTU(1280) is used when unsuccessful command sequence is used. And I request the method to change this MMTU, for example sysctl command as I said in the previous mail. Best regards, Hideki Yamamoto -------------------------------------------------------------------- 1. Test environment -------------------------------------------------------------------- - HW [FreeBSD BOX #99]----[SW]-----[FreeBSD BOX #98] - OS h99# uname -a FreeBSD h99 9.0-CURRENT FreeBSD 9.0-CURRENT #4: Sun Nov 8 19:44:55 JST 2009 hyama@h99:/usr/obj/usr/src/sys/GENERIC i386 - ping6 ping6 is extended by the DF patch by the following mail to this ML: "2009/12/11 pluknet :" -------------------------------------------------------------------- 2. Problem situation -------------------------------------------------------------------- udpgw is a short program to send udp packet to 2003:98::2 with specified packet length. Packet length is specified by -s option. This destination is over tunnel end point by gif0. h99# ifconfig xl0 inet6 2001:99::1 h99# ifconfig gif0 create h99# ifconfig gif0 inet tunnel 192.168.1.8 192.168.1.4 h99# route add -inet6 2001:98::/64 -interface gif0 add net 2001:98::/64: gateway gif0 h99# ifconfig gif0 up h99# ping6 2001:98::1 PING6(56=3D40+8+8 bytes) 2001:99::1 --> 2001:98::1 16 bytes from 2001:98::1, icmp_seq=3D0 hlim=3D64 time=3D0.700 ms 16 bytes from 2001:98::1, icmp_seq=3D1 hlim=3D64 time=3D0.683 ms 16 bytes from 2001:98::1, icmp_seq=3D2 hlim=3D64 time=3D0.665 ms C-c C-c --- 2001:98::1 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev =3D 0.665/0.683/0.700/0.014 ms h99# ifconfig gif0 mtu 1400 h99# ifconfig xl0: flags=3D8843 metric 0 mtu = 1500 options=3D9 ether 00:04:75:85:73:e8 inet6 2001:99::1 prefixlen 64 inet6 fe80::204:75ff:fe85:73e8%xl0 prefixlen 64 scopeid 0x1 nd6 options=3D21 media: Ethernet autoselect (100baseTX ) status: active fxp0: flags=3D8843 metric 0 mtu= 1500 options=3D2009 ether 00:20:ed:2c:d4:55 inet6 fe80::220:edff:fe2c:d455%fxp0 prefixlen 64 scopeid 0x2 inet 192.168.1.8 netmask 0xffffff00 broadcast 192.168.1.255 inet6 2001:c90:48d:7139::1 prefixlen 64 inet6 2001:c90:48d:7139:220:edff:fe2c:d455 prefixlen 64 autocon= f nd6 options=3D23 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=3D21 gif0: flags=3D8051 metric 0 mtu 1400 tunnel inet 192.168.1.8 --> 192.168.1.4 inet6 fe80::204:75ff:fe85:73e8%gif0 prefixlen 64 scopeid 0x4 nd6 options=3D23 options=3D1 h99# route add -inet6 2003:98::/64 -interface gif0 add net 2003:98::/64: gateway gif0 h99# ./udpgw -o -s 1300 & tshark -i gif0 -w udpgw-99.cap [1] 36697 Let's send 1300 length packet to 2003:98::2 Capturing on gif0 8 C-c C-ch99# fg ./udpgw -o -s 1300 C-c C-c h99# tshark -V -r udpgw-99.cap |grep Payload Payload length: 1240 Payload length: 84 Payload length: 1240 Payload length: 84 Payload length: 1240 Payload length: 84 Payload length: 1240 Payload length: 84 h99# -------------------------------------------------------------------- [Appendix 1] Ping6 is no problem -------------------------------------------------------------------- h99# ifconfig gif0 gif0: flags=3D8051 metric 0 mtu 1400 tunnel inet 192.168.1.8 --> 192.168.1.4 inet6 fe80::204:75ff:fe85:73e8%gif0 prefixlen 64 scopeid 0x4 nd6 options=3D23 options=3D1 h99# ping6 -D -s 1340 2001:98::1 PING6(1388=3D40+8+1340 bytes) 2001:99::1 --> 2001:98::1 1348 bytes from 2001:98::1, icmp_seq=3D0 hlim=3D64 time=3D1.392 ms 1348 bytes from 2001:98::1, icmp_seq=3D1 hlim=3D64 time=3D1.297 ms C-c C-c --- 2001:98::1 ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev =3D 1.297/1.345/1.392/0.047 ms h99# ping6 -D -s 1360 2001:98::1 PING6(1408=3D40+8+1360 bytes) 2001:99::1 --> 2001:98::1 ping6: sendmsg: Message too long ping6: wrote 2001:98::1 1368 chars, ret=3D-1 ping6: sendmsg: Message too long ping6: wrote 2001:98::1 1368 chars, ret=3D-1 C-c C-c --- 2001:98::1 ping6 statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss h99# ifconfig gif0 mtu 1440 h99# ping6 -D -s 1360 2001:98::1 PING6(1408=3D40+8+1360 bytes) 2001:99::1 --> 2001:98::1 1368 bytes from 2001:98::1, icmp_seq=3D0 hlim=3D64 time=3D1.414 ms 1368 bytes from 2001:98::1, icmp_seq=3D1 hlim=3D64 time=3D1.355 ms C-c C-c --- 2001:98::1 ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev =3D 1.355/1.385/1.414/0.029 ms -------------------------------------------------------------------- [Appendix 2] When command sequence is chagend, there is no problem -------------------------------------------------------------------- h99# ifconfig gif0 down h99# ifconfig gif0 deletetunnel h99# ifconfig gif0 gif0: flags=3D8010 metric 0 mtu 1440 inet6 fe80::204:75ff:fe85:73e8%gif0 prefixlen 64 scopeid 0x4 nd6 options=3D23 options=3D1 h99# ifconfig gif1 create h99# ifconfig gif1 mtu 1440 h99# ifconfig gif1 inet tunnel 192.168.1.8 192.168.1.4 h99# ifconfig gif1 up h99# ifconfig gif1 gif1: flags=3D8051 metric 0 mtu 1440 tunnel inet 192.168.1.8 --> 192.168.1.4 inet6 fe80::204:75ff:fe85:73e8%gif1 prefixlen 64 scopeid 0x5 nd6 options=3D23 options=3D1 h99# route delete -inet6 2003:98::/64 delete net 2003:98::/64 h99# route add -inet6 2003:98::/64 -interface gif1 add net 2003:98::/64: gateway gif1 h99# route delete -inet6 2001:98::/64 delete net 2001:98::/64 h99# route add -inet6 2001:98::/64 -interface gif1 add net 2001:98::/64: gateway gif1 h99# ping6 -D -s 1360 2001:98::1 PING6(1408=3D40+8+1360 bytes) 2001:99::1 --> 2001:98::1 1368 bytes from 2001:98::1, icmp_seq=3D0 hlim=3D64 time=3D1.446 ms C-c C-c --- 2001:98::1 ping6 statistics --- --- 2001:98::1 ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev =3D 1.446/1.446/1.446/0.000 ms h99# ./udpgw -o -s 1300 & tshark -i gif1 -w udpgw-99-gif1.cap [1] 66386 Let's send 1300 length packet to 2003:98::2 Capturing on gif1 4 C-c C-ch99# fg ./udpgw -o -s 1300 C-c C-c h99# tshark -V -r udpgw-99-gif1.cap |grep Payload Payload length: 1308 Payload length: 1308 Payload length: 1308 Payload length: 1308 Payload length: 1308 h99# I do not know why. -------------------------------------------------------------------- [Appendix 3] udpgw.c -------------------------------------------------------------------- /********************************************************************** ***********************************************************************/ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include char *send_addr=3D"2003:98::2"; char *send_port=3D"18000"; char *recv_addr=3D"2001:99::1"; char *recv_port=3D"16000"; int send_s; int only_out=3D0; int only_in=3D0; int out_packet_size; struct addrinfo *send_res; main(ac,av) int ac; char **av; { int c; while ((c =3D getopt(ac, av, "s:oi")) !=3D -1) { switch (c) { case 'o': only_out++; break; case 'i': only_in++; break; case 's': out_packet_size =3D atoi(optarg); break; default: Usage(); exit (1); } } if( only_in && only_out ){ Usage(); exit (1); } if( only_in =3D=3D 0 ){ create_send_socket(); if( only_out ){ send_v6_udp(); exit; exit; } } recv_v6_udp(); } Usage() { printf("Usage: udpgw [-o][-i][-s output_packet_size]\n"); } create_send_socket() { struct addrinfo hints; int error; memset(&hints, 0, sizeof(hints)); hints.ai_family =3D PF_UNSPEC; hints.ai_socktype =3D SOCK_DGRAM; error =3D getaddrinfo(send_addr, send_port, &hints, &send_res); if (error !=3D 0) errx(1, "%s", gai_strerror(error)); send_res->ai_family =3D AF_INET6; send_s =3D socket(send_res->ai_family, send_res->ai_socktype, send_res->ai_protocol); if (send_s < 0) err(1, "socket"); } send_v6_udp() { int len,cc,i; char buf[2000]; for( i=3D0; i<2000 ; i++ ){ buf[i]=3D'a'; } if( 1501 > out_packet_size ){ cc =3D out_packet_size ; }else{ cc =3D 1500; } printf("Let's send %d length packet to %s\n",cc,send_addr); while(1){ len =3D sendto(send_s, buf, cc, 0, send_res->ai_addr, send_res->ai_addr= len); sleep(1); } } recv_v6_udp() { int recv_s; struct addrinfo hints, *res; int error; int len,cc,ccout; char buf[2000]; FILE *outfp=3Dstdout; int fromlen; struct sockaddr_in6 from6; memset(&hints, 0, sizeof(hints)); hints.ai_family =3D PF_UNSPEC; hints.ai_socktype =3D SOCK_DGRAM; error =3D getaddrinfo(recv_addr, recv_port, &hints, &res); if (error !=3D 0) errx(1, "%s", gai_strerror(error)); res->ai_family =3D AF_INET6; recv_s =3D socket(res->ai_family, res->ai_socktype, res->ai_protoco= l); if (recv_s < 0) err(1, "socket"); while(1){ cc =3D recvfrom(recv_s, (void *)buf, sizeof(buf), 0, (struct sockaddr *)&from6, &fromlen); if (cc < 0) { warn("recvfrom"); continue; } if ( only_in =3D=3D 0 ){ len =3D sendto(send_s, buf, cc, 0, send_res->ai_addr, send_res->ai_addrlen); } else { if ((ccout =3D fwrite(buf, cc, 1, outfp)) < 1) close(recv_s); } } } ------------------------------------------------- 2009/12/27 Julian Elischer : > Hideki Yamamoto wrote: >> >> Hi, >> >> I often use FreeBSD for developing the gateway. For example, I use gif f= or >> the >> tunnel protocol when using IPv6 over IPv4 and use an application for >> changing >> packet address for special purpose. =A0When we were using old FreeBSD, s= uch >> as >> FreeBSD 4.11, the MTU of the tunnel packets or forwarded packets >> was not limited into 1280. However, FreeBSD 6,7, and 8 fragments packets >> by 1280 when using tunnel. > > ?? huh? > it is defined by the MTU of the gif interface as set with ifconfig > >> >> I know that this behavior is based on the RFC specification. =A0However >> it is not useful when using AV application that use around 1400B RTP >> packet. >> AV packets will be fragmented into long packets (1280) and short >> packets (1400-1280) >> when using tunnel, and short packet will sometimes be lost by network. >> >> I hope new parameter by sysctl to control MTU of tunnel will be >> implemented. >> The following is an example of new paramter to control MTU size. >> >> =A0 =A0 net.inet6.use_mmtu :1 --- is the same as current versions, it me= ans >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 minimum MTU 1280 >> will be used when gateway node. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 :0--- is the same as the >> old versions. It means >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 OS uses >> as long MTU size as possible >> =A0 =A0 =A0 =A0 =A0 =A0( I hope "1" will be default) >> >> Are there any comment on this matter? >> >> Best regards, >> >> Hideki Yamamoto >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Sun Dec 27 12:43: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 D113D1065672 for ; Sun, 27 Dec 2009 12:43:07 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 61FC18FC0A for ; Sun, 27 Dec 2009 12:43:07 +0000 (UTC) Received: by fxm27 with SMTP id 27so9595571fxm.3 for ; Sun, 27 Dec 2009 04:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=kKvnropDR0vS972ljZHEmOB/A+S/2ygOIUlE8fd0RTU=; b=xiQpQJ74GHjq//mFtC+2/Ye10OHQDqpVT5PFNwtokrUfqWKJR0slG0TirkrvvOrsHo xdDywJUFJwBl+nBIXdmithcRI6f7iKJ1IbR912R8xFwrR8NXcffiNp9aX6qyqVzdu54C TJd3qXHfSzf0mCKwzA4sHcsgba5Qj16LyCoI8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=hApQbJTJnQR25+nm/KjnOcFul7iF/WFrcOk3ZhPZc7dlknaWRn60s2KBFT/rauEcsE LWJ3WuViWY9l++/ZEELGHVKc+sTCuK87uPYDLD6HiutkmhJqOM66sLZz3rTtkij8SZLf Yb57w1HvHQNVyHFJcm1FsJn3UtaUjqj24h2jE= Received: by 10.223.2.69 with SMTP id 5mr6601328fai.88.1261917779074; Sun, 27 Dec 2009 04:42:59 -0800 (PST) Received: from ?10.0.10.2? (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 13sm3696348fxm.1.2009.12.27.04.42.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 27 Dec 2009 04:42:58 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <200912262027.34338.freebsd@insightbb.com> Date: Sun, 27 Dec 2009 12:42:56 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <815CD398-B92D-4D2E-B46E-5431C1283D03@freebsd.org> References: <200912262027.34338.freebsd@insightbb.com> To: Steven Friedrich X-Mailer: Apple Mail (2.1077) Cc: freebsd-net@freebsd.org Subject: Re: Do any of the wireless ethernet drivers support higher than 54Mbps rates X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2009 12:43:07 -0000 On 27 Dec 2009, at 01:27, Steven Friedrich wrote: > It's not a big deal, but I'd like to find a wireless driver that = outperforms=20 > hard-wired ethernet (not gigabit, just standard 100TX or whatever it's = called) >=20 > Is there a spreadsheet or database that shows what caps each driver = has? Currently, we are still working on 11n support, so no drivers in the = tree can do the throughput you expect. If you want something better than 54mbps, try ath with superg. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Sun Dec 27 12:58:09 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 ADC6F106566B; Sun, 27 Dec 2009 12:58:09 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 85A5E8FC0A; Sun, 27 Dec 2009 12:58:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBRCw9rZ032110; Sun, 27 Dec 2009 12:58:09 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBRCw9Lt032106; Sun, 27 Dec 2009 12:58:09 GMT (envelope-from brucec) Date: Sun, 27 Dec 2009 12:58:09 GMT Message-Id: <200912271258.nBRCw9Lt032106@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/142066: [patch] [sctp] Missing parenthesis in sys/netinet/sctp_pcb.c . X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2009 12:58:09 -0000 Old Synopsis: Missing parenthesis in sys/netinet/sctp_pcb.c . New Synopsis: [patch] [sctp] Missing parenthesis in sys/netinet/sctp_pcb.c . Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Sun Dec 27 12:57:08 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=142066 From owner-freebsd-net@FreeBSD.ORG Sun Dec 27 15:33:59 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 3003110656A3; Sun, 27 Dec 2009 15:33:59 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 084528FC19; Sun, 27 Dec 2009 15:33:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBRFXw9j078410; Sun, 27 Dec 2009 15:33:58 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBRFXwia078406; Sun, 27 Dec 2009 15:33:58 GMT (envelope-from brucec) Date: Sun, 27 Dec 2009 15:33:58 GMT Message-Id: <200912271533.nBRFXwia078406@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/86871: [tcp] [patch] allocation logic for PCBs in TIME_WAIT state causes packet drops on stateful FWs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2009 15:33:59 -0000 Old Synopsis: allocation logic for PCBs in TIME_WAIT state causes packet drops on stateful FWs New Synopsis: [tcp] [patch] allocation logic for PCBs in TIME_WAIT state causes packet drops on stateful FWs Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Sun Dec 27 15:32:36 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=86871 From owner-freebsd-net@FreeBSD.ORG Mon Dec 28 04:53: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 A7A3D106566C; Mon, 28 Dec 2009 04:53: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 7F7288FC0C; Mon, 28 Dec 2009 04:53:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBS4rpkT005380; Mon, 28 Dec 2009 04:53:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBS4rpW3005376; Mon, 28 Dec 2009 04:53:51 GMT (envelope-from linimon) Date: Mon, 28 Dec 2009 04:53:51 GMT Message-Id: <200912280453.nBS4rpW3005376@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/142052: [panic] MROUTED option causes kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 04:53:51 -0000 Old Synopsis: MROUTED option causes kernel panic New Synopsis: [panic] MROUTED option causes kernel panic Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 28 04:52:36 UTC 2009 Responsible-Changed-Why: This does not sound i386-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=142052 From owner-freebsd-net@FreeBSD.ORG Mon Dec 28 11:07:04 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 B3356106566B for ; Mon, 28 Dec 2009 11:07:04 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A19878FC17 for ; Mon, 28 Dec 2009 11:07:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBSB74As079556 for ; Mon, 28 Dec 2009 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBSB73Ws079554 for freebsd-net@FreeBSD.org; Mon, 28 Dec 2009 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Dec 2009 11:07:03 GMT Message-Id: <200912281107.nBSB73Ws079554@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 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/142066 net [patch] [sctp] Missing parenthesis in sys/netinet/sctp o kern/142052 net [panic] MROUTED option causes kernel panic o kern/142019 net [em] em needs "ifconfig em0 down up" when link was gon o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141843 net [em] [vlan] Intel txcsum and assigned vlan invoke wron o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141720 net [sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net [sctp] [panic] Own lock on stcb at return from input o kern/141697 net [sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net [rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net [sctp] [panic] kernel page fault with non-sleepable lo o kern/141646 net [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged fr o kern/141314 net Network Performance has decreased by 30% [regression] o kern/141285 net [em] hangs down/up intel nic during creating vlan o kern/141256 net [iwn] iwn(4) causes page fault on interface up o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140970 net [bce] The two NetXtreme II BCM5709S NICs on our HP Bl4 o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140684 net [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc s kern/140597 net [request] implement Lost Retransmission Detection o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net [bce] [arp] ARP not sent through Bridge Firewall with o kern/140036 net [iwn] [lor] lock order reversal with iwn0_com_lock and o kern/139761 net [bce] bce driver on IBM HS22 [No PHY found on Child MI o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138999 net [libc] lighttpd/php-cgi with freebsd sendfile(2) enabl o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop f kern/138666 net [multicast] [panic] not working multicast through igmp o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net [tcp] TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net [panic] spawning several dhclients in parallel panics 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/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se 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/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/133786 net [netinet] [patch] ip_input might cause kernel panic 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 f kern/133213 net arp and sshd errors on 7.1-PRERELEASE 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 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/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/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 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 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/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/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 [if_em] FreeBSD 7 multicast routing problem 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 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 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/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/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af 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/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s 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 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] [patch] if_sis short cable fix problems with Net 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 382 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 28 13: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 23596106566C for ; Mon, 28 Dec 2009 13: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 12B028FC15 for ; Mon, 28 Dec 2009 13:50:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBSDo2uC038002 for ; Mon, 28 Dec 2009 13:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBSDo2Js038001; Mon, 28 Dec 2009 13:50:02 GMT (envelope-from gnats) Date: Mon, 28 Dec 2009 13:50:02 GMT Message-Id: <200912281350.nBSDo2Js038001@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Shteryana Shopova Cc: Subject: Re: kern/142052: [panic] MROUTED option causes kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Shteryana Shopova List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 13:50:03 -0000 The following reply was made to PR kern/142052; it has been noted by GNATS. From: Shteryana Shopova To: bug-followup@FreeBSD.org Cc: s.bilberry@gmail.com Subject: Re: kern/142052: [panic] MROUTED option causes kernel panic Date: Mon, 28 Dec 2009 15:13:54 +0200 --001636b2accc5f3724047bc9adf4 Content-Type: text/plain; charset=UTF-8 From what I can tell looking at the backtrace and sources, the kernel crashes because it tries to insert an entry in the multicast forwarding cache TAILQ, but the TAILQ is not initialized - attached patch (against stable/8 ) tries to fix this. It would be nice to get a confirmation whether the problem still exists with the patch applied. --001636b2accc5f3724047bc9adf4 Content-Type: application/octet-stream; name="ip_mroute.c-20091228-01.diff" Content-Disposition: attachment; filename="ip_mroute.c-20091228-01.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g3r9gvx50 SW5kZXg6IGlwX21yb3V0ZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGlwX21yb3V0ZS5jCShyZXZpc2lvbiAy MDA0NDMpCisrKyBpcF9tcm91dGUuYwkod29ya2luZyBjb3B5KQpAQCAtMTM4NCw2ICsxMzg0LDE1 IEBACiAJICAgIHJ0LT5tZmNfcnAuc19hZGRyID0gSU5BRERSX0FOWTsKIAkgICAgcnQtPm1mY19i d19tZXRlciA9IE5VTEw7CiAKKwkgICAgLyogaW5pdGlhbGl6ZSBwa3QgY291bnRlcnMgcGVyIHNy Yy1ncnAgKi8KKwkgICAgcnQtPm1mY19wa3RfY250ICAgID0gMDsKKwkgICAgcnQtPm1mY19ieXRl X2NudCAgID0gMDsKKwkgICAgcnQtPm1mY193cm9uZ19pZiAgID0gMDsKKwkgICAgdGltZXZhbGNs ZWFyKCZydC0+bWZjX2xhc3RfYXNzZXJ0KTsKKworCSAgICBUQUlMUV9JTklUKCZydC0+bWZjX3N0 YWxsKTsKKwkgICAgcnQtPm1mY19uc3RhbGwgPSAwOworCiAJICAgIC8qIGxpbmsgaW50byB0YWJs ZSAqLwogCSAgICBMSVNUX0lOU0VSVF9IRUFEKCZtZmNoYXNodGJsW2hhc2hdLCBydCwgbWZjX2hh c2gpOwogCSAgICBUQUlMUV9JTlNFUlRfSEVBRCgmcnQtPm1mY19zdGFsbCwgcnRlLCBydGVfbGlu ayk7Cg== --001636b2accc5f3724047bc9adf4-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 28 18:58:04 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 1D2071065707 for ; Mon, 28 Dec 2009 18:58:04 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id DD3018FC17 for ; Mon, 28 Dec 2009 18:58:03 +0000 (UTC) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id 2DE66B0388F8 for ; Mon, 28 Dec 2009 13:58:03 -0500 (EST) thread-index: AcqH7659XmFWA1T3QdaKyso3F/lb/Q== Received: from dllstx1-8sst9f1.corp.verio.net ([10.144.0.7]) by iad-wprd-xchw01.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Dec 2009 13:58:01 -0500 Received: by dllstx1-8sst9f1.corp.verio.net (sSMTP sendmail emulation); Mon, 28 Dec 2009 12:58:01 +0000 Date: Mon, 28 Dec 2009 12:58:01 -0600 From: "David DeSimone" Content-Transfer-Encoding: 7bit To: Message-ID: <20091228185801.GA5508@verio.net> Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Mail-Followup-To: freebsd-net@freebsd.org References: <90dbee150912261333l602c4161nccaf1995dc83699a@mail.gmail.com> <4B3691FF.3050402@elischer.org> <90dbee150912270236k3be6e530r80d9e7576274137c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <90dbee150912270236k3be6e530r80d9e7576274137c@mail.gmail.com> Precedence: bulk User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 28 Dec 2009 18:58:01.0708 (UTC) FILETIME=[ADD8CAC0:01CA87EF] Subject: Re: GIF MTU parmeter is needed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 18:58:04 -0000 Hideki Yamamoto wrote: > > h99# ifconfig xl0 inet6 2001:99::1 > h99# ifconfig gif0 create > h99# ifconfig gif0 inet tunnel 192.168.1.8 192.168.1.4 > h99# route add -inet6 2001:98::/64 -interface gif0 > add net 2001:98::/64: gateway gif0 > h99# ifconfig gif0 up I wonder if the problem you're seeing is due to the MTU attached to the static route that you're adding rather than the MTU of the interface. Try different command sequences and perform a "route get" to find out what MTU is being applied to the routes, to see if they change to what you expect. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Mon Dec 28 19:06: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 5F297106568B for ; Mon, 28 Dec 2009 19:06:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outg.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 4749A8FC12 for ; Mon, 28 Dec 2009 19:06:05 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 04835B7554 for ; Mon, 28 Dec 2009 11:06:05 -0800 (PST) X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id C1A342D6011 for ; Mon, 28 Dec 2009 11:06:04 -0800 (PST) Message-ID: <4B39019C.1030705@elischer.org> Date: Mon, 28 Dec 2009 11:06:04 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <90dbee150912261333l602c4161nccaf1995dc83699a@mail.gmail.com> <4B3691FF.3050402@elischer.org> <90dbee150912270236k3be6e530r80d9e7576274137c@mail.gmail.com> <20091228185801.GA5508@verio.net> In-Reply-To: <20091228185801.GA5508@verio.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: GIF MTU parmeter is needed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 19:06:05 -0000 David DeSimone wrote: > Hideki Yamamoto wrote: >> h99# ifconfig xl0 inet6 2001:99::1 >> h99# ifconfig gif0 create >> h99# ifconfig gif0 inet tunnel 192.168.1.8 192.168.1.4 >> h99# route add -inet6 2001:98::/64 -interface gif0 >> add net 2001:98::/64: gateway gif0 >> h99# ifconfig gif0 up > > I wonder if the problem you're seeing is due to the MTU attached to the > static route that you're adding rather than the MTU of the interface. > > Try different command sequences and perform a "route get" to find out > what MTU is being applied to the routes, to see if they change to what > you expect. > Actually the route mtu will over-ride the interface mtu I think.. route change {address} mtu xxxx From owner-freebsd-net@FreeBSD.ORG Tue Dec 29 07:41:49 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 5D5C01065676 for ; Tue, 29 Dec 2009 07:41:49 +0000 (UTC) (envelope-from hyama99@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id DD3D08FC08 for ; Tue, 29 Dec 2009 07:41:48 +0000 (UTC) Received: by fxm27 with SMTP id 27so10617547fxm.3 for ; Mon, 28 Dec 2009 23:41:40 -0800 (PST) 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=8nobQPadsUpKEQwf9xnPeW/fIlkN7tBqPQN/rMqnqt8=; b=qYM+0QJnjxe9f8TR7LH15HatYL/CJqEsyNsYwEwmkO4UDhPXIhz1ShV196NlySLQz0 vvAA38xLQp4XBe4u41weAucsK3WxezH8Z9rJbUgYpmF+V9WOmJrdG1wrRyUHEd7OOO45 TftQwP1CZQ7CA2YRO49xtdcAhKJNdfIqjTXe4= 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=ESNTUxA83n6JARQPswU52qcQAEAq3xfpw90fxIOEooHtn7ohjjcZTjXezCllu3acIc 25HT/7YgOEIWjQgvnlhKEUJzer2xM0i2ZVpwJIxRSojURXC1P/kHOtIuFLPv/LZIGIXj OfA8kDnloRQZmwK/2E730L3oVt3QO2gTJnUiY= MIME-Version: 1.0 Received: by 10.239.153.133 with SMTP id z5mr758880hbb.88.1262072500575; Mon, 28 Dec 2009 23:41:40 -0800 (PST) In-Reply-To: <4B39019C.1030705@elischer.org> References: <90dbee150912261333l602c4161nccaf1995dc83699a@mail.gmail.com> <4B3691FF.3050402@elischer.org> <90dbee150912270236k3be6e530r80d9e7576274137c@mail.gmail.com> <20091228185801.GA5508@verio.net> <4B39019C.1030705@elischer.org> Date: Tue, 29 Dec 2009 16:41:40 +0900 Message-ID: <90dbee150912282341j206505d1jd3ef13b2ff866f5f@mail.gmail.com> From: Hideki Yamamoto To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: GIF MTU parmeter is needed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 07:41:49 -0000 Hi, Thank you for your information. I understand what happened in my freebsd box. As David and Julian said, "route change" command control MTU of gif, and th= e initial value is set from gif interface MTU value when "route add" command is executed. The initial value is independent from the gif interface condition, up and d= own. The following shows the result of my test: --------------------------------------------------------------------- Even after creating gif interface and getting it up, MTU value by route commamd is copied from interface MTU value when "route add" is executed. --------------------------------------------------------------------- h9# ifconfig gif5 create up h9# route add -inet6 2003:98::/64 -interface gif5 add net 2003:98::/64: gateway gif5 h9# route get -inet6 2003:98::/64 route to: 2003:98:: destination: 2003:98:: mask: ffff:ffff:ffff:ffff:: interface: gif5 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1280 1 0 h9# route delete -inet6 2003:98::/64 delete net 2003:98::/64 h9# ifconfig gif5 mtu 1500 h9# route add -inet6 2003:98::/64 -interface gif5 add net 2003:98::/64: gateway gif5 h9# route get -inet6 2003:98::/64 route to: 2003:98:: destination: 2003:98:: mask: ffff:ffff:ffff:ffff:: interface: gif5 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 h9# ifconfig gif5 inet tunnel 192.168.1.8 192.168.1.51 h9# ( ./udpgw -o -s 1500 & tshark -V -i gif5 | grep Payload ) & sleep 2 ; killall udpgw [4] 1236 [1] 1238 Let's send 1500 length packet to 2003:98::2 Capturing on gif5 Payload length: 1456 Payload length: 68 Payload length: 1456 Payload length: 68 Payload length: 1456 Payload length: 68 Payload length: 1456 Payload length: 1456 Payload length: 68 --------------------------------------------------------------------- After changing MTU from 1500 to 1300 by ifconfig command, MTU value by route commamd is changed to 1300 automatically. --------------------------------------------------------------------- h9# ifconfig gif5 mtu 1300 h9# ( ./udpgw -o -s 1500 & tshark -V -i gif5 | grep Payload ) & sleep 2 ; killall udpgw [5] 1281 [1] 1283 Let's send 1500 length packet to 2003:98::2 Capturing on gif5 Payload length: 1256 Payload length: 268 Payload length: 1256 Payload length: 268 Payload length: 1256 Payload length: 268 Payload length: 1256 Payload length: 268 Payload length: 1256 Payload length: 1256 Payload length: 268 Payload length: 1256 Payload length: 268 Payload length: 268 h9# route get -inet6 2003:98::/64 route to: 2003:98:: destination: 2003:98:: mask: ffff:ffff:ffff:ffff:: interface: gif5 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1300 1 0 --------------------------------------------------------------------- However, when changing MTU from 1300 to 1500 by ifconfig command, MTU value by route command is not changed to 1500 automatically. --------------------------------------------------------------------- h9# ifconfig gif5 mtu 1500 h9# route get -inet6 2003:98::/64 route to: 2003:98:: destination: 2003:98:: mask: ffff:ffff:ffff:ffff:: interface: gif5 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1300 1 0 h9# 2009/12/29 Julian Elischer : > David DeSimone wrote: >> >> Hideki Yamamoto wrote: >>> >>> =A0 =A0h99# ifconfig xl0 inet6 2001:99::1 >>> =A0 =A0h99# ifconfig gif0 create >>> =A0 =A0h99# ifconfig gif0 inet tunnel 192.168.1.8 192.168.1.4 >>> =A0 =A0h99# route add -inet6 2001:98::/64 -interface gif0 >>> =A0 =A0add net 2001:98::/64: gateway gif0 >>> =A0 =A0h99# ifconfig =A0gif0 up >> >> I wonder if the problem you're seeing is due to the MTU attached to the >> static route that you're adding rather than the MTU of the interface. >> >> Try different command sequences and perform a "route get" to find out >> what MTU is being applied to the routes, to see if they change to what >> you expect. >> > > > Actually the route mtu will over-ride the interface mtu I think.. > route change {address} mtu xxxx > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Dec 29 11:20: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 D5E59106568B for ; Tue, 29 Dec 2009 11:20:13 +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 AD4398FC1A for ; Tue, 29 Dec 2009 11:20:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBTBKDLn055993 for ; Tue, 29 Dec 2009 11:20:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBTBKD75055992; Tue, 29 Dec 2009 11:20:13 GMT (envelope-from gnats) Date: Tue, 29 Dec 2009 11:20:13 GMT Message-Id: <200912291120.nBTBKD75055992@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Dennis Yusupoff Cc: Subject: Re: kern/141285: [em] hangs down/up intel nic during creating vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dennis Yusupoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 11:20:13 -0000 The following reply was made to PR kern/141285; it has been noted by GNATS. From: Dennis Yusupoff To: bug-followup@FreeBSD.org, proks@sky.od.ua Cc: Subject: Re: kern/141285: [em] hangs down/up intel nic during creating vlan Date: Tue, 29 Dec 2009 14:15:09 +0300 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig090C306B3805EF6BB842448B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This bug looks exactly as mine: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/141843 And IMHO, it's a really critical severity. --- With best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg --------------enig090C306B3805EF6BB842448B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLOeS9AAoJEBUTaqBS2NB4wzsH/1dh+UwRRN3BXdJTLhLmG9dN fnfMqqWkWmcIfrwuu96OwyabhYL0nNW2HbQanFe1SmDDK0jk2AjXNpDbAeGeYKlc HtIQaUpx3ZpGPZrBvgUZmwrv1XIBre2jsnpNo45LEgtFLR1nBXJIZ/shbEeFZ94x +dFFpeCKuItfwbWla0D4LDGhuifGcAvOZQZKG8B/SmHHsnfEgpZPexov0OrULWnj huBHIpsV89Ke/cdIZl4840X0FUb5x4LLcRW0SmvxaWg/admsMha8pTOkEbBPskt9 O86MXN0L9yHx1xQtywt+GusHMukh8oQXTKGr8dEH2XKPpdSUpQ/goGLuI2vhG7o= =5fSL -----END PGP SIGNATURE----- --------------enig090C306B3805EF6BB842448B-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 29 18:54:41 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 2996010656A3; Tue, 29 Dec 2009 18:54:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F15768FC1E; Tue, 29 Dec 2009 18:54:40 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A6B1846B51; Tue, 29 Dec 2009 13:54:40 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id DA0DA8A01F; Tue, 29 Dec 2009 13:54:39 -0500 (EST) From: John Baldwin To: Brooks Davis Date: Tue, 29 Dec 2009 13:54:26 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200912291354.26708.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 29 Dec 2009 13:54:39 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: net@freebsd.org Subject: Add support for vlans to rc.d startup scripts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 18:54:41 -0000 This patch takes the work done for VAP devices for wireless and extends it to support adding VLAN interfaces to network devices more easily. A list of vlan interfaces is specified via 'vlans_'. If the vlan name is just a number, then that number is taken to be a tag and a '.' vlan interface device is created. Otherwise, a 'create_args_' variable must be defined that includes the 'vlan ' in order for the vlan to be successfully created. If one had the following lines in rc.conf for example: vlans_foo="101 bar vlan100" create_args_bar="vlan 102" create_args_vlan100="vlan 104" Then this would result in the following vlan devices being created during boot: foo.101: flags=8842 metric 0 mtu 1500 options=3 ether 00:24:81:40:e3:ef media: Ethernet autoselect vlan: 101 parent interface: foo bar: flags=8842 metric 0 mtu 1500 options=3 ether 00:24:81:40:e3:ef media: Ethernet autoselect vlan: 102 parent interface: foo vlan100: flags=8842 metric 0 mtu 1500 options=3 ether 00:24:81:40:e3:ef media: Ethernet autoselect vlan: 104 parent interface: foo If one uses 'sh /etc/rc.d/netif start foo' then the vlan devices will be created, and if one does 'sh /etc/rc.d/netif stop foo' then the vlan devices will be destroyed. One downside is that similar to the wlan interfaces, the ifconfig output for these devices is not displayed as part of the normal boot messages. Doing so would require some way for ifn_start and ifn_stop to communicate their list of child interfaces along with create/fail status for each back to the main loop in /etc/rc.d/netif. The patch is at http://www.FreeBSD.org/~jhb/patches/vlans_head.patch and is included below. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Dec 29 19:00:12 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 98DCA1065695 for ; Tue, 29 Dec 2009 19:00:12 +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 8697F8FC19 for ; Tue, 29 Dec 2009 19:00:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBTJ0Chk079527 for ; Tue, 29 Dec 2009 19:00:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBTJ0C9A079526; Tue, 29 Dec 2009 19:00:12 GMT (envelope-from gnats) Date: Tue, 29 Dec 2009 19:00:12 GMT Message-Id: <200912291900.nBTJ0C9A079526@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Pyun YongHyeon Cc: Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets 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: Tue, 29 Dec 2009 19:00:12 -0000 The following reply was made to PR kern/141843; it has been noted by GNATS. From: Pyun YongHyeon To: Dennis Yusupoff Cc: bug-followup@FreeBSD.org Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets Date: Tue, 29 Dec 2009 10:51:19 -0800 On Mon, Dec 21, 2009 at 11:53:22PM +0000, linimon@freebsd.org wrote: > Old Synopsis: Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets > New Synopsis: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Mon Dec 21 23:51:33 UTC 2009 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 I'm not sure whether you're seeing one of edge case of em(4)/igb(4) checksum offload issue. Personally I couldn't reproduce the issue but I guess the checksum offload/TSO handling might cause unexpected result. If you disable Tx checksum offload or TSO em(4) work as expected, right? If so, would you try the following patch and let me know whether it makes any difference? http://people.freebsd.org/~yongari/em.csum_tso.20091229.patch From owner-freebsd-net@FreeBSD.ORG Tue Dec 29 21:20:09 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 4F36510657C2 for ; Tue, 29 Dec 2009 21:20:09 +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 3A60C8FC0A for ; Tue, 29 Dec 2009 21:20:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBTLK7Fe007880 for ; Tue, 29 Dec 2009 21:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBTLK7kO007879; Tue, 29 Dec 2009 21:20:07 GMT (envelope-from gnats) Date: Tue, 29 Dec 2009 21:20:07 GMT Message-Id: <200912292120.nBTLK7kO007879@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Sergey Chernikov Cc: Subject: Re: kern/142052: [panic] MROUTED option causes kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sergey Chernikov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 21:20:09 -0000 The following reply was made to PR kern/142052; it has been noted by GNATS. From: Sergey Chernikov To: syrinx@FreeBSD.org Cc: bug-followup@FreeBSD.org Subject: Re: kern/142052: [panic] MROUTED option causes kernel panic Date: Tue, 29 Dec 2009 23:52:16 +0300 After more than 1 day uptime in the same conditions, but with the patch applied, I can say that it fixes the problem. Please commit to 8.0-STABLE. From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 00:33:06 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 5C88E1065698 for ; Wed, 30 Dec 2009 00:33:06 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 263448FC0C for ; Wed, 30 Dec 2009 00:33:06 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 950EA73098; Wed, 30 Dec 2009 01:24:47 +0100 (CET) Date: Wed, 30 Dec 2009 01:24:47 +0100 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20091230002447.GA55727@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: RFC: documented and actual behaviour of "ipfw tee" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 00:33:06 -0000 There a difference between the documented and actual behaviour of "ipfw tee" which occurs when there are multiple rules with the same number, e.g. rule_id number body r1 500 tee port1 dst-ip 1.2.3.0/24 r2 500 tee port2 dst-ip 1.2.4.0/24 r3 500 accept ip from any to any r4 510 count ip from any to any + the manpage says "processing continues with the NEXT RULE" (so after r1 we have r2, then r3, ...); + the implementation behaves as "processing continues with the NEXT NUMBERED RULE" (ie. after 500 continues with 510). The actual behaviour is an artifact of how "divert" is implemented: diverted packet only carry the rule number so we cannot tell, on a reinject, which of the rules numbered "500" matched, and we restart from the next one. Tee was implemented as an extension of divert. Skipping rules in my opinion is very unintuitive, but there is no way to fix it (unless we extend the API) as the rule_id is only known within the kernel. For 'tee', however, packets the situation is different because the copy of the packet that remains in the kernel does not lose knowledge of the matching rule so we can easily continue from the very next rule, same as it happens for dummynet packets with one_pass=0 (and tee'd netgraph packets, which I think already do "the right thing"). Since I am doing some work in this are of the code, I'd like to ask opinions on how to proceed: A. preserve the current behaviour and fix the manpage; B. fix the code to behave as the manpage says; C. introduce a sysctl to choose between A and B. Of course this moves the problem on which default to choose :) Because it is a very special case that I doubt many people have hit, I'd be inclined to do B and consider the old behaviour a bug. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 00:45:06 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 02388106568B for ; Wed, 30 Dec 2009 00:45:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outw.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id DD5A98FC13 for ; Wed, 30 Dec 2009 00:45:05 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 7BFF8C482; Tue, 29 Dec 2009 16:45:05 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 258352D6012; Tue, 29 Dec 2009 16:45:05 -0800 (PST) Message-ID: <4B3AA290.8000508@elischer.org> Date: Tue, 29 Dec 2009 16:45:04 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Luigi Rizzo References: <20091230002447.GA55727@onelab2.iet.unipi.it> In-Reply-To: <20091230002447.GA55727@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: RFC: documented and actual behaviour of "ipfw tee" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 00:45:06 -0000 Luigi Rizzo wrote: > There a difference between the documented and actual behaviour of > "ipfw tee" which occurs when there are multiple rules with the same > number, e.g. > > rule_id number body > r1 500 tee port1 dst-ip 1.2.3.0/24 > r2 500 tee port2 dst-ip 1.2.4.0/24 > r3 500 accept ip from any to any > r4 510 count ip from any to any > > + the manpage says "processing continues with the NEXT RULE" > (so after r1 we have r2, then r3, ...); > + the implementation behaves as "processing continues with the > NEXT NUMBERED RULE" (ie. after 500 continues with 510). > TEE should go to the next RULE with the original packet, but if you reinject the tee'd copy of the packet it should go to the next rule NUMBER. > The actual behaviour is an artifact of how "divert" is implemented: > diverted packet only carry the rule number so we cannot tell, on a > reinject, which of the rules numbered "500" matched, and we restart > from the next one. Tee was implemented as an extension of divert. > > Skipping rules in my opinion is very unintuitive, but there is > no way to fix it (unless we extend the API) as the rule_id is only > known within the kernel. > > For 'tee', however, packets the situation is different because the > copy of the packet that remains in the kernel does not lose knowledge > of the matching rule so we can easily continue from the very next > rule, same as it happens for dummynet packets with one_pass=0 (and > tee'd netgraph packets, which I think already do "the right thing"). > > Since I am doing some work in this are of the code, I'd like to ask > opinions on how to proceed: > > A. preserve the current behaviour and fix the manpage; > B. fix the code to behave as the manpage says; > C. introduce a sysctl to choose between A and B. > Of course this moves the problem on which default > to choose :) > > Because it is a very special case that I doubt many people have hit, > I'd be inclined to do B and consider the old behaviour a bug. > > cheers > luigi > > _______________________________________________ > 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 Dec 30 09: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 C237D1065693 for ; Wed, 30 Dec 2009 09: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 54BE78FC1E for ; Wed, 30 Dec 2009 09:00:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBU90A6i080609 for ; Wed, 30 Dec 2009 09:00:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBU90AH5080607; Wed, 30 Dec 2009 09:00:10 GMT (envelope-from gnats) Date: Wed, 30 Dec 2009 09:00:10 GMT Message-Id: <200912300900.nBU90AH5080607@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/142052: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 09:00:10 -0000 The following reply was made to PR kern/142052; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/142052: commit references a PR Date: Wed, 30 Dec 2009 08:52:27 +0000 (UTC) Author: syrinx Date: Wed Dec 30 08:52:13 2009 New Revision: 201254 URL: http://svn.freebsd.org/changeset/base/201254 Log: Make sure the multicast forwarding cache entry's stall queue is properly initialized before trying to insert an entry into it. PR: kern/142052 Reviewed by: bms MFC after: now Modified: head/sys/netinet/ip_mroute.c Modified: head/sys/netinet/ip_mroute.c ============================================================================== --- head/sys/netinet/ip_mroute.c Wed Dec 30 06:37:58 2009 (r201253) +++ head/sys/netinet/ip_mroute.c Wed Dec 30 08:52:13 2009 (r201254) @@ -1386,6 +1386,15 @@ fail: rt->mfc_rp.s_addr = INADDR_ANY; rt->mfc_bw_meter = NULL; + /* initialize pkt counters per src-grp */ + rt->mfc_pkt_cnt = 0; + rt->mfc_byte_cnt = 0; + rt->mfc_wrong_if = 0; + timevalclear(&rt->mfc_last_assert); + + TAILQ_INIT(&rt->mfc_stall); + rt->mfc_nstall = 0; + /* link into table */ LIST_INSERT_HEAD(&mfchashtbl[hash], rt, mfc_hash); TAILQ_INSERT_HEAD(&rt->mfc_stall, rte, rte_link); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 09:30: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 1FA53106568F for ; Wed, 30 Dec 2009 09:30:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0E9958FC0A for ; Wed, 30 Dec 2009 09:30:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBU9U567007632 for ; Wed, 30 Dec 2009 09:30:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBU9U5GO007626; Wed, 30 Dec 2009 09:30:05 GMT (envelope-from gnats) Date: Wed, 30 Dec 2009 09:30:05 GMT Message-Id: <200912300930.nBU9U5GO007626@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Dalibor Gudzic Cc: Subject: Re: kern/140796: [ath] [panic] privileged instruction fault X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dalibor Gudzic List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 09:30:06 -0000 The following reply was made to PR kern/140796; it has been noted by GNATS. From: Dalibor Gudzic To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/140796: [ath] [panic] privileged instruction fault Date: Wed, 30 Dec 2009 09:58:09 +0100 A small followup, I tried the new FreeBSD 8-RELEASE and now I am able to pass the boot. But the atheros is still not functioning. Here is the full dmesg: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) M CPU 430 @ 1.73GHz (1729.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6e8 Stepping = 8 Features=0xafe9fbff Features2=0xc109 AMD Features=0x100000 TSC: P-state invariant real memory = 1610612736 (1536 MB) avail memory = 1496326144 (1427 MB) ACPI APIC Table: MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of f0013000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_button0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 128M pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xa0000000-0xbfffffff,0xc8000000-0xc8ffffff irq 16 at device 0.0 on pci1 pcib2: irq 27 at device 2.0 on pci0 pci2: on pcib2 pcib3: irq 31 at device 3.0 on pci0 pci3: on pcib3 atapci0: port 0x60b8-0x60bf,0x60b0-0x60b3,0x6008-0x600f,0x6004-0x6007,0x6010-0x601f,0x6400-0x64ff irq 21 at device 15.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x60a0-0x60af at device 15.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] uhci0: port 0x6020-0x603f irq 20 at device 16.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x6040-0x605f irq 22 at device 16.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x6060-0x607f irq 21 at device 16.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0x6080-0x609f irq 23 at device 16.3 on pci0 uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem 0xc9400000-0xc94000ff irq 21 at device 16.4 on pci0 ehci0: [ITHREAD] usbus4: waiting for BIOS to give up control usbus4: timed out waiting for BIOS usbus4: EHCI version 1.0 usbus4: on ehci0 isab0: at device 17.0 on pci0 isa0: on isab0 vr0: port 0x6800-0x68ff mem 0xc9400400-0xc94004ff irq 23 at device 18.0 on pci0 vr0: Quirks: 0x0 vr0: Revision: 0x7c miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:14:0b:08:64:5b vr0: [ITHREAD] pcib4: at device 19.0 on pci0 pci4: on pcib4 pci4: at device 1.0 (no driver attached) pcib5: at device 19.1 on pci0 pci5: on pcib5 ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on pci5 ath0: [ITHREAD] ath0: unable to attach hardware; HAL status 3 device_attach: ath0 attach returned 6 acpi_acad0: on acpi0 battery0: on acpi0 acpi_tz0: on acpi0 atrtc0: port 0x70-0x75 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0 cpu0: on acpi0 p4tcc0: on cpu0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1729023049 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 acd0: DVDR at ata1-master UDMA33 ad4: 57231MB at ata2-master SATA150 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/ad4s3a ugen0.2: at usbus0 ums0: on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 ugen4.2: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 984MB (2015232 512 byte sectors: 64H 32S/T 984C) From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 10:40: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 9D376106568D for ; Wed, 30 Dec 2009 10:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC218FC16 for ; Wed, 30 Dec 2009 10:40:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBUAe4g5074723 for ; Wed, 30 Dec 2009 10:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBUAe4YN074722; Wed, 30 Dec 2009 10:40:04 GMT (envelope-from gnats) Date: Wed, 30 Dec 2009 10:40:04 GMT Message-Id: <200912301040.nBUAe4YN074722@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Dennis Yusupoff Cc: Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dennis Yusupoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 10:40:04 -0000 The following reply was made to PR kern/141843; it has been noted by GNATS. From: Dennis Yusupoff To: pyunyh@gmail.com Cc: bug-followup@FreeBSD.org Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets Date: Wed, 30 Dec 2009 13:34:30 +0300 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig42235F443B11536DEDB37A0B Content-Type: multipart/alternative; boundary="------------060207040500050208050702" This is a multi-part message in MIME format. --------------060207040500050208050702 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 29.12.2009 21:51, Pyun YongHyeon ?????: > On Mon, Dec 21, 2009 at 11:53:22PM +0000, linimon@freebsd.org wrote: > =20 >> Old Synopsis: Intel txcsum and assigned vlan invoke wrong dst MAC in T= CP packets >> New Synopsis: [em] [vlan] Intel txcsum and assigned vlan invoke wrong = dst MAC in TCP packets >> >> Responsible-Changed-From-To: freebsd-bugs->freebsd-net >> Responsible-Changed-By: linimon >> Responsible-Changed-When: Mon Dec 21 23:51:33 UTC 2009 >> Responsible-Changed-Why:=20 >> Over to maintainer(s). >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D141843 >> =20 > I'm not sure whether you're seeing one of edge case of em(4)/igb(4) > checksum offload issue. Personally I couldn't reproduce the issue > but I guess the checksum offload/TSO handling might cause > unexpected result. If you disable Tx checksum offload or TSO em(4) > work as expected, right?=20 Not exactly. Only checksum offload gives this issue, TSO on/off doesn't matter. By the way, we checked UDP also and found something interested. For it, we run echo service on server ("|echo dgram udp wait =20 root internal|" in //etc/inetd.conf/) and send strings by "|nc -4 -u server 7|" from client. So...UDP works fine before, while and after "ifconfig vlanX vlan X vlandev em0" command given at server. And the most interesting things is what while server "hangs" for TCP-connections, "establishing" UDP connections between client and server...helps it to "unhang" TCP, so it begins to works correctly. > If so, would you try the following patch > and let me know whether it makes any difference? > > http://people.freebsd.org/~yongari/em.csum_tso.20091229.patch > =20 Doesn't help, same behavior. And moreover, UDP also doesn't "help" and doesn't work so. If you'd like, I could give you an access to this server via SSH, would y= ou? --------------060207040500050208050702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 29.12.2009 21:51, Pyun YongHyeon пишет: 
On Mon, Dec 21, 2009 at 11:53:22PM +0000, linimon@freeb=
 sd.org wrote:
   
Old Synopsis: Intel txcsum and assigned vlan invoke wr=
 ong dst MAC in TCP packets
 New Synopsis: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst=
  MAC in TCP packets
 
 Responsible-Changed-From-To: freebsd-bugs->freebsd-net
 Responsible-Changed-By: linimon
 Responsible-Changed-When: Mon Dec 21 23:51:33 UTC 2009
 Responsible-Changed-Why:=20
 Over to maintainer(s).
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D14184=
 3
     
 I'm not sure whether you're seeing one of edge case of em(4)/igb(4)
 checksum offload issue. Personally I couldn't reproduce the issue
 but I guess the checksum offload/TSO handling might cause
 unexpected result. If you disable Tx checksum offload or TSO em(4)
 work as expected, right?
Not exactly.
Only checksum offload gives this issue, TSO on/off doesn't matter.
By the way, we checked UDP also and found something interested.
For it, we run echo service on server ("echo    dgra= m   udp     wait    root    internal"  in <= i>/etc/inetd.conf) and send strings by "nc -4 -u server 7" from client.
So...UDP works fine before, while and after "ifconfig vlanX vlan X vlandev em0" command given at server. And the most interesting things is what while server "hangs" for TCP-connections, "establishing" UDP connections between client and server...helps it to "unhang" TCP, so it begins to works correctly.

If so, would you try the following patch
 and let me know whether it makes any difference?
 
 http://people.freebsd.org/~yongari/em.cs=
 um_tso.20091229.patch
Doesn't help, same behavior. And moreover, UDP also doesn't "help" and doesn't work so.

If you'd like, I could give you an access to this server via SSH, would you?
--------------060207040500050208050702-- --------------enig42235F443B11536DEDB37A0B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLOyy2AAoJEBUTaqBS2NB4Le8IAIkQsJHiS2y3JjHRmYK/2OFz jHtHZGOnWw8cHzR275Sr75Os1z8hTJCwDhPwaMaqAr45pA+zg6E9QkKlr3ZbEPgW PNoxdIo+HN7xqJFAt9ye8BviE/HC0gelRSf0rUdc+qS2sR1MH7Pwa8uNwgg1/bpy BMNPWBjCAmsvx5AyaUi7zuGDzhz0UUMcO+k7DlXnJO1GX8ABR6T4mdU2ZzXYGGk7 e5oaT2++ezm5nKN/ABfseQ3UXzG10gv7N0H+4FpWJD5H1lm0pw3tphHGehzbwzBV 6YZmMYq0dHw+E4X5Ybbxe/jnrEsw2aeZdDIfBEqyOgGsudW/7j9zF/VsJPbY57g= =tVqG -----END PGP SIGNATURE----- --------------enig42235F443B11536DEDB37A0B-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 13:53:25 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 40C4A1065693 for ; Wed, 30 Dec 2009 13:53:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 8EFB38FC19 for ; Wed, 30 Dec 2009 13:53:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id nBUDrFkH078697; Thu, 31 Dec 2009 00:53:15 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 31 Dec 2009 00:53:15 +1100 (EST) From: Ian Smith To: Julian Elischer In-Reply-To: <4B3AA290.8000508@elischer.org> Message-ID: <20091230221119.L81420@sola.nimnet.asn.au> References: <20091230002447.GA55727@onelab2.iet.unipi.it> <4B3AA290.8000508@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Luigi Rizzo , net@freebsd.org Subject: Re: RFC: documented and actual behaviour of "ipfw tee" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 13:53:25 -0000 On Tue, 29 Dec 2009, Julian Elischer wrote: > Luigi Rizzo wrote: > > There a difference between the documented and actual behaviour of > > "ipfw tee" which occurs when there are multiple rules with the same > > number, e.g. > > > > rule_id number body > > r1 500 tee port1 dst-ip 1.2.3.0/24 > > r2 500 tee port2 dst-ip 1.2.4.0/24 > > r3 500 accept ip from any to any > > r4 510 count ip from any to any > > > > + the manpage says "processing continues with the NEXT RULE" > > (so after r1 we have r2, then r3, ...); > > + the implementation behaves as "processing continues with the > > NEXT NUMBERED RULE" (ie. after 500 continues with 510). > > > > TEE should go to the next RULE with the original packet, but if > you reinject the tee'd copy of the packet it should go to the > next rule NUMBER. Which is what happens now, right? Same behaviour on tee reinjection as divert does seem consistent. So if there is a problem, it's only with the original packet continuing with the next rule if same-numbered? > > The actual behaviour is an artifact of how "divert" is implemented: > > diverted packet only carry the rule number so we cannot tell, on a > > reinject, which of the rules numbered "500" matched, and we restart > > from the next one. Tee was implemented as an extension of divert. It seems fair that tee act the same as divert on reinjection, and this can't be changed without breaking existing divert socket code eg natd? > > Skipping rules in my opinion is very unintuitive, but there is > > no way to fix it (unless we extend the API) as the rule_id is only > > known within the kernel. > > > > For 'tee', however, packets the situation is different because the > > copy of the packet that remains in the kernel does not lose knowledge > > of the matching rule so we can easily continue from the very next > > rule, same as it happens for dummynet packets with one_pass=0 (and > > tee'd netgraph packets, which I think already do "the right thing"). Hmm. After divert you can match 'diverted' to distinguish reinjected packets later. Does/can/should this apply to reinjected tee'd packets? Similarly perhaps, with a set of same-numbered nat rules, are mapped packets 'reinjected' at the next rule, or the next higher-numbered rule? > > Since I am doing some work in this are of the code, I'd like to ask > > opinions on how to proceed: > > > > A. preserve the current behaviour and fix the manpage; I tend to this, though probably not knowing all the ramifications, especially not having played with ng_ipfw stuff at all. So for A, here's what we have, with suggested clarification in []: divert port Divert packets that match this rule to the divert(4) socket bound to port port. The search terminates. [Reinjected packets continue at the next higher-numbered rule.] tee port Send a copy of packets matching this rule to the divert(4) socket bound to port port. The search continues with the next rule. [Reinjected packets continue at the next higher-numbered rule.] > > B. fix the code to behave as the manpage says; Seems it's already correct regarding the original packet, and just needs clarifying re the reinjected packets, if I'm following this right? > > C. introduce a sysctl to choose between A and B. > > Of course this moves the problem on which default > > to choose :) > > > > Because it is a very special case that I doubt many people have hit, > > I'd be inclined to do B and consider the old behaviour a bug. Mike Makonnen's ipfw-classifyd can reinject packets at specified rule numbers by tcp/udp port classification by updating the tag/number, and has the same issue. There was some confusion there too regarding this, that I think a man clarification may have helped avoid. I'm also a bit confused by apparent overloading of one_pass function for dummynet pipe, netgraph, ng_tee and now nat too. What if you want to do kernel nat but wanted one_pass behaviour for pipes? Separate issue but similar distinction between divert vs in-kernel behaviour maybe? FWIW, Ian From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 15:48:53 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 5D21B1065672 for ; Wed, 30 Dec 2009 15:48:53 +0000 (UTC) (envelope-from proks@skylinetele.com) Received: from Harpy.sky.od.ua (harpy.sky.od.ua [81.25.224.2]) by mx1.freebsd.org (Postfix) with ESMTP id DA4028FC15 for ; Wed, 30 Dec 2009 15:48:52 +0000 (UTC) Received: from logos.sky.od.ua (logos [81.25.224.11]) by Harpy.sky.od.ua (8.12.10/8.12.10) with ESMTP id nBUFmpwi031382; Wed, 30 Dec 2009 17:48:51 +0200 Message-ID: <4B3B765F.1090403@skylinetele.com> Date: Wed, 30 Dec 2009 17:48:47 +0200 From: "Prokofiev S.P." User-Agent: Thunderbird 2.0.0.21 (X11/20090410) MIME-Version: 1.0 To: Pyun YongHyeon References: <200912291900.nBTJ0C9A079526@freefall.freebsd.org> In-Reply-To: <200912291900.nBTJ0C9A079526@freefall.freebsd.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 15:48:53 -0000 I can reproduce this case. server1 has nic nfe0 trouble server2 has nic em0 and em1 em0@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (82573E)' class = network subclass = ethernet em1@pci0:14:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel PRO/1000 PL Network Adaptor (82573L)' class = network subclass = ethernet scheme: server1-nfe0 -- switch -- em1-trouble-server2 on server2: ifconfig vlan555 create vlandev em1 vlan 555 10.10.10.2/24 and i can't ping from another server1 with ip 10.10.10.1/24 and switch has not mac address of server2 nic. nic hangs down/up in /var/log/messages: Dec 30 16:38:56 server2 kernel: em1: link state changed to DOWN Dec 30 16:38:56 server2 kernel: vlan555: link state changed to DOWN Dec 30 16:39:00 server2 kernel: em1: link state changed to UP Dec 30 16:39:00 server2 kernel: vlan555: link state changed to UP then ifconfig em1 down && ifconfig em1 up server1 began to ping and connect to iperf on server2 then ifconfig vlan556 create vlandev em1 vlan 556 10.11.11.2/24 in messages: Dec 30 16:40:28 server2 kernel: em1: link state changed to DOWN Dec 30 16:40:28 server2 kernel: vlan555: link state changed to DOWN Dec 30 16:40:28 server2 kernel: vlan556: link state changed to DOWN Dec 30 16:40:31 server2 kernel: em1: link state changed to UP Dec 30 16:40:31 server2 kernel: vlan555: link state changed to UP Dec 30 16:40:31 server2 kernel: vlan556: link state changed to UP server1 continue ping ip 10.10.10.2 on server2, but not connect to iperf and really, tcpdump -letn -i vlan555 on server1 shown changing mac address server1 in output packets from server2 ifconfig em1 -txcsum -tso resolve this problem, but not resolve hangs down/up kern/141285 after apply your patch and rebuild kernel: on server2: ifconfig vlan555 create vlandev em1 vlan 555 10.10.10.2/24 hangs down/up nic, not ping again ifconfig em1 down && ifconfig em1 up - don't help ifconfig em1 -txcsum -tso -vlanhwtag help ONLY for example tcpdump -letn -i vlan555 on server1 00:1b:fc:af:a1:b4 - mac-address nic of server1 00:30:48:8d:fe:ed - mac-address nic of server2 mac 00:1b:fc:af:a1:b4 exchange on e4:98:fc:af:a1:b4 and d8:e0:fc:af:a1:b4 and ... in reply from server2 00:1b:fc:af:a1:b4 > 00:30:48:8d:fe:ed, ethertype IPv4 (0x0800), length 74: 10.10.10.1.61411 > 10.10.10.2.5001: S 564478084:564478084(0) win 65535 00:30:48:8d:fe:ed > e4:98:fc:af:a1:b4, ethertype IPv4 (0x0800), length 74: 10.10.10.2.5001 > 10.10.10.1.61411: S 2331848301:2331848301(0) ack 564478085 win 65535 00:1b:fc:af:a1:b4 > 00:30:48:8d:fe:ed, ethertype IPv4 (0x0800), length 74: 10.10.10.1.61411 > 10.10.10.2.5001: S 564478084:564478084(0) win 65535 00:30:48:8d:fe:ed > d8:e0:fc:af:a1:b4, ethertype IPv4 (0x0800), length 74: 10.10.10.2.5001 > 10.10.10.1.61411: S 2331848301:2331848301(0) ack 564478085 win 65535 00:30:48:8d:fe:ed > d8:e0:fc:af:a1:b4, ethertype IPv4 (0x0800), length 74: 10.10.10.2.5001 > 10.10.10.1.61411: S 2331848301:2331848301(0) ack 564478085 win 65535 00:1b:fc:af:a1:b4 > 00:30:48:8d:fe:ed, ethertype IPv4 (0x0800), length 74: 10.10.10.1.61411 > 10.10.10.2.5001: S 564478084:564478084(0) win 65535 00:30:48:8d:fe:ed > cc:60:fc:af:a1:b4, ethertype IPv4 (0x0800), length 74: 10.10.10.2.5001 > 10.10.10.1.61411: S 2331848301:2331848301(0) ack 564478085 win 65535 00:30:48:8d:fe:ed > cc:60:fc:af:a1:b4, ethertype IPv4 (0x0800), length 74: 10.10.10.2.5001 > 10.10.10.1.61411: S 2331848301:2331848301(0) ack 564478085 win 65535 00:1b:fc:af:a1:b4 > 00:30:48:8d:fe:ed, ethertype IPv4 (0x0800), length 62: 10.10.10.1.61411 > 10.10.10.2.5001: S 564478084:564478084(0) win 65535 sorry for my english Pyun YongHyeon wrote: > The following reply was made to PR kern/141843; it has been noted by GNATS. > > From: Pyun YongHyeon > To: Dennis Yusupoff > Cc: bug-followup@FreeBSD.org > Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets > Date: Tue, 29 Dec 2009 10:51:19 -0800 > > On Mon, Dec 21, 2009 at 11:53:22PM +0000, linimon@freebsd.org wrote: > > Old Synopsis: Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets > > New Synopsis: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > > Responsible-Changed-By: linimon > > Responsible-Changed-When: Mon Dec 21 23:51:33 UTC 2009 > > Responsible-Changed-Why: > > Over to maintainer(s). > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 > > I'm not sure whether you're seeing one of edge case of em(4)/igb(4) > checksum offload issue. Personally I couldn't reproduce the issue > but I guess the checksum offload/TSO handling might cause > unexpected result. If you disable Tx checksum offload or TSO em(4) > work as expected, right? If so, would you try the following patch > and let me know whether it makes any difference? > > http://people.freebsd.org/~yongari/em.csum_tso.20091229.patch > _______________________________________________ > 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 Dec 30 16:30: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 B45651065698 for ; Wed, 30 Dec 2009 16:30:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 836678FC23 for ; Wed, 30 Dec 2009 16:30:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBUGU8qt094329 for ; Wed, 30 Dec 2009 16:30:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBUGU8CD094326; Wed, 30 Dec 2009 16:30:08 GMT (envelope-from gnats) Date: Wed, 30 Dec 2009 16:30:08 GMT Message-Id: <200912301630.nBUGU8CD094326@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Rui Paulo Cc: Subject: Re: kern/140796: [ath] [panic] privileged instruction fault X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rui Paulo List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 16:30:08 -0000 The following reply was made to PR kern/140796; it has been noted by GNATS. From: Rui Paulo To: bug-followup@FreeBSD.org, dalibor.gudzic@gmail.com Cc: Subject: Re: kern/140796: [ath] [panic] privileged instruction fault Date: Wed, 30 Dec 2009 15:59:18 +0000 Are you sure this card works properly? Can you try with a different card? -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 20:30: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 778DA106568B for ; Wed, 30 Dec 2009 20:30:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0D0BF8FC18 for ; Wed, 30 Dec 2009 20:30:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBUKU54F012803 for ; Wed, 30 Dec 2009 20:30:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBUKU5eA012796; Wed, 30 Dec 2009 20:30:05 GMT (envelope-from gnats) Date: Wed, 30 Dec 2009 20:30:05 GMT Message-Id: <200912302030.nBUKU5eA012796@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Pyun YongHyeon Cc: Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets 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, 30 Dec 2009 20:30:08 -0000 The following reply was made to PR kern/141843; it has been noted by GNATS. From: Pyun YongHyeon To: Dennis Yusupoff Cc: bug-followup@FreeBSD.org Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets Date: Wed, 30 Dec 2009 12:20:14 -0800 On Wed, Dec 30, 2009 at 01:34:30PM +0300, Dennis Yusupoff wrote: > 29.12.2009 21:51, Pyun YongHyeon ?????: > > On Mon, Dec 21, 2009 at 11:53:22PM +0000, linimon@freebsd.org wrote: > > > >> Old Synopsis: Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets > >> New Synopsis: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets > >> > >> Responsible-Changed-From-To: freebsd-bugs->freebsd-net > >> Responsible-Changed-By: linimon > >> Responsible-Changed-When: Mon Dec 21 23:51:33 UTC 2009 > >> Responsible-Changed-Why: > >> Over to maintainer(s). > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 > >> > > I'm not sure whether you're seeing one of edge case of em(4)/igb(4) > > checksum offload issue. Personally I couldn't reproduce the issue > > but I guess the checksum offload/TSO handling might cause > > unexpected result. If you disable Tx checksum offload or TSO em(4) > > work as expected, right? > Not exactly. > Only checksum offload gives this issue, TSO on/off doesn't matter. > By the way, we checked UDP also and found something interested. > For it, we run echo service on server ("|echo dgram udp wait > root internal|" in //etc/inetd.conf/) and send strings by "|nc -4 -u > server 7|" from client. > So...UDP works fine before, while and after "ifconfig vlanX vlan X > vlandev em0" command given at server. And the most interesting things is > what while server "hangs" for TCP-connections, "establishing" UDP > connections between client and server...helps it to "unhang" TCP, so it > begins to works correctly. > > > If so, would you try the following patch > > and let me know whether it makes any difference? > > > > http://people.freebsd.org/~yongari/em.csum_tso.20091229.patch > > > Doesn't help, same behavior. And moreover, UDP also doesn't "help" and > doesn't work so. > Sorry, that wasn't expected one. From your explanation above I think I found a possible cause of checksum offload issue of em(4). The issue was not I initially thought though. It seems the checksum offload context configured in em(4) was incorrectly reused even if a frame requires a new context as IP/TCP header length, checksum offload offset was changed. Setting up new context put more burden to hardware such that em(4) used to avoid new context setup as possible as it can. However it seems em(4) failed to compare all required field in the checksum offload context. Would you try the following patch again? http://people.freebsd.org/~yongari/em.csum_tso.20091230.patch > If you'd like, I could give you an access to this server via SSH, would you? Thanks for the offer. ATM I'm somewhat busy to address other driver issues. If the patch does not work and I find spare time I'll let you know. From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 21:30:03 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 825F0106566B for ; Wed, 30 Dec 2009 21:30:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outc.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6545E8FC18 for ; Wed, 30 Dec 2009 21:30:03 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 2EFD7B3E6; Wed, 30 Dec 2009 13:30:03 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 6E9432D6019; Wed, 30 Dec 2009 13:30:02 -0800 (PST) Message-ID: <4B3BC659.7010707@elischer.org> Date: Wed, 30 Dec 2009 13:30:01 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Ian Smith References: <20091230002447.GA55727@onelab2.iet.unipi.it> <4B3AA290.8000508@elischer.org> <20091230221119.L81420@sola.nimnet.asn.au> In-Reply-To: <20091230221119.L81420@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , net@freebsd.org Subject: Re: RFC: documented and actual behaviour of "ipfw tee" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 21:30:03 -0000 Ian Smith wrote: > On Tue, 29 Dec 2009, Julian Elischer wrote: > > Luigi Rizzo wrote: > > > There a difference between the documented and actual behaviour of > > > "ipfw tee" which occurs when there are multiple rules with the same > > > number, e.g. > > > > > > rule_id number body > > > r1 500 tee port1 dst-ip 1.2.3.0/24 > > > r2 500 tee port2 dst-ip 1.2.4.0/24 > > > r3 500 accept ip from any to any > > > r4 510 count ip from any to any > > > > > > + the manpage says "processing continues with the NEXT RULE" > > > (so after r1 we have r2, then r3, ...); > > > + the implementation behaves as "processing continues with the > > > NEXT NUMBERED RULE" (ie. after 500 continues with 510). > > > > > > > TEE should go to the next RULE with the original packet, but if > > you reinject the tee'd copy of the packet it should go to the > > next rule NUMBER. > > Which is what happens now, right? Same behaviour on tee reinjection as > divert does seem consistent. So if there is a problem, it's only with > the original packet continuing with the next rule if same-numbered? from Luigi's description I'm not sure what happens now.. :-) teh two cases are different. Processing with the original packet acts as if the rule had done nothing. Processiong with a reinjected packet acts the same as a reinjected divert packet.. i.e. next rule NUMBER not next rule. > > > > The actual behaviour is an artifact of how "divert" is implemented: > > > diverted packet only carry the rule number so we cannot tell, on a > > > reinject, which of the rules numbered "500" matched, and we restart > > > from the next one. Tee was implemented as an extension of divert. > > It seems fair that tee act the same as divert on reinjection, and this > can't be changed without breaking existing divert socket code eg natd? it's also the only way it can work really. It can't tell the difference between rules with the same number. > > > > Skipping rules in my opinion is very unintuitive, but there is > > > no way to fix it (unless we extend the API) as the rule_id is only > > > known within the kernel. > > > > > > For 'tee', however, packets the situation is different because the > > > copy of the packet that remains in the kernel does not lose knowledge > > > of the matching rule so we can easily continue from the very next > > > rule, same as it happens for dummynet packets with one_pass=0 (and > > > tee'd netgraph packets, which I think already do "the right thing"). > > Hmm. After divert you can match 'diverted' to distinguish reinjected > packets later. Does/can/should this apply to reinjected tee'd packets? yes, there is no such thing as a reinjected tee packet as teh user app can't tell if it was diverted or teed. > > Similarly perhaps, with a set of same-numbered nat rules, are mapped > packets 'reinjected' at the next rule, or the next higher-numbered rule? I think NAT processing in the kernel can keep track od where it is up to, so next RULE. (differnet from userland nat via divert). > > > > Since I am doing some work in this are of the code, I'd like to ask > > > opinions on how to proceed: > > > > > > A. preserve the current behaviour and fix the manpage; > > I tend to this, though probably not knowing all the ramifications, > especially not having played with ng_ipfw stuff at all. > > So for A, here's what we have, with suggested clarification in []: > > divert port > Divert packets that match this rule to the divert(4) socket bound > to port port. The search terminates. [Reinjected packets continue > at the next higher-numbered rule.] > > tee port > Send a copy of packets matching this rule to the divert(4) socket > bound to port port. The search continues with the next rule. > [Reinjected packets continue at the next higher-numbered rule.] yes > > > > B. fix the code to behave as the manpage says; > > Seems it's already correct regarding the original packet, and just needs > clarifying re the reinjected packets, if I'm following this right? I think the man page should reflec the behavious mentionned above. i.e. copy and original packets continue at differnet rules. > > > > C. introduce a sysctl to choose between A and B. > > > Of course this moves the problem on which default > > > to choose :) no > > > > > > Because it is a very special case that I doubt many people have hit, > > > I'd be inclined to do B and consider the old behaviour a bug. no the original behaviour was not accidental. They were never going to come to teh same rule unless the next rule is on a different number. > > Mike Makonnen's ipfw-classifyd can reinject packets at specified rule > numbers by tcp/udp port classification by updating the tag/number, and > has the same issue. There was some confusion there too regarding this, > that I think a man clarification may have helped avoid. > > I'm also a bit confused by apparent overloading of one_pass function for > dummynet pipe, netgraph, ng_tee and now nat too. What if you want to > do kernel nat but wanted one_pass behaviour for pipes? Separate issue > but similar distinction between divert vs in-kernel behaviour maybe? yes that has sort of worried me too, but I haven't hit it in practice (yet). > > FWIW, Ian From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 22:25:30 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 E3D731065670 for ; Wed, 30 Dec 2009 22:25:30 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 968428FC14 for ; Wed, 30 Dec 2009 22:25:30 +0000 (UTC) Received: by yxe1 with SMTP id 1so11352274yxe.3 for ; Wed, 30 Dec 2009 14:25:25 -0800 (PST) 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:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=YBCJIExy6KnrdWm4mGP2HPNGLHNpUB/YdOQDHUbdf/g=; b=RlmaXwzwKQ6AsPVxh7P7sQ3sIFnZnru89thHNo/HzNTjtGLSiyd8loaRypJKNXjPbJ vb2nbMIeMb4iI5TpCI2oR7oRcRrEjwOqf9/zaK5pjryyXqUL5G+cqMY0awsKCmkZrWR5 bSzRJJEfF8yklJHxyxcQ+sbA6yXFnus4BG6Dk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=BLZRbaNY2AMhdXjSqLQqhySaBsbnkJ1R3kNMaHj4gaGnPjyf3hCkXVCmDn2T2M7y0k 9Tya4sQxdRQV1Yopgab6gPjL7Prm0O9xAcFU3MQnCOtH+JTa9e9ok/AUppvZC9R3MNKK VZR3ODHGGyNFgx+tdx0XzkyrycTHBAoonOHQI= Received: by 10.101.160.6 with SMTP id m6mr19277219ano.104.1262211925265; Wed, 30 Dec 2009 14:25:25 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 20sm4865026ywh.47.2009.12.30.14.25.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 30 Dec 2009 14:25:23 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 30 Dec 2009 14:24:03 -0800 From: Pyun YongHyeon Date: Wed, 30 Dec 2009 14:24:03 -0800 To: "Lhunath (Maarten B.)" Message-ID: <20091230222403.GO1166@michelle.cdnetworks.com> References: <20091224194214.GE8146@michelle.cdnetworks.com> <5D9DCA13-95CC-4848-AAFF-04900CE841B2@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D9DCA13-95CC-4848-AAFF-04900CE841B2@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: mskc0: Tx descriptor error X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 22:25:31 -0000 On Thu, Dec 24, 2009 at 10:25:46PM +0100, Lhunath (Maarten B.) wrote: > >> e1000phy0: PHY 0 on miibus0 > >> e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > > > I guess you hit known msk(4) issue for 88E8056/88E1149 PHY. Some > > users have no problems but others seem to suffer from the issue. > > There is also a PR about this but it seems it's hard to fix that > > mainly because I don't have access to the hardware. > > Perhaps if you can provide patches against the 8.0-REL msk(1) to make it extremely verbose, I could provide the output and we might learn more about the cause of this issue. The fact that it's so easily reproduced must play in favor. > A kind user gave me remote access to a 7.2-RELEASE system that has this controller. After applying latest msk(4)/mii(4) in HEAD I was not able to reproduce the issue on Yukon Ultra controller. So would you try latest msk(4)/mii(4) in HEAD? Just copying the related files in HEAD(msk(4) files in /usr/src/sys/dev/msk directory and mii(4) files in /usr/src/sys/dev/mii directory) and rebuild your kernel. From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 22:49:18 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 D621A106566B for ; Wed, 30 Dec 2009 22:49:18 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 996648FC15 for ; Wed, 30 Dec 2009 22:49:18 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 021FB7310A; Wed, 30 Dec 2009 23:57:06 +0100 (CET) Date: Wed, 30 Dec 2009 23:57:05 +0100 From: Luigi Rizzo To: Julian Elischer Message-ID: <20091230225705.GC64766@onelab2.iet.unipi.it> References: <20091230002447.GA55727@onelab2.iet.unipi.it> <4B3AA290.8000508@elischer.org> <20091230221119.L81420@sola.nimnet.asn.au> <4B3BC659.7010707@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B3BC659.7010707@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: Ian Smith , net@freebsd.org Subject: Re: RFC: documented and actual behaviour of "ipfw tee" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 22:49:19 -0000 On Wed, Dec 30, 2009 at 01:30:01PM -0800, Julian Elischer wrote: > Ian Smith wrote: > >On Tue, 29 Dec 2009, Julian Elischer wrote: > > > Luigi Rizzo wrote: > > > > There a difference between the documented and actual behaviour of > > > > "ipfw tee" which occurs when there are multiple rules with the same > > > > number, e.g. > > > > > > > > rule_id number body > > > > r1 500 tee port1 dst-ip 1.2.3.0/24 > > > > r2 500 tee port2 dst-ip 1.2.4.0/24 > > > > r3 500 accept ip from any to any > > > > r4 510 count ip from any to any > > > > > > > > + the manpage says "processing continues with the NEXT RULE" > > > > (so after r1 we have r2, then r3, ...); > > > > + the implementation behaves as "processing continues with the > > > > NEXT NUMBERED RULE" (ie. after 500 continues with 510). > > > > > > > > > > TEE should go to the next RULE with the original packet, but if > > > you reinject the tee'd copy of the packet it should go to the > > > next rule NUMBER. > > > >Which is what happens now, right? Same behaviour on tee reinjection as > >divert does seem consistent. So if there is a problem, it's only with > >the original packet continuing with the next rule if same-numbered? > > from Luigi's description I'm not sure what happens now.. :-) fair enough, let me explain again: A. with "divert" the packet is passed to the divert socket, and when/if reinjected processing continues no earlier than the the NEXT NUMBERED rule. This is a restriction due to the current divert socket API that I have no intention to change. B. with "tee", the copy of the packet that goes to the socket behaves the same as above. The original, which remains in the kernel, continues processing from the NEXT NUMBERED RULE. C. with "netgraph", the packet is passed to the netgraph node, and when/if reinjected processing continues with the NEXT RULE. This is different from #A D. with "ngtee", the copy of the packet that goes to the netgraph node behaves as in #C. The original packet, continues processing with the NEXT RULE (again, different from "tee" processing in #B) E. For the records, packets going through dummynet and reinjected because net.inet.ip.fw.one_pass=0, continue from the NEXT RULE. I think there is some agreement that "tee" and "ngtee" should do the same thing for the original packet (the one that continues processing), and i believe the correct approach is #D (i.e. continue from the NEXT RULE). The point of my original question was to correct what is done in case #B above. I am less clear on what to do for the packets passed to the divert socket or netgraph node (cases #A and #B above), but i would vote for keeping things unchanged because it is the best we can do. (Ideally, I think that all forms of diversion should continue by default from the NEXT RULE -- this is what currently happens with netgraph #B and dummynet #E. But we cannot change "divert" #A because of API limitations, and I think we cannot change dummynet #E to continue with the next numbered rule because it breaks existing configurations. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 23:55:09 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 B3D8510656AA for ; Wed, 30 Dec 2009 23:55:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 00A638FC2B for ; Wed, 30 Dec 2009 23:55:08 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 652192DA6E; Wed, 30 Dec 2009 15:55:10 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 1B18A2D6013; Wed, 30 Dec 2009 15:55:08 -0800 (PST) Message-ID: <4B3BE85B.6080309@elischer.org> Date: Wed, 30 Dec 2009 15:55:07 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Luigi Rizzo References: <20091230002447.GA55727@onelab2.iet.unipi.it> <4B3AA290.8000508@elischer.org> <20091230221119.L81420@sola.nimnet.asn.au> <4B3BC659.7010707@elischer.org> <20091230225705.GC64766@onelab2.iet.unipi.it> In-Reply-To: <20091230225705.GC64766@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian Smith , net@freebsd.org Subject: Re: RFC: documented and actual behaviour of "ipfw tee" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 23:55:09 -0000 Luigi Rizzo wrote: > On Wed, Dec 30, 2009 at 01:30:01PM -0800, Julian Elischer wrote: >> Ian Smith wrote: >>> On Tue, 29 Dec 2009, Julian Elischer wrote: >>>> Luigi Rizzo wrote: >>>>> There a difference between the documented and actual behaviour of >>>>> "ipfw tee" which occurs when there are multiple rules with the same >>>>> number, e.g. >>>>> >>>>> rule_id number body >>>>> r1 500 tee port1 dst-ip 1.2.3.0/24 >>>>> r2 500 tee port2 dst-ip 1.2.4.0/24 >>>>> r3 500 accept ip from any to any >>>>> r4 510 count ip from any to any >>>>> >>>>> + the manpage says "processing continues with the NEXT RULE" >>>>> (so after r1 we have r2, then r3, ...); >>>>> + the implementation behaves as "processing continues with the >>>>> NEXT NUMBERED RULE" (ie. after 500 continues with 510). >>>>> >>>> TEE should go to the next RULE with the original packet, but if >>>> you reinject the tee'd copy of the packet it should go to the >>>> next rule NUMBER. >>> Which is what happens now, right? Same behaviour on tee reinjection as >>> divert does seem consistent. So if there is a problem, it's only with >>> the original packet continuing with the next rule if same-numbered? >> from Luigi's description I'm not sure what happens now.. :-) > > fair enough, let me explain again: > A. with "divert" the packet is passed to the divert > socket, and when/if reinjected processing continues no earlier > than the the NEXT NUMBERED rule. This is a restriction due to the > current divert socket API that I have no intention to change. > > B. with "tee", the copy of the packet that goes to the socket > behaves the same as above. The original, which remains in > the kernel, continues processing from the NEXT NUMBERED RULE. This is unexpected. It should continue at the next rule are you sure? > > C. with "netgraph", the packet is passed to the netgraph node, > and when/if reinjected processing continues with the NEXT RULE. > This is different from #A AHHHHH now I understand. to me this does make some sense. Think of the RULE as a netgraph node. it has a hook to the outside netgraph graph through which packets may come and go. they are coming to that RULE and the only place they can go thereafter is the next rule. (I have not looked at the code nor have I ever used a netgraph rule in ipfw, I didn't write it but I can see how this may come about.) (goes off to read netgraph/ipfw interface code) > > D. with "ngtee", the copy of the packet that goes to the netgraph > node behaves as in #C. The original packet, continues processing > with the NEXT RULE (again, different from "tee" processing in #B) This I would expect > > E. For the records, packets going through dummynet and reinjected > because net.inet.ip.fw.one_pass=0, continue from the NEXT RULE. what if someone rewrites the firewall while they are 'away'? > > I think there is some agreement that "tee" and "ngtee" should do > the same thing for the original packet (the one that continues > processing), and i believe the correct approach is #D (i.e. continue > from the NEXT RULE). The point of my original question was to correct > what is done in case #B above. > > I am less clear on what to do for the packets passed to the divert > socket or netgraph node (cases #A and #B above), but i would vote > for keeping things unchanged because it is the best we can do. > (Ideally, I think that all forms of > diversion should continue by default from the NEXT RULE -- this is > what currently happens with netgraph #B and dummynet #E. > But we cannot change "divert" #A because of API limitations, > and I think we cannot change dummynet #E to continue with the next > numbered rule because it breaks existing configurations. the golden standard is ot continue at the next rule, but in divert's case the best it can do is the next "identifiable" rule. The design goal on divert sockets was that if the application gets a sockaddr from a divert socket and use it unchanged to pass the packet back it will do as close to the right thing as possible. The sockaddr gives you the rule number that sent the packet to you. sending hte packet back to THAT number would casue a loop, so the best we can do is the NEXT number, (whatever that is). the problem comes because numbers may not be unique, but I had to "live with that" as we have no other way to identify a rule from user land. > > cheers > luigi From owner-freebsd-net@FreeBSD.ORG Thu Dec 31 00:28:30 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 6C597106568D for ; Thu, 31 Dec 2009 00:28:30 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 07D798FC08 for ; Thu, 31 Dec 2009 00:28:29 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3A2677310A; Thu, 31 Dec 2009 01:36:16 +0100 (CET) Date: Thu, 31 Dec 2009 01:36:16 +0100 From: Luigi Rizzo To: Julian Elischer Message-ID: <20091231003616.GA73067@onelab2.iet.unipi.it> References: <20091230002447.GA55727@onelab2.iet.unipi.it> <4B3AA290.8000508@elischer.org> <20091230221119.L81420@sola.nimnet.asn.au> <4B3BC659.7010707@elischer.org> <20091230225705.GC64766@onelab2.iet.unipi.it> <4B3BE85B.6080309@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B3BE85B.6080309@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: Ian Smith , net@freebsd.org Subject: Re: RFC: documented and actual behaviour of "ipfw tee" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 00:28:30 -0000 On Wed, Dec 30, 2009 at 03:55:07PM -0800, Julian Elischer wrote: > Luigi Rizzo wrote: ... > >>>Which is what happens now, right? Same behaviour on tee reinjection as > >>>divert does seem consistent. So if there is a problem, it's only with > >>>the original packet continuing with the next rule if same-numbered? > >>from Luigi's description I'm not sure what happens now.. :-) > > > >fair enough, let me explain again: > >A. with "divert" the packet is passed to the divert > > socket, and when/if reinjected processing continues no earlier > > than the the NEXT NUMBERED rule. This is a restriction due to the > > current divert socket API that I have no intention to change. > > > >B. with "tee", the copy of the packet that goes to the socket > > behaves the same as above. The original, which remains in > > the kernel, continues processing from the NEXT NUMBERED RULE. > > This is unexpected. It should continue at the next rule > are you sure? yes. this happens because the original has the same mtag as the reinjected 'diverted' packet. I can fix it easily now that we have rule_id. In the past it cold be fixed too, but needed more restructuring of code. ... > > > >E. For the records, packets going through dummynet and reinjected > > because net.inet.ip.fw.one_pass=0, continue from the NEXT RULE. > > what if someone rewrites the firewall while they are 'away'? this is dealt as an exception, in different ways: - In RELENG-7, the mtag contains a pointer to the continuation rule. If the firewall is modified (with an ipfw delete) all pointers are cleared and the packet goes to the default rule. BTW i think packets in netgraph nodes are not protected by this and we might dereference an invalid pointer. - in RELENG_8, with the rule_id feature, we track exactly the matching rule, so if that rule is still existing we can locate it, and continue from the next one (at the time of the reinjection). If the original matching rule disappears, then we jump to the default rule; - in HEAD, with the recent changes i made, rule identifiers are ordered (rulenum:rule_id) so even if the original matching rule disappears i can still locate the next one, and dont need to use the default rule. cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu Dec 31 00:38:52 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 6EF2F106568B for ; Thu, 31 Dec 2009 00:38:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outq.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 53F9A8FC16 for ; Thu, 31 Dec 2009 00:38:52 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A9008B3E6; Wed, 30 Dec 2009 16:39:43 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 8DE502D6013; Wed, 30 Dec 2009 16:38:51 -0800 (PST) Message-ID: <4B3BF29B.2040607@elischer.org> Date: Wed, 30 Dec 2009 16:38:51 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Luigi Rizzo References: <20091230002447.GA55727@onelab2.iet.unipi.it> <4B3AA290.8000508@elischer.org> <20091230221119.L81420@sola.nimnet.asn.au> <4B3BC659.7010707@elischer.org> <20091230225705.GC64766@onelab2.iet.unipi.it> <4B3BE85B.6080309@elischer.org> <20091231003616.GA73067@onelab2.iet.unipi.it> In-Reply-To: <20091231003616.GA73067@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian Smith , net@freebsd.org Subject: Re: RFC: documented and actual behaviour of "ipfw tee" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 00:38:52 -0000 Luigi Rizzo wrote: > On Wed, Dec 30, 2009 at 03:55:07PM -0800, Julian Elischer wrote: >> Luigi Rizzo wrote: > ... >>>>> Which is what happens now, right? Same behaviour on tee reinjection as >>>>> divert does seem consistent. So if there is a problem, it's only with >>>>> the original packet continuing with the next rule if same-numbered? >>> >from Luigi's description I'm not sure what happens now.. :-) >>> >>> fair enough, let me explain again: >>> A. with "divert" the packet is passed to the divert >>> socket, and when/if reinjected processing continues no earlier >>> than the the NEXT NUMBERED rule. This is a restriction due to the >>> current divert socket API that I have no intention to change. >>> >>> B. with "tee", the copy of the packet that goes to the socket >>> behaves the same as above. The original, which remains in >>> the kernel, continues processing from the NEXT NUMBERED RULE. >> This is unexpected. It should continue at the next rule >> are you sure? > > yes. this happens because the original has the same mtag as the > reinjected 'diverted' packet. I can fix it easily now that we > have rule_id. In the past it cold be fixed too, but needed more > restructuring of code. I had code somewhere where tee didn't leave firewall, but just sent the other packet out, so it could just continue on. at Ironport I had to hack on divert/tee a bit to make it work well with L2 packets. so that got rewritten a bit. > > From owner-freebsd-net@FreeBSD.ORG Thu Dec 31 05:04: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 DF85E1065672 for ; Thu, 31 Dec 2009 05:04:05 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id BB84E8FC21 for ; Thu, 31 Dec 2009 05:04:05 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id nBV4ptID084468 for ; Wed, 30 Dec 2009 20:51:55 -0800 (PST) (envelope-from mahan@mahan.org) Message-ID: <4B3C2CC1.9070308@mahan.org> Date: Wed, 30 Dec 2009 20:46:57 -0800 From: Patrick Mahan User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Any plans to upgrade the tftp client and server images for FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 05:04:06 -0000 Not sure if this is the correct list, but I am working as part of a kernel team that is using FreeBSD 8.0 for it's base OS. We have had a ongoing issue with our bootloader (u-boot) with it being unable to tftp from the tftp server running on our FreeBSD server. We traced the issue down to the tftp code in u-boot was using the 'blksize' option and was not handling the option nak correctly. Since we didn't want to have to require a change in the bootloader, it was instead decided to fix the tftp server to support RFC 2348. After looking around the internet, we found that the tftp server under NetBSD did support RFC 2348. This made it an easy port, one line change to the usr.bin/tftp/Makefile and a slight change to libexec/tftpd.c (changed the name of an internal function from 'sendfile' back to 'xmitfile'). It has been working just fine for us. So I have been tasked with asking if the FreeBSD developers would like this code for future inclusion (or one of the current developers could just grab it from NetBSD). Reading the website it seems to contribute we need to be running -CURRENT which is not currently possible (other reasons we are using 8.0. This is actually a recent upgrade as we were previously using FreeBSD 6.2). So if this is something that could be useful, I have the code and a patch to modify the original NetBSD code to contribute. Also, if it is already done, then I was not able to view it (I tried the CVS and SVN web source browser and did not see any changes related to adding RFC 2348 support. Thanks for listening, Patrick From owner-freebsd-net@FreeBSD.ORG Thu Dec 31 15:37: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 ACDC2106566C for ; Thu, 31 Dec 2009 15:37:14 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 488B98FC1B for ; Thu, 31 Dec 2009 15:37:13 +0000 (UTC) Received: by ewy26 with SMTP id 26so10455714ewy.3 for ; Thu, 31 Dec 2009 07:37:08 -0800 (PST) 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=m4AxMpx0C5f9Tiee563JR51hoxacjUNs9++dGRe5Dls=; b=dm9qXZqFLNthA2/Rbe+KoiYJwAxhLW8atqE1tcd4+d+DWtK4UagPHKVBS86kPNulqj Tzo7LjGnqy16i3p282lp56dRXRl8iFO3pc/BbhhI0JINzN9TxFlurX4eCkkm2C1ukvqN 1rYpd/NXYxTXm4HuMF4bYr0MOOkc/O5Bs891E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=aT2mtfn6AGmRQbZu1mdXe/gutYNRgR1mCH0mr8KLBwl7lGGj0PAmghe11rpTZbGeP2 +OPex8qS5B5yJwhG5F0+z/pAVb5dwKDHXz94b9HYmyaVP6bDMiwI7P0DhaZFXj0MDBX8 XlIJsG053Sk9j3D4WFpCSNFSeRagkEcLwb9so= MIME-Version: 1.0 Received: by 10.213.2.70 with SMTP id 6mr12834957ebi.30.1262273827607; Thu, 31 Dec 2009 07:37:07 -0800 (PST) Date: Thu, 31 Dec 2009 16:37:07 +0100 Message-ID: <3a142e750912310737y46a4760emd4235f1e133a42e0@mail.gmail.com> From: Paul B Mahol To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ndis: missing media status reporting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 15:37:14 -0000 Hi, if_ndis.c doesnt update link speed when associated. Patch is available here: misc/142197: ndis is missing media status reporting http://www.freebsd.org/cgi/query-pr.cgi?pr=142197 -- Paul B Mahol From owner-freebsd-net@FreeBSD.ORG Thu Dec 31 15:48:37 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 992ED106566B for ; Thu, 31 Dec 2009 15:48:37 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 280848FC14 for ; Thu, 31 Dec 2009 15:48:36 +0000 (UTC) Received: by fxm27 with SMTP id 27so12246948fxm.3 for ; Thu, 31 Dec 2009 07:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=79R8ca4dKKkdfEgRN8yQMajgDwWrI2JMW/tY6iwxZEE=; b=u4KuQiyCqmFUKxCPAGSzetdOEVZmm8wQt0yTm1ZA6ko/BuzTEo4Mm4NnyCsPZK9gSf 7lIEDpfTtibPdOfJlzGwHpqScDP/+nbFf6eq18kssIwCAWVqYspuq70h3DZy82r8UqZ8 08t4IMCp5Aulf3CInbmwkl4qr73XsnqEbF46g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Or2gCZlkSfllL3x0zbKgaOcjOUxdyAiAXHc42P1gSW2QbOp3ss6IJnN4zvhQQIv8Wl gICvF5dHSDzA+eTdvMp+/mPmKmpXMMErrNMUJRW6RwBGTdk2ZLNSii6mXl8b3Wuo7mHZ dfEonA/oyiVLqQ8zlP0ZzmU5YctP1WyLLVHBA= Received: by 10.223.25.27 with SMTP id x27mr14437728fab.7.1262274509395; Thu, 31 Dec 2009 07:48:29 -0800 (PST) Received: from ?10.0.10.2? (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 14sm4956371fxm.7.2009.12.31.07.48.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 31 Dec 2009 07:48:28 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4B3C2CC1.9070308@mahan.org> Date: Thu, 31 Dec 2009 15:48:26 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2C4E1C7D-90CF-4D0D-9B86-668ACB516299@freebsd.org> References: <4B3C2CC1.9070308@mahan.org> To: Patrick Mahan X-Mailer: Apple Mail (2.1077) Cc: freebsd-net@freebsd.org Subject: Re: Any plans to upgrade the tftp client and server images for FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 15:48:37 -0000 hi, On 31 Dec 2009, at 04:46, Patrick Mahan wrote: > Not sure if this is the correct list, but I am working as part of > a kernel team that is using FreeBSD 8.0 for it's base OS. >=20 > We have had a ongoing issue with our bootloader (u-boot) with it > being unable to tftp from the tftp server running on our FreeBSD > server. We traced the issue down to the tftp code in u-boot was > using the 'blksize' option and was not handling the option nak > correctly. Since we didn't want to have to require a change in > the bootloader, it was instead decided to fix the tftp server to > support RFC 2348. After looking around the internet, we found that > the tftp server under NetBSD did support RFC 2348. This made it > an easy port, one line change to the usr.bin/tftp/Makefile and a > slight change to libexec/tftpd.c (changed the name of an internal > function from 'sendfile' back to 'xmitfile'). It has been working > just fine for us. >=20 > So I have been tasked with asking if the FreeBSD developers would > like this code for future inclusion (or one of the current developers > could just grab it from NetBSD). Yes. >=20 > Reading the website it seems to contribute we need to be running = -CURRENT > which is not currently possible (other reasons we are using 8.0. This > is actually a recent upgrade as we were previously using FreeBSD 6.2). >=20 > So if this is something that could be useful, I have the code and a = patch > to modify the original NetBSD code to contribute. >=20 > Also, if it is already done, then I was not able to view it (I tried = the CVS and > SVN web source browser and did not see any changes related to adding = RFC 2348 > support. The tftp server on 8.0 is the same as on 9.0. Can you send a patch? Thanks, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Thu Dec 31 16:49:41 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 4600E10656BC; Thu, 31 Dec 2009 16:49:41 +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 1D3538FC17; Thu, 31 Dec 2009 16:49:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBVGnfKf069674; Thu, 31 Dec 2009 16:49:41 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBVGnek4069670; Thu, 31 Dec 2009 16:49:40 GMT (envelope-from linimon) Date: Thu, 31 Dec 2009 16:49:40 GMT Message-Id: <200912311649.nBVGnek4069670@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/142197: [ndis] [patch] ndis is missing media status reporting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 16:49:41 -0000 Old Synopsis: ndis is missing media status reporting New Synopsis: [ndis] [patch] ndis is missing media status reporting Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Dec 31 16:49:09 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=142197 From owner-freebsd-net@FreeBSD.ORG Thu Dec 31 17:07:12 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 4F6C01065676 for ; Thu, 31 Dec 2009 17:07:12 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 121F38FC17 for ; Thu, 31 Dec 2009 17:07:12 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D3E087310D; Thu, 31 Dec 2009 18:15:00 +0100 (CET) Date: Thu, 31 Dec 2009 18:15:00 +0100 From: Luigi Rizzo To: Julian Elischer Message-ID: <20091231171500.GA82767@onelab2.iet.unipi.it> References: <20091230002447.GA55727@onelab2.iet.unipi.it> <4B3AA290.8000508@elischer.org> <20091230221119.L81420@sola.nimnet.asn.au> <4B3BC659.7010707@elischer.org> <20091230225705.GC64766@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091230225705.GC64766@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i Cc: Ian Smith , net@freebsd.org Subject: Re: RFC: documented and actual behaviour of "ipfw tee" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 17:07:12 -0000 On Wed, Dec 30, 2009 at 11:57:05PM +0100, Luigi Rizzo wrote: > On Wed, Dec 30, 2009 at 01:30:01PM -0800, Julian Elischer wrote: > > Ian Smith wrote: > > >On Tue, 29 Dec 2009, Julian Elischer wrote: > > > > Luigi Rizzo wrote: > > > > > There a difference between the documented and actual behaviour of > > > > > "ipfw tee" which occurs when there are multiple rules with the same > > > > > number, e.g. > > > > > > > > > > rule_id number body > > > > > r1 500 tee port1 dst-ip 1.2.3.0/24 > > > > > r2 500 tee port2 dst-ip 1.2.4.0/24 > > > > > r3 500 accept ip from any to any > > > > > r4 510 count ip from any to any > > > > > > > > > > + the manpage says "processing continues with the NEXT RULE" > > > > > (so after r1 we have r2, then r3, ...); > > > > > + the implementation behaves as "processing continues with the > > > > > NEXT NUMBERED RULE" (ie. after 500 continues with 510). > > > > > > > > > > > > > TEE should go to the next RULE with the original packet, but if > > > > you reinject the tee'd copy of the packet it should go to the > > > > next rule NUMBER. > > > > > >Which is what happens now, right? Same behaviour on tee reinjection as > > >divert does seem consistent. So if there is a problem, it's only with > > >the original packet continuing with the next rule if same-numbered? > > > > from Luigi's description I'm not sure what happens now.. :-) > > fair enough, let me explain again: > A. with "divert" the packet is passed to the divert > socket, and when/if reinjected processing continues no earlier > than the the NEXT NUMBERED rule. This is a restriction due to the > current divert socket API that I have no intention to change. > > B. with "tee", the copy of the packet that goes to the socket > behaves the same as above. The original, which remains in > the kernel, continues processing from the NEXT NUMBERED RULE. > > C. with "netgraph", the packet is passed to the netgraph node, > and when/if reinjected processing continues with the NEXT RULE. > This is different from #A > > D. with "ngtee", the copy of the packet that goes to the netgraph > node behaves as in #C. The original packet, continues processing > with the NEXT RULE (again, different from "tee" processing in #B) Upon inspection, it seems that ngtee is different from what I said above. The comment in ng_ipfw_input() says /* * We have two modes: in normal mode we add a tag to packet, which is * important to return packet back to IP stack. In tee mode we make * a copy of a packet and forward it into netgraph without a tag. */ which means that with ngtee, the copy that goes to netgraph is untagged, so i totally fail to understand what is the expected usage model. cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu Dec 31 20:02:49 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 158BD106566B; Thu, 31 Dec 2009 20:02:49 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-pz0-f185.google.com (mail-pz0-f185.google.com [209.85.222.185]) by mx1.freebsd.org (Postfix) with ESMTP id D02398FC12; Thu, 31 Dec 2009 20:02:48 +0000 (UTC) Received: by pzk15 with SMTP id 15so9018203pzk.3 for ; Thu, 31 Dec 2009 12:02:46 -0800 (PST) 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=n1u8ukRMEDpNy0diiDvz+frXPCw8p84Ph0BZOiFRxrQ=; b=olTJRwCqPOgrAfx+2MVeCu0K78EblPQxGUS36Z4KOKy+KzwTJVvdeliwZnqGbAVq/5 xYCBo3dnD2f5I/gvc3qBvYJZjlij0D8ei1hivItsjk1i955RyWpujVYtvAhx0YpZhkob kSjK5FAdWIGBtCfnlOnyIC+ZxR5OyEB+rRoX8= 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=Nd8Ui97ahLig69/rPYuECre4x7t+659nLw7Yx49IcYccINH+yKZ8rdZgPzuV6QDuha u/cy9btKUKaW8JI7njzms/A8n02O+uBmW7LXtHuLbFx52VpiswuvTgXd8vQmdYt8kr+t JyyHCN9F1TMAYqEmuZ8wKW43sKLPPRBOGwSJQ= MIME-Version: 1.0 Received: by 10.114.4.17 with SMTP id 17mr10797834wad.35.1262289765859; Thu, 31 Dec 2009 12:02:45 -0800 (PST) In-Reply-To: <2C4E1C7D-90CF-4D0D-9B86-668ACB516299@freebsd.org> References: <4B3C2CC1.9070308@mahan.org> <2C4E1C7D-90CF-4D0D-9B86-668ACB516299@freebsd.org> Date: Thu, 31 Dec 2009 12:02:45 -0800 Message-ID: From: Xin LI To: Rui Paulo Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org, Edwin Groothuis , Patrick Mahan Subject: Re: Any plans to upgrade the tftp client and server images for FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 20:02:49 -0000 Hi, On Thu, Dec 31, 2009 at 7:48 AM, Rui Paulo wrote: >> Also, if it is already done, then I was not able to view it (I tried the CVS and >> SVN web source browser and did not see any changes related to adding RFC 2348 >> support. > > The tftp server on 8.0 is the same as on 9.0. Can you send a patch? I think edwin@ (cc'ed) worked on TFTP and have a patch to implement it, he just didn't committed against -HEAD for some reason (?) Cheers, -- Xin LI http://www.delphij.net From owner-freebsd-net@FreeBSD.ORG Thu Dec 31 20:10: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 70872106566C for ; Thu, 31 Dec 2009 20:10:03 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id EDF338FC19 for ; Thu, 31 Dec 2009 20:09:33 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id C7D40A5E600; Fri, 1 Jan 2010 04:09:25 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id T1tFNqyFbpAI; Fri, 1 Jan 2010 04:08:47 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id B3E16A5639A; Fri, 1 Jan 2010 04:08:44 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=nidBqr3kWanlLz0qbkeKEFU7HMS56Tp6Ram6ynfhhUpfb+wSTJyA/C1WJBmnjxuYe 6k5J/DNXKsmkUF+6+CMMw== Message-ID: <4B3D04BB.503@delphij.net> Date: Thu, 31 Dec 2009 12:08:27 -0800 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20091220 Thunderbird/3.0 ThunderBrowse/3.2.6.8 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4B3C2CC1.9070308@mahan.org> <2C4E1C7D-90CF-4D0D-9B86-668ACB516299@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Any plans to upgrade the tftp client and server images for FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 20:10:03 -0000 On 2009/12/31 12:02, Xin LI wrote: > Hi, > > On Thu, Dec 31, 2009 at 7:48 AM, Rui Paulo wrote: >>> Also, if it is already done, then I was not able to view it (I tried the CVS and >>> SVN web source browser and did not see any changes related to adding RFC 2348 >>> support. >> >> The tftp server on 8.0 is the same as on 9.0. Can you send a patch? > > I think edwin@ (cc'ed) worked on TFTP and have a patch to implement > it, he just didn't committed against -HEAD for some reason (?) Oh and it's available in ports at net/freebsd-tftp. Cheers, -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die