Results 1 to 2 of 2
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- May 2012
delivering a packet through tun file descriptor leads to different res
openvpn --mktun --dev tun2 ip link set tun2 up ip addr add 10.0.0.1/24 dev tun2
my program source code:
I run the program `tun` by
./tun -i tun2
I capture it via tcpdump, the pcap file is:
there is no ICMP echo reply
Then I run a [simpletun][http://www.cis.syr.edu/~wedu/seed/La...es/simpletun.c on two machines, it works fine, and the pcap file is
in the two pcap files, the two ping packets are the same, but my program doesn't trigger a ping echo reply
it is strange, the principles of my program and `simpletun` are the same, they both write a ping packet to the `fd`, and the ping packets are the same, why my program doesn't get a echo reply while `simpletun` gets?
the output of ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 00:24:d7:78:71:38 brd ff:ff:ff:ff:ff:ff 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 5c:26:0a:2b:b8:06 brd ff:ff:ff:ff:ff:ff inet 188.8.131.52/20 brd 184.108.40.206 scope global eth0 inet6 fe80::5e26:aff:fe2b:b806/64 scope link valid_lft forever preferred_lft forever 7: tun2: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 100 link/none inet 10.0.0.1/24 scope global tun2
default via 220.127.116.11 dev eth0 proto static 10.0.0.0/24 dev tun2 proto kernel scope link src 10.0.0.1 18.104.22.168/20 dev eth0 proto kernel scope link src 22.214.171.124 metric 1
- Join Date
- Apr 2009
- I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
See my response to your other posting... And please don't do duplicate postings - edit or add to only one thread for the topic you are looking for help on.Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!