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" > >