> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> "Marius Petrescu" <marius(a)yo2loj.ro>
> Date:
> 06/06/2015 09:48 PM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Hi Rob,
>
> I was quite active in the Mikrotik community and tried to push a little our
> ampr tunnel stuff.
> But the results are actually null. People are friendly but not interested.
Ok... at the moment I am reading the forum to see how change requests actually are
to be posted and how they are handled, as I have some other requests.
> The missing element is a way to create an IPIP interface without a specific
> peer IP, and add routes to specific peers on a given IPIP interface to get
> it in multipoint mode.
That is clear, yes. I already found that the do not support static routes being bound to
interfaces, let alone "onlink" routes. So even when you would want to load routes using
a script, it still cannot be done. They must have a reason for this (probably they want
to keep the routing entirely clean according to common practices), as the Linux kernel
can do a lot more than what they expose via the config interface.
>
> The easiest way to get ampr up fully is actually to set up a metarouter on a
> mipsbe routerboard (they have a xen virtualization on those), and run a
> OpenWRT in it, to do IPIP encap and run ampr-ripd. I have tried that, it
> works, but at the moment I use a PPC based routerboard which doesn't offer
> virtualization.
> But your RB2011 is a good candidate for this kind of setup, being mipsbe
> based. Others would be the RB45x, the RB75x, the RB95x and the OmniTik
> series.
As I wrote, I have no need for this because my RB2011 has a radio link to HAMNET and
as a backup I can setup an IPsec VPN to our gateway. So I don't need to be on the IPIP
mesh. And I still have a Linux system in colocation (a Raspberry Pi) that is on IPIP.
But for others, this approach can be interesting.
Some systems e.g. www.pe1chl.ampr.org and hampi.pe1chl.ampr.org are routed over
this radio link and the MikroTik (but there is no useful content on them).
>
> Regarding to linux: They run a proprietary distribution on a 3 kernel, but
> shell access is unfortunately not available, and there is no way to add 3-rd
> party extensions.
>
The device can be "rooted", though. You get a busybox shell. I have not done that yet,
it will probably make it difficult to get support in case I encounter some bug I want to be fixed.
Rob
Maybe we should recommend some outbound firewalling for such known nuisances?
To reduce traffic, drop neighbor discovery and smb as well as MikroTik
Neighbor Discovery Protocol on tunl0 (optional, but a good idea):
iptables -A OUTPUT -o tunl0 -p udp --dport 10001 -j DROP
iptables -A OUTPUT -o tunl0 -p udp --dport 137:139 -j DROP
iptables -A OUTPUT -o tunl0 -p udp --dport 5678 -j DROP
81.174.253.193 2014-02-23 11:14:58 G7UOD
24.85.103.226 2014-05-22 15:26:56 VE7ASS
> Subject:
> Re: [44net] Strange Broadcasts...
> From:
> "Marius Petrescu" <marius(a)yo2loj.ro>
> Date:
> 06/06/2015 08:54 AM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> The iptables solution doesn't apply to Mikrotik equipment since they don't
> run Linux.
Of course they are! It is easy to add iptables rules like that to a MikroTik router.
But even easier to just turn off the sending of the MNDP packets.
> The Mikrotik Neighbor Discovery Protocol (MNDP) is enabled by default on
> newly created IPIP interfaces.
> And since there is such an interface for each mesh partner, they are
> probable programatically generated by a script.
Well, running IPIP mesh on a MikroTik may not be a good idea. At least not until it
supports ampr-ripd so you can run just a single IPIP interface for the entire mesh,
and use a separate routing table updated by RIP messages.
(similar to the situation with other commercial routers like Cisco and Juniper)
Did anyone ever try to get such a change incorporated by the MikroTik people?
I have no idea how friendly they are to such specialized requests, but on the other
hand they have a very broad collection of exotic protocols and configuration items.
(I just got a 2011UiAS-2HnD this week, and I am impressed. I will use it as my home
router, but not on the IPIP mesh, it will be connected to my Ubiquiti Airgrid with a link
to the local HAMNET which again is linked to our gateway)
Rob
I was at NANOG 64 <https://www.nanog.org/meetings/nanog64/home> this week and
picked up an Atlas Probe from RIPE. <https://atlas.ripe.net>
I've got it online here on my 44net space in Florida.
https://atlas.ripe.net/probes/18550/
Don't know if anyone else has one online on 44net, or the AMPRnet, but it
might be of interest to the group.
You can also sign up and get a probe, might be cool to have a few spread out
on the BGP speakers and at the main gateway.
They are trivial to configure, DHCP and then it manages it self from there.
73's, W9CR
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
So on my jnos machine, every minute without fail, I see the following
broadcast on tun0:
Fri Jun 5 14:22:01 2015 - tun0 recv:
IP: len 168 81.174.253.193->192.168.1.149 ihl 20 ttl 243 tos 160 prot IP
IP: len 148 44.131.160.1->255.255.255.255 ihl 20 ttl 64 DF prot UDP
UDP: len 128 5678->5678 Data 120
0000 ..<.....teqgate01....6.27....MikroTik....."".....ILXI-T3GZ....RB
0040 1200......................Ug.....ipip-ampr-24.85.103.226
Fri Jun 5 14:22:01 2015 - tun0 recv:
IP: len 168 81.174.253.193->192.168.1.149 ihl 20 ttl 243 tos 160 prot IP
IP: len 148 44.131.160.1->255.255.255.255 ihl 20 ttl 64 DF prot UDP
UDP: len 128 5678->5678 Data 120
0000 ..<.....teqgate01....6.27....MikroTik....."".....ILXI-T3GZ....RB
0040 1200......................Ug.....ipip-ampr-24.85.103.226
(encap) 44.131.160.1->255.255.255.255 DF UDP
0000 ..<.....teqgate01....6.27....MikroTik....."".....ILXI-T3GZ....RB
0040 1200......................Ug.....ipip-ampr-24.85.103.226
Fri Jun 5 14:22:01 2015 - tun0 sent:
IP: len 148 44.131.160.1->255.255.255.255 ihl 20 ttl 63 DF prot UDP
UDP: len 128 5678->5678 Data 120
0000 ..<.....teqgate01....6.27....MikroTik....."".....ILXI-T3GZ....RB
0040 1200......................Ug.....ipip-ampr-24.85.103.226
Why is this happening? Anyone else seeing this stuff?
Best,
jerome - ve7ass
Vancouver
> Subject:
> Re: [44net] Bad MX records in the ampr.org DNS
> From:
> Tom Hayward <esarfl(a)gmail.com>
> Date:
> 06/02/2015 10:01 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
>> I'm not sure if this is how everyone does it, but we (HamWAN) had to
>> make DNS changes via our regional coordinator. We would construct an
>> email in AMPR DNS robot format and send it to him, then he would
>> forward it to the robot. This added quite a bit of latency (half day
>> plus) to our updates and quite a workload for our regional coordinator
>> (our network is growing fast).
I think when you are responsible for some subnet and you have frequent updates,
it would be trivial to get you registered as submitter of updates to the DNS robot.
Also, there should be DNS update functionality in the portal and it should be possible
to be a regional coordinator there, so you can approve the updates for your network.
However, that function is still not completed.
I think that when problems are encountered, solutions should be sought that result
in a clear and workable solution for everyone, not a fork of the main system. Effort
spent on running a DNS for a subdomain had better been spent on a usable update
mechanism for the main DNS.
Rob
> Subject:
> Re: [44net] Bad MX records in the ampr.org DNS
> From:
> Brian Kantor <Brian(a)UCSD.Edu>
> Date:
> 06/02/2015 04:08 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> There are seven AMPR.ORG and 44.in-addr DNS servers located around the
> world. The chance that all of them will be down at once is close to zero.
> We allow people to AXFR their content so it is perfectly possible
> to have a redundant DNS server on your local net which can answer queries
> regarding those zones even if you are partitioned from the Internet somehow.
>
Indeed... I don't see a reason to have a private nameserver for a subdomain either.
The ampr.org nameserver works well, it allows updates, maybe the only thing that could
be nice is the ability to set TXT and other records. Having a subdomain just makes things
more complex.
The only reason I did a replication of the zone is that a local amateur who is running a
newscast was telling the world that one of the advantages of AMPRnet/HAMNET is that
it would continue to work when Internet was down. I explained him that it is not that
straightforward as we depend on Internet services, most notably DNS.
I thought a bit and decided to load the ampr.org zone in a nameserver on our gateway
that already is working as a caching resolver for our 44.137.0.0/16 subnet. I think now
it will resolve ampr.org names even without a connection (although I have not fully tested that
yet). Of course only those names that are in the ampr.org zone, not those that are below
a subdomain served by some other server. But we cannot cache the entire world's DNS,
and only the ampr.org zone should be sufficient to connect most wellknown systems.
I did not use AXFR, I download the zone from ftp://hamradio.ucsd.edu/pub/ampr.tar.gz
Both methods have their advantages/disadvantages, I think.
Rob
> Subject:
> Re: [44net] Bad MX records in the ampr.org DNS
> From:
> Don Fanning <don(a)00100100.net>
> Date:
> 05/28/2015 02:45 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> On Wed, May 27, 2015 at 5:36 PM, Bryan Fields<Bryan(a)bryanfields.net> wrote:
>
>>
>>> > >That is not true at all. The previous paragraph states that it must
>>> > >process the entire FQDN and not many any inferences as to the domain's
>>> > >relationship with the FQDN.
>> >
>> >I'd like to try it out then, as I'm certain this doesn't work that way in
>> >most
>> >resolvers for MX's. I've run into it before even.
>> >
>> >
> I can tell you that GMail's MX RR's work in this fashion. I don't need to
> know their A record for my DNS. I just add their CNAME'ed MX records to my
> domain files and my mail shows up. And my domain isn't hosted by them.
> Just my mail hosting.
>
> https://support.google.com/a/answer/33915?hl=en
Indeed, it is allowed to have some record like:
sub.domain IN CNAME another.domain
with
another.domain IN MX 10 hostname
But that is not what I mean. What is NOT allowed (by the spec) is to have:
name IN MX 10 mail
mail IN CNAME some.mail.server
So you can have a CNAME pointing to MX, but not MX pointing to CNAME.
Also, I don't understand the relation to the Google example. The support page you mention gives a
list of MX records with names that are all A and AAAA records, no CNAME involved at all.
In practice, it appears that the CNAME works with some mail transfer agents. But bind9 is complaining.
The literal IP address in an MX record results in 2 warnings, one that there is an address in the MX record
and another that the 111.222.333.444.ampr.org is not defined. This of course is because an address is not
expected there, and it is treated as a domain name relative to the $origin of the zone.
When your server has no associated name, of course you can assign one within ampr.org.
Also, when you want your server to SEND mail in addition to RECEIVING it, you need to have a name and a
matching reverse, or many spamfilters will just drop your mail on the floor.
Rob
Don't get me wrong. I'm not saying people should ignore the RFC1035
standards. I'm just saying its possible. The one's I'm aware of are all
companies using 'In-House' mail systems designed to either keep the mail
staying in-house, and/or prevent outside mail from getting in.
But, as pointed out, this group should be following the RFC1035 standard.
----------
Wm Lewis (KG6BAJ)
AMPR Net IP Address Coordinator - Northern and Central California Regions
(A 100% Volunteer Group)
(530) 263-1595 (Home/Office)
______________________________________________
----------
This message is for the designated recipient only and MAY CONTAIN
PRIVILEGED OR CONFIDENTIAL INFORMATION.
If you have received it in error, please notify the sender immediately and
delete the original. Any other use of this E-mail is prohibited.
At 03:48 PM 5/27/2015, you wrote:
>(Please trim inclusions from previous messages)
>_______________________________________________
>On Wed, May 27, 2015 at 3:41 PM, William Lewis <kg6baj(a)n1oes.org> wrote:
> > Where you say "Owners, please update them with a proper hostname instead of
> > the literal IP address." I would like to point out that it is entirely
> > possible to have an IP address that has no HOSTNAME assigned to it at all.
> > The most common are used for mail. I use 2 that are setup this way for
> > security reasons.
>
>MX records must point to a hostname. Here's a good description of why:
>http://serverfault.com/a/663122
>
>But the bottom line is: it's the spec.
>
>Tom KD7LXL
>_________________________________________
>44Net mailing list
>44Net(a)hamradio.ucsd.edu
>http://hamradio.ucsd.edu/mailman/listinfo/44net
