Hello fellows 44 crew
I have a ping not returning syndrome from my 44 address via Internet.
From any ampr system ping to 44.153.0.1 are answered ok, but
from internet don't receive answer to pings sent to 44.153.0.1
To try thru Internet I use https://www.wormly.com/test_remote_ping setting 44.153.0.1 as destination for pings.
System is an ubuntu 10.03 and jnos2.0i, locally pings returns ok.
I made some traces that follows, some related autoexec.nos are at end.
Same symptom happens with several 44 systems, pings from Internet don't return. As pings don't return any other tcp function doesn't work either.
Any help/guidance/sugestion will be much appreciated.
Best 73, lu7abf, Pedro Converso
PD: Router: TL-MR3420 DMZ: 44.153.0.10 (IP of my jnos2)
================================================================
Trace of tun0 interfase made by jnos> trace tun0 211
Here can be seen that tun0 receives Echo request encapsulated thru amprgw and Reply with no encapsulation, which originating pinger doesn't receive
Mon May 19 16:36:37 2014 - tun0 recv: IP: len 104 169.228.66.251->44.153.0.1 ihl 20 ttl 39 prot IP IP: len 84 184.72.226.23->44.153.0.1 ihl 20 ttl 38 DF prot ICMP ICMP: type Echo Request id 58952 seq 1 0000 45 00 00 68 63 95 00 00 27 04 16 84 a9 e4 42 fb E..hc...'...)dB{ 0010 2c 99 00 01 45 00 00 54 33 75 40 00 26 01 5a 3a ,...E..T3u@.&.Z: 0020 b8 48 e2 17 2c 99 00 01 08 00 f1 bb e6 48 00 01 8Hb.,.....q;fH.. 0030 2e 5d 7a 53 00 00 00 00 ab 76 0d 00 00 00 00 00 .]zS....+v...... 0040 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ 0050 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./ 0060 30 31 32 33 34 35 36 37 01234567
Mon May 19 16:36:37 2014 - tun0 recv: IP: len 104 169.228.66.251->44.153.0.1 ihl 20 ttl 39 prot IP IP: len 84 184.72.226.23->44.153.0.1 ihl 20 ttl 38 DF prot ICMP ICMP: type Echo Request id 58952 seq 1 0000 45 00 00 68 63 95 00 00 27 04 16 84 a9 e4 42 fb E..hc...'...)dB{ 0010 2c 99 00 01 45 00 00 54 33 75 40 00 26 01 5a 3a ,...E..T3u@.&.Z: 0020 b8 48 e2 17 2c 99 00 01 08 00 f1 bb e6 48 00 01 8Hb.,.....q;fH.. 0030 2e 5d 7a 53 00 00 00 00 ab 76 0d 00 00 00 00 00 .]zS....+v...... 0040 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ 0050 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./ 0060 30 31 32 33 34 35 36 37 01234567
Mon May 19 16:36:37 2014 - tun0 sent: IP: len 84 44.153.0.1->184.72.226.23 ihl 20 ttl 175 prot ICMP ICMP: type Echo Reply id 58952 seq 1 0000 45 00 00 54 71 c7 00 00 af 01 d2 e7 2c 99 00 01 E..TqG../.Rg,... 0010 b8 48 e2 17 00 00 f9 bb e6 48 00 01 2e 5d 7a 53 8Hb...y;fH...]zS 0020 00 00 00 00 ab 76 0d 00 00 00 00 00 10 11 12 13 ....+v.......... 0030 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"# 0040 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123 0050 34 35 36 37 4567
=======================================================================
Trace of encap interfase made by jnos> trace encap 211
Here can be seen that encap interfase receives echo req but don't answer
Mon May 19 16:36:37 2014 - encap recv: IP: len 84 184.72.226.23->44.153.0.1 ihl 20 ttl 38 DF prot ICMP ICMP: type Echo Request id 58952 seq 1 0000 45 00 00 54 33 75 40 00 26 01 5a 3a b8 48 e2 17 E..T3u@.&.Z:8Hb. 0010 2c 99 00 01 08 00 f1 bb e6 48 00 01 2e 5d 7a 53 ,.....q;fH...]zS 0020 00 00 00 00 ab 76 0d 00 00 00 00 00 10 11 12 13 ....+v.......... 0030 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"# 0040 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123 0050 34 35 36 37 4567
Mon May 19 16:36:37 2014 - encap recv: IP: len 84 184.72.226.23->44.153.0.1 ihl 20 ttl 38 DF prot ICMP ICMP: type Echo Request id 58952 seq 2 0000 45 00 00 54 33 76 40 00 26 01 5a 39 b8 48 e2 17 E..T3v@.&.Z98Hb. 0010 2c 99 00 01 08 00 38 ce e6 48 00 02 2f 5d 7a 53 ,.....8NfH../]zS 0020 00 00 00 00 6f 63 01 00 00 00 00 00 10 11 12 13 ....oc.......... 0030 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"# 0040 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123 0050 34 35 36 37 4567
Mon May 19 16:36:37 2014 - encap recv: IP: len 84 184.72.226.23->44.153.0.1 ihl 20 ttl 38 DF prot ICMP ICMP: type Echo Request id 58952 seq 3 0000 45 00 00 54 33 77 40 00 26 01 5a 38 b8 48 e2 17 E..T3w@.&.Z88Hb. 0010 2c 99 00 01 08 00 c7 a0 e6 48 00 03 2f 5d 7a 53 ,.....G fH../]zS 0020 00 00 00 00 dd 8f 04 00 00 00 00 00 10 11 12 13 ....]........... 0030 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"# 0040 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123 0050 34 35 36 37 4567
=======================================================================
Related autoexec.nos commands to routes & interfaces
hostname lu7abf.ampr.org. ip address 44.153.0.1 ax25 mycall lu7abf attach tun tun0 1500 0 ifconfig tun0 ipaddress 44.153.0.10 ifconfig tun0 netmask 255.255.255.0 ifconfig tun0 mtu 1500 shell ifconfig tun0 44.153.0.3 pointopoint 44.153.0.10 mtu 1500 up shell route add 44.153.0.1 gw 44.153.0.3 tun0 shell sudo arp -sD 44.153.0.10 eth0 pub shell echo 0 > /proc/sys/net/ipv4/conf/tun0/rp_filter # disable arp_filter shell echo 1 > /proc/sys/net/ipv4/ip_forward # enable ip_forward shell iptables -t nat -A PREROUTING -d 44.153.0.10/32 --proto 4 -j DNAT --to 44.153.0.1 shell iptables -t nat -A PREROUTING -d 44.153.0.10/32 --proto 94 -j DNAT --to 44.153.0.1 shell iptables -t nat -A POSTROUTING -s 44.153.0.1/32 -o eth0 -p 4 shell iptables -t nat -A POSTROUTING -s 44.153.0.1/32 -o eth0 -p 94 shell sudo -s iptables -t nat -A PREROUTING -d 44.153.0.3/32 -p tcp --dport 23 -j DNAT --to 44.153.0.1:23 shell sudo -s iptables -t nat -A PREROUTING -d 44.153.0.3/32 -p tcp --dport 6300 -j DNAT --to 44.153.0.1:23 shell sudo -s iptables -t nat -A PREROUTING -d lu7abf.org.ar -p tcp --dport 6300 -j DNAT --to 44.153.0.1:23 shell sudo -s iptables -t nat -A POSTROUTING -s 44.153.0.1/32 -o eth0 -j MASQUERADE shell sudo -s iptables -t nat -A POSTROUTING -s 44.153.0.10/32 -o eth0 -j MASQUERADE ifconfig encap ip 44.153.0.1 ifconfig encap mtu 1500 ifconfig encap netmask 0xffffffff ifconfig encap broadcast 255.255.255.255 ifc encap descript "IPIP Encapulation interface" arp eaves tun0 on arp eaves encap on arp poll tun0 on arp poll encap on arp maxq 20 route addprivate default tun0 44.153.0.3 route add 44.153.0.1 tun0 44.153.0.10 route add 44.153.0.2 tun0 44.153.0.10 route add 44.153.0.3 tun0 44.153.0.10
========================================================
On 2014-05-19 23:26, Pedro Converso wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hello fellows 44 crew
I have a ping not returning syndrome from my 44 address via Internet.
From any ampr system ping to 44.153.0.1 are answered ok, but from internet don't receive answer to pings sent to 44.153.0.1
To try thru Internet I use https://www.wormly.com/test_remote_ping setting 44.153.0.1 as destination for pings.
System is an ubuntu 10.03 and jnos2.0i, locally pings returns ok.
I made some traces that follows, some related autoexec.nos are at end.
Your traces are tcpdumps; you might want to try traceroute (or tracepath when on Linux) instead.
[..]
Mon May 19 16:36:37 2014 - tun0 recv: IP: len 104 169.228.66.251->44.153.0.1 ihl 20 ttl 39 prot IP IP: len 84 184.72.226.23->44.153.0.1 ihl 20 ttl 38 DF prot ICMP ICMP: type Echo Request id 58952 seq 1
That is a IPv4-in-IPv4-ICMPv4 packet.
Mon May 19 16:36:37 2014 - tun0 sent: IP: len 84 44.153.0.1->184.72.226.23 ihl 20 ttl 175 prot ICMP ICMP: type Echo Reply id 58952 seq 1
That is a IPv4-ICMPv4 packet.
That should match the former, IPv4-IPv4-ICMPv4
ifconfig tun0 ipaddress 44.153.0.10 ifconfig tun0 netmask 255.255.255.0 ifconfig tun0 mtu 1500 shell ifconfig tun0 44.153.0.3 pointopoint 44.153.0.10 mtu 1500 up
Please note that you are mixing up typical 'tunX' usage. Typically 'tunX' is the tun/tap interface. The above makes this a IPv4-in-IPv4 tunnel.
Interresting that you see the encapsulated result on tun0 though, one would expect to see that on the underlying interface, not here.
That 1500 MTU is likely bad, unless you run jumboframes towards UCSD.
shell iptables -t nat -A PREROUTING -d 44.153.0.10/32 --proto 4 -j DNAT --to 44.153.0.1
This makes all packets going to 44.153.0.10 of type ipencap (IPv4-in-IPv4) be send to 44.153.0.1 instead of the real destination. Is that really what you want to do, and why?
shell iptables -t nat -A PREROUTING -d 44.153.0.10/32 --proto 94 -j DNAT --to 44.153.0.1
Same but for the 94 variant of IPv4-in-IPv4. (though in theory one is allowed to use any IP version inside of the other there)
Same Q: why do you do that?
shell iptables -t nat -A POSTROUTING -s 44.153.0.1/32 -o eth0 -p 4 shell iptables -t nat -A POSTROUTING -s 44.153.0.1/32 -o eth0 -p 94
Except for counting packets, these two rules have no effect.
shell sudo -s iptables -t nat -A PREROUTING -d 44.153.0.3/32 -p tcp --dport 23 -j DNAT --to 44.153.0.1:23
This causes everything towards .3 to go to .1
shell sudo -s iptables -t nat -A PREROUTING -d 44.153.0.3/32 -p tcp --dport 6300 -j DNAT --to 44.153.0.1:23
Same but redirecting port 6300.
shell sudo -s iptables -t nat -A PREROUTING -d lu7abf.org.ar -p tcp --dport 6300 -j DNAT --to 44.153.0.1:23
shell sudo -s iptables -t nat -A POSTROUTING -s 44.153.0.1/32 -o eth0 -j MASQUERADE shell sudo -s iptables -t nat -A POSTROUTING -s 44.153.0.10/32 -o eth0 -j MASQUERADE
This causes these two 44 net addresses to become NATted when they try and communicate to your local network.
As those addresses are local though, it is unlikely there are used to ever communicate with services living on eth0, unless you force programs to do so.
ifconfig encap ip 44.153.0.1 ifconfig encap mtu 1500 ifconfig encap netmask 0xffffffff ifconfig encap broadcast 255.255.255.255 ifc encap descript "IPIP Encapulation interface"
And here you configure a secondary encapsulation interface. Are you sure you need two?
Greets, Jeroen
Hi Jeroen,
Thanks! for taking care of my ping not responded situation.
Will try to comment on your answer.
You're right, the first trace on tun0 shows my 44 IP inside a packet sent by amprgw IP: len 104 169.228.66.251->44.153.0.1 ihl 20 ttl 39 prot IP IP: len 84 184.72.226.23->44.153.0.1 ihl 20 ttl 38 DF prot ICMP ICMP: type Echo Request id 58952 seq 1
Answer come back, but without being encaped IP: len 84 44.153.0.1->184.72.226.23 ihl 20 ttl 175 prot ICMP ICMP: type Echo Reply id 58952 seq 1
But this doesn't satisfy the original ping as is not acknowledged by https://www.wormly.com/test_remote_ping
I intend that tun0 interfase, defined both in jnos and in linux, act as link between the two systems, it does his work as all tcp sessions are working ok and encaped between my 44 system and other 44s and viceversa.
44.153.0.3 is Linux, 44.153.0.10 is jnos which has 44.153.0.1 address. Router gateway is 44.153.0.2, all this is tried to be related thru the commands both thru shell and inside jnos. I have only one ethernet card on the PC, so jnos doesn't have an ethernet interfase, and relies on this tun0 to comunicate to linux and to the internet.
Perhaps some of these commands are doing harm, and/or causing this strange no ping answer from no 44 systems, but I was not able to found which one. Commands I used are result of many test & try and result of many months of experimenting.
What wonder me is that many 44 systems (not only mine) are not reachable thru internet, but perfectly reachable encapsulating within 44 land.
I.E. try ping gb7cip.ampr.org , or ve3mch.ampr.org you won't reach via Internet, but if you ping from within a 44 systems will respond ok.
You can try telnet to lu7abf.org.ar where you get into my bbs and then ping above systems and see they do respond.
Note that you won't reach my system telneting to lu7abf.ampr.org as this ping not working is avoiding this.
I am more than willing to change wathever is suggested to try this work, so our 44 systems could be reachable.
Once more appreciate time and actual comments already given, I am looking deeply to see what to change.
Best 73, lu7abf, Pedro Converso
On Mon, May 19, 2014 at 6:48 PM, Jeroen Massar jeroen@massar.ch wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 2014-05-19 23:26, Pedro Converso wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hello fellows 44 crew
I have a ping not returning syndrome from my 44 address via Internet.
From any ampr system ping to 44.153.0.1 are answered ok, but from internet don't receive answer to pings sent to 44.153.0.1
To try thru Internet I use https://www.wormly.com/test_remote_ping setting 44.153.0.1 as destination for pings.
System is an ubuntu 10.03 and jnos2.0i, locally pings returns ok.
I made some traces that follows, some related autoexec.nos are at end.
Your traces are tcpdumps; you might want to try traceroute (or tracepath when on Linux) instead.
[..]
Mon May 19 16:36:37 2014 - tun0 recv: IP: len 104 169.228.66.251->44.153.0.1 ihl 20 ttl 39 prot IP IP: len 84 184.72.226.23->44.153.0.1 ihl 20 ttl 38 DF prot ICMP ICMP: type Echo Request id 58952 seq 1
That is a IPv4-in-IPv4-ICMPv4 packet.
Mon May 19 16:36:37 2014 - tun0 sent: IP: len 84 44.153.0.1->184.72.226.23 ihl 20 ttl 175 prot ICMP ICMP: type Echo Reply id 58952 seq 1
That is a IPv4-ICMPv4 packet.
That should match the former, IPv4-IPv4-ICMPv4
ifconfig tun0 ipaddress 44.153.0.10 ifconfig tun0 netmask 255.255.255.0 ifconfig tun0 mtu 1500 shell ifconfig tun0 44.153.0.3 pointopoint 44.153.0.10 mtu 1500 up
Please note that you are mixing up typical 'tunX' usage. Typically 'tunX' is the tun/tap interface. The above makes this a IPv4-in-IPv4 tunnel.
Interresting that you see the encapsulated result on tun0 though, one would expect to see that on the underlying interface, not here.
That 1500 MTU is likely bad, unless you run jumboframes towards UCSD.
shell iptables -t nat -A PREROUTING -d 44.153.0.10/32 --proto 4 -j DNAT --to 44.153.0.1
This makes all packets going to 44.153.0.10 of type ipencap (IPv4-in-IPv4) be send to 44.153.0.1 instead of the real destination. Is that really what you want to do, and why?
shell iptables -t nat -A PREROUTING -d 44.153.0.10/32 --proto 94 -j
DNAT
--to 44.153.0.1
Same but for the 94 variant of IPv4-in-IPv4. (though in theory one is allowed to use any IP version inside of the other there)
Same Q: why do you do that?
shell iptables -t nat -A POSTROUTING -s 44.153.0.1/32 -o eth0 -p 4 shell iptables -t nat -A POSTROUTING -s 44.153.0.1/32 -o eth0 -p 94
Except for counting packets, these two rules have no effect.
shell sudo -s iptables -t nat -A PREROUTING -d 44.153.0.3/32 -p tcp
--dport
23 -j DNAT --to 44.153.0.1:23
This causes everything towards .3 to go to .1
shell sudo -s iptables -t nat -A PREROUTING -d 44.153.0.3/32 -p tcp
--dport
6300 -j DNAT --to 44.153.0.1:23
Same but redirecting port 6300.
shell sudo -s iptables -t nat -A PREROUTING -d lu7abf.org.ar -p tcp
--dport
6300 -j DNAT --to 44.153.0.1:23
shell sudo -s iptables -t nat -A POSTROUTING -s 44.153.0.1/32 -o eth0 -j MASQUERADE shell sudo -s iptables -t nat -A POSTROUTING -s 44.153.0.10/32 -o eth0
-j
MASQUERADE
This causes these two 44 net addresses to become NATted when they try and communicate to your local network.
As those addresses are local though, it is unlikely there are used to ever communicate with services living on eth0, unless you force programs to do so.
ifconfig encap ip 44.153.0.1 ifconfig encap mtu 1500 ifconfig encap netmask 0xffffffff ifconfig encap broadcast 255.255.255.255 ifc encap descript "IPIP Encapulation interface"
And here you configure a secondary encapsulation interface. Are you sure you need two?
Greets, Jeroen
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-
Jeroen Massar -
Pedro Converso