14 Nov
2014
14 Nov
'14
8:19 p.m.
Subject:
Re: [44net] Attn LX gateway
From:
"Marc, LX1DUC" <lx1duc(a)laru.lu>
Date:
11/14/2014 12:25 AM
To:
44net(a)hamradio.ucsd.edu
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/11/2014 21:46, Rob Janssen wrote:
As Rob seems to have had issues finding the correct contact email
address for the IP address mentioned, I thought this might be helpful
to share with the group:
For IP addresses allocated by RIPE there is the Abuse (Contact) Finder:
https://apps.db.ripe.net/search/abuse-finder.html
Not each and every network has updated to the latest RIPE policies,
but it's always worth a shot:-)
73 de Marc
It is also helpful when some contact or identifying information is present in the
gateway listing on portal.ampr.org.
In this case it only points to a clubstation with an info address, but via that I was
able to get the message forwarded to you.
It would have been helpful when your callsign and/or e-mail had been present
in the portal listing.
73,
Rob
15 Nov
15 Nov
9:02 a.m.
New subject: amprgw - am I misunderstanding something?
Hi folks.
I'm adding a rip44 processor and ipip tunnel support to my BPQ32/LinBPQ
networking software.
I've set up an encap entry for 44.131.56.0/27 and I receive the block of
RIP44 messages every 5 minutes, and random packets addressed to 44.131.56.1,
presumably from network scanners. If I ping 44.131.56.1 from a normal
internet host I also see the encapsulated packets. So far so good. But if I
try pinging any other address in my subnet, I don't get anything. I'd expect
amprgw to send me packets for any address in my subnet.
Am I misunderstanding how amprgw is supposed to work?
Thanks,
John G8BPQ
9:16 a.m.
New subject: amprgw - am I misunderstanding something?
On 15/11/2014 5:02 PM, John Wiseman wrote:
But if I
try pinging any other address in my subnet, I don't get anything. I'd expect
amprgw to send me packets for any address in my subnet.
Do the other addresses in
your subnet that you're trying to ping have
ampr.org DNS entries? If not, then no forwarding of those IPs by amprgw.
73
Gavin
VK6HGR
--
Gavin Rogers | Amateur radio station VK6HGR
http://www.livingwaters.com/good | http://vk6hgr.ampr.org/
MSN/Skype/Email: grogers(a)vk6hgr.echidna.id.au
9:29 a.m.
New subject: amprgw - am I misunderstanding something?
amprgw has a filter in it that only allows traffic to hosts that
are in the DNS. 44.131.56.1 is there; 44.131.56.2 is not, so pings
and other traffic to 44.131.56.2 will not be forwarded.
- Brian
On Sat, Nov 15, 2014 at 09:02:09AM -0000, John Wiseman wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Hi folks.
I'm adding a rip44 processor and ipip tunnel support to my BPQ32/LinBPQ
networking software.
I've set up an encap entry for 44.131.56.0/27 and I receive the block of
RIP44 messages every 5 minutes, and random packets addressed to 44.131.56.1,
presumably from network scanners. If I ping 44.131.56.1 from a normal
internet host I also see the encapsulated packets. So far so good. But if I
try pinging any other address in my subnet, I don't get anything. I'd expect
amprgw to send me packets for any address in my subnet.
Am I misunderstanding how amprgw is supposed to work?
Thanks,
John G8BPQ
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
10:56 a.m.
New subject: amprgw - am I misunderstanding something?
Which may need clarification for some - how to get an address into the DNS.
On Sat, November 15, 2014 4:29 am, Brian Kantor wrote:
amprgw has a filter in it that only allows traffic to
hosts that are in the
DNS. 44.131.56.1 is there; 44.131.56.2 is not, so pings
and other traffic to 44.131.56.2 will not be forwarded. - Brian
--
Charles J. Hargrove - N2NOV
NYC ARECS/RACES Citywide Radio Officer/Skywarn Coord.
NYC-ARECS/RACES Net Mon. @ 8:30PM 147.360/107.2 PL
http://www.nyc-arecs.org and http://www.nyc-skywarn.org
NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM
on 7.036 Mhz USB/1500 hz waterfall spot; Olivia 8/500 check-ins
"Information is the oxygen of the modern age. It seeps through the walls topped
by barbed wire, it wafts across the electrified borders." - Ronald Reagan
"The more corrupt the state, the more it legislates." - Tacitus
"Molann an obair an fear" - Irish Saying
(The work praises the man.)
"No matter how big and powerful government gets, and the many services it
provides, it can never take the place of volunteers." - Ronald Reagan
11:26 a.m.
New subject: amprgw - am I misunderstanding something?
Thanks, Brian, and others who have responded.
That was the fact I was missing!
73, John
-----Original Message-----
From: 44net-bounces+john.wiseman=cantab.net(a)hamradio.ucsd.edu
[mailto:44net-bounces+john.wiseman=cantab.net@hamradio.ucsd.edu] On Behalf
Of Brian Kantor
Sent: 15 November 2014 09:30
To: AMPRNet working group
Subject: Re: [44net] amprgw - am I misunderstanding something?
(Please trim inclusions from previous messages)
_______________________________________________
amprgw has a filter in it that only allows traffic to hosts that
are in the DNS. 44.131.56.1 is there; 44.131.56.2 is not, so pings
and other traffic to 44.131.56.2 will not be forwarded.
- Brian
3:01 p.m.
New subject: amprgw - am I misunderstanding something?
John et al;
On Sat, 2014-11-15 at 09:02 +0000, John Wiseman wrote:
I'm adding a rip44 processor and ipip tunnel
support to my BPQ32/LinBPQ
networking software.
As you know from 44.48.0.42, ampr-ripd and a standard linux tunnel works
fine for your software and has for the past year and a half or so; but
for the windows environments to be able to handle rip/ipencap this I'm
sure would be a welcomed thing for those folks.
I've set up an encap entry for 44.131.56.0/27 and
I receive the block of
RIP44 messages every 5 minutes, and random packets addressed to 44.131.56.1,
presumably from network scanners. If I ping 44.131.56.1 from a normal
internet host I also see the encapsulated packets. So far so good. But if I
try pinging any other address in my subnet, I don't get anything. I'd expect
amprgw to send me packets for any address in my subnet.
As Brian mentioned, commercial<>amprnet requires dns entries for the IPs
you want publicly routable, however if you only want to stay within the
amprnet, the portal entry should be enough as 44<>44 routing is
point-to-point. This excludes those announced via BGP. This may be a
useful scenario for test environments on a larger scale, and sites that
are RF only.
--
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
3:59 p.m.
New subject: Unable to edit gateway on portal
Hi
Anyone else having a blank page when you try to edit your own gateway on the portal?
Andy
G0HXT
4:04 p.m.
New subject: Unable to edit gateway on portal
Andy.
Same story here :((
Tom - SP2L
(ex sp2lob)
4:06 p.m.
New subject: Unable to edit gateway on portal
Andy.
Something went totally askew... :(
Best regards.
Tom - SP2L
(ex sp2lob)
6:36 p.m.
New subject: Unable to edit gateway on portal
I have temporarily disabled the ability to edit gateways whilst I work on the code.
Chris
On 15 Nov 2014, at 15:59, Andy Brittain
<g0hxt(a)greatbrittain.co.uk> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Hi
Anyone else having a blank page when you try to edit your own gateway on the portal?
Andy
G0HXT
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
18 Nov
18 Nov
1:20 p.m.
New subject: amprgw ok?
Hi.
I'm not seeing any rip44 packets from amprgw, though I'm getting IPIP
packets from other gateways. Is it just me or is there a general problem?
Thanks,
John
1:51 p.m.
New subject: amprgw ok?
John et al.
Checked just while ago:
sp2l@linux:/# rip44d -d -i tunl0 -vvv
found local address: 44.165.2.2
found local address: 44.165.15.1
found local address: 192.168.0.101
found local address: 127.0.0.1
opening UDP socket 520...
entering main loop, waiting for RIPv2 datagrams
received from 44.0.0.1: 520: 124 bytes
RIPv2 packet contains password <PasswordGoesHere> but we require none
...
and nothing more follows...
Seems that something went askew.
Whereas, usually there is at least 18 lines received.
Best regards.
--
Tom - SP2L
(ex sp2lob)
------------------------------------
It is nice to be important.
But it is more important to be nice!
1:54 p.m.
New subject: amprgw ok?
It is being worked on.
On 18 Nov 2014, at 13:51, SP2L <SP2L(a)wp.pl>
wrote:
(Please trim inclusions from previous messages)
_______________________________________________
John et al.
Checked just while ago:
sp2l@linux:/# rip44d -d -i tunl0 -vvv
found local address: 44.165.2.2
found local address: 44.165.15.1
found local address: 192.168.0.101
found local address: 127.0.0.1
opening UDP socket 520...
entering main loop, waiting for RIPv2 datagrams
received from 44.0.0.1: 520: 124 bytes
RIPv2 packet contains password <PasswordGoesHere> but we require none
...
and nothing more follows...
Seems that something went askew.
Whereas, usually there is at least 18 lines received.
Best regards.
--
Tom - SP2L
(ex sp2lob)
------------------------------------
It is nice to be important.
But it is more important to be nice!
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
4:10 p.m.
New subject: amprgw ok?
Summary:
There is damage to the database.
Chris says he's working on it.
- Brian
4:14 p.m.
New subject: amprgw ok?
Brian;
On Tue, 2014-11-18 at 08:10 -0800, Brian Kantor wrote:
Summary:
There is damage to the database.
Chris says he's working on it.
Thank you.. and Chris too!
--
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
5:05 p.m.
New subject: amprgw ok?
Brian, Chris, thank you for your efforts.
I took a look at the latest sent encap info and I want to bring in
discussion the way how some gateways are announced.
route addprivate 44.24.240/20 encap 44.24.221.1
Now this one is ok. The gateway (44.24.221.1) is BGP announced, but not in
the encap file. Everything ok and working.
Now to the other two IMHO are wrong:
route addprivate 44.151.94.28/32 encap 44.151.94.28
So this host expects to get encapsulated traffic to a gateway which is the
host itself. This leeds to a routing loop and is not possible with a regular
setup.
This encap entry is in fact plain and simple useless: It states 'you can
reach me via me' which gives not much information.
route addprivate 44.140/16 encap 44.140.0.1
The
same applies to the above, just that the whole subnet is routed to a
gateway which is part of that subnet itself.
The idea is that a route can not point to a gateway for which the route is
resolved by the route itself.
It may be said that those are BGP routed subnets and the gateway is directly
reacheable.
But the routing is resolved by the route with the most specific netmask. In
this case exactly the one which defines the host (or subnet) itself.
Unless there is a mechanism available to mark those gateways and create a
higher priority route to them so they can be reached directly, this is not
functional.
Please comment on a possible sollution/approach on those setups.
73s de Marius, YO2LOJ
5:20 p.m.
New subject: amprgw ok?
Marius et al;
On Tue, 2014-11-18 at 19:05 +0200, Marius Petrescu wrote:
What if we were to change the "addprivate" flag for those BGP announced
to something like "addbgp" and have ripv2 either ignore it in its
broadcasts and in the encap.txt (which xnos should ignore also) or some
flag which would exclude it from being routed via ipencap?
The multitude of linux/xnos/bpq/etc users wouldn't have to all include
exceptions for these routes then, it'd be automagic no?
--
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
route
addprivate 44.151.94.28/32 encap 44.151.94.28
So this host expects to get
encapsulated traffic to a gateway which is the
host itself. This leeds to a routing loop and is not possible with a regular
setup.
This encap entry is in fact plain and simple useless: It states 'you can
reach me via me' which gives not much information.
8:27 p.m.
New subject: amprgw ok?
We think everything is ok now. Please advise if otherwise.
- Brian
8:38 p.m.
New subject: amprgw ok?
Brian and Chris;
On Tue, 2014-11-18 at 12:27 -0800, Brian Kantor wrote:
We think everything is ok now. Please advise if
otherwise.
From what I can see, things look good.
Thanks for
the efforts!
--
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
19 Nov
19 Nov
8:54 a.m.
New subject: Tunnels and BGP routing
Sorry to push this, but I think we really need an agreed solution for this
topic.
I wish to emphasize some use cases so we can find a common approach
(assuming that he 44/8 route via ampr-gw is gone).
All descriptions are from the point of view of the "regular" tunneled
gateway.
1. 44 subnet, BGP announced, with a public IP available for tunneling
This doesn't pose any problems. Has to be published in the encap file,
regular route handling is OK.
If direct non-tunneling access is desired, the entry has to be ignored in
the encap/RIP data.
Can be implemented by adding a higher priority (lower metric) route to
that subnet via default gw, or add the GW address to the rip daemon ignore
option.
Drawback on direct access would be that ham traffic can not be identified
as such (because of NAT), except when originating on other BGP announced
44 subnets.
Using src-address filtering with gw data from the encap can increase
security.
2. 44 subnet, BGP announced, with a public 44 tunnel gateway address, not
present in the encap/RIP data
This should also work without problems, as long as there is no default
44/8 route.
The same issues as in (1) apply.
3. 44 subnet, BGP announced, with 44 public tunnel gateway address in the
same subnet.
In this case, tunnel access is prevented by a routing loop.
There are solutions for this, but none of them automaticaly (for the moment).
a. A specific route can be defined for the tunnel gateway via default
gateway. This will allow the gateway to be direct reachable, and all the
traffic for the subnet will be tunneled to it.
One major drawback is the fact that the gateway itself will not be
reachable via that tunnel.
b. Outgoing proto 4 (ipip) traffic can be marked and handled by a separate
routing table, so that it can be directed to that specific gw host.
c. The route can be ignored in encap/RIP, and accessed directly, of course
ham traffic from non-BGP announced hosts will not be distinguishable from
regular traffic, except if src-address filtered based on encap data.
4. Single 44 host, BGP announced, accepting tunnel connections to it.
Here, the only option would be to policy route the outgoing ipip traffic
to the default system gateway, as described in (3).
Conclusion:
The universal solution would actually be that outgoing proto 4 (ipip)
traffic should be marked and handled by a separate routing table and NATed
to the system's gateway address.
This should not affect any routes except when using private ipip tunnels
to other gateways, in which case specific routes have to be added to that
routing table.
This could be implemented in the ampr-ripd daemon and done automatically
using a secondary routing table, for all RIP routes which have a 44
gateway address.
I assume this could also be done in xNOS systems.
Have a nice day,
Marius, YO2LOJ
15 Nov
15 Nov
4:26 p.m.
New subject: Attn LX gateway
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It would have been helpful when your callsign and/or
e-mail had
been present in the portal listing.
Well I'm not the only sysadmin for this gateway and I'm surely not
available 24/7, that's why the portal lists the organisation whose
sysadmins jointly co-administrate the gateway, so that whatever
happens to an individual member the sysadmins will always remain
reachable using a single point of contact.
However I'm discussing the publication of IRT contact data
specifically tailored to AMPR sysadmins and provide the link to the
IRT data within the gateway notes.
73 de Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBAgAGBQJUZ37BAAoJEHFIN1T8ZA8vtOQP/i1R37Gsp8HlBofY9fFwDqLx
J8Y39Mrg15HW/D9R/ST+CAjOPYH92Cv6DVkzjbpOgE5Si1jRpapds7zW+sKu6lCq
GXjD+AGhzQ4t/PR4BVu7uaWpxi+yWxDpFdPdmCSzoeANwkYg+kz6X/wiQVF3NZpB
d6ddvJGDk+yyTUBaRfj0dWrZ/sVN9DY0bUYOg8sT9+m1UZgS3Do1sZDJdfQaSbq1
KRoqOGJ90bqJ0+8FzRrjcLDKoRB0oqrxCuHNiW/8R2F+eGq+GqzxI3uGVXk6vGfn
vLErH8PXzx4uR+anKi7tc30YQiltu+vgbhi1OTzKM3I4t7gd84Tvb9CqEJy0z1dt
skHkmYzjDAyfxRBHT7S4HBF8rngXEOfQ03MY0ImjLBh3x/SO+Fk1Xzplnafj412l
R0wAmb/9md4brMC/bNbieYfd14ZFL7eiRgHAeCQw3AeZwrBu4vsjUWtpS+v2ebr+
pEGfrnsObS2qaW54VjcWozaq6gUQvPO7OO6MbpL8VoX3G3qgh4WObF2GWfF96Fvf
YjuHbNbM0jDX6b8aM8wBXFUjUHw4TOduO9JS4qhztfptsWoTOz5HIq3fC53GaEmj
0nxeYghSvOzNbRBe5xnFegKM2raT5B2QKuwOgro5DLVsLuQ+zO1swpxHUYMVQcYm
PU3t8mBEbLzqUmu/o6dZ
=Ln+I
-----END PGP SIGNATURE-----
25 Nov
25 Nov
4:20 p.m.
New subject: Attn LX gateway
However I'm discussing the publication of IRT
contact data
specifically tailored to AMPR sysadmins and provide the link to the
IRT data within the gateway notes.
We have published an update to our gateway entry
https://portal.ampr.org/gateways_list.php?a=view&id=533
it now references a CERT contact page
http://laru.lu/working-groups/digital-data-networks-ddc/147-cert-en.html
Comments welcome.
vy 73
--
Marc, LX1DUC
--
www.laru.lu - Luxembourg Amateur Radio Union
www.emcomm.services - Emergency Communication
www.ham-dmr.lu - DMR Infos for HAMs
16 Nov
16 Nov
12:36 p.m.
New subject: ampr-ripd 1.12 released
Hello OMs,
Following the idea from Rob, PE1CHL, I added the possibility to execute a
system command from ampr-ripd if routes are set or changed.
This will happen on startup, after an existing encap is found in
/var/lib/ampr-ripd, or after 30 seconds after a RIP update, if there is a
change in the encap data (AFTER saving the new encap file if requested).
There are no other changes in the code. If you do not need this feature, no
update is required.
You can get the changes from GitHub: https://github.com/yo2loj/ampr-ripd
Or the usal locations:
inet: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.12.tgz
44net: http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.12.tgz
73s
Marius, YO2LOJ
20 Nov
20 Nov
12:23 a.m.
New subject: ampr-ripd 1.13 released
Hello OMs,
Following the recent outage at ampr-gw and the latest discussions, I did
some modifications to the daemon.
Routing:
- Ignore subnets for which the gateway is inside their own subnet
RIP forwarding:
- Reconstruct forwarded RIP messages to be able to send them even on ampr-gw
outages
- Forwarded local RIP messages do not use authentication anymore
- Forwarded local RIP messages are sent 30 seconds after a RIP update,
otherwise every 29 seconds
You can get the changes from GitHub: https://github.com/yo2loj/ampr-ripd
Or the usual locations:
inet: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.13.tgz
44net: http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.13.tgz
73s
Marius, YO2LOJ
3448
days inactive
3459
days old
24 comments
13 participants
participants (13)
-
Andy Brittain -
Brian -
Brian Kantor -
Charles Hargrove -
Chris -
G1FEF
-
Gavin Rogers -
John Wiseman -
Marc, LX1DUC -
Marius Petrescu -
marius＠yo2loj.ro
-
Rob Janssen -
SP2L