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 hy...@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 <pluk...@gmail.com>:"
--------------------------------------------------------------------
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=40+8+8 bytes) 2001:99::1 --> 2001:98::1
16 bytes from 2001:98::1, icmp_seq=0 hlim=64 time=0.700 ms
16 bytes from 2001:98::1, icmp_seq=1 hlim=64 time=0.683 ms
16 bytes from 2001:98::1, icmp_seq=2 hlim=64 time=0.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 = 0.665/0.683/0.700/0.014 ms
h99# ifconfig gif0 mtu 1400
h99# ifconfig
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9<RXCSUM,VLAN_MTU>
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=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=2009<RXCSUM,VLAN_MTU,WOL_MAGIC>
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 autoconf
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> 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=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
options=1<ACCEPT_REV_ETHIP_VER>
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=8051<UP,POINTOPOINT,RUNNING,MULTICAST> 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=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
options=1<ACCEPT_REV_ETHIP_VER>
h99# ping6 -D -s 1340 2001:98::1
PING6(1388=40+8+1340 bytes) 2001:99::1 --> 2001:98::1
1348 bytes from 2001:98::1, icmp_seq=0 hlim=64 time=1.392 ms
1348 bytes from 2001:98::1, icmp_seq=1 hlim=64 time=1.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 = 1.297/1.345/1.392/0.047 ms
h99# ping6 -D -s 1360 2001:98::1
PING6(1408=40+8+1360 bytes) 2001:99::1 --> 2001:98::1
ping6: sendmsg: Message too long
ping6: wrote 2001:98::1 1368 chars, ret=-1
ping6: sendmsg: Message too long
ping6: wrote 2001:98::1 1368 chars, ret=-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=40+8+1360 bytes) 2001:99::1 --> 2001:98::1
1368 bytes from 2001:98::1, icmp_seq=0 hlim=64 time=1.414 ms
1368 bytes from 2001:98::1, icmp_seq=1 hlim=64 time=1.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 = 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=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1440
inet6 fe80::204:75ff:fe85:73e8%gif0 prefixlen 64 scopeid 0x4
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
options=1<ACCEPT_REV_ETHIP_VER>
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=8051<UP,POINTOPOINT,RUNNING,MULTICAST> 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=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
options=1<ACCEPT_REV_ETHIP_VER>
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=40+8+1360 bytes) 2001:99::1 --> 2001:98::1
1368 bytes from 2001:98::1, icmp_seq=0 hlim=64 time=1.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 = 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 <sys/param.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <net/if.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <err.h>
#include <errno.h>
#include <ifaddrs.h>
char *send_addr="2003:98::2";
char *send_port="18000";
char *recv_addr="2001:99::1";
char *recv_port="16000";
int send_s;
int only_out=0;
int only_in=0;
int out_packet_size;
struct addrinfo *send_res;
main(ac,av)
int ac;
char **av;
{
int c;
while ((c = getopt(ac, av, "s:oi")) != -1) {
switch (c) {
case 'o':
only_out++;
break;
case 'i':
only_in++;
break;
case 's':
out_packet_size = atoi(optarg);
break;
default:
Usage();
exit (1);
}
}
if( only_in && only_out ){
Usage();
exit (1);
}
if( only_in == 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 = PF_UNSPEC;
hints.ai_socktype = SOCK_DGRAM;
error = getaddrinfo(send_addr, send_port, &hints, &send_res);
if (error != 0) errx(1, "%s", gai_strerror(error));
send_res->ai_family = AF_INET6;
send_s = 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=0; i<2000 ; i++ ){
buf[i]='a';
}
if( 1501 > out_packet_size ){
cc = out_packet_size ;
}else{
cc = 1500;
}
printf("Let's send %d length packet to %s\n",cc,send_addr);
while(1){
len = sendto(send_s, buf, cc, 0, send_res->ai_addr, send_res->ai_addrlen);
sleep(1);
}
}
recv_v6_udp()
{
int recv_s;
struct addrinfo hints, *res;
int error;
int len,cc,ccout;
char buf[2000];
FILE *outfp=stdout;
int fromlen;
struct sockaddr_in6 from6;
memset(&hints, 0, sizeof(hints));
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_DGRAM;
error = getaddrinfo(recv_addr, recv_port, &hints, &res);
if (error != 0) errx(1, "%s", gai_strerror(error));
res->ai_family = AF_INET6;
recv_s = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
if (recv_s < 0) err(1, "socket");
while(1){
cc = recvfrom(recv_s, (void *)buf, sizeof(buf), 0,
(struct sockaddr *)&from6, &fromlen);
if (cc < 0) {
warn("recvfrom");
continue;
}
if ( only_in == 0 ){
len = sendto(send_s, buf, cc, 0, send_res->ai_addr,
send_res->ai_addrlen);
} else {
if ((ccout = fwrite(buf, cc, 1, outfp)) < 1)
close(recv_s);
}
}
}
-------------------------------------------------
2009/12/27 Julian Elischer <jul...@elischer.org>:
> Hideki Yamamoto wrote:
>>
>> Hi,
>>
>> I often use FreeBSD for developing the gateway. For example, I use gif for
>> the
>> tunnel protocol when using IPv6 over IPv4 and use an application for
>> changing
>> packet address for special purpose. When we were using old FreeBSD, such
>> 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. However
>> 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.
>>
>> net.inet6.use_mmtu :1 --- is the same as current versions, it means
>> minimum MTU 1280
>> will be used when gateway node.
>> :0--- is the same as the
>> old versions. It means
>> OS uses
>> as long MTU size as possible
>> ( 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-unsubscr...@freebsd.org"
>
>
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
