heyeshuang / tb-tun Goto Github PK

What steps will reproduce the problem?
1.

ICMP package on IPv4 should be reflected to the IPv6 according to RFC2893.
But TB-TUN has nothing to do with ICMP.

2.

According to RFC3506, "If the IPv6 MTU size proves to be too large for some
intermediate IPv4 subnet, IPv4 fragmentation will ensue....The IPv4 'do not
fragment' bit *SHOULD NOT* be set in the encapsulating IPv4 header." But
TB-TUN disobey these 2 rules. It causes IPv6 packages missing data and did
not report any error by ICMP when IPv6 MTU is to large.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

I was skimming through tb_userspace.c and noticed a lot of numeric constants 
with a hard-coded little-endian byte order.

For example, 0x0220 is used to match "2002", which will certainly fail on any 
big-endian architecture.  Instead, you should match against htons(0x2002).

This bug exists all throughout the code.

For a reference on network programming, see:
http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html

What steps will reproduce the problem?
1. Built tb_userspace (gcc tb_userspace.c -l pthread -o tb_userspace)
2. Try and configure a tunnel (setsid ./tb_userspace tb 5.6.7.8 1.2.3.4 sit > 
/dev/null)

What version of the product are you using? On what operating system?
tb-tun_r18.tar.gz 
2.6.26-2-openvz-amd64

Please provide any additional information below.
Worked fine, rebooted my container and it's no longer working :(

What steps will reproduce the problem?

Packages from one 6to4 network to another 6to4 network, e.g. from
2002:0102:0304:: to 2002:0506:0708:: are sent directly by relay server
1.2.3.4 to relay server 5.6.7.8, not by default gw 192.88.99.1. 

While when using as 6to4, TB-TUN wrongly restricted the source IPv4 address
to the default gw's(192.88.99.1) when receiving 6in4 packages. Causing
packages from other 6to4 networks to TB-TUN been dropped. 

What is the expected output? What do you see instead?

from 2002:xxxx:xxxx::xxxx:xxxx(Using linux tunnel) pinging
2002:yyyy:yyyy::yyyy:yyyy(Using TB-TUN)
Request timed out.


Please use labels and text to provide additional information.

According to RFC 3964, 6to4 routers and relays should ensure that:

    * either or both the source and destination addresses of any
encapsulated packet is within the 6to4 IPv6 prefix 2002::/16,
    * if the source IPv6 address is a 6to4 IPv6 address, its corresponding
6to4 router IPv4 address matches the IPv4 source address in the IPv4
encapsulation header,
    * similarly, if the destination IPv6 address is a 6to4 IPv6 address,
its corresponding 6to4 router IPv4 address matches the IPv4 destination
address in the IPv4 encapsulation header.

So address corresponding check should be added.

Tunnelbroker(Using TB-TUN with a specified relay server and static IPv6
address, such as tunnel porvided by http://tunnelbroker.net/) is not
affected by this bug. 

What steps will reproduce the problem?
1. Follow the instructions for tunnelbroker with Hurricane Electric
2. ping6 ipv6.google.com

What is the expected output? What do you see instead?
Expected: Able to ping Google over IPv6
Observed: Timeout

What version of the product are you using? On what operating system?
Linux 2.6.32-348.4.1.el5.028stab107.1 #1 SMP Wed Apr 17 19:37:50 MSD 2013 i686 
i686 i686 GNU/Linux

Please provide any additional information below.
The problem is that the instructions don't set a Gateway for the IPv6 device. 
The following command resolves the problem:

/sbin/route -A inet6 add ::/0 gw 2001:470:1f08:ec8::1 dev tb

where 2001:470:1f08:ec8::1 is the IPv6 gateway provided by Hurricane Electric.

What steps will reproduce the problem?
1. gcc -o tb_userspace.new -lpthread tb_userspace.c
2. it complains about missing defintion of ETH_P_IPV6
3.

What is the expected output? What do you see instead?
Expected compilation without warning and errors.
Complain about missing definition and wrong parameter type.

What version of the product are you using? On what operating system?
CentOS on burst.net VPS

Please provide any additional information below.

The patch attached include the linux/if_ether.h for this definition and a
type cast to remove a compiler warning when using a sockaddr_in in a
sockaddr parameter