Hi all,
I have setup, after many years of absence, our AMPRnet GATEWAY in Athens, running in a LINUX BOX.
I have a dynamic IP here which rarely changes and up to now I had access to several AMPRnet hosts.
Yesterday I had to reset my router (TL-WR1043ND running DD-WRT) and I lost connectivity.
Checking http://portal.ampr.org I can see that my new Internet IP has been updated (it takes about 1 hour I think).
Problem is that now I cannot ping gb7cip.ampr.org or any other AMPRnet host I could before?
I can see that rip44d is doing it's thing using "tcpdump -i tunl0".
How long does it take for AMPRnet to be informed after a change in Internet IP (nor 44net IP)? It has been more than 12 hours since my router got it's new IP and no joy yet!
Any ideas guys?
If the station you are trying to ping is using the encap.txt process and not rip then it will take as long as whatever the timing is on that station. For example I have mine updating every 24 hrs because there are rarely any changes and that is first thing every morning.
73, Don - ve3zda
On Mon, Aug 5, 2013 at 5:56 AM, Demetre SV1UY demetre.sv1uy@gmail.comwrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi all,
I have setup, after many years of absence, our AMPRnet GATEWAY in Athens, running in a LINUX BOX.
I have a dynamic IP here which rarely changes and up to now I had access to several AMPRnet hosts.
Yesterday I had to reset my router (TL-WR1043ND running DD-WRT) and I lost connectivity.
Checking http://portal.ampr.org I can see that my new Internet IP has been updated (it takes about 1 hour I think).
Problem is that now I cannot ping gb7cip.ampr.org or any other AMPRnet host I could before?
I can see that rip44d is doing it's thing using "tcpdump -i tunl0".
How long does it take for AMPRnet to be informed after a change in Internet IP (nor 44net IP)? It has been more than 12 hours since my router got it's new IP and no joy yet!
Any ideas guys?
-- 73 de SV1UY Demetre Ch. Valaris IP Coordinator for AMPRnet in Greece e-mail: demetre.sv1uy@gmail.com Radio e-mail: sv1uy@winlink.org (to use my radio e-mail put //WL2K in the beginning of the subject line) http://www.qsl.net/sv1uy _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Hi Blaine,
I still can't ping you. I guess I have to do more tests! hi hi hi!!!
73 de SV1UY
On Mon, Aug 5, 2013 at 1:53 PM, Don Moore ve3zda@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ If the station you are trying to ping is using the encap.txt process and not rip then it will take as long as whatever the timing is on that station. For example I have mine updating every 24 hrs because there are rarely any changes and that is first thing every morning.
73, Don - ve3zda
On Mon, Aug 5, 2013 at 5:56 AM, Demetre SV1UY demetre.sv1uy@gmail.comwrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi all,
I have setup, after many years of absence, our AMPRnet GATEWAY in Athens, running in a LINUX BOX.
I have a dynamic IP here which rarely changes and up to now I had access to several AMPRnet hosts.
Yesterday I had to reset my router (TL-WR1043ND running DD-WRT) and I lost connectivity.
Checking http://portal.ampr.org I can see that my new Internet IP has been updated (it takes about 1 hour I think).
Problem is that now I cannot ping gb7cip.ampr.org or any other AMPRnet host I could before?
I can see that rip44d is doing it's thing using "tcpdump -i tunl0".
How long does it take for AMPRnet to be informed after a change in Internet IP (nor 44net IP)? It has been more than 12 hours since my router got it's new IP and no joy yet!
Any ideas guys?
-- 73 de SV1UY Demetre Ch. Valaris IP Coordinator for AMPRnet in Greece e-mail: demetre.sv1uy@gmail.com Radio e-mail: sv1uy@winlink.org (to use my radio e-mail put //WL2K in the beginning of the subject line) http://www.qsl.net/sv1uy _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Hello Demetre,
blackhole is the MUST. How about my IP 44.165.2.2, is it pingable for you? 44.165.2.1 should respod as well ...
B.rgds. Tom - sp2lob
Demetre,
You may try 44.139.11.6 which is my another IP at the moment, via AMPRNet VPN... (thanks to Hessu, OH7LZB)
B.rgds. Tom - sp2lob
You should describe the network setup in a graphically.
I also see several issues unless your setup is fundamentally different:
- if this is an iptables firewall for a host reachable directly via public IP, the host will be completely exposed (by excepting all protocol 4 packages). - the route 44.0.0.0/8 via tunl0 should always point to the UCSD router, e.g. "ip route add 44/8 dev tunl0 via 169.228.66.251 onlink table 44
I have published a HowTo http://marc.storck.lu/blog/2013/08/howto-setup-an-amprnet-gateway-on-linux/ which describes how to setup the IPIP tunnel server. Configuration element for NATted IPIP tunnel servers is yet missing, but I'm working on it.
73 de Marc
Quoting sp2lob@tlen.pl:
(Please trim inclusions from previous messages) _______________________________________________ Demetre,
Might be helpfull:
http://n1uro.ampr.org/cgi-bin/safe-config.cgi
B.rgds. Tom - sp2lob
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
I have published a HowTo http://marc.storck.lu/blog/2013/08/howto-setup-an-amprnet-gateway-on-linux/ which describes how to setup the IPIP tunnel server. Configuration element for NATted IPIP tunnel servers is yet missing, but I'm working on it.
It would be nice if someone prepares Linux distro preset for this purpose.
Marc,
I saw your post in your blog and I am going to use it tonight. I do not use 2 ethernet ports although this is probably better. I only have a DD-WRT router connected to a Speedtouch 585v7 (as an ADSL modem in bridge mode) and my AMPRnet Gateway in a LinuxMint Box with one ethernet port and 4 radio ports in it's 4 x RS232 adaptors.
73 de Demetre SV1UY
I saw your post in your blog and I am going to use it tonight. I do not use 2 ethernet ports although this is probably better. I only have a DD-WRT router connected to a Speedtouch 585v7 (as an ADSL modem in bridge mode) and my AMPRnet Gateway in a LinuxMint Box with one ethernet port and 4 radio ports in it's 4 x RS232 adaptors.
In case your DD-WRT uses PPPoE to "dial" an Internet connection via eth0, you should have a ppp0 interface which will receive your public dynamic IP (or if you're unlucky and your ISP employs CGN, you will receive a private IP and things probably just won't work).
On the DD-WRT ppp0 will be your (virtual) WAN port and eth0 will be your LAN port.
The eth0 on your DD-WRT and the eth0 on your Linuxbox should be able to use an IP address within 44/8 without issues. You will just have to make sure that packets from within your LAN which should go via the IPIP full mesh must use the LinuxMint Box as default gateway and not the DD-WRT, while all other boxes (not need for AMPRnet access) and your LinuxMint box must use the DD-WRT as default gateway. But you are free to set this up as you prefer.
73 de Marc, LX1DUC
Hi Marc and all,
This sort of setup (44 addresses in my home LAN) I was using years ago, when we had ADSLs with 256kbps download with static IP and also well before the ADSL era when I was using a 14400bps dialup modem connected to a 386 PC running Santa Cruz Unix and later Spackware Linux v 0.92 with diald (a dial on demand daemon).
Maybe I will do the same although I must make all my Desktop PCs, Laptops, Netbooks, Tablets, Internet Radios, Smart TV, NAS Boxes and Mobile Phones use 44 addresses. I am not sure if this is very ethical for AMPRnet but I like the idea because if I want to access AMPRnet I will be stuck to my LinuxMint Box because all other PCs etc will have 192.168.x.x addresses. I'm sure I could use some sort of Proxy in my LinuxMint Box for accessing AMRnet from all my devices, but this is another story and right now I'm stuck with my AMRPnet GATEWAY not working when using rip44d.
Thanks everybody for trying to help. Please keep the ideas coming. I hope that I will soon fond a solution.
73 de Demetre SV1UY
On Mon, Aug 5, 2013 at 7:50 PM, Marc, LX1DUC lx1duc@rlx.lu wrote:
(Please trim inclusions from previous messages) _______________________________________________
I saw your post in your blog and I am going to use it tonight. I do not use 2 ethernet ports although this is probably better. I only have a DD-WRT router connected to a Speedtouch 585v7 (as an ADSL modem in bridge mode) and my AMPRnet Gateway in a LinuxMint Box with one ethernet port and 4 radio ports in it's 4 x RS232 adaptors.
In case your DD-WRT uses PPPoE to "dial" an Internet connection via eth0, you should have a ppp0 interface which will receive your public dynamic IP (or if you're unlucky and your ISP employs CGN, you will receive a private IP and things probably just won't work).
On the DD-WRT ppp0 will be your (virtual) WAN port and eth0 will be your LAN port.
The eth0 on your DD-WRT and the eth0 on your Linuxbox should be able to use an IP address within 44/8 without issues. You will just have to make sure that packets from within your LAN which should go via the IPIP full mesh must use the LinuxMint Box as default gateway and not the DD-WRT, while all other boxes (not need for AMPRnet access) and your LinuxMint box must use the DD-WRT as default gateway. But you are free to set this up as you prefer.
73 de Marc, LX1DUC
On Mon, Aug 5, 2013 at 6:26 PM, Marc, LX1DUC lx1duc@rlx.lu wrote:
- the route 44.0.0.0/8 via tunl0 should always point to the UCSD router,
e.g. "ip route add 44/8 dev tunl0 via 169.228.66.251 onlink table 44
I've seen this claim several times, but I don't understand why exactly such a route would be necessary. Could you elaborate a bit?
While running a rip44 setup, you're going to get all routes updated within an hour of any changes. As Brian described, that's going to happen quite precisely at the same time when the UCSD router loads the updated routes:
"However, the updated routing table is only loaded at the top of the hour so there is a delay of up to 1 hour before your change will be reflected in the amprgw router and the rip44 data."
In the old days, when you manually updated your routes every month or so, having a fallback /8 route back to UCSD might have helped you to have a path to newly added gateways in the mean time. But these days, with RIP44 or other relatively quick updates, I think it's just a recipe for potential routing loops.
- Hessu, OH7LZB
I've seen this claim several times, but I don't understand why exactly such a route would be necessary. Could you elaborate a bit?
Some networks are not routed via the IPIP full mesh but directly via the Internet. For example Sweden and Australia announce their network directly via BGP but at the same time it seems that they don't have IPIP full mesh access.
As such if you want to reach any of those networks from within the IPIP full mesh, you will need to route your packets via a default route for 44/8 to the UCSD router which can then route the packets towards the internet.
The reason why you cannot just inject your packets to the Internet via your own Internet upstream lies in BCP 38 (http://tools.ietf.org/html/bcp38), which btw is a good thing for the internet as a whole (I admit in our specific case it's less useful, but still...).
73 de Marc, LX1DUC
On Tue, Aug 06, 2013 at 12:16:24PM +0000, Marc, LX1DUC wrote:
As such if you want to reach any of those networks from within the IPIP full mesh, you will need to route your packets via a default route for 44/8 to the UCSD router which can then route the packets towards the internet.
Which it turns out isn't working - it just gets stuck in a routing loop here due to the 44/8 route pointing back to the router. So the only way to get to the BGP'd subnets from a tunneled subnet is via mesh tunnels - which aren't yet in place in any of the BGP'd subnets as far as I know. Thus the net effect has been to isolate portions of the AMPRNet, precisely the opposite of what we hoped to accomplish by providing additional points of connection.
It is therefore incumbent upon the BGP'd subnets to get their mesh routers in operation quickly or remain cut off from the rest of the AMPRNet. - Brian
On Tue, Aug 6, 2013 at 3:16 PM, Marc, LX1DUC lx1duc@rlx.lu wrote:
I've seen this claim several times, but I don't understand why exactly such a route would be necessary. Could you elaborate a bit?
Some networks are not routed via the IPIP full mesh but directly via the Internet. For example Sweden and Australia announce their network directly via BGP but at the same time it seems that they don't have IPIP full mesh access.
As such if you want to reach any of those networks from within the IPIP full mesh, you will need to route your packets via a default route for 44/8 to the UCSD router which can then route the packets towards the internet.
But but... that does not work.
I tested it, and Brian confirmed that amprgw can not route packets out to the Internet to the BGP 44/8 sites, unless those sites are also reachable via an IPIP mesh. The technical reason is that the first upstream router between amprgw and the Internet has a static 44/8 route towards amprgw, and does not have the full Internet BGP table which would contain more specific routes to the BGP-only sites.
The BGP-enabled sites currently need to be present also in the IPIP table, and have (at least) an IPIP decapsulation gateway, so that other regular gateways can transmit packets to them. amprgw currently cannot act as a relay.
Also, it's more optimal to transmit the packets directly using a tunnel instead of trying to route via amprgw, even if it worked.
- Hessu
But but... that does not work.
I tested it, and Brian confirmed that amprgw can not route packets out to the Internet to the BGP 44/8 sites, unless those sites are also reachable via an IPIP mesh. The technical reason is that the first upstream router between amprgw and the Internet has a static 44/8 route towards amprgw, and does not have the full Internet BGP table which would contain more specific routes to the BGP-only sites.
The BGP-enabled sites currently need to be present also in the IPIP table, and have (at least) an IPIP decapsulation gateway, so that other regular gateways can transmit packets to them. amprgw currently cannot act as a relay.
Yes, actually I know but I thought the routing loop at UCSD would be temporary. OTOH those BGP-but-no-IPIP-guys are breaking the AMPRnet and MUST fix their installation!
Also, it's more optimal to transmit the packets directly using a tunnel instead of trying to route via amprgw, even if it worked.
True.
I completely disagree. We should be moving forward, not backwards to 2 decade old band-aid internetworking technology, which means eventually all routing should be based on BGP when traffic needs to travel beyond the 'local' 44-net resources. If IPIP or a VPN is needed to tunnel to a small subnet, then it should tie to an upstream router that can handle the BGP routing.
------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
On Tue, Aug 6, 2013 at 6:27 AM, Marc, LX1DUC lx1duc@rlx.lu wrote:
(Please trim inclusions from previous messages) Yes, actually I know but I thought the routing loop at UCSD would be temporary. OTOH those BGP-but-no-IPIP-guys are breaking the AMPRnet and MUST fix their installation!
[catching up on old emails here]
But but... that does not work. I tested it, and Brian confirmed that amprgw can not route packets out to the Internet to the BGP 44/8 sites, unless those sites are also reachable via an IPIP mesh. The technical reason is that the first upstream router between amprgw and the Internet has a static 44/8 route towards amprgw, and does not have the full Internet BGP table which would contain more specific routes to the BGP-only sites.
Since there are so few remote AMPR BGP speakers, why not configure these more specific routes on the upstream router as statics? That would be an improvement from what we currently have and the better solution would be to at least have the Internet learned 44/8 BGP routes leaked into this router to avoid using static routes.
--David KI6ZHD
Could be lots of reasons for this.
The stations you want to connect to may not be using RIP. They may be manually updating their encap files. Who knows?
Have you seen your changes in the encap file? On Aug 5, 2013 5:56 AM, "Demetre SV1UY" demetre.sv1uy@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi all,
I have setup, after many years of absence, our AMPRnet GATEWAY in Athens, running in a LINUX BOX.
I have a dynamic IP here which rarely changes and up to now I had access to several AMPRnet hosts.
Yesterday I had to reset my router (TL-WR1043ND running DD-WRT) and I lost connectivity.
Checking http://portal.ampr.org I can see that my new Internet IP has been updated (it takes about 1 hour I think).
Problem is that now I cannot ping gb7cip.ampr.org or any other AMPRnet host I could before?
I can see that rip44d is doing it's thing using "tcpdump -i tunl0".
How long does it take for AMPRnet to be informed after a change in Internet IP (nor 44net IP)? It has been more than 12 hours since my router got it's new IP and no joy yet!
Any ideas guys?
-- 73 de SV1UY Demetre Ch. Valaris IP Coordinator for AMPRnet in Greece e-mail: demetre.sv1uy@gmail.com Radio e-mail: sv1uy@winlink.org (to use my radio e-mail put //WL2K in the beginning of the subject line) http://www.qsl.net/sv1uy _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On Mon, Aug 05, 2013 at 12:56:29PM +0300, Demetre SV1UY wrote:
How long does it take for AMPRnet to be informed after a change in Internet IP
The database at amprgw is slaved in real time to the database at the portal so changes at the portal are reflected in mere seconds.
However, the updated routing table is only loaded at the top of the hour so there is a delay of up to 1 hour before your change will be reflected in the amprgw router and the rip44 data.
Of course, gateways using emailed or manually-fetched routing tables (ie, the encap file) may be further delayed. - Brian
Hello Demetre
GB7CIP updates the encap every 24 hours a 06:45Hrs UK time
73 Paul
In message CAOP4WsNXzS+ndBfYugNciuVXMXpSODPk8Ljzkx35F5Ch8_0F6A@mail.gmail.com, Demetre SV1UY demetre.sv1uy@gmail.com writes
(Please trim inclusions from previous messages) _______________________________________________ Hi all,
I have setup, after many years of absence, our AMPRnet GATEWAY in Athens, running in a LINUX BOX.
I have a dynamic IP here which rarely changes and up to now I had access to several AMPRnet hosts.
Yesterday I had to reset my router (TL-WR1043ND running DD-WRT) and I lost connectivity.
Checking http://portal.ampr.org I can see that my new Internet IP has been updated (it takes about 1 hour I think).
Problem is that now I cannot ping gb7cip.ampr.org or any other AMPRnet host I could before?
I can see that rip44d is doing it's thing using "tcpdump -i tunl0".
How long does it take for AMPRnet to be informed after a change in Internet IP (nor 44net IP)? It has been more than 12 hours since my router got it's new IP and no joy yet!
Any ideas guys?
-
Brian Kantor -
David Ranch -
Demetre SV1UY -
Don Moore -
Heikki Hannikainen -
K7VE - John -
Marc, LX1DUC -
Mark Phillips -
Paul Lewis -
sp2lob＠tlen.pl -
YT9TP op. Pedja