25 Mar
2014
25 Mar
'14
2:40 p.m.
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.
28 Mar
28 Mar
4:58 p.m.
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(a)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.
>
5:20 p.m.
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(a)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(a)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.
>
5:24 p.m.
On Fri, Mar 28, 2014 at 2:20 PM, Marius Petrescu <marius(a)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
5:55 p.m.
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.
5:59 p.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
6:10 p.m.
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(a)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,
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net 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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net 
6:26 p.m.
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(a)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
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
On 28 Mar 2014, at 21:59, Bart Kus
<me(a)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
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net 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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
6:34 p.m.
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(a)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(a)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(a)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(a)hamradio.ucsd.edu
>>>> http://hamradio.ucsd.edu/mailman/listinfo/44net
>>>
>>> _________________________________________
>>> 44Net mailing list
>>> 44Net(a)hamradio.ucsd.edu
>>> http://hamradio.ucsd.edu/mailman/listinfo/44net
>>
>> _________________________________________
>> 44Net mailing list
>> 44Net(a)hamradio.ucsd.edu
>> http://hamradio.ucsd.edu/mailman/listinfo/44net
>
6:37 p.m.
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(a)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(a)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(a)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(a)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(a)hamradio.ucsd.edu
> >>>> http://hamradio.ucsd.edu/mailman/listinfo/44net
> >>>
> >>> _________________________________________
> >>> 44Net mailing list
> >>> 44Net(a)hamradio.ucsd.edu
> >>> http://hamradio.ucsd.edu/mailman/listinfo/44net
> >>
> >> _________________________________________
> >> 44Net mailing list
> >> 44Net(a)hamradio.ucsd.edu
> >> http://hamradio.ucsd.edu/mailman/listinfo/44net
> >
8:12 p.m.
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
6:03 p.m.
On Fri, Mar 28, 2014 at 2:55 PM, Chris <chris(a)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
8:36 p.m.
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
29 Mar
29 Mar
4:47 a.m.
On 29 Mar 2014, at 00:36, "Marc, LX1DUC"
<lx1duc(a)laru.lu> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
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.
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
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
5:42 a.m.
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
11:44 a.m.
On Sat, Mar 29, 2014 at 1:47 AM, Chris <chris(a)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
5:50 a.m.
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
6:17 a.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net > http://on4hu.be/ ftp://ftp.on4hu.be
http://on4hu.be:81
> COMPUTER ARE LIKE AIR-CONDITIONNERS THE
> STOP WORKING AS SOON YOU OPEN WINDOWS
> for 44net use http://44.144.11.137:81/
6:07 p.m.
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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
30 Mar
30 Mar
12:20 a.m.
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
31 Mar
31 Mar
1:22 a.m.
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? 
2:52 p.m.
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(a)g1fef.co.uk> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
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(a)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.
As you do this, can you please give consideration to implementing an event-push system as
well as supporting polling? 
29 Mar
29 Mar
11:21 a.m.
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(a)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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
1:12 p.m.
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
2:14 p.m.
Last change in the broadcasts today was at 16:20 UTC...
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
5:59 p.m.
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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
28 Mar
28 Mar
8:59 p.m.
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
30 Mar
30 Mar
12:23 a.m.
On 3/28/2014 5:59 PM, Marc, LX1DUC wrote:
_______________________________________________
On 28/03/2014 21:58, Tom Hayward wrote:
Yup, you're right. We're moving forward with an anycast solution for
our IPIP tunnel termination/origination to achieve redundancy.
--Bart
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.
3888
days inactive
3894
days old
29 comments
11 participants
participants (11)
-
Andy Brittain -
Bart Kus -
Brian Kantor -
Chris -
Eric Fort -
G1FEF
-
Marc, LX1DUC -
Marius Petrescu -
Michael E Fox - N6MEF -
on4hu -
Tom Hayward