Marc, LX1DUC,
Per Brian in a Jan 22 note:
44.0.0.1 responds to pings received from the Internet. It does not respond to pings coming into it over an encap connection to it, for some reason that I've not been able to figure out. I believe it to be a difficulty in getting it to recognize decapped pings.
If you are receiving the rip44 announcements, you have properly configured your tunnel to receive IP-in-IP encapsulation from 44.0.0.1. Feel free to use:
http://44.60.44.10/tools or http://kb3vwg-010.ampr.org/tools
I see your encap as:
44.161.202.0 via 46.29.183.253 dev tunl0 onlink window 840 44.161.203.0 via 46.29.183.253 dev tunl0 onlink window 840 44.161.229.0 via 46.29.183.253 dev tunl0 onlink window 840
Also, I am unable to ping 44.161.229.126. What script/configuration did you use to enable your tunnel; did you specify a local or remote IP (un-needed)? Feel free to look at my script at http://44.60.44.13/startampr
73,
Lynwood KB3VWG
Thank you Lynwood for your help.
I'm currently using rip44d version 1.1. Could you tell me where to find version 1.2 with support the -t option?
I haven't been using your startampr script but I will now.
vy 73 de Marc, LX1DUC
Marc,
The script is available from: https://github.com/hessu/rip44d
or as a convenience, at the same site
See http://wiki.ampr.org/index.php/Rip44d for more details.
-Lynwood
Marc,
I do not suggest removing the 169.228.66.251 route. It was discussed a few weeks ago that removing the route on my standard Ubuntu machine causes RIP44 to fail (no longer receive RIP44 announcements). No resolution was reached in that discussion. ONE of the following routes must be manually added before RIP44 is operational:
ip route add default dev tunl0 via 169.228.66.251 onlink table 44
If you do not wish to have your subnet accessible from the Public Internet., use the following instead:
ip route add 44.0.0.1 dev tunl0 via 169.228.66.251 onlink table 44 window 840
Further, 44.0.0.1 via 169.228.66.251 IS indeed a valid allocation on AMPR, it happens to be the Main AMPRGW.
- Lynwood KB3VWG
On 03/27/2013 10:40 AM, marius@yo2loj.ro wrote:
I simply add 169.228.66.251 to the hosts to be ignored (option -a 169.228.66.251 ) so that route doesn't make it into the machine...
Marius,
I am unable to ping 44.182.21.1. You can verify at:
http://44.60.44.10/tools/ping/php-ping.php
44.182.21.0 via 89.122.215.236 dev tunl0 onlink window 840
-Lynwood
Hi Lynwood,
I can ping/connect various ampr hosts via tunnel and can be reached/pinged from them (e.g. ve3zda.ampr.org, stecat, brklyn and others - just checked). 44.60.44.10 is not among them. So encapsulation on this side works ok, including the removed 44.0.0.1 route (which I can by the way ping correctly via the regular internet since it is a regular public IP and it has to be since it is the gateway for the tunnelled 44 hosts).
So I would check the setup on your side again, ensuring that incoming requests AND outgoing ampr replies go via tunnel as defined in the broadcasts (wireshark is your friend...).
Marius
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Wednesday, March 27, 2013 17:24 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Newbie issue
I am unable to ping 44.182.21.1. You can verify at:
http://44.60.44.10/tools/ping/php-ping.php
44.182.21.0 via 89.122.215.236 dev tunl0 onlink window 840
Marius,
1.) 44.60.44.10 was offline for about 60 minutes prior to this email, that should have been verifiable by not being able to reach the HTTP website. As I noted before, ping/traceroute my router at 44.60.44.1, as it should be online at all times. At this time, the HTTP site is up, and 44.60.44.10 SHOULD be pingable on AMPR and the Public Internet.
2.) We discussed this matter twice before; we are aware that we cannot ping each other. Again, there was no resolution on your part. I noted in previous weeks that some hosts on AMPR cannot be pinged, I resolved that matter with all other stations, except yourself. I last asked what Network Operating System are you using, I do not recall your response being provided.
3.) I provide http://44.60.44.10/tools for the pruposes of having users test and verify the same occurs at my station as theirs.
4.)
PING ve3zda.ampr.org (44.135.90.2) 56(84) bytes of data. 64 bytes from ve3zda.ampr.org (44.135.90.2): icmp_req=1 ttl=253 time=61.6 ms 64 bytes from ve3zda.ampr.org (44.135.90.2): icmp_req=2 ttl=253 time=60.3 ms 64 bytes from ve3zda.ampr.org (44.135.90.2): icmp_req=3 ttl=253 time=64.3 ms 64 bytes from ve3zda.ampr.org (44.135.90.2): icmp_req=4 ttl=253 time=65.7 ms
--- ve3zda.ampr.org ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 60.324/63.002/65.782/2.160 ms
5.) stecat.ampr.org and brklyn.ampr.org are invalid hostnames (I also host a DNS Server at 44.60.44.3).
- Lynwood
Hi again Lynwood,
As I recall, I stated in the beginning of the previous discussion, I use Debian 6 on my gateway. "stecat" and "brklyn" are netrom nodes from which I can ping my tunnel endpoint. stecat is ve2pkt's node (at 44.135.49.4) but not reachable via telnet, only by netrom (I probably don't know the port). brklyn is ve1jot.ampr.org (44.135.32.74) and works, including an axip link over the tunnel.
Btw: - I can not ping 44.60.44.10 from neither of them, but all can ping my system.
Also other hosts working: db0eeo.ampr.org/telnet 3600, iz3lsv.ampr.org /ping, gb7cp.ampr.org /ping+telnet
So I would think tere is no problem on this side.
73 de Marius, YO2LOJ
Marius,
I'm not certain of your meaning "only via netrom?"
Also, I think you have confused my KB3VWG gateway (76.114.216.250) for Marc's (46.29.183.253).
My http://44.60.44.10 IS reachable over AMPR; and is confusing if you fail to mention that 44.161.229.126 is NOT a HTTP host.
Of the hosts you listed, I am only able to ping ve3zda.ampr.org.
Please verify you have an operational Internet Protocol Version 4 interface at the address 44.182.21.1, configured to respond to a ICMP Type 8 Message (Echo Request):
ping 44.182.21.1
I am using standard ICMP Echo Requests via IPv4 to tests these hosts.
I understand you are using Debian as your Operating System, does that mean the Linux Kernel is your Network Operating System? For example, I am using a standard installation of Ubuntu GNU/Linux, my Kernel is enabled for IPv4 forwarding, RIP44 is my routing protocol; excluding prerequisites, my router has no other software installed. I do NOT have netrom or telnet installed on 44.60.44.0/24 at this time.
- Lynwood
Lynwood, I really don't get it where you want to go.
Maybe I confused the IP's since I looked only on Marc's traces, but the comments are equally valid. Your system is reacheable from the internet, but not via direct tunnel connection. And this because youprobably send all respones to the gw instead of the individual tunneling partners, but this is a assumption.
Fyi: I have a fullt fledged setup, with full IPv4 and IPv6 acces. I host a full featured cluster, a igate, a convers node, mail server, ham forum, some web sites and a SIP VoIp setup. Also my system accepts PPtP acces for fellow ham operators providing 44 addresses if they like. And yes, I do communication programming and networking for a living.
Unlike yourself, I can connect almost every node that has ampr access (and I mean connect, not a mere ping). So please stop asking me to check my systems, since it is yours that doesn't connect, doesn't ping and doesn't accept incoming connections except from the public internet.
And this is my last statement to this topic.
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Wednesday, March 27, 2013 23:03 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Newbie issue
(Please trim inclusions from previous messages) _______________________________________________
Well, it becomes difficult to troubleshoot if other stations will not assist. Thanks Bob, you are the first station since I last tested that also noted an inability to ping me.
Marius, the reason I asked is because the last time I tested, it was determined some stations were using other protocols and simply saying "I can't ping you." You then mentioned these were NetRom connections. I am left to assume that you ARE using ICMP Echo Request over IPv4 unless you confirmed.
The reason I am asking what Network OS is being used is to make a list of all stations I have attempted to ping, and compare their NOS to the list of problems or reported lack of connectivity to my station. I was trying to determine if you are using Debian or some other network software.
Not every station uses the same software suite or Operating System, just as you mentioned "full-fledged" means something different to all stations. In fact, I am now curious about AMPR IPv6 allocations, I did not know they were available.
73,
Lynwood
Well, you have this one:
::ffff:44.0.0.0/104
On Wed, Mar 27, 2013 at 2:54 PM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________
I am now curious about AMPR IPv6 allocations, I did not know they were available.
Neither did I. - Brian _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On Wed, Mar 27, 2013 at 02:57:30PM -0700, Cory (NQ1E) wrote:
Well, you have this one: ::ffff:44.0.0.0/104
Uh, that's cheating. :-) - Brian
On Wed, Mar 27, 2013 at 2:54 PM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________
I am now curious about AMPR IPv6 allocations, I did not know they were available.
Neither did I. - Brian
There are no IPv6 ampr adresses. I just have a IPv4/IPv6 dual stack setup. That's all. The ampr part is just a small part in the system. It is not exclusively ampr dedicated.
I talked about netrom because I use nerom to connect to remote nodes and then try to ping you from those nodes... Usually a node allows ping and telnet using its gatewaying setup.
Marius, YO@LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Wednesday, March 27, 2013 23:51 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Newbie issue
(Please trim inclusions from previous messages) _______________________________________________ Well, it becomes difficult to troubleshoot if other stations will not assist. Thanks Bob, you are the first station since I last tested that also noted an inability to ping me.
Marius, the reason I asked is because the last time I tested, it was determined some stations were using other protocols and simply saying "I can't ping you." You then mentioned these were NetRom connections. I am left to assume that you ARE using ICMP Echo Request over IPv4 unless you confirmed.
The reason I am asking what Network OS is being used is to make a list of all stations I have attempted to ping, and compare their NOS to the list of problems or reported lack of connectivity to my station. I was trying to determine if you are using Debian or some other network software.
Not every station uses the same software suite or Operating System, just as you mentioned "full-fledged" means something different to all stations. In fact, I am now curious about AMPR IPv6 allocations, I did not know they were available.
73,
Lynwood
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Brian,
I think we found the problem...76.114.216.250 is my gateway IP, and it is being announced on RIP44; and is listed as such on https://protal.ampr.org (that has been my IP address for approximately 21 days). Am I to understand it's not being updated in encap?
44.60.0.0/16 - is Maryland 44.60.44.0/24 - KB3VWG AMPR
-Lynwood
Well so I was receiving your ICMP ECHO REQUEST packets. But somehow they had the ampgrgw's non-44net as destination IP.... I will analyze the packets on the upstream router tomorrow and see what's goong on.
73 de Marc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Well maybe it's better to get things working step by step.
First step I want to get to work is ping from Internet. As I do receive routing updates via RIPv2, the communication between the central amprgw and my gateway must work.
However, ping and traceroute from Internet does not. Ping and traceroute from Internet must go via Brian's central amprgw, so if RIPv2 works I don't see why ping and traceroute shouldn't.
This is what the traceroute looks:
traceroute to 44.161.229.126 (44.161.229.126), 64 hops max, 52 byte packets 1 * * * 2 e0.vtt176-1.lux.lu.as51405.net (46.29.176.120) 98.936 ms 25.167 ms 76.600 ms 3 83.243.15.25 (83.243.15.25) 21.690 ms 40.556 ms 60.720 ms 4 llnw.dus.ecix.net (194.146.118.93) 34.630 ms 89.112 ms 33.067 ms 5 tge1-5.fr4.frf.llnw.net (69.28.189.161) 69.808 ms 46.594 ms 55.931 ms 6 tge1-2.fr4.ams.llnw.net (69.28.171.54) 102.495 ms 115.217 ms 94.458 ms 7 tge16-1.fr4.lga.llnw.net (69.28.189.49) 280.854 ms 213.193 ms 299.031 ms 8 tge1-2.fr4.ord.llnw.net (69.28.172.198) 307.245 ms 204.316 ms 249.123 ms 9 tge1-3.fr4.sjc.llnw.net (69.28.172.77) 200.818 ms 202.944 ms 199.952 ms 10 * * * 11 dc-oak-core1--paix-px1-ge.cenic.net (137.164.47.19) 232.588 ms 207.561 ms 205.932 ms 12 dc-tri-core1--oak-core1-10ge-4.cenic.net (137.164.46.43) 204.926 ms 204.194 ms 213.565 ms 13 dc-riv-core1--tri-core1-4.cenic.net (137.164.46.248) 195.708 ms 208.480 ms 209.391 ms 14 dc-sdg-agg1--riv-core1-10ge-2.cenic.net (137.164.47.15) 214.901 ms 215.563 ms 216.029 ms 15 dc-ucsd-1--sdg-agg1.cenic.net (137.164.23.54) 201.269 ms 213.264 ms 202.829 ms 16 nodem-core--mx0-30ge.ucsd.edu (132.239.254.163) 213.142 ms 200.361 ms 214.848 ms 17 ebu3b-6509-nodem-core-interconnect-vl910-bcast-255-131.ucsd.edu (132.239.255.131) 201.741 ms 204.033 ms 202.348 ms 18 amprgw.sysnet.ucsd.edu (169.228.66.251) 204.463 ms 201.769 ms 200.333 ms
On the my 44net gateway no iptables rules have been defined:
# iptables-save # Generated by iptables-save v1.4.8 on Thu Mar 28 22:59:30 2013 *filter :INPUT ACCEPT [31352:6172307] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [27531:4868700] COMMIT # Completed on Thu Mar 28 22:59:30 2013
I'm pinging 44.161.229.126 and 176.9.140.87 from my Laptop at home.
On my 44net gateway only the packets to 176.9.140.87 show up in a trace:
# tshark -i any not port 22 Running as user "root" and group "root". This could be dangerous. Capturing on Pseudo-device that captures on all interfaces 0.000000 46.29.176.121 -> 176.9.140.87 ICMP Echo (ping) request 0.000023 176.9.140.87 -> 46.29.176.121 ICMP Echo (ping) reply 1.002346 46.29.176.121 -> 176.9.140.87 ICMP Echo (ping) request 1.002365 176.9.140.87 -> 46.29.176.121 ICMP Echo (ping) reply 2.002563 46.29.176.121 -> 176.9.140.87 ICMP Echo (ping) request 2.002593 176.9.140.87 -> 46.29.176.121 ICMP Echo (ping) reply 3.000364 46.29.176.121 -> 176.9.140.87 ICMP Echo (ping) request 3.000390 176.9.140.87 -> 46.29.176.121 ICMP Echo (ping) reply
Brian can you see what happens with the ICMP ECHO REQUEST packets from 46.29.176.121 to 44.161.229.126?
Regards,
Marc
On 27/03/2013 23:35, Marc STORCK wrote:
(Please trim inclusions from previous messages) _______________________________________________ Well so I was receiving your ICMP ECHO REQUEST packets. But somehow they had the ampgrgw's non-44net as destination IP.... I will analyze the packets on the upstream router tomorrow and see what's goong on.
73 de Marc _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On Thu, 28 Mar 2013, Marc, LX1DUC wrote:
However, ping and traceroute from Internet does not. Ping and traceroute from Internet must go via Brian's central amprgw, so if RIPv2 works I don't see why ping and traceroute shouldn't.
amprgw will only transmit packets to you, if the destination 44.x address is registered in the ampr.org DNS zone.
traceroute to 44.161.229.126 (44.161.229.126), 64 hops max, 52 byte packets
hessu@hessu-mac:~$> host 44.161.229.126 Host 126.229.161.44.in-addr.arpa. not found: 3(NXDOMAIN)
Not in ampr.org DNS, packets to that address will not get from the Internet to your gateway via the central amprgw.
- Hessu
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
How much time does it take for the DNS to update? Some additions were approved 10 hours ago, but they don't resolve yet...
(If it's once per day, then there is no point to allow a TTL value of 1 hour...)
73 de Marc
On 28/03/2013 23:30, Heikki Hannikainen wrote:
On Thu, 28 Mar 2013, Marc, LX1DUC wrote:
However, ping and traceroute from Internet does not. Ping and traceroute from Internet must go via Brian's central amprgw, so if RIPv2 works I don't see why ping and traceroute shouldn't.
amprgw will only transmit packets to you, if the destination 44.x address is registered in the ampr.org DNS zone.
traceroute to 44.161.229.126 (44.161.229.126), 64 hops max, 52 byte packets
hessu@hessu-mac:~$> host 44.161.229.126 Host 126.229.161.44.in-addr.arpa. not found: 3(NXDOMAIN)
Not in ampr.org DNS, packets to that address will not get from the Internet to your gateway via the central amprgw.
- Hessu
On Thu, Mar 28, 2013 at 11:49:47PM +0100, Marc, LX1DUC wrote:
How much time does it take for the DNS to update? Some additions were approved 10 hours ago, but they don't resolve yet...
If you're referring to DNS updates made on the web site, they don't update at all because that part of the web site isn't operational yet.
Only DNS changes made by the email robot are currently effective. Your regional coordinator or I can make those changes for you. They update hourly. - Brian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29/03/2013 00:56, Brian Kantor wrote:
If you're referring to DNS updates made on the web site, they don't update at all because that part of the web site isn't operational yet.
Ohh, OK. That explains it.
I'm not sure if my regional co-ordinator Arsène, LX1TB has ever used the DNS robot, so if you don't mind could you please add the following records:
amprgw.lx0rl IN A 3600 44.161.229.126 aprs-igate.lx0rl-3 IN A 3600 44.161.202.10
73 de Marc
Done. - Brian
On Fri, Mar 29, 2013 at 01:05:54AM +0100, Marc, LX1DUC wrote:
On 29/03/2013 00:56, Brian Kantor wrote:
If you're referring to DNS updates made on the web site, they don't update at all because that part of the web site isn't operational yet.
Ohh, OK. That explains it.
I'm not sure if my regional co-ordinator Arsène, LX1TB has ever used the DNS robot, so if you don't mind could you please add the following records:
amprgw.lx0rl IN A 3600 44.161.229.126 aprs-igate.lx0rl-3 IN A 3600 44.161.202.10
73 de Marc
On Thu, Mar 28, 2013 at 05:16:25PM -0700, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ Done.
- Brian
And it works:
brian@catbox:~$ traceroute -n 44.161.229.126 traceroute to 44.161.229.126 (44.161.229.126), 30 hops max, 60 byte packets 1 192.168.1.1 0.540 ms 1.361 ms 1.614 ms 2 * * * 3 76.167.6.13 21.382 ms 25.091 ms 29.082 ms 4 72.129.2.168 46.194 ms 46.743 ms 46.860 ms 5 72.129.1.2 46.944 ms 47.653 ms 47.767 ms 6 66.109.6.64 40.189 ms 40.547 ms 39.578 ms 7 66.109.6.129 67.781 ms 17.755 ms 44.691 ms 8 206.223.143.14 26.054 ms 16.798 ms 18.666 ms 9 64.57.20.227 28.114 ms 33.131 ms 28.773 ms 10 137.164.46.117 36.108 ms 39.312 ms 42.604 ms 11 137.164.46.65 42.432 ms 43.121 ms 35.440 ms 12 137.164.47.111 46.850 ms 43.175 ms 33.868 ms 13 137.164.23.54 37.881 ms 41.139 ms 39.666 ms 14 132.239.254.163 43.493 ms 45.487 ms 45.936 ms 15 132.239.255.131 46.880 ms 49.937 ms 53.650 ms 16 169.228.66.251 57.827 ms 46.058 ms 49.569 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 44.161.229.126 212.925 ms 216.588 ms 220.600 ms
John, VE1JOT,
Question, what Operating System and Network stack are you using (just Linux, or JNOS on top of your OS)?
I've been troubleshooting my connection, attempting to determine why I am unable to reach some stations over AMPR; and able to reach others without issue. I can ping/traceroute your 44.135.32.201 address, and wanted to make a note of your setup.
traceroute to 44.135.32.201 (44.135.32.201), 30 hops max, 60 byte packets 1 kb3vwg-001.ampr.org (44.60.44.1) 0.450 ms 0.347 ms 0.263 ms 2 linux.ve1jot.ampr.org (44.135.32.201) 54.849 ms 61.003 ms 61.286 ms
73,
Lynwood KB3VWG
All,
Has anyone manually set the MTU of their un-encapsulated interface(s) on their 44Net Gateway to a value other than 1500?
-Lynwood KB3VWG
My IPIP tunl0 MTU set to 512 I can not get pings back from 44.60.44.1 Just run Linux system at gb7cip. Not running any Jnos,Tnos,xnos etc 73 de Paul g4apl In message 5164734A.501@aol.com, lleachii@aol.com writes
(Please trim inclusions from previous messages) _______________________________________________ All,
Has anyone manually set the MTU of their un-encapsulated interface(s) on their 44Net Gateway to a value other than 1500?
-Lynwood KB3VWG _________________________________________
All,
Paul's note made me consider a few things; and, I now know why WE cannot contact some Stations:
- To test, I changed my tunl0 MTU to 512, I began having failures with my tunnel. I was no longer able to reach certain services within AMPR or on the Internet. I could only perform pings to devices that I had already been able to reach.
- I've attempted to use netalyzr.icsi.berkeley.edu to examine the connection for over a year, it was finally determined between Berkeley and myself that there must be a router in the path dropping ICMP - Fragmentation Needed messages when the tunnel's MTU (1480 for me) is reached. I confirm that my router is sending them, as I've done MTU pings from my 44LAN while running Wireshark and can see my router sending the message.
Marius,
You wrote
>/ I can confirm the behavior described by Don... />/ I can ping ve3zda.ampr.org without problems. />/ As for 44.60.44.1, 44.60.44.10, 44.60.44.11 and 44.60.44.12, ping goes out />/ via encap interface but there's no response on the ipip tunnel. />/ />/ My system: 44.182.21.1/89.122.215.236/
the VE3ZDA.ampr.org entry (44.135.90.2, which I can ping) is:
44.135.90.2 via 70.52.124.227 dev tunl0 onlink window 840
To test, I added the following route to my routing table:
ip route add 44.182.21.1 dev tunl0 via 89.122.215.236 onlink table 44 window 840
PING 44.182.21.1 (44.182.21.1) 56(84) bytes of data. 64 bytes from 44.182.21.1: icmp_req=1 ttl=63 time=158 ms 64 bytes from 44.182.21.1: icmp_req=2 ttl=63 time=157 ms 64 bytes from 44.182.21.1: icmp_req=3 ttl=63 time=156 ms 64 bytes from 44.182.21.1: icmp_req=4 ttl=63 time=156 ms
The populated route reads:
44.182.21.0 via 89.122.215.236 dev tunl0 onlink window 840
44.182.21.0 is a valid IP address on the ICANN Internet and does not imply a subnet in any form.
It should contain a /24 notation as in the AMPRPortal:
44.182.21.0/24 via 89.122.215.236 dev tunl0 onlink window 840
No AMPR networks on my routing table (populated by RIP44d) contain the proper CIDR notations.
-Lynwood KB3VWG
Hessu,
It works! Thanks!
All,
My tools/services should be online and available to AMPR:
http://kb3vwg-010.ampr.org/tools/ping/php-ping.php http://kb3vwg-010.ampr.org/tools/trace/php-trace.php DNS (ampr.org and 44.in-addr.arpa, fully recursive for 44.0.0.0/8 hosts): 44.60.44.3
EchoLink Proxy: 44.60.44.253:443 44.60.44.254:80
73,
Lynwood KB3VWG
Marius,
With rip44d v1.3 I now see:
44.182.20.0/24 via 89.122.215.236 dev tunl0 onlink window 840 44.182.21.0/24 via 89.122.215.236 dev tunl0 onlink window 840
PING 44.182.21.1 (44.182.21.1) 56(84) bytes of data. 64 bytes from 44.182.21.1: icmp_req=1 ttl=63 time=161 ms 64 bytes from 44.182.21.1: icmp_req=2 ttl=63 time=174 ms 64 bytes from 44.182.21.1: icmp_req=3 ttl=63 time=156 ms 64 bytes from 44.182.21.1: icmp_req=4 ttl=63 time=156 ms
Though, I'm still unable to traceroute you.
-Lynwood
Don,
44.182.21.0 is the Marius' network 44net address. Within AMPR, it is not a valid IP, try 44.182.21.1.
-Lynwood
About traceroute... I think traceroute relies on a icmp message "expired in transit" returned by each host on the route with increasing TTL on each probe. I am not shure that encap tunnels are able to provide such behavior. By looking to the traces, the "expired" icmp message is sent to the public tunnel endpoint IP from the machine where the TTL expires, but it is not encapsulated so does not make it to back to the traceroute utility. This could be a linux-only behavior, never tried it on nos derivatives...
Marius.
Marius,
I use the following to have operational traceroute over the tunnel:
ip tunnel change ttl 64 mode ipip tunl0
-Lynwood
Don,
Those problems were resolved yesterday. Rip44d has been updated to version 1.3, it now correctly adds routes to the kernel routing table (which are referenced by their network address and CIDR prefix).
The 0's refer to the routing tables and CIDR type routing, which for a /24 (or 256 IP host network), the network [address] begins at 0, the first usable address is 1, and the broadcast is 255.
Prior to the rip44d fix, the problem was rip44d-based routers would only have 44.182.21.0 (a single IP address, /32) in their table, instead of 44.182.21.0/24 (which references 44.182.21.1-44.182.21.254). Therefore, Marius and I couldn't ping each other because I did not have a route for the IPs 44.182.21.1-254.
-Lynwood
On Fri, 12 Apr 2013, lleachii@aol.com wrote:
Prior to the rip44d fix, the problem was rip44d-based routers would only have 44.182.21.0 (a single IP address, /32) in their table, instead of 44.182.21.0/24 (which references 44.182.21.1-44.182.21.254). Therefore, Marius and I couldn't ping each other because I did not have a route for the IPs 44.182.21.1-254.
Just to clarify a little bit, the bug was introduced to rip44d in git commit ba0912e305 (Feb 25, 2012, "Fixed to use prefix length / CIDR format when calling /sbin/ip"). Previous versions of rip44d didn't have it, and there are a bunch of people happily running older versions which are fine.
https://github.com/hessu/rip44d/commits/master
Stupid, embarrassing bug nonetheless. :)
- Hessu
Samantha,
I'm curious if you were able to setup your node and what Operating System you're using. Also, I'm curious about your reference to IPv6; is it for purposes of exploration/curiosity, or is there a current Amateur demand in your area for IPv6 enabled nodes?
73,
Lynwood KB3VWG
On Tue, 16 Apr 2013, lleachii@aol.com wrote:
I'm curious if you were able to setup your node and what Operating System you're using. Also, I'm curious about your reference to IPv6; is it for purposes of exploration/curiosity, or is there a current Amateur demand in your area for IPv6 enabled nodes?
Some networks don't speak IPv4 anymore.
This will have to be addressed in *NOS in time (or abandonment).
-- Kris Kirby, KE4AHR Disinformation Analyst
On Tue, 16 Apr 2013, Jerald A DeLong wrote:
Some networks don't speak IPv4 anymore.
This will have to be addressed in *NOS in time (or abandonment).
Dual stacked nodes are going to be in use for some time ipv4 isn't going to get shut off tomorrow.
This year some residential access networks will shut off IPv4 in a way that prevents running an amprnet gateway over IPIP or IPUDP tunneling. Operators are putting IPv4 more and more behind "carrier-grade NAT" devices, and not giving any public IPv4 addresses to the customers at all. The NAT is being done on the operator's device, so plain IPIP or IPUDP tunneling as we do it now won't work at all.
At the same time, some of them are starting to give public, routable IPv6 addresses to the end customer. If you use IPv6 for your connection, you bypass the NAT! You could do IPv4 over IPv6 tunneling to get your AMPRnet, for example, but since not all gateways have IPv6, you couldn't have a full mesh of connections to all other gateways. There could be a set of IPv4+IPv6 enabled gateways which would relay traffic for you from IPv4-only gateways. Or something like that.
For example, see DS-Lite:
http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#Dual-Stack_Lite_.28D...
Not all network operators will be doing this, but some. At work we talk with operators a lot, since we make software for them to sell and deliver to their end customers. We're getting questions about IPv6 deployment and operators are checking with us how our software will work when they deploy.
- Hessu, OH7LZB
Hi Lynwood
We have dual stacked servers (we are an isp here in Australia) so we see the best of both worlds
Sam
----- Original Message ----- From: lleachii@aol.com To: 44net@hamradio.ucsd.edu Sent: Wednesday, April 17, 2013 7:39 AM Subject: Re: [44net] APRS & IPv6 - JNOS (Docs) Offtopic
(Please trim inclusions from previous messages) _______________________________________________ Samantha,
I'm curious if you were able to setup your node and what Operating System you're using. Also, I'm curious about your reference to IPv6; is it for purposes of exploration/curiosity, or is there a current Amateur demand in your area for IPv6 enabled nodes?
73,
Lynwood KB3VWG
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
I'm not quite certain I understand the problem you are attempting to solve; but to add, I am actually passing traffic through two residential gateways/routers running DD-WRT. They do in fact pass IPIP, as I'm running an AMPR gateway and a 4-to-6 tunnel behind the devices.
Many newer consumer routers pass certain tunnels and allow multiple VPN connections which are not TCP or UDP (e.g. 'VPN Passthrough' on newer routers).
73,
Lynwood KB3VWG
It is about seting up a tunnel via a router one has no access to to set up port forwarding or other pass-throughts (it is an ISPs router which does NAT).
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Friday, April 19, 2013 21:23 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] private tunnel?
(Please trim inclusions from previous messages) _______________________________________________ I'm not quite certain I understand the problem you are attempting to solve
Greetings,
On Fri, 19 Apr 2013, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________
It is about seting up a tunnel via a router one has no access to to set up port forwarding or other pass-throughts (it is an ISPs router which does NAT).
Can you get someone on the outside to route your subnet or subnets to you via AXUDP ???
--- Jay WB8TKL
That is the idea, to have a tunneling partner outside. And axudp probably will work in one direction only, since nobody will forward incoming connections to the machine inside.
IMHO something like OpenVPN seems still the best solution with the client inside and the server otside.
-----Original Message-----
Can you get someone on the outside to route your subnet or subnets to you via AXUDP ???
--- Jay WB8TKL
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
All,
A few points and questions:
1.) It's noted that IPIP does not traverse firewalls, that is not the case with me, as I am traversing two firewalls to reach my Gateway server, both devices using using DD-WRT, and it appears to broadcast any packet that is not UDP or TCP. In fact, I also run a IPv6 tunnel on a Vyatta instance in the same manner. Also, depending on the firewall's NOS, it can be permitted through configuration (granted, you must have control of that network device).
2.) KB9MWR asked if anyone was using a firewall or IPtables, I do firewall my 44 Network, and only permit forwarding on that network for 44 hosts (i.e. someone could send an enscapsulated packet for any AMPR subnet and it will be forwarded via my GW, all other IP addresses are dropped at the firewall). I also restrict/permit services to certain /32 IP addresses, etc. In addition, some hosts on my network are only available on AMPR and/or ACLs only permitting 44 hosts to use those services (e.g. my DNS ACL permits full recursion for 44 hosts and allows only 44.in-addr.arpa and ampr.org resolution for all others).
3.) Would this VPN system allow me to use my 44Net allocation, or only the allocation located at the VPN server itself?
4.) It is my understanding that the ARRL CA is not online, this would require manual revocations, manual trusts (I'm not very familiar with VPN via certificate)?
73,
Lynwood KB3VWG
KB9MWR,
Well, I have not personally firewalled the WAN interface in the manner described (since I use it as an optional second Gateway and I am in control of two firewalls before the GW), though it is possible. The easiest method would to be to drop all incoming packets by default, only allowing ICMP type 8 (Echo Request) and IPIP.
As I'm aware, aside from Ping (Echo Request), only a spoofed ACK packet can reveal a firewalled online host. Since rip44 and proper routing configuration allows received IPIP packets to be returned only to valid subnets, only permitting Ping and IPIP should be rather secure.
It will not prevent (for example) an IPIP packet spoofed by a non-AMPR user sent to your GW that possesses a valid 44 src IP and a dst IP that's valid on your subnet. The reply would return to the AMPR IP in the SRC address (unless they have a firewall). This is prevented since only AMPR users know both the GW IP addresses and their associated subnets. Just to note, this behaviour may be valid in a multihomed network.
-Lynwood
KB9MWR,
Certainty, I have a Buffalo WHR-HP-G54 running v24-sp2 (08/07/10) std (revision 14896) connected directly to my cable modem. To the Buffalo device, I have a WRT54G v3 running v24-sp2 (08/07/10) mega (revision 14896). Prior to the v3, I also had a ver5 device running DD-WRT micro with no issues as well.
Connected to the WRT54G is a Ubuntu-based VM Server containing the virtual machine running my Linux AMPR GW.
You may wish to allow VPN passthrough under Security > VPN Passthrough; though this hasn't been needed in my configuration. I noted you said that you are not passing IPIP rip packets, as far as the DD-WRT router is concerned, IPIP packets are the same, no matter what's in the packet (I'm receiving AMPR IPv4-in-IPv4 in addition to IPv6-in-IPv4 for another machine).
To clarify, my WRT54G is not in the DMZ.
-KB3VWG Lynwood
KB9MWR,
I have not always used the mega version (I just began using that device); also, the mega device is not connected to the Internet, the Standard is. So, I assure you, standard passes IPIP packets.
To make the ampr dynamic, place your dynamic hostname in the portal instead of the IP.
Steve,
I'm wondering if in Setup > Advanced Routing - you have your device setup as a Gateway (which uses NAT), BGP, Router (no NAT) or OSLR.
Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT 0 -- anywhere anywhere TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU lan2wan 0 -- anywhere anywhere ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED TRIGGER 0 -- anywhere anywhere TRIGGER type:in match:0 relate:0 trigger_out 0 -- anywhere anywhere ACCEPT 0 -- anywhere anywhere state NEW DROP 0 -- anywhere anywhere
That's what I thought, it's not 44.182.21.0 but rather 44.182.21.1 and maybe that's part of the problem for those attempting to ping you..
Yes I was able to ping 44.182.21.1 long ago but as I"ve been reviewing the replies I only see .0 referred to and not .1
73, Don
On Fri, Apr 12, 2013 at 9:26 AM, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
Marius,
With rip44d v1.3 I now see:
44.182.20.0/24 via 89.122.215.236 dev tunl0 onlink window 840 44.182.21.0/24 via 89.122.215.236 dev tunl0 onlink window 840
PING 44.182.21.1 (44.182.21.1) 56(84) bytes of data. 64 bytes from 44.182.21.1: icmp_req=1 ttl=63 time=161 ms 64 bytes from 44.182.21.1: icmp_req=2 ttl=63 time=174 ms 64 bytes from 44.182.21.1: icmp_req=3 ttl=63 time=156 ms 64 bytes from 44.182.21.1: icmp_req=4 ttl=63 time=156 ms
Though, I'm still unable to traceroute you.
-Lynwood
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Morning All
Seeing if anyone has got instructions on how to configure JNOS for APRS and IPv6
Thanks
Samantha VK4FQ | VK4TTT
aprs with jnos:
http://www.langelaar.net/projects/nosaprs/NOSaprs.htm
at the end of that page you wiil find an example with the bare minimum config for your autoexec.nos.
There is no IPv6 support in jnos (yet)
73,
Bob (Boudewijn) VE3TOK
On 13-04-12 11:15 AM, VK4FQ/VK4TTT Sam wrote:
(Please trim inclusions from previous messages) _______________________________________________
Morning All
Seeing if anyone has got instructions on how to configure JNOS for APRS and IPv6
Thanks
Samantha VK4FQ | VK4TTT
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Hi Lynwood,
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Thursday, April 11, 2013 15:32 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Gateways Unreachable after Dynamic IP Update
The populated route reads:
44.182.21.0 via 89.122.215.236 dev tunl0 onlink window 840
44.182.21.0 is a valid IP address on the ICANN Internet and does not imply a subnet in any form.
It should contain a /24 notation as in the AMPRPortal:
44.182.21.0/24 via 89.122.215.236 dev tunl0 onlink window 840
No AMPR networks on my routing table (populated by RIP44d) contain the proper CIDR notations.
This is what I see in the encap file:
route addprivate 44.182.20/24 encap 89.122.215.236 route addprivate 44.182.21/24 encap 89.122.215.236
Now these entries seem correct to me. Does it work with the new version from Hessu?
Marius, YO2LOJ
I've just tried to ping 44.182.21.0 and lookup the address and nothing is returned in either case. Is 44.182.21.0 registered?
73, Don
On Fri, Apr 12, 2013 at 8:34 AM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi Lynwood,
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Thursday, April 11, 2013 15:32 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Gateways Unreachable after Dynamic IP Update
The populated route reads:
44.182.21.0 via 89.122.215.236 dev tunl0 onlink window 840
44.182.21.0 is a valid IP address on the ICANN Internet and does not imply a subnet in any form.
It should contain a /24 notation as in the AMPRPortal:
44.182.21.0/24 via 89.122.215.236 dev tunl0 onlink window 840
No AMPR networks on my routing table (populated by RIP44d) contain the proper CIDR notations.
This is what I see in the encap file:
route addprivate 44.182.20/24 encap 89.122.215.236 route addprivate 44.182.21/24 encap 89.122.215.236
Now these entries seem correct to me. Does it work with the new version from Hessu?
Marius, YO2LOJ
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On 13-04-09 04:54 PM, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ John, VE1JOT,
Question, what Operating System and Network stack are you using (just Linux, or JNOS on top of your OS)?
I've been troubleshooting my connection, attempting to determine why I am unable to reach some stations over AMPR; and able to reach others without issue. I can ping/traceroute your 44.135.32.201 address, and wanted to make a note of your setup.
traceroute to 44.135.32.201 (44.135.32.201), 30 hops max, 60 byte packets 1 kb3vwg-001.ampr.org (44.60.44.1) 0.450 ms 0.347 ms 0.263 ms 2 linux.ve1jot.ampr.org (44.135.32.201) 54.849 ms 61.003 ms 61.286 ms
73,
Lynwood KB3VWG _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Hi Lynwood, well, I'm running linux mint 14.1 on a laptop with jnos 2.0j2 (44.135.32.74) also running linux ax25 stack at the 44.135.32.201 address...this is to my wireless router which is connected to the cable modem...I found I had to add the path to the two 44-net addresses to my router with a route add statement in DD-WRT running in the router...otherwise stuff from regular ip addresses wouldn't find my 44-net.now I can access jnos and company from my local 192-net and has the added worry/benefit of being available from the entire inet....I'm running rip44d on the linux/jnos machine to handle the gateway entries...but I sure would LIKE to run rip44d on the actual wrt54g router...would be sooo much slicker, hi hi! I have the userland patches (google tuncreate.c) for jnos and linux using tun0, and also using tunl0 for getting the rip updates and handling the encap routes....just had a complete hard drive failure three or 4 days ago, so had to re-do everything from memory (arrgh!), but the benefit was a new laptop as the linux server with twice the ram, and a 2.8 ghz processor.... 44.135.32.74 is the jnos part (ve1jot-8)...telnet might be working to it...from it, you can go to ve1jot-7 (linux node) which has a few axudp routes and handles the radio ports (hf and vhf)...my config files are a mess, but if you like, PM me and I can attach a few for your confusion, lawl! HTH, John
Hi Lynwood,
I don't see any reaction at all with IPIP so maybe it is something simple like a firewall rule. The best is to monitor the incoming traffic with tcpdump to see what is going on. My IP is here 44.135.85.151 or jnos at 44.135.85.30.
73,
Bob VE3TOK
On 13-03-27 05:51 PM, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Well, it becomes difficult to troubleshoot if other stations will not assist. Thanks Bob, you are the first station since I last tested that also noted an inability to ping me.
Marius, the reason I asked is because the last time I tested, it was determined some stations were using other protocols and simply saying "I can't ping you." You then mentioned these were NetRom connections. I am left to assume that you ARE using ICMP Echo Request over IPv4 unless you confirmed.
The reason I am asking what Network OS is being used is to make a list of all stations I have attempted to ping, and compare their NOS to the list of problems or reported lack of connectivity to my station. I was trying to determine if you are using Debian or some other network software.
Not every station uses the same software suite or Operating System, just as you mentioned "full-fledged" means something different to all stations. In fact, I am now curious about AMPR IPv6 allocations, I did not know they were available.
73,
Lynwood
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
I'm very much interested in others looking to implement services via RF and provide radio links in their local area; myection (Atlantic-MDC) is interested in building an infrastructure. And I've been working on back-end/backhaul resources that will provide rackspace for L7 services.
While some Stations many not see the benefit, I do have interest in my area to break the 1200 Baud speed barrier (and proprietary equipment restrictions).
-Lynwood KB3VWG
All,
Quite a few persons mentioned have mentioned that cellphones and other means of commercial Internet and communications can be used instead of HSMM; but I must agree with Pedja that the purpose of Amateur Communications is to provide a backup to the commodity utility services for use in emergency - among other purposes. In addition, the Amateur Radio and Satellite services are available for by those who are interested in studying and improving in the radio art without monetary interest. The purposes for the commercial spectrum are completely different than that allocated for amateur use. In the US, it's also unrealistic to assume that the commercial communications infrastructure will be locally available in case of certain emergencies - considering the history of the availability of communications during local and national events.
I'd have to agree with Pedja; in my Section, we are very interested in providing HSMM services at locations we serve in Emergency situations. For example, we would be interested in being capable of VoIP, VideoConferencing, the email of files and/or high-speed (>56k) data transfer. We eventually envision a complete Amateur-only Network that does not rely whatsoever on Commodity Communications for Backhaul. My RACES/ARES organisations (W3PGC and K3ERA) provide services to the hospitals in our county.
I personally find it unrealistic to pay exuberant sums of money for devices that are only useful for infrastructure operating at 1200 baud, or to assume they'll be very useful to an agency such as a hospital or Red Cross station during a prolonged event. Compared to 1200 baud, IPoAC (IP over Avian Carrier protocol - RFC1149) actually becomes more viable - depending on the amount of data to be transferred, the payload and the ability to find other carriers to do so.
http://en.wikipedia.org/wiki/IP_over_Avian_Carriers
73,
Lynwood KB3VWG
-Lynwood
I now have rip44d version 1.2. Thanks for the help.
I used the site: http://44.60.44.10/tools/ping/php-ping.php to ping 44.161.229.126
but on the gateway I see quite strange packet traces:
# tshark -i eth0 not port 22 Running as user "root" and group "root". This could be dangerous. Capturing on eth0 3.659640 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000) 4.670065 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000) 5.675693 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000) 6.683756 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000)
# tshark -i tunl0 not port 22 Running as user "root" and group "root". This could be dangerous. Capturing on tunl0 0.000000 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000) 1.010436 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000) 2.019145 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000) 3.027052 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol (proto=IPIP 0x04, off=512, ID=0000)
Surfing from my office network to http://44.60.44.10/tools/ping/php-ping.php works fine. Surfing to http://44.161.229.126 gives a timeout on my browser and not a single tcp packet towards port 80 on my gateway.
I am using the startampr script proposed earlier.
The gateway is a fresh install done morning using Debian 6.0.7 64bit
73 de Marc
I confirm this: 44.60.44.10 is reachable from me via the public internet (read via ampr gateway), but not via direct tunnel.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Marc, LX1DUC Sent: Wednesday, March 27, 2013 22:23 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Newbie issue
Surfing from my office network to http://44.60.44.10/tools/ping/php-ping.php works fine. Surfing to http://44.161.229.126 gives a timeout on my browser and not a single tcp packet towards port 80 on my gateway.
I confirm this: 44.60.44.10 is reachable from me via the public internet (read via ampr gateway), but not via direct tunnel.
I can confirm the same.
Bob VE3TOK
On 13-03-27 04:28 PM, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ I confirm this: 44.60.44.10 is reachable from me via the public internet (read via ampr gateway), but not via direct tunnel.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Marc, LX1DUC Sent: Wednesday, March 27, 2013 22:23 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Newbie issue
Surfing from my office network to http://44.60.44.10/tools/ping/php-ping.php works fine. Surfing to http://44.161.229.126 gives a timeout on my browser and not a single tcp packet towards port 80 on my gateway.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
# tshark -i eth0 not port 22 Running as user "root" and group "root". This could be dangerous. Capturing on eth0 3.659640 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol
(proto=IPIP 0x04, off=512, ID=0000)
4.670065 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol
(proto=IPIP 0x04, off=512, ID=0000)
5.675693 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol
(proto=IPIP 0x04, off=512, ID=0000)
6.683756 76.114.216.250 -> 169.228.66.251 IP Fragmented IP protocol
(proto=IPIP 0x04, off=512, ID=0000)
This traces are correct Marc, they are IPIP encapsulated frames (protocol 0x04) as it should be.
Surfing from my office network to http://44.60.44.10/tools/ping/php-ping.php works fine.
Here you use the public internet, so all traffic goes via 44.0.0.1 and is sent to the needed tunnel.
Surfing to http://44.161.229.126 gives a timeout on my browser and not a
single tcp packet towards port 80 on my gateway.
You mean that when surfing to your gw from the office? If all is set up correctly, you should get incoming packets proto 4 from 169.228.66.251 to your public IP (I assume 76.114.216.250). Check that your firewall settings allow incoming IP proto 4 on your interface.
Marius, YO2LOJ
It's strange that the packets are shown as fragmented packets.
Also I have no idea who 76.114.216.250 is, it's the source IP for fragmented IP packets received on my gateway when pinging from your website...
There is no firewall on that system
# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination
Chain FORWARD (policy ACCEPT) target prot opt source destination
Chain OUTPUT (policy ACCEPT) target prot opt source destination
Also I don't see any ICMP reply packets and your website reports:
PING 44.161.229.126 (44.161.229.126) 56(84) bytes of data.
--- 44.161.229.126 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3025ms
This is my current kernel version in case this is relevant:
# uname -a Linux debian 2.6.32-5-amd64 #1 SMP Mon Feb 25 00:26:11 UTC 2013 x86_64 GNU/Linux
73 de Marc, LX1DUC
On Wed, Mar 27, 2013 at 10:24:42PM +0100, Marc, LX1DUC wrote:
Also I have no idea who 76.114.216.250 is, it's the source IP for fragmented IP packets received on my gateway when pinging from your website...
It appears to be c-76-114-216-250.hsd1.md.comcast.net, which I guess as being a home internet connection in Maryland USA. It's not in the encap file, which makes it strange as a source of encap'd packets.
Could someone's home IP address have changed when they weren't looking? - Brian
Ooops, my mistake, it's in encap and active:
44.60.44.0/24 ipip-> 76.114.216.250[1,0]: 8090/4847421
Sorry. - Brian
On Wed, Mar 27, 2013 at 02:53:23PM -0700, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Wed, Mar 27, 2013 at 10:24:42PM +0100, Marc, LX1DUC wrote:
Also I have no idea who 76.114.216.250 is, it's the source IP for fragmented IP packets received on my gateway when pinging from your website...
It appears to be c-76-114-216-250.hsd1.md.comcast.net, which I guess as being a home internet connection in Maryland USA. It's not in the encap file, which makes it strange as a source of encap'd packets.
Could someone's home IP address have changed when they weren't looking?
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
-
Bob Tenty -
Brian Kantor -
Cory (NQ1E) -
Don Moore -
Heikki Hannikainen -
Jay Nugent -
Jerald A DeLong -
JJ -
Kris Kirby -
lleachii＠aol.com -
Marc STORCK -
Marc, LX1DUC
-
Marius Petrescu -
Paul Lewis -
VK4FQ/VK4TTT Sam