Screenshot
This network (44.24.240.0/20) is available via both 209.189.196.68 and 198.178.136.80. However, I'm unable to list more than one point of contact. I realize this was probably a design decision at some point, but it doesn't seem like a good idea from a redundancy perspective.
--Bart
PS: If you're wondering why the image looks like crap, it's to satisfy the puny 32kB message size limit of the list.
AMPR IPIP tunnels are currently broken for our network, 44.24.240.0/20. 44.24.240.0/20 is multi-homed. We have two edge routers. We originate IPIP tunnels from both routers, but other AMPR systems only accept IPIP traffic from one of the routers. Why? The second gateway IP is not in the encap file.
The portal will not let us add a second gateway IP for 44.24.240.0/20, because one already exists. Can we get this restriction lifted?
Second issue:
Something changed with the encap file download process. The script that builds our IPIP tunnels uses "curl https://portal.ampr.org/getdata.php" to download the encap data. A few days ago this was working just fine. Now the returned file is empty.
Loading that url with a web browser also returns an empty page. However, if I click the "download encap" link at https://portal.ampr.org/gateways_list.php, it works fine. Some funky session bug, I assume.
Please fix this issue, or point me towards the documentation that explains a better way to get the encap data.
Tom KD7LXL
On Tue, Mar 25, 2014 at 11:40 AM, Bart Kus me@bartk.us wrote:
(Please trim inclusions from previous messages) _______________________________________________ Screenshot
This network (44.24.240.0/20) is available via both 209.189.196.68 and 198.178.136.80. However, I'm unable to list more than one point of contact. I realize this was probably a design decision at some point, but it doesn't seem like a good idea from a redundancy perspective.
--Bart
PS: If you're wondering why the image looks like crap, it's to satisfy the puny 32kB message size limit of the list.
Hi Tom,
Just a simple question: If there would be 2 entries in the routes to your system, how would you expect the other systems to guess which tunnel endpoint to use for encapsulation?
Your subnet may be multihomed, but you need either to split it up for P2P tunnels to work, or do the "internal" routing yourself and use a single gateway with an unique ip address. Remember that there are no such things as connection tracking in the ampr full mesh concept. No matter where you originate your tunnel, ipip is stateless and the replies will go to the destination, via the defined gateway. That is why tunnels originated on a second device will get no reply traffic, since those replies will be directed to the proper gateway as defined in the encap file/Rip broadcast (that one being the other device with the "official" gateway address).
The only solution to this would be to switch from ipip to a stateful tunnel protocol, like pptp, l2tp or sstp. This would of course work, but it will require a interface for every possible link partner (340 at the moment of this writing).
73s de 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 Tom Hayward Sent: Friday, March 28, 2014 22:58 To: AMPRNet working group Subject: Re: [44net] Can't add redundant AMPR gateway to portal
(Please trim inclusions from previous messages) _______________________________________________ AMPR IPIP tunnels are currently broken for our network, 44.24.240.0/20. 44.24.240.0/20 is multi-homed. We have two edge routers. We originate IPIP tunnels from both routers, but other AMPR systems only accept IPIP traffic from one of the routers. Why? The second gateway IP is not in the encap file.
The portal will not let us add a second gateway IP for 44.24.240.0/20, because one already exists. Can we get this restriction lifted?
Second issue:
Something changed with the encap file download process. The script that builds our IPIP tunnels uses "curl https://portal.ampr.org/getdata.php" to download the encap data. A few days ago this was working just fine. Now the returned file is empty.
Loading that url with a web browser also returns an empty page. However, if I click the "download encap" link at https://portal.ampr.org/gateways_list.php, it works fine. Some funky session bug, I assume.
Please fix this issue, or point me towards the documentation that explains a better way to get the encap data.
Tom KD7LXL
On Tue, Mar 25, 2014 at 11:40 AM, Bart Kus me@bartk.us wrote:
(Please trim inclusions from previous messages) _______________________________________________ Screenshot
This network (44.24.240.0/20) is available via both 209.189.196.68 and 198.178.136.80. However, I'm unable to list more than one point of
contact.
I realize this was probably a design decision at some point, but it
doesn't
seem like a good idea from a redundancy perspective.
--Bart
PS: If you're wondering why the image looks like crap, it's to satisfy the puny 32kB message size limit of the list.
On Fri, Mar 28, 2014 at 2:20 PM, Marius Petrescu marius@yo2loj.ro wrote:
Just a simple question: If there would be 2 entries in the routes to your system, how would you expect the other systems to guess which tunnel endpoint to use for encapsulation?
Your subnet may be multihomed, but you need either to split it up for P2P tunnels to work, or do the "internal" routing yourself
It doesn't matter which gateway the return route comes through. Either will work. We handle that routing internally.
Tom KD7LXL
Hi Tom,
Second issue:
This is not a bug, this is intentional. I have been re-writing sections of the portal to enhance security following several hacking attempts. One insecure script I found when I audited the system was the getdata.php script. It has been re-written to be secure, You should not have been able to access the encap file directly from it in the first place, that kind of access was never documented, nor was it ever intended to be used like that.
The correct way to access the encap file remotely by script, is via FTP. I have had a couple of people asking about an API which I may introduce at a later stage, but for now you should access the encap file via FTP.
Regards, Chris
Something changed with the encap file download process. The script that builds our IPIP tunnels uses "curl https://portal.ampr.org/getdata.php" to download the encap data. A few days ago this was working just fine. Now the returned file is empty.
Loading that url with a web browser also returns an empty page. However, if I click the "download encap" link at https://portal.ampr.org/gateways_list.php, it works fine. Some funky session bug, I assume.
Please fix this issue, or point me towards the documentation that explains a better way to get the encap data.
Hey Chris,
Do you know how timely the multicast RIP announcements are? Are they sent out every time someone re-configures a gateway on the portal? Is there some scheduled re-broadcast of all routes?
Also, where is the source code for all this?
Thanks for any details,
--Bart
On 03/28/2014 02:55 PM, Chris wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi Tom,
Second issue:
This is not a bug, this is intentional. I have been re-writing sections of the portal to enhance security following several hacking attempts. One insecure script I found when I audited the system was the getdata.php script. It has been re-written to be secure, You should not have been able to access the encap file directly from it in the first place, that kind of access was never documented, nor was it ever intended to be used like that.
The correct way to access the encap file remotely by script, is via FTP. I have had a couple of people asking about an API which I may introduce at a later stage, but for now you should access the encap file via FTP.
Regards, Chris
Something changed with the encap file download process. The script that builds our IPIP tunnels uses "curl https://portal.ampr.org/getdata.php" to download the encap data. A few days ago this was working just fine. Now the returned file is empty.
Loading that url with a web browser also returns an empty page. However, if I click the "download encap" link at https://portal.ampr.org/gateways_list.php, it works fine. Some funky session bug, I assume.
Please fix this issue, or point me towards the documentation that explains a better way to get the encap data.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Brian replicates the portal database in realtime local to where his RIP server is and uses the live database to populate the routing announcements. I'm not sure how often the RIP software polls the database, but I'm sure Brian can enlighten us...
I'm in the process of adding the portal code to a subversion repository and once that has been completed I will probably open source it. In the meantime if anyone wants to assist with developing the portal code or with translations into other languages, please get in touch.
Thanks, Chris
On 28 Mar 2014, at 21:59, Bart Kus me@bartk.us wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hey Chris,
Do you know how timely the multicast RIP announcements are? Are they sent out every time someone re-configures a gateway on the portal? Is there some scheduled re-broadcast of all routes?
Also, where is the source code for all this?
Thanks for any details,
--Bart
On 03/28/2014 02:55 PM, Chris wrote: (Please trim inclusions from previous messages) _______________________________________________ Hi Tom,
Second issue:
This is not a bug, this is intentional. I have been re-writing sections of the portal to enhance security following several hacking attempts. One insecure script I found when I audited the system was the getdata.php script. It has been re-written to be secure, You should not have been able to access the encap file directly from it in the first place, that kind of access was never documented, nor was it ever intended to be used like that.
The correct way to access the encap file remotely by script, is via FTP. I have had a couple of people asking about an API which I may introduce at a later stage, but for now you should access the encap file via FTP.
Regards, Chris
Something changed with the encap file download process. The script that builds our IPIP tunnels uses "curl https://portal.ampr.org/getdata.php" to download the encap data. A few days ago this was working just fine. Now the returned file is empty.
Loading that url with a web browser also returns an empty page. However, if I click the "download encap" link at https://portal.ampr.org/gateways_list.php, it works fine. Some funky session bug, I assume.
Please fix this issue, or point me towards the documentation that explains a better way to get the encap data.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Not intending to hyjack the thread here.... but isn't this backwards? shouldn't the encap be built from the rip announcements rather than the reverse? I.E. rip being the current reality vs the encap being more of a statement of network architecture.
Eric AF6EP
On Fri, Mar 28, 2014 at 3:10 PM, Chris chris@g1fef.co.uk wrote:
(Please trim inclusions from previous messages) _______________________________________________ Brian replicates the portal database in realtime local to where his RIP server is and uses the live database to populate the routing announcements. I'm not sure how often the RIP software polls the database, but I'm sure Brian can enlighten us...
I'm in the process of adding the portal code to a subversion repository and once that has been completed I will probably open source it. In the meantime if anyone wants to assist with developing the portal code or with translations into other languages, please get in touch.
Thanks, Chris
On 28 Mar 2014, at 21:59, Bart Kus me@bartk.us wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hey Chris,
Do you know how timely the multicast RIP announcements are? Are they
sent out every time someone re-configures a gateway on the portal? Is there some scheduled re-broadcast of all routes?
Also, where is the source code for all this?
Thanks for any details,
--Bart
On 03/28/2014 02:55 PM, Chris wrote: (Please trim inclusions from previous messages) _______________________________________________ Hi Tom,
Second issue:
This is not a bug, this is intentional. I have been re-writing sections
of the portal to enhance security following several hacking attempts. One insecure script I found when I audited the system was the getdata.php script. It has been re-written to be secure, You should not have been able to access the encap file directly from it in the first place, that kind of access was never documented, nor was it ever intended to be used like that.
The correct way to access the encap file remotely by script, is via
FTP. I have had a couple of people asking about an API which I may introduce at a later stage, but for now you should access the encap file via FTP.
Regards, Chris
Something changed with the encap file download process. The script that builds our IPIP tunnels uses "curl https://portal.ampr.org/getdata.php" to download the encap data. A few days ago this was working just fine. Now the returned file is empty.
Loading that url with a web browser also returns an empty page. However, if I click the "download encap" link at https://portal.ampr.org/gateways_list.php, it works fine. Some funky session bug, I assume.
Please fix this issue, or point me towards the documentation that explains a better way to get the encap data.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
The RIP announcements are just broadcast from the authoritative source, which is the portal data, as provided by each and every gateway operator.
Sent from my iPhone
On 28 Mar 2014, at 22:26, Eric Fort eric.fort@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Not intending to hyjack the thread here.... but isn't this backwards? shouldn't the encap be built from the rip announcements rather than the reverse? I.E. rip being the current reality vs the encap being more of a statement of network architecture.
Eric AF6EP
On Fri, Mar 28, 2014 at 3:10 PM, Chris chris@g1fef.co.uk wrote:
(Please trim inclusions from previous messages) _______________________________________________ Brian replicates the portal database in realtime local to where his RIP server is and uses the live database to populate the routing announcements. I'm not sure how often the RIP software polls the database, but I'm sure Brian can enlighten us...
I'm in the process of adding the portal code to a subversion repository and once that has been completed I will probably open source it. In the meantime if anyone wants to assist with developing the portal code or with translations into other languages, please get in touch.
Thanks, Chris
On 28 Mar 2014, at 21:59, Bart Kus me@bartk.us wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hey Chris,
Do you know how timely the multicast RIP announcements are? Are they
sent out every time someone re-configures a gateway on the portal? Is there some scheduled re-broadcast of all routes?
Also, where is the source code for all this?
Thanks for any details,
--Bart
On 03/28/2014 02:55 PM, Chris wrote: (Please trim inclusions from previous messages) _______________________________________________ Hi Tom,
Second issue:
This is not a bug, this is intentional. I have been re-writing sections
of the portal to enhance security following several hacking attempts. One insecure script I found when I audited the system was the getdata.php script. It has been re-written to be secure, You should not have been able to access the encap file directly from it in the first place, that kind of access was never documented, nor was it ever intended to be used like that.
The correct way to access the encap file remotely by script, is via
FTP. I have had a couple of people asking about an API which I may introduce at a later stage, but for now you should access the encap file via FTP.
Regards, Chris
Something changed with the encap file download process. The script that builds our IPIP tunnels uses "curl https://portal.ampr.org/getdata.php" to download the encap data. A few days ago this was working just fine. Now the returned file is empty.
Loading that url with a web browser also returns an empty page. However, if I click the "download encap" link at https://portal.ampr.org/gateways_list.php, it works fine. Some funky session bug, I assume.
Please fix this issue, or point me towards the documentation that explains a better way to get the encap data.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
I thought the whole point of RIP was that it is a *DYNAMIC* routing protocol.
Eric AF6EP
On Fri, Mar 28, 2014 at 3:34 PM, G1FEF chris@g1fef.co.uk wrote:
The RIP announcements are just broadcast from the authoritative source, which is the portal data, as provided by each and every gateway operator.
Sent from my iPhone
On 28 Mar 2014, at 22:26, Eric Fort eric.fort@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Not intending to hyjack the thread here.... but isn't this backwards? shouldn't the encap be built from the rip announcements rather than the reverse? I.E. rip being the current reality vs the encap being more of a statement of network architecture.
Eric AF6EP
On Fri, Mar 28, 2014 at 3:10 PM, Chris chris@g1fef.co.uk wrote:
(Please trim inclusions from previous messages) _______________________________________________ Brian replicates the portal database in realtime local to where his RIP server is and uses the live database to populate the routing
announcements.
I'm not sure how often the RIP software polls the database, but I'm sure Brian can enlighten us...
I'm in the process of adding the portal code to a subversion repository and once that has been completed I will probably open source it. In the meantime if anyone wants to assist with developing the portal code or
with
translations into other languages, please get in touch.
Thanks, Chris
On 28 Mar 2014, at 21:59, Bart Kus me@bartk.us wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hey Chris,
Do you know how timely the multicast RIP announcements are? Are they
sent out every time someone re-configures a gateway on the portal? Is there some scheduled re-broadcast of all routes?
Also, where is the source code for all this?
Thanks for any details,
--Bart
On 03/28/2014 02:55 PM, Chris wrote: (Please trim inclusions from previous messages) _______________________________________________ Hi Tom,
Second issue:
This is not a bug, this is intentional. I have been re-writing
sections
of the portal to enhance security following several hacking attempts.
One
insecure script I found when I audited the system was the getdata.php script. It has been re-written to be secure, You should not have been
able
to access the encap file directly from it in the first place, that kind
of
access was never documented, nor was it ever intended to be used like
that.
The correct way to access the encap file remotely by script, is via
FTP. I have had a couple of people asking about an API which I may introduce at a later stage, but for now you should access the encap file via FTP.
Regards, Chris
Something changed with the encap file download process. The script that builds our IPIP tunnels uses "curl https://portal.ampr.org/getdata.php" to download the encap data. A
few
days ago this was working just fine. Now the returned file is empty.
Loading that url with a web browser also returns an empty page. However, if I click the "download encap" link at https://portal.ampr.org/gateways_list.php, it works fine. Some funky session bug, I assume.
Please fix this issue, or point me towards the documentation that explains a better way to get the encap data.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Fri, Mar 28, 2014 at 02:59:45PM -0700, Bart Kus wrote:
Do you know how timely the multicast RIP announcements are? Are they sent out every time someone re-configures a gateway on the portal? Is there some scheduled re-broadcast of all routes?
They are sent out every five minutes and contain all current routing information.
- Brian
On Fri, Mar 28, 2014 at 2:55 PM, Chris chris@g1fef.co.uk wrote:
This is not a bug, this is intentional. I have been re-writing sections of the portal to enhance security following several hacking attempts. One insecure script I found when I audited the system was the getdata.php script. It has been re-written to be secure, You should not have been able to access the encap file directly from it in the first place, that kind of access was never documented, nor was it ever intended to be used like that.
The correct way to access the encap file remotely by script, is via FTP. I have had a couple of people asking about an API which I may introduce at a later stage, but for now you should access the encap file via FTP.
Regards, Chris
Can you point me towards the documentation for this? I don't know the url.
Tom KD7LXL
On 28/03/2014 22:55, Chris wrote:
This is not a bug, this is intentional. I have been re-writing sections of the portal to enhance security following several hacking attempts. One insecure script I found when I audited the system was the getdata.php script. It has been re-written to be secure, You should not have been able to access the encap file directly from it in the first place, that kind of access was never documented, nor was it ever intended to be used like that.
Good idea, but it has serious side effects. You shouldn't make such drastic changes to services that are used by the community, even for the sake of security. The very least would be to announce such a change to this mailing list, so that SysOps can adapt their tools, before the users experience unreachable networks. It upsets people if you proceed like you did, people will complain loudly which probably doesn't
The correct way to access the encap file remotely by script, is via FTP. I have had a couple of people asking about an API which I may introduce at a later stage, but for now you should access the encap file via FTP.
Good point. BUT I cannot find the URL to the FTP anywhere on the portal, indeed the portal only provides a link to https://portal.ampr.org/getdata.php
So I went on and checked the http://wiki.ampr.org, no link can be found to the FTP server.
There is no encap file on ftp://hamradio.ucsd.edu/pub/ either.
Google returns http://www.qsl.net/kb9mwr/wapr/tcpip/encap.txt, file date is 2006/05/28 22:00:21
I would be glad if someone could point me to a current encap.txt file. (The version on the portal seemed to be generated on request... let's see how current the FTP version will be...)
73 de Marc
On 29 Mar 2014, at 00:36, "Marc, LX1DUC" lx1duc@laru.lu wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 28/03/2014 22:55, Chris wrote: This is not a bug, this is intentional. I have been re-writing sections of the portal to enhance security following several hacking attempts. One insecure script I found when I audited the system was the getdata.php script. It has been re-written to be secure, You should not have been able to access the encap file directly from it in the first place, that kind of access was never documented, nor was it ever intended to be used like that.
Good idea, but it has serious side effects. You shouldn't make such drastic changes to services that are used by the community, even for the sake of security. The very least would be to announce such a change to this mailing list, so that SysOps can adapt their tools, before the users experience unreachable networks. It upsets people if you proceed like you did, people will complain loudly which probably doesn't
As I said, that script was never documented as being accessible in that fashion, it was just a link from a page a human had to log into. If anyone has decided to link scripts into internal pages without even advising me that they were doing so then they run the risk that things can, and probably will, change.
The correct way to access the encap file remotely by script, is via FTP. I have had a couple of people asking about an API which I may introduce at a later stage, but for now you should access the encap file via FTP.
Good point. BUT I cannot find the URL to the FTP anywhere on the portal, indeed the portal only provides a link to https://portal.ampr.org/getdata.php
The FTP details have never officially been published as far as I am aware, they have been passed from one OM to another. Again I believe this to be intentional, although security through obscurity is never a great idea IMHO.
The FTP site is ftp.ampr-gateways.org
The username and password I am happy to divulge privately to any genuine radio amateur that emails me.
73 Chris G1FEF
So I went on and checked the http://wiki.ampr.org, no link can be found to the FTP server.
There is no encap file on ftp://hamradio.ucsd.edu/pub/ either.
Google returns http://www.qsl.net/kb9mwr/wapr/tcpip/encap.txt, file date is 2006/05/28 22:00:21
I would be glad if someone could point me to a current encap.txt file. (The version on the portal seemed to be generated on request... let's see how current the FTP version will be...)
73 de Marc _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 29/03/2014 09:47, Chris wrote:
As I said, that script was never documented as being accessible in that fashion, it was just a link from a page a human had to log into. If anyone has decided to link scripts into internal pages without even advising me that they were doing so then they run the risk that things can, and probably will, change.
The HTTP link was and still is listed prominently on the portal website, the FTP link is secret.
Now, make a guess which link is being used.
Also if you put something on the portal, I don't think that the natural thing would be to consult with anybody about it's usage... why would you put it onto the portal if we were never ever to use it...
73 de Marc
On Sat, Mar 29, 2014 at 1:47 AM, Chris chris@g1fef.co.uk wrote:
The FTP site is ftp.ampr-gateways.org
Hey, now we're getting there! A hostname is a critical part of a url. Can someone please fill me in on the other critical details needed to access the encap file?
Tom KD7LXL
On 29/03/2014 01:36, Marc, LX1DUC wrote:
(The version on the portal seemed to be generated on request... let's see how current the FTP version will be...)
Well I have been watching the FTP file, it seems from my perspective that the delay is more than 1 hour, or the file has been generated irregularly in the last hours.
It's a pity. Networks with dynamic IP addresses changing once a day (disconnect forced by ISP) will be unreachable from other 44net networks for up to the delay of regeneration of the encap.txt file.
Those disconnecting more frequently will be unreachable for a good part of the day.
The HTTP link allowed me to have an up2date encap.txt whenever I needed it.
I would like to suggest to add a 2nd way to access the HTTP link automatically. For example via a "key" provided as an option:
https://portal.ampr.org/getdata.php?key=.....
The value of the key could be calculated from
md5(concat(ftpusername,':',ftppassword)) or md5(concat(portalusername,':',portalpassword))
73 de Marc
hello Marc i dont have any answer if i ping li1duc.ampr.org ? i get unknow host vy73s André ON4HU
Le 29/03/2014 10:51, Marc, LX1DUC a écrit :
(Please trim inclusions from previous messages) _______________________________________________ On 29/03/2014 10:50, Marc, LX1DUC wrote:
The HTTP link allowed me to have an up2date encap.txt whenever I needed it.
or provide a second copy of the encap.txt file with the DynDNS hostnames in it, so that we can resolve the hosts as often as we like on our own.
73 de Marc _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
I have started work on an API that will allow straight forward querying of the gateways database from remote scripts. I'm also moving house ATM, so it might be a week or three away, but it will be done sooner rather than later.
Regards, Chris
Sent from my iPad
On 29 Mar 2014, at 09:51, "Marc, LX1DUC" lx1duc@laru.lu wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 29/03/2014 10:50, Marc, LX1DUC wrote: The HTTP link allowed me to have an up2date encap.txt whenever I needed it.
or provide a second copy of the encap.txt file with the DynDNS hostnames in it, so that we can resolve the hosts as often as we like on our own.
73 de Marc _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 3/29/2014 3:07 PM, Chris wrote:
(Please trim inclusions from previous messages) _______________________________________________ I have started work on an API that will allow straight forward querying of the gateways database from remote scripts. I'm also moving house ATM, so it might be a week or three away, but it will be done sooner rather than later.
As you do this, can you please give consideration to implementing an event-push system as well as supporting polling? The RIPv2 multicast announcements come close, but still have a 5 minute lag and just blast the entire data set, not just the changes.
At some point, it would also be good to eliminate UCSD as the single point of failure for all this route distribution.
--Bart
On 3/29/2014 3:07 PM, Chris wrote: (Please trim inclusions from previous messages) _______________________________________________ I have started work on an API that will allow straight forward querying of the gateways database from remote scripts.
As you do this, can you please give consideration to implementing an event-push system as well as supporting polling?
Actually that's a good idea, would others be interested? if so, any preference on a protocol for the data exchange or doesn't it matter? I.e. if I make up my own proprietary system as long as it's published on the wiki with some sample scripts?
73 Chris G1FEF
Think its a great idea however, I would need someone to tell me how to implement it :-)
Andy G0HXT
On 31 Mar 2014, at 06:22, G1FEF chris@g1fef.co.uk wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 3/29/2014 3:07 PM, Chris wrote: (Please trim inclusions from previous messages) _______________________________________________ I have started work on an API that will allow straight forward querying of the gateways database from remote scripts.
As you do this, can you please give consideration to implementing an event-push system as well as supporting polling?
Actually that's a good idea, would others be interested? if so, any preference on a protocol for the data exchange or doesn't it matter? I.e. if I make up my own proprietary system as long as it's published on the wiki with some sample scripts?
73 Chris G1FEF
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
The question comes up again and again. At one point, someone (Chris, Brian, ?) posted the update intervals for the encaps file and the RIP updates. It clearly defined how long it would take before any change on the portal showed up in both outputs. But I can't find it and it's really info that should be posted on the wiki.
Can someone who knows the details post the info on the wiki?
And for any future topics like that, if you're the person providing the answer, can you post the answer on the wiki and then send a link on the list? Sending the info to the list virtually guarantees that it will be unfindable after a few months and we'll continue to have a black hole in the amprnet documentation.
Michael N6MEF
-----Original Message----- From: 44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu [mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Marc, LX1DUC Sent: Saturday, March 29, 2014 2:50 AM To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Can't add redundant AMPR gateway to portal
(Please trim inclusions from previous messages) _______________________________________________ On 29/03/2014 01:36, Marc, LX1DUC wrote:
(The version on the portal seemed to be generated on request... let's see how current the FTP version will be...)
Well I have been watching the FTP file, it seems from my perspective that the delay is more than 1 hour, or the file has been generated irregularly in the last hours.
It's a pity. Networks with dynamic IP addresses changing once a day (disconnect forced by ISP) will be unreachable from other 44net networks for up to the delay of regeneration of the encap.txt file.
Those disconnecting more frequently will be unreachable for a good part of the day.
The HTTP link allowed me to have an up2date encap.txt whenever I needed it.
I would like to suggest to add a 2nd way to access the HTTP link automatically. For example via a "key" provided as an option:
https://portal.ampr.org/getdata.php?key=.....
The value of the key could be calculated from
md5(concat(ftpusername,':',ftppassword)) or md5(concat(portalusername,':',portalpassword))
73 de Marc
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 29/03/2014 16:21, Michael E Fox - N6MEF wrote:
It clearly defined how long it would take before any change on the portal showed up in both outputs.
I saw file versions for today, generated at 03:45 (v3.733) and 15:55 (v3.734).
Seems like the file is updated every 12 hours...
73 de Marc
Last change in the broadcasts today was at 16:20 UTC...
-----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: Saturday, March 29, 2014 19:12 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Can't add redundant AMPR gateway to portal
(Please trim inclusions from previous messages) _______________________________________________ On 29/03/2014 16:21, Michael E Fox - N6MEF wrote:
It clearly defined how long it would take before any change on the portal showed up in both outputs.
I saw file versions for today, generated at 03:45 (v3.733) and 15:55 (v3.734).
Seems like the file is updated every 12 hours...
73 de Marc _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
The portal database is realtime, in other words if someone updates their gateway entry on the portal (or via the email robot) the encap file you can download from the portal will contain the new data.
There is a cron job that runs every 5 minutes, it checks to see if the encap version is different from the last time it ran, if it is not the script exits, if the version is different it regenerates the FTP encap file and also emails the new encap file to anyone that selected the "Only when changed" option on the portal.
There are other cron jobs that run periodically to service the "Daily", "Weekly" and "Monthly" emailing of the encap file.
I'm in the middle of a house move, so no Internet ATM, just got 3G on my iPad for email, but I will add a wiki page about the encap file when I can. I will include a more detailed description of the whole process as well as what options are available.
Regards, Chris
Sent from my iPad
On 29 Mar 2014, at 17:12, "Marc, LX1DUC" lx1duc@laru.lu wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 29/03/2014 16:21, Michael E Fox - N6MEF wrote: It clearly defined how long it would take before any change on the portal showed up in both outputs.
I saw file versions for today, generated at 03:45 (v3.733) and 15:55 (v3.734).
Seems like the file is updated every 12 hours...
73 de Marc _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 28/03/2014 21:58, Tom Hayward wrote:
AMPR IPIP tunnels are currently broken for our network, 44.24.240.0/20. 44.24.240.0/20 is multi-homed. We have two edge routers. We originate IPIP tunnels from both routers, but other AMPR systems only accept IPIP traffic from one of the routers. Why? The second gateway IP is not in the encap file.
The problem with 2+ gateway for a single network is that with IPIP we don't know if a packet has been delivered to your gateway or not. We only know to encap traffic towards you into IPIP towards a destination IP. Once the IPIP packet has left my gateway, the packet is gone, wether it has been sent to a gateway that is currently reachable or not.
So actually 2+ gateways does NOT give you redundancy, for that we would need to know the state of your gateways and stop using unavailable gateways. So the only thing you might get is round robin packet delivery if ECMP is supported by my gateway. Debugging a failure situation in such a setup could be very hard.
Until such time that networks are announced directly by their gateways using some existing or new routing protocol or ...., there will be no possibility to have redundancy.
However you can add 1 single IP to the gateway list and than anycast that IP from different machines in the same or different locations, that way the routing protocols used to announce and reach your anycast IPIP endpoint will take care of the necessary redundancy. There might be other ways... YMMV.
73 de Marc
On 3/28/2014 5:59 PM, Marc, LX1DUC wrote:
On 28/03/2014 21:58, Tom Hayward wrote:
AMPR IPIP tunnels are currently broken for our network, 44.24.240.0/20. 44.24.240.0/20 is multi-homed. We have two edge routers. We originate IPIP tunnels from both routers, but other AMPR systems only accept IPIP traffic from one of the routers. Why? The second gateway IP is not in the encap file.
The problem with 2+ gateway for a single network is that with IPIP we don't know if a packet has been delivered to your gateway or not. We only know to encap traffic towards you into IPIP towards a destination IP. Once the IPIP packet has left my gateway, the packet is gone, wether it has been sent to a gateway that is currently reachable or not.
So actually 2+ gateways does NOT give you redundancy, for that we would need to know the state of your gateways and stop using unavailable gateways. So the only thing you might get is round robin packet delivery if ECMP is supported by my gateway. Debugging a failure situation in such a setup could be very hard.
Until such time that networks are announced directly by their gateways using some existing or new routing protocol or ...., there will be no possibility to have redundancy.
However you can add 1 single IP to the gateway list and than anycast that IP from different machines in the same or different locations, that way the routing protocols used to announce and reach your anycast IPIP endpoint will take care of the necessary redundancy. There might be other ways... YMMV.
Yup, you're right. We're moving forward with an anycast solution for our IPIP tunnel termination/origination to achieve redundancy.
--Bart
-
Andy Brittain -
Bart Kus -
Brian Kantor -
Chris -
Eric Fort -
G1FEF
-
Marc, LX1DUC -
Marius Petrescu -
Michael E Fox - N6MEF -
on4hu -
Tom Hayward