- 44net - mailman.ardc.net

by Bryan Fields

The hamradionow guy the videos of the 2015 TAPR forum at Dayton up. Thought it may be of interest to the group. https://www.youtube.com/watch?v=eAzkSP2nt0M&feature=youtu.be&t=85 73's W9CR -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

9 years, 11 months

1
0
0 0

Re: [44net] Strange Broadcasts...

by Steve L

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

9 years, 11 months

6
5
0 0

Re: [44net] Strange Broadcasts...

by Rob Janssen

> 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

9 years, 11 months

2
1
0 0

RIPE Atlas Probe on 44net?

by Bryan Fields

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

9 years, 11 months

1
0
0 0

Strange Broadcasts...

by jerome schatten

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

9 years, 11 months

3
4
0 0

Re: [44net] Bad MX records in the ampr.org DNS

by Rob Janssen

> 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

9 years, 11 months

1
0
0 0

Re: [44net] Bad MX records in the ampr.org DNS

by Rob Janssen

> 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

9 years, 11 months

3
2
0 0

Re: [44net] Bad MX records in the ampr.org DNS

by Rob Janssen

> 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

9 years, 11 months

11
23
0 0

Re: [44net] Bad MX records in the ampr.org DNS

by William Lewis

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

9 years, 11 months

3
8
0 0

Re: [44net] Bad MX records in the ampr.org DNS

by Rob Janssen

> Subject: > Re: [44net] Bad MX records in the ampr.org DNS > From: > Rob Janssen <pe1chl(a)amsat.org> > Date: > 05/25/2015 09:18 PM > > To: > 44net(a)hamradio.ucsd.edu > Over the past few days, I have found and deleted about 2000 bad MX records and 935 bad CNAME records. It appears that in the past some standard procedure has inserted many records like this: callsign IN A 44.x.x.x callsign IN MX 10 callsign Later, apparently the IN A records have been deleted during some cleanup, but the IN MX records remained. They of course serve no function, and bind9 complains when the zone is loaded. Furthermore, a large number of records like this existed: something IN CNAME callsign Again, the corresponding callsign has been deleted in the past (its A records, and now also the dangling MX) and that CNAME points to nothing. I have removed those as well. There was a number of records like this: callsign IN MX 10 44.x.x.x This format is not allowed. A hostname should appear instead of the literal IP address. I have changed the records to have the corresponding hostname from the ampr.org zone. Errors that still remain are: records of the format: callsign IN MX 10 111.222.333.444 (referring to a public IP) Those are: *.xe2mbq IN MX 5 200.23.120.6 *.xe2yun IN MX 10 200.23.120.6 grr.kc8lcp IN MX 10 204.227.124.61 ka9kim IN MX 30 207.74.35.36 kc5ghg IN MX 20 206.61.58.173 linux.n8ivx IN MX 10 209.4.74.218 n5dbx IN MX 20 206.61.57.1 n8ivx IN MX 10 208.231.146.247 pacgate.zl1udy IN MX 0 202.14.100.2 ur4wwe IN MX 20 194.44.138.1 us5we IN MX 20 194.44.138.1 va3hum IN MX 20 206.248.184.186 va3yh IN MX 20 206.248.184.186 ve3fub IN MX 20 206.248.184.186 wb5fro IN MX 20 206.61.58.173 yo3ru IN MX 10 141.85.43.57 Owners, please update them with a proper hostname instead of the literal IP address. Also, these names are used in records like: callsign IN MX 10 name but the name refers to a CNAME, not to an IN A record. This is not allowed by the spec, although it usually works. If possible, change the MX to have a hostname that points to an A record. The illegally used CNAMEs are: alcoy athnet bbs.vk2czr club.oh1rbi ea4rct edugraf etxgate.nb5i g0wfs gateway.n8xja gb7sol-10 gb7tvg gw.ir3ip haifa hougw2 hougw jh3qnh ka7oei kb7yw kj7pf mail.ncpa mx2.ir3ip poagw pp5dq pp5dq-gw pp5mcb-gw-7 pp5uf router.kl7eet va3lug ve3cgr ve3mch ve3uow ve6lip vk2pk vk2yui vk5lz vk5tty w7yg wa7ipx wa7slg Of course there is still lots of other out-of-date info in the DNS, but now at least it is more standards compliant. Rob

9 years, 11 months

4
3
0 0

hu.ampr.org DNS

by Rob Janssen

> Subject: > [44net] hu.ampr.org DNS > From: > Norbert Varga <nonoo(a)nonoo.hu> > Date: > 05/25/2015 11:37 AM > > To: > 44net(a)hamradio.ucsd.edu > > > Dear 44net, > > First of all, hello to everybody on the list, I've just subscribed. > We're currently building the hamnet network in Hungary, now we have some > working links, tunnels and hosts which I've already added to the hamnetdb. > > I saw that some host names can be resolved using "regular" internet DNS > servers, like router.db0ajw.ampr.org can be resolved to 44.225.36.129 using > Google's 8.8.8.8 DNS server. > > My question is that how can this be accomplished? If we have a DNS server > which can resolve our hosts to IPs and backwards, can one of the AMPR DNS > servers be set up to transfer our zones? > > I saw that the portal has a DNS section but it's not live yet. > > Thanks for the help and 73s de HA2NON Do you have a reason to use a subdomain .hu.ampr.org instead of putting the Hungarian callsigns directly under .ampr.org as almost everyone else is doing? You can easily submit your DNS records to the ampr.org DNS service. This is accomplished using a mail robot where you can mail your zone changes and that will put them in the flat .ampr.org zone. You can also arrange that NS records for hu.ampr.org are put in the ampr.org DNS. Then all requests for callsign.hu.ampr.org will be referred to your servers. Of course your servers have to be available both on amprnet and on internet. This is now done by Germany, Spain and Sweden. (but I do not see a compelling reason to do that) Rob

9 years, 11 months

4
4
0 0

Re: [44net] Bad MX records in the ampr.org DNS

by Rob Janssen

> Subject: > Re: [44net] Bad MX records in the ampr.org DNS > From: > John Ronan <jpronans(a)gmail.com> > Date: > 05/25/2015 11:00 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On 25/05/15 09:52, Rob Janssen wrote: >> linux.ei2edb.ampr.org/MX 'ei2edb.ampr.org' has no address records (A or AAAA) >> os2.ei2edb.ampr.org/MX 'ei2edb.ampr.org' has no address records (A or AAAA) >> ei7gm.ampr.org/MX 'bbs.ei7gm.ampr.org' is a CNAME (illegal) >> ei7gm.ampr.org/MX 'dubbbs.ei7gm.ampr.org' has no address records (A or AAAA) >> 486.ei9fk.ampr.org/MX 'ei9fk.ampr.org' has no address records (A or AAAA) > Delete them, > > They are all ancient DNA. > > Regards > John > EI7IG After consulting Brian I have deleted all MX records that point to names for which no address record exists, including 4 of the above. 867 records in total. Looking at CNAME and dotted address in MX records will be the next step. Note that an MX record must have a hostname that in turn has A and/or AAAA records. So MX records that contain e.g. "44.0.0.1" are not allowed. Neither are MX records that have a name that in turn is a CNAME pointer. Most mail software will probably handle those bad MX records, so I have not yet deleted them. I advise those that make use of their MX records to fix them (replace the IP address with a hostname that resolves to that address, and replace a name that refers to a CNAME with the name that the CNAME points to). Then I can check things again in some time. Rob

9 years, 11 months

1
0
0 0

hu.ampr.org DNS

by Norbert Varga

Dear 44net, First of all, hello to everybody on the list, I've just subscribed. We're currently building the hamnet network in Hungary, now we have some working links, tunnels and hosts which I've already added to the hamnetdb. I saw that some host names can be resolved using "regular" internet DNS servers, like router.db0ajw.ampr.org can be resolved to 44.225.36.129 using Google's 8.8.8.8 DNS server. My question is that how can this be accomplished? If we have a DNS server which can resolve our hosts to IPs and backwards, can one of the AMPR DNS servers be set up to transfer our zones? I saw that the portal has a DNS section but it's not live yet. Thanks for the help and 73s de HA2NON -- Norbert Varga http://www.nonoo.hu/

9 years, 11 months

2
1
0 0

ampr-gateways.org

by G1FEF

I am going to retire ampr-gateways.org as everything is now available under portal.ampr.org including the FTP site that was under amp-gateways.org So if anyone still has amp-gateways.org configured now is the time to update it to portal.apr.org Thanks, Chris

9 years, 11 months

1
1
0 0

Bad MX records in the ampr.org DNS

by Rob Janssen

While trying to load the ampr.org zone into a local DNS server, I noticed that there are quite a number of bad MX records in the zone. Most are nonexisting hosts, but also sometimes a literal IP address or CNAME appears in the MX record. Maybe the maintainers of those ranges can have a look at them and consider what to do? Or should I just delete them (I can easily construct a robot mail message that does that)? (probably many hams have set an MX to a friend in the past, and that host has been deleted afterwards) Below is the list of warnings from bind9. When replying to this message, please DON'T quote the entire list of warnings. Rob 13lksd.ampr.org/MX '13lksd.ampr.org' has no address records (A or AAAA) 13lksd.ampr.org/MX 'electron.kb7pwd.ampr.org' has no address records (A or AAAA) 4x1kt.ampr.org/MX 'haifa.ampr.org' is a CNAME (illegal) 4x4hf.ampr.org/MX 'haifa.ampr.org' is a CNAME (illegal) 4x4li.ampr.org/MX 'haifa.ampr.org' is a CNAME (illegal) 4z4yu.ampr.org/MX 'haifa.ampr.org' is a CNAME (illegal) 4z5ca.ampr.org/MX 'haifa.ampr.org' is a CNAME (illegal) 4z5dk.ampr.org/MX 'haifa.ampr.org' is a CNAME (illegal) 4z7dcb.ampr.org/MX 'haifa.ampr.org' is a CNAME (illegal) 4z9chb.ampr.org/MX 'haifa.ampr.org' is a CNAME (illegal) aa0dn.ampr.org/MX 'aa0dn.ampr.org' has no address records (A or AAAA) ice.aa0dn.ampr.org/MX 'ice.aa0dn.ampr.org' has no address records (A or AAAA) spare.aa0dn.ampr.org/MX 'spare.aa0dn.ampr.org' has no address records (A or AAAA) sys1.aa0dn.ampr.org/MX 'sys1.aa0dn.ampr.org' has no address records (A or AAAA) sys2.aa0dn.ampr.org/MX 'sys2.aa0dn.ampr.org' has no address records (A or AAAA) sys3.aa0dn.ampr.org/MX 'sys3.aa0dn.ampr.org' has no address records (A or AAAA) sys4.aa0dn.ampr.org/MX 'sys4.aa0dn.ampr.org' has no address records (A or AAAA) tnos.aa5jj.ampr.org/MX 'tnos.aa5jj.ampr.org' has no address records (A or AAAA) aa6vn.ampr.org/MX 'aa6vn.ampr.org' has no address records (A or AAAA) aa6vn.ampr.org/MX 'orinda.ampr.org' has no address records (A or AAAA) aa6vn.ampr.org/MX 'w6yx.ampr.org' has no address records (A or AAAA) meteor.aa7xy.ampr.org/MX 'wa7slg.ampr.org' is a CNAME (illegal) nova.aa7xy.ampr.org/MX 'wa7slg.ampr.org' is a CNAME (illegal) ab5ls.ampr.org/MX 'gate.kb5ggo.ampr.org' has no address records (A or AAAA) ab5yy.ampr.org/MX 'gate.kb5ggo.ampr.org' has no address records (A or AAAA) ab6qv.ampr.org/MX 'gw.ab6qv.ampr.org' has no address records (A or AAAA) gw.ab6qv.ampr.org/MX 'gw.ab6qv.ampr.org' has no address records (A or AAAA) oc.ab6qv.ampr.org/MX 'gw.ab6qv.ampr.org' has no address records (A or AAAA) ab6ym.ampr.org/MX 'ab6ym.ampr.org' has no address records (A or AAAA) ab6z.ampr.org/MX 'ab6z.ampr.org' has no address records (A or AAAA) ab7ee.ampr.org/MX 'wa7slg.ampr.org' is a CNAME (illegal) ab7ps.ampr.org/MX 'kb6le.ampr.org' has no address records (A or AAAA) ab7qf.ampr.org/MX 'wa7slg.ampr.org' is a CNAME (illegal) ac6vr.ampr.org/MX 'gw.ab6qv.ampr.org' has no address records (A or AAAA) ae4yb.ampr.org/MX 'ae4yb.ampr.org' has no address records (A or AAAA) ah6gt.ampr.org/MX 'ah6gt.ampr.org' has no address records (A or AAAA) ai0s.ampr.org/MX 'ai0s.ampr.org' has no address records (A or AAAA) ampr-to-usenet.ampr.org/MX 'w6yx.ampr.org' has no address records (A or AAAA) archihq.ampr.org/MX 'archihq.ampr.org' has no address records (A or AAAA) archihq.ampr.org/MX 'hawaii.ampr.org' has no address records (A or AAAA) azgtwy.ampr.org/MX 'azgtwy.ampr.org' has no address records (A or AAAA) bde-arc.ampr.org/MX 'k6bde.ampr.org' has no address records (A or AAAA) on0baf.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on0baf.baf.be.ampr.org/MX 'on0kul-10.ampr.org' has no address records (A or AAAA) on1ans.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1bgi.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1bpj.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1bqi.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1cb.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1cix.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1cmo.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1dbq.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1dct.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1dds.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1dgw.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1djx.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1dlb.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1dlb-10.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1dlv.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1dnf.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1dnn.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1doa.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1dow.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on1ill.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4ahq.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4ajg.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4ajj.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4akv.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4awm.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4baf.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4ban.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4bbt.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4blu.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4cfl.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4cid.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4cja.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4cju.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4cw.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4kes.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4mp.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4ms.baf.be.ampr.org/MX 'on4ms.baf.be.ampr.org' has no address records (A or AAAA) on4ms.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4ms-4.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on4rst.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on6kn.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on6rh.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on7ho.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on7qj.baf.be.ampr.org/MX 'on0baf.baf.be.ampr.org' has no address records (A or AAAA) on0brw.brarc.be.ampr.org/MX 'on0brw.brarc.be.ampr.org' has no address records (A or AAAA) on0brw.brarc.be.ampr.org/MX 'on0kul-10.ampr.org' has no address records (A or AAAA) on0abt.brg.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on1buc.brg.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on1jl.brg.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) sys2.on1jl.brg.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on4aak.brg.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on6hh.brg.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on0pwg.dks.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on1buc.dks.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on6hh.dks.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on0eul.eul.be.ampr.org/MX 'on0eul.eul.be.ampr.org' has no address records (A or AAAA) on0eul.eul.be.ampr.org/MX 'on0kul-10.ampr.org' has no address records (A or AAAA) on0onz.knk.be.ampr.org/MX 'on0onz.knk.be.ampr.org' has no address records (A or AAAA) on1cgi.knk.be.ampr.org/MX 'on0onz.knk.be.ampr.org' has no address records (A or AAAA) on5fu.knk.be.ampr.org/MX 'on0onz.knk.be.ampr.org' has no address records (A or AAAA) on0ck.ktk.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on5di.ktk.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on6hh.ktk.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on0lar.lar.be.ampr.org/MX 'on0lar.lar.be.ampr.org' has no address records (A or AAAA) on1dcd.lar.be.ampr.org/MX 'on0lar.lar.be.ampr.org' has no address records (A or AAAA) on6bn.lar.be.ampr.org/MX 'on0lar.lar.be.ampr.org' has no address records (A or AAAA) on0nmr.nmr.be.ampr.org/MX 'on0nmr.nmr.be.ampr.org' has no address records (A or AAAA) on0nmr.nmr.be.ampr.org/MX 'on0kul-10.ampr.org' has no address records (A or AAAA) on1mgl.nmr.be.ampr.org/MX 'on0nmr.nmr.be.ampr.org' has no address records (A or AAAA) on1mgl-10.nmr.be.ampr.org/MX 'on0nmr.nmr.be.ampr.org' has no address records (A or AAAA) on0ob.oud.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on0ob.oud.be.ampr.org/MX 'on0kul-10.ampr.org' has no address records (A or AAAA) on1aee.oud.be.ampr.org/MX 'on0ob.ampr.org' is a CNAME (illegal) on1cdp.oud.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on1dhw.oud.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on5fs.oud.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on5fs-11.oud.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on5tn.oud.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on6gj.oud.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on6py.oud.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on7df.oud.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on7gq.oud.be.ampr.org/MX 'on0ob.oud.be.ampr.org' has no address records (A or AAAA) on1bhm.ufa.be.ampr.org/MX 'on4ufa.ufa.be.ampr.org' has no address records (A or AAAA) on1brq.ufa.be.ampr.org/MX 'on4ufa.ufa.be.ampr.org' has no address records (A or AAAA) on6ua.ufa.be.ampr.org/MX 'on4ufa.ufa.be.ampr.org' has no address records (A or AAAA) on7kb.ufa.be.ampr.org/MX 'on4ufa.ufa.be.ampr.org' has no address records (A or AAAA) on7ko.ufa.be.ampr.org/MX 'on4ufa.ufa.be.ampr.org' has no address records (A or AAAA) benicia.ampr.org/MX 'benicia.ampr.org' has no address records (A or AAAA) benicia.ampr.org/MX 'w6yx.ampr.org' has no address records (A or AAAA) concord.ampr.org/MX 'concord.ampr.org' has no address records (A or AAAA) ea4axu.ampr.org/MX 'ea4rct.ampr.org' is a CNAME (illegal) pedro.eb4dhe.ampr.org/MX '44.133.28.100.ampr.org' has no address records (A or AAAA) pedro.eb4dhe.ampr.org/MX '194.224.61.14.ampr.org' has no address records (A or AAAA) pedro.eb4dhe.ampr.org/MX '194.179.1.100.ampr.org' has no address records (A or AAAA) eb4euf.ampr.org/MX 'smtp.eb4euf.ampr.org' has no address records (A or AAAA) eb4euf.ampr.org/MX 'smtp.ext.ea4els.ampr.org' has no address records (A or AAAA) yogui.eb5dgp.ampr.org/MX 'alcoy.ampr.org' is a CNAME (illegal) ebhub.ampr.org/MX 'nyc-gw.kb2vlx.ampr.org' has no address records (A or AAAA) ec4dfp.ampr.org/MX 'ea4rct.ampr.org' is a CNAME (illegal) bbs.edugraf.ampr.org/MX 'edugraf.ampr.org' is a CNAME (illegal) edugraf-bbs.ampr.org/MX 'edugraf.ampr.org' is a CNAME (illegal) linux.ei2edb.ampr.org/MX 'ei2edb.ampr.org' has no address records (A or AAAA) os2.ei2edb.ampr.org/MX 'ei2edb.ampr.org' has no address records (A or AAAA) ei7gm.ampr.org/MX 'bbs.ei7gm.ampr.org' is a CNAME (illegal) ei7gm.ampr.org/MX 'dubbbs.ei7gm.ampr.org' has no address records (A or AAAA) 486.ei9fk.ampr.org/MX 'ei9fk.ampr.org' has no address records (A or AAAA) warning: '141.85.43.57': MX is an address warning: '147.162.96.170.': MX is an address warning: '148.63.33.158.': MX is an address warning: '193.226.25.6.': MX is an address warning: '194.126.13.1.': MX is an address warning: '194.179.1.100': MX is an address warning: '194.224.61.14': MX is an address warning: '194.44.138.1': MX is an address warning: '195.223.165.251': MX is an address warning: '200.23.120.6': MX is an address warning: '202.14.100.2': MX is an address warning: '204.227.124.61': MX is an address warning: '206.248.184.186': MX is an address warning: '206.61.57.1': MX is an address warning: '206.61.58.173': MX is an address warning: '207.74.35.36': MX is an address warning: '208.231.146.247': MX is an address warning: '209.4.74.218': MX is an address warning: '212.244.162.166.': MX is an address warning: '212.44.70.60.': MX is an address warning: '24.1.227.2.': MX is an address warning: '44.131.163.240': MX is an address warning: '44.132.81.2': MX is an address warning: '44.133.28.100': MX is an address warning: '44.135.85.30': MX is an address warning: '44.188.224.1': MX is an address warning: '44.188.224.9': MX is an address warning: '44.76.0.26': MX is an address warning: '44.76.0.27': MX is an address warning: '44.76.0.28': MX is an address warning: '44.76.0.29': MX is an address warning: '44.76.2.231': MX is an address warning: '44.76.2.232': MX is an address warning: '44.76.4.60': MX is an address warning: '44.88.0.11': MX is an address warning: '44.88.0.9': MX is an address warning: '65.5.141.186.': MX is an address

9 years, 11 months

2
1
0 0

Re: [44net] ampr-gateways.org

by Rob Janssen

> Subject: > Re: [44net] ampr-gateways.org > From: > Steve L <kb9mwr(a)gmail.com> > Date: > 05/23/2015 08:09 PM > > To: > "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu> > > > I had to look at it via the wayback machine. For a minute I though > this was the site that the nice map of gateways. It looks like that is just another standalone site that you need to enter your data on, and that almost nobody knows it exists. IMHO such a site is only worth doing when it is linked to the actual data, not when it is yet another place to enter data. Check http://hamnetdb.net/ when you are looking for a site that brings some real value. In fact it offers much more than the portal and I think it should be considered to merge the portal function into it. Its ways of handling subnets and addresses are much more usable than those of the portal, and it can do so much more. It only needs a section to enter data for IPIP gateways. Rob

9 years, 11 months

1
0
0 0

Re: [44net] ampr-gateways.org

by Steve L

I had to look at it via the wayback machine. For a minute I though this was the site that the nice map of gateways. Turns out that is: http://www.ampr-gates.net/frame_e.htm It would be really nice to have gateways portion of the portal list some geographic info. For those looking for connectivity to area XXX. I think this is our main selling point and we need to advertise it a bit. Right now if you lookup each gateway subnet you can derive the geographic area from the networks portion of the portal. Thanks again for your work Chris.

9 years, 11 months

1
0
0 0

44net connection with RaspberryPi behind NAT

by Fred Boogaard

Hi all, I'm new to amprnet and linux and try to get my RaspberryPi connected with the 44net. I have setup the Pi and configured IPIP tunl0. I can ping to 44.137.0.0/16. The problem is that I do not receive any RIPv2 packets with ampr-ripd or rip44d. The situation is that the Pi is behind the DMZ of my ISP router and I think that's causing the problem. Have try ed the cron as a 1 minute ping as suggested at http://n1uro.ampr.org/linuxconf/amprnat.txt but without result. Do you have any suggestions or advise on what to do to get this running? 73, Fred/PA8F

9 years, 11 months

3
2
0 0

Re: [44net] easy amprnet attachemet and connection - seeking peers for cost sharing

by Rial Sloan

> > > On 13.5.2015. 04:55, Andrew Ragone (RIT Alumni) wrote: > > > >> With that said, I am not sure what the advantage of this is (aside from > >> perhaps the dynamic IP issue you mention), though, since you could > always > >> write a script to login to the AMPRNet portal and tweak the IPIP tunnels > >> with any WAN IP address updates. When you have the free gateway over in > >> California already, it seems like that would be the way to go aside from > >> directly advertising your own BGP CIDR block. > >> > > > > I guess this would allow anyone with any decent router with VPN client > > capability) to be able to connect to 44net without requirements for > > struggling with dedicated computer and very specific installation to make > > it run. > > > > Yes, exactly and well said! that's exactly the point I've been pushing > for a long time. the single dedicated IP is taken care of by the cloud > based hub and a relitively simple setup on your client router at your > network edge simply makes 44net show up on your lan. no dedicated machine, > no dedicated or special software, no having to write custom config files, > just easy and instantly deployable using standard protocols used everyday > that real people use often and understand. > > Eric > Hi Eric, Are you doing the BGP announce or would the hosting provider you are proposing we share doing the announce? Are you familiar with what the HamWAN group is doing with their Open Peering Policy (http://www.hamwan.org/t/Open+Peering+Policy)? Rial F Sloan II N0OTZ

9 years, 11 months

1
0
0 0

Re: [44net] easy amprnet attachemet and connection - seeking peers for cost sharing

by Rob Janssen

> Subject: > Re: [44net] easy amprnet attachemet and connection - seeking peers for cost sharing > From: > Eric Fort <eric.fort(a)gmail.com> > Date: > 05/13/2015 05:40 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > there are 2 problems here which I'm working to address. The first being > that even though ipip tunneling is defined via rfc it's still relitively > nonstandard and I can't think of anywhere other than amateur radio / 44net > where it is used, much less used widely. It's also not generally handeled > well by many consumer grade household nat routers. I can't go to the web > interface on my cheapo whatever name consumer router and set up the > tunnel(s) I need to import a link to amprnet. If Tunnels are done with > something like IPSec, PPTP, or OpenVPN it's much better supported and is > easier to setup. the edge connections can simply establish their link(s) > to one or more hubs with known static IP, be assigned/connected to a > netblock, and be in business just by using their basic consumer grade > router and no other fancy or overly technical setup. > > Eric > AF6EP True. We already offer OpenVPN and IPsec VPN connection to our BGP routed gateway in Amsterdam, the Netherlands (44.137.0.0/16). (and IPIP of course) Indeed it makes entry a lot easier for those on the typical internet connection with NAT and maybe not a fixed address (although that is not really a problem here) What VPN protocols do you want to offer? I am considering adding support for OpenConnect (an open implementation of Cisco AnyConnect SSL VPN). That could even replace OpenVPN on the long run (I am not very happy with some aspects of it). Do you offer connections from your VPN users to non-44 Internet addresses and back? (this makes it more tricky and error-prone for users to configure their side, as they will need some form of policy routing that is not always available or easy to setup) Rob

9 years, 11 months

1
0
0 0

BGP VPN access

by Bryan Fields

So I've had this working for some time now, but wanted to announce it to the group. in case anyone wants to try. I have a VPN router on vpn.w9cr.net You can use an IP sec VPN dialer to connect to it and then get an IP out of a /28 I have set aside for it. I don't mesh with the 44net ipip encap, but I believe we have connectivity to that via the hamwan guys from Seattle. I have no radius server or anything fancy, it's a crisco 1811 in my rack in tampa. I've confirmed it works with the apple VPN dialer. carrar has it working under windows with shrewsoft too. If you want to test/play send me your callsign/name and a password (numbers/letters/uppercase, no special char's), and I'll provision it and send back the group ID and PSK. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

9 years, 11 months

1
0
0 0

easy amprnet attachemet and connection - seeking peers for cost sharing

by Eric Fort

After completing a successful experiment that demonstrated just how easy it can be to connect to amprnet without any need for a static public ip address and by just a few peers working together I'm looking for interested parties that may be interested in sharing the cost of a cloud based vpn server which would then host a 44/24 netblock routed via bgp. use of standard vpn tools makes this setup extremely easy and usable/compatable with NAT firewalls, and standard dynamic routing protocols and tools make things easy as well. I'd like to set this up based in the usa on plenty of bandwidth. please speak up if you would be willing to share cost and help make a go of this. Eric AF6EP

9 years, 11 months

4
6
0 0

Re: [44net] easy amprnet attachemet and connection - seeking peers for cost sharing

by Bryan Fields

On 5/12/15 10:01 PM, Eric Fort wrote: > I'd like to set this up based in the usa on plenty of > bandwidth. please speak up if you would be willing to share cost and help > make a go of this. Eric, I have some space and could probably figure out how to spin up a VM for you here or just give you shell on a box. I'm collocated at 400 N Tampa which is well connected to across multiple carriers. Give me some details about what you're thinking. Will you be at Dayton? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

9 years, 11 months

1
0
0 0

Ampr Wiki

by Brian

Chris; I tried to log on my account to do some notes and it says my account is invalid...? Can you please double check and verify that it is still valid? Thanks much! -- The most difficult egg to beat is one that is hard boiled. 73 de Brian Rogers - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

9 years, 11 months

2
1
0 0

expiring old routes

by Niall Parker

Hello, I recall some discussion on this a while back but don't remember if there was a solution and can't find it in the archives ... Is there a way to expire an announced encap route ? I'm trying to concentrate all the UBC subnets back at our router there and an experiment with 44.135.190/24 via another host isn't going away ... I can purge it from the router itself but it looks like the rest of the system is probably sending that subnet to the old (defunct) ip. ... Niall

10 years

2
2
0 0

Port Forwarding

by gm4upx＠gb7jd.co.uk

Hello, As someone new to the intricacies of port forwarding I have been puzzled why I cannot maintain a connection when I have the entry shown below for port 7300 active yet connections via port 6300 and 8000 work as expected. $IPTABLES -A FORWARD -d 44.131.8.0/27 -p tcp -m tcp --dport 6300:6310 -j ACCEPT $IPTABLES -A FORWARD -d 44.131.8.0/27 -p tcp -m tcp --dport 7300:7310 -j ACCEPT $IPTABLES -A FORWARD -d 44.131.8.0/27 -p tcp -m tcp --dport 8000:8011 -j ACCEPT $IPTABLES -t nat -A PREROUTING -p tcp --dport 6300 -j DNAT --to-destination 44.131.8.16:6300 #$IPTABLES -t nat -A PREROUTING -p tcp --dport 7300 -j DNAT --to-destination 44.131.8.16:7300 $IPTABLES -t nat -A PREROUTING -p tcp --dport 8000 -j DNAT --to-destination 44.131.8.16:8000 Placing a [ # ] as shown allows the connections. Regards, Ian..

10 years

2
3
0 0

encap.txt to Cisco script

by Nick G4IRX

A while ago Jason KY9J kindly sent me a copy of his script (which I have since lost) to convert encap.txt to generate tunnels for a Cisco IOS router. Are you still subscribed to the list Jason or can anybody else help with a copy of the script? http://hamradio.ucsd.edu/mailman/private/44net/2012-November/000534.html was the original thread. Many thanks, Nick G4IRX.

10 years

3
3
0 0

(no subject)

by Don Moore

Whoever owns 44.131.160.1 you need to check your system configuration. It cannot do anything with 255.255.255.255 Below what I am seeing 8:20:25.632390 IP 81.174.253.193 > 192.168.1.150: IP 44.131.160.1.5678 > 255.255.255.255.5678: UDP, length 120 (ipip-proto-4) 08:20:25.635667 IP 192.168.1.150 > 81.174.253.193: IP 44.135.90.2 > 44.131.160.1: ICMP host 255.255.255.255 unreachable, length 36 (ipip-proto-4) -- cheers, Don - ve3zda

10 years

2
2
0 0

gateways downlad

by Don Moore

Could someone explain why the manual download of the gateways is different than the what the portal shows? A station had an ip address change yesterday and because I download daily I manually changed to his new address. When the download took place this morning his old address was sent and of course replaced the new one. -- cheers, Don - ve3zda

10 years

1
0
0 0

ve3clg 4

by Boudewijn (Bob) Tenty

xnet.ve3clg del A 44.135.82.18 linux2.ve3clg in A 44.135.82.18 xnet.ve3clg in A 44.135.82.19

10 years, 1 month

1
1
0 0

Re: [44net] Gateways

by Kevin

Hi Tom, Thanks for the link, Will have a look at it in morning and see how to pop it in the mikrotik and see if it plays ball Cheers, Kevin 2E0LSR /P Sent from Somewhere Rural with limited Cell Coverage! Try HF or VHF/UHF better chances! <div>-------- Original message --------</div><div>From: Tom Hayward <esarfl(a)gmail.com> </div><div>Date:26/03/2015 18:10 (GMT+00:00) </div><div>To: AMPRNet working group <44net(a)hamradio.ucsd.edu> </div><div>Subject: Re: [44net] Gateways </div><div> </div>(Please trim inclusions from previous messages) _______________________________________________ Thu, Mar 26, 2015 at 11:03 AM, Kevin <kevin(a)sidx.org.uk> wrote: > I just need to know now what needs to be setup on my router which can then send out the RIP advertisement to the Internet and announce the Subnets that > Im using MikroTik hardware which is based on the same logic and routabilities as Cisco hardware You might try my script: https://github.com/kd7lxl/python-amprapi/#updaterospy updateros.py reads the list of gateways and routes from the AMPR API and translates that to Mikrotik commands. It simply automates the creation and destructions of IPIP interfaces and static routes. I run it against our routers via cron hourly on my desktop. It is not capable of rip44. Tom KD7LXL _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

10 years, 1 month

5
10
0 0

Re: [44net] Gateways

by Kevin

Hi Marius, I did indeed get the allocation about a month ago and also got a response from the gw robot earlier today, I currently have single /29 range but will be advertising other ranges once this works (advertising routes for friends) I have a static public I can build this on which is on my current connection (later I can migrate it to another one of my statics as I own my own AS and /24 PI space from RIPE I can access the 44net from another ip space if needed while im testing I also have access to multiple other routers within UK via VPN ect I intend on being the GW for this region (norfolk) due to my skills and ability to host this on a 1GB line I have on a remote site within Norfolk I just need to know now what needs to be setup on my router which can then send out the RIP advertisement to the Internet and announce the Subnets that Im using MikroTik hardware which is based on the same logic and routabilities as Cisco hardware Cheers, Kevin 2E0LSR /P Sent from Somewhere Rural with limited Cell Coverage! Try HF or VHF/UHF better chances! <div>-------- Original message --------</div><div>From: Marius Petrescu <marius(a)yo2loj.ro> </div><div>Date:26/03/2015 17:46 (GMT+00:00) </div><div>To: 'AMPRNet working group' <44net(a)hamradio.ucsd.edu> </div><div>Subject: Re: [44net] Gateways </div><div> </div>(Please trim inclusions from previous messages) _______________________________________________ Greetings Kevin, To figure this out, I need a little more info on your setup. - did you get your GW in the end - btw, your country admin needs to approve your allocation, maybe there's the issue? - do you have a single subnet (which can be expressed in a single IP/mask combination) ? - do you have a static IP address to build your GW upon ? - do you have some other means to connect to the 44 address space (e.g. hamnet - high speed wlan)? - do you need to set up a complex network with more than 1 GW and direct connections between them ? 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 Kevin Sent: Thursday, March 26, 2015 16:23 To: 44net(a)hamradio.ucsd.edu Subject: [44net] Gateways (Please trim inclusions from previous messages) _______________________________________________ Afternoon All, Ive not gotten a GW entry into the system, after a long time waiting for the Robot to reply to my message, Next thing now is what next?? There is no documentation as to what the next step is now I¹ve added this gw to the portal and my announced subnetsÐ On the actual physical GW what do I need to do for it to be announced?? Thanks, Regards, Kevin 2E0LSR (M6EMT) / MS0SIA Consultant Wireless & Networking Engineer MTCNA, MTCRE, MTCINE, UCWA, UEWA, CompTIA A+

10 years, 1 month

2
1
0 0

Gateways

by Kevin

Afternoon All, Ive not gotten a GW entry into the system, after a long time waiting for the Robot to reply to my message, Next thing now is what next?? There is no documentation as to what the next step is now I¹ve added this gw to the portal and my announced subnets On the actual physical GW what do I need to do for it to be announced?? Thanks, Regards, Kevin 2E0LSR (M6EMT) / MS0SIA Consultant Wireless & Networking Engineer MTCNA, MTCRE, MTCINE, UCWA, UEWA, CompTIA A+

10 years, 1 month

3
2
0 0

Pls help! on adding subnet

by Pedro Converso

I am unable to set a subnet either thru portal or Robot email. Thru portal added dynamic GW lu8fjh.dyndns.org actually on 201.253.187.32 Trying plaintext email to gateways(a)ampr.org: Gateway: lu8fjh.dyndns.org Password: xxxxxxxx Subnets: 44.153.072.013/32 Title: GW lu8fjh.dyndns.org for 44.153.72.13 New Entry I get answer back as a line just saying: *** Gateways V 6.0 ** Thru portal there are many subnets to choose, but there is no way to add a new one. Emailed to ampr development but no answer up to now. Don't know if have something to do, have seen on 44net msgs there is a setting to specify either TUNNEL or BGP but don't see where to specify. Appreciate any advice! 73, lu7abf, Pedro 44.153 Argentina ampr Coord

10 years, 1 month

1
0
0 0

help for changing an existing allocation

by F6CNB

I need to add the subnets 44.168.52.0/24 and 44.168.254.24/29 to my gateway but the 44.168 coordinator seems to be out of reach. I am running the French gateway for 44.168.0.0 and this subnet is not allocated to me neither defined (I assume) as connected thru a tunnel. Is somebody can change the flag to tunnel. That way , I can add it to my gateway and get the proper routing for Ile de La Reunion which just joined the "European" HAMNET network. Chris, The flags are confusing in the case of HAMNET France. Most of the subnets are radio connected to my gateway thru high speed 5.6/5.7 links. It is not obvious at all for them that they need to check gateway/tunnel and not radio. As I operate a large gateway to a fast growing network, The old free typing gateway subnet routing was a lot of more convenient. 73 Remi F6CNB (or W5/F6CNB)

10 years, 1 month

2
1
0 0

Re: [44net] Multicast problem?

by lleachii＠aol.com

I'm also experiencing the same issue (no routes received) with rip44d... There is no -r option. Suggestions? - KB3VWG

10 years, 1 month

1
0
0 0

Proposal on using the "Radio" flag

by marius＠yo2loj.ro

In light of what was discussed here, I would propose the following usage of the "radio" flag: A subnet marked as "Radio" should use this flag exclusively and inherit the Tunnel or BGP flag from its parent network. For allocation only purposes only, a network without any flags is enough. Rationale: A pure radio network doesn't exist from the point of view of ampr-net since it would not present any internet connectivity. If this connectivity is present, meaning it is reachable by any kind of means, IPIP or BGP routed, it will allow a connectivity method, the same as its parent network. 73s, Marius, YO2LOJ

10 years, 1 month

8
8
0 0

Re: [44net] TUNNEL vs DIRECT connection of subnets

by Rob Janssen

> Subject: > [44net] TUNNEL vs DIRECT connection of subnets > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 03/14/2015 02:30 AM > > To: > 44net(a)hamradio.ucsd.edu > > > At the current moment I can see no way for an AMPRNet subnet to be both > TUNNEL and DIRECT (BGP-announced) connected, unless a special provision > has been made to operate a gateway from a non-44/8 address into the > BGP-connected subnet. Sure, but I think that is not unreasonable. We do it on our gateway and there is no problem with it. The provider has issued a small non-44 subnet to the gateway machine and it routes the net-44 traffic to that address. (i.e. our provider announces 44.137.0.0/16 on BGP and accepts the traffic on their core router and they forward it to us, we forward our traffic for internet to them on another address in that subnet on which their router listens). We are also on the IPIP mesh with our /16 and the tunnel endpoint is that same non-44 address (213.222.29.194). This means that other IPIP gateways forward traffic via a tunnel. This works just fine. It also means the others do not have to setup exceptions for our subnet in their IPIP tunnel systems. Getting the /30 network required for this should be no problem even today. Rob

10 years, 1 month

2
1
0 0

TUNNEL vs DIRECT connection of subnets

by Brian Kantor

At the current moment I can see no way for an AMPRNet subnet to be both TUNNEL and DIRECT (BGP-announced) connected, unless a special provision has been made to operate a gateway from a non-44/8 address into the BGP-connected subnet. This is because the tunnel mesh can't reach 44/8 addresses that aren't reachable via a non-44/8 tunnel entrance. This means that we can't have gateways whose entrance address is in 44/8. This implies that TUNNEL and DIRECT should be mutually-exclusive options in allocation requests. I'd be happy to be wrong about this. - Brian

10 years, 1 month

3
3
0 0

Re: [44net] TUNNEL vs DIRECT connection of subnets

by Bryan Fields

On 3/13/15 9:30 PM, Brian Kantor wrote: > At the current moment I can see no way for an AMPRNet subnet to be both > TUNNEL and DIRECT (BGP-announced) connected, unless a special provision > has been made to operate a gateway from a non-44/8 address into the > BGP-connected subnet. > > This is because the tunnel mesh can't reach 44/8 addresses that aren't > reachable via a non-44/8 tunnel entrance. > > This means that we can't have gateways whose entrance address is in 44/8. This has been a known issue for about two years now. The solution to this is to fix the routing on the gateway at UCSD for the IPIP encap users. If UCSD network department is unwilling to fix this I'm sure we can find an alternate IX who would be willing to make it work. I know my users are more concerned with access to the internet than access to the rest of 44net, and the ipip encap mesh cannot be configure on the border router (IPIP encap needs an hardware option). I'm experimenting with a vRR that might be able to do it in software, but it's not high on my list of things to do. I believe Tim Osburn did some work regarding a tunnel endpoint to bridge the gap here, but this single gateway design for the IPIP users is holding amprnet back, and has been for some time. 73's W9CR -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

10 years, 1 month

1
0
0 0

Re: [44net] Portal changes

by Rob Janssen

> Subject: > Re: [44net] Portal changes > From: > Chris <chris(a)g1fef.co.uk> > Date: > 03/12/2015 08:12 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > This is an issue that has cropped up before and was on my TODO list: as you quite rightly point out, some networks are connected via multiple means, e.g. BGP and Tunnels, etc. > > So today I have crossed off one more item from my TODO list, networks now have three separate checkboxes for connection type and you can check more than one (or leave them all unchecked if the network is not yet connected). > > The changes involved several processes so if anyone finds any bugs that have crept in, please let me know. > > Also, for anyone that has an allocated network, please ensure that the correct box(es) are ticked for your network(s). > > Thanks, > Chris > Please make it possible for coordinators to enter regional networks and edit existing ones. Also when hosts and/or subnets already exist in those ranges (i.e. please get rid of the "there are children" error message and allow the operation anyway). It is very difficult to restructure the network registrations as it is now. One really cannot expect that everything will be correct from the start. I entered network descriptions in the HamnetDB and it does not show those issues: there one can define a subnet between the country- and user networks without problem, and also remove or resize it at will. Rob

10 years, 1 month

1
0
0 0

VPN tunnel FAIL

by Mathison Ott

I need help trouble shooting the vpn tunnel ive setup on my RPI its part of a mesh network, here in berkeley,CA. pi@KJ6DZB-4 /etc/openvpn $ service openvpn restart [ ok ] Stopping virtual private network daemon:. [....] Starting virtual private network daemon: clientEnter Private Key Password: failed! Ive set up the same Cert and key file on a windows box and it works. 73 Mathison kj6dzb

10 years, 1 month

2
1
0 0

Portal changes

by Chris

Hello Everyone, I finally found some free time and have been working on the Portal code today: Fixed a few bugs that have been reported to me; Altered the wording on the emails that are sent out following feedback; Removed validation checks for co-ordinators rejecting IP allocation requests; Removed strict control over what networks can be added to gateways. The last point probably requires further explanation: I added a filter that only allowed gateway owners to link networks to their gateways that were a) allocated and b) owned by them. This caused some issues as some people have their networks announced by gateways controlled by other people. So now, anyone can add any network to their gateway that a) has been allocated, and b) has the "connection type” field set to “TUNNEL”. You just select which network you want to add from the drop down box. If the network you wanted to add doesn’t appear in the drop down box, please check that it has been allocated and that it’s connection type is set to “TUNNEL”. Any problems, bugs, etc, please let me know. Thanks, Chris

10 years, 1 month

6
8
0 0

Re: [44net] portal changes

by F6CNB

Chris, Thanks for the work. In the portal gateway network allocations, I think a free typing instead of the lis twill be more useful. It'll allow to add allocations which were not classified as tunnel at the time of the creation and more important i twill allow the group multiple allocated subnets in a single one for gateways which are handling multiple allocations. This will reduce the size of the routing table. 73 de Remi F6CNB

10 years, 1 month

2
1
0 0

Re: [44net] Portal IPIP Mesh Announcements

by Brian Kantor

On Thu, Mar 05, 2015 at 12:00:00PM -0800, 44net-request(a)hamradio.ucsd.edu wrote: > > I've been asked to host 44.158.144.0/22 on my Gateway DB0FHN. It seems > > the portal has changed the policy. I can't add 44.158.144.0/22 to my > > gateway 141.75.245.225. > > > > I guess I need to foward this to Chris? Jann, I added it for you. - Brian

10 years, 2 months

1
0
0 0

Portal IPIP Mesh Announcements

by Jann Traschewski

Hi! I've been asked to host 44.158.144.0/22 on my Gateway DB0FHN. It seems the portal has changed the policy. I can't add 44.158.144.0/22 to my gateway 141.75.245.225. I guess I need to foward this to Chris? 73, Jann -- Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn

10 years, 2 months

2
1
0 0

Multicast problem?

by Rob Janssen

While debugging the "suddenly lost route" that happened again at our gateway today, I stopped and restarted ampr-ripd to use the debug option, and now it suddenly no longer receives any multicast packets. I think I have read on this list or elsewhere that there is an issue with a recent glibc update or kernel update (not sure which one it was). Does anyone have details? Now ampr-ripd only works when the -r flag is passed. Without -r it sets up everything and it opens the multicast socket (which appears to work OK when looking in the trace, it is opened on the tunl0 interface), but nothing is ever received. It looks like it worked OK during the previous run, which was probably using an older glibc that was updated recently (but the system had not been rebooted). It is a Debian Wheezy system, so similar issues probably occur on the Raspberry Pi. W.r.t. the problem I was tracking: the route to 44.137.33.48/28 via 92.108.199.241 dev tunl0 has suddenly vanished at 17:00 local time (16:00 UTC), but when I looked in a wireshark dump it was appearing in the RIP broadcast. ampr-ripd did not pick it up. To trace that I recompiled ampr-ripd with debug code, started it, and then I noticed it would no longer receive ANYTHING. With -r it again receives packets and it also inserted the route to 44.137.33.48/28 again, so I am still at a loss what happened there. Rob

10 years, 2 months

5
6
0 0

Re: [44net] Multicast problem?

by Rob Janssen

> Subject: > Re: [44net] Multicast problem? > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 03/02/2015 08:44 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hi Rob, > > ampr-ripd works as expected without the -r option on my debian 7 setup with > kernel 3.2.0-4 and libc 2.13.38-0deb7u7. > I never upgraded to 2.13.38-0deb7u8, so the problem could be there. > > By the way, as sugested by Brian, N1URO, I think the -r option could be > dropped so that the daemon always uses raw sockets. Ok, the status on this machine now is: Linux gw-44-137 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1 x86_64 GNU/Linux (a kernel update to Debian version 3.5 (still kernel 3.2.0-4 of course) has been installed but the system has not been rebooted yet) libc is version 2.13-38+deb7u8 So indeed it could be that version that is the problem. With -r it works ok, but of course it means that ALL received tunnel packets are passed to ampr-ripd to be filtered there in user mode. The multicast socket should be more efficient. It has worked quite well for a long time, why would it suddenly fail? (of course there is still the problem of sometimes disappearing routes that you may notice I am already hunting down for quite some time and I am not even sure if it is in ampr-ripd, in the RIP transmitting server, or somewhere else) Rob

10 years, 2 months

1
0
0 0

Re: [44net] Portal

by Rob Janssen

> Subject: > Re: [44net] Portal > From: > Tom Hayward <esarfl(a)gmail.com> > Date: > 02/26/2015 08:06 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > I think if you were to open source the portal you would get more > volunteers. I, and many other open source developers, tend to wait to > jump in to a new project until we have an itch that needs scratching. > When a bug affects me, I'll look to the source to see if I can squash > it. If I can, the project maintainer can expect a patch from me. If > the source isn't public, I'll send a bug report to the developer. I > presume you would prefer patches to bug reports. I agree with that. I have submitted several reports and explained my requirements to Tom SP2L but as I have no access to the code I cannot have a glance to see how quickly some of my immediate requirements can be built in, let alone do the work and submit it. I still get "DNS requests" from users who apparently do not see the big red print on top of the DNS page, and I cannot edit the subnet structure in the system to match reality. I submitted it in text form to Chris long ago but it was not inserted. We are currently building a HAMNET similar to what has been done in Germany and Austria, and we really need a working system some time. I fully understand that time is not always available, but some way has to be found to keep the day-to-day operations possible, maybe with a lower level access to the data when writing code for the userfriendly web frontend is the bottleneck. Rob

10 years, 2 months

7
9
0 0

Re: [44net] Portal

by Rob Janssen

> Subject: > Re: [44net] Portal > From: > "SP2L-wp" <sp2l(a)wp.pl> > Date: > 02/26/2015 11:24 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > > > All of us, we are just(?) human beings. We make > mistakes, we forget things... Also, all of us, > we have our private life, family, health problems... > And what Chris perfectly pointed out, sometime > life unexpectedly, without any excuse - intervenes! > Thus making our life much harder and tough... Sure I agree with that. But as it is, the portal is so far from what we need, and the move towards the goal has been so slow, that I think we must re-think what to do. It is all a hobby, but at times some people are very active developing some part of it, and it becomes a problem when other parts don't keep up with the needs and they are dependent on it. This afternoon I entered a lot of data in the HAMNET DB. (hamnetdb.net) That system is much more like what is required. I could easily enter existing subnet layouts and other definitions, because it does not have that strict "owner" model that the portal has. And it also allows to enter a lot more info. Of course it does not have the links to the tunnel gateway and RIP server, and some more info would be required for that (like defining gateway entries), but it is an opensource project and it might well be easier to extend it towards what we need than to continue developing the portal. Rob

10 years, 2 months

1
0
0 0

Re: [44net] Portal

by Bryan Fields

+1 This needs to be open source, it's a major core component of the AMPRnet space. On February 27, 2015 9:38:21 AM EST, "Javier Henderson (javier)" <javier(a)cisco.com> wrote: > >Why the reluctance to put the code on a public repo that is easily >accessible without having to ask? -- Bryan Fields 727-409-1194 http://bryanfields.net

10 years, 2 months

1
0
0 0

Re: [44net] Portal

by Rob Janssen

> Subject: > Re: [44net] 44.151.29.29/32 F4LTS > From: > "Marc, LX1DUC" <lx1duc(a)laru.lu> > Date: > 02/25/2015 08:25 PM > > To: > 44net(a)hamradio.ucsd.edu > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> >I would be happy to scrap the Portal and go back to the procmail >> >scripts that Jim Fuller developed and operated for decades. >> >Things worked, and worked dependably, back then!! >> > >> >The Portal is way too "vaccuumous" for me:( >> > >> >--- Jay WB8TKL > Hello Jay, > > I assume that like any development project, Jim's solution didn't work > 100% from the beginning either. Cut the developers of the portal some > slack and report your issues here, so the issues become known and can > be fixed (or someone may provide a workaround). > > Anyway the thanks to all the developers on the project! > > 73 de Marc I agree with that in principle, but I have reported several issues and rarely ever was anything changed to solve those issues, while in the meantime things were changed that caused even more issues (like the mandatory selection of a registered subnet for an IPIP tunnel), or that added features that were not near the top of any wishlist observed here (like an API). What I need in my daily work as a coordinator in a network that has been springing into life again is a usable mechanism for address assignment, and a way to edit an existing structure into the new database. Without those present, I have to work around the system and tell people to ignore features and make requests in a separate mail. That would be fine if there would be visible progress, say a new feature every month or two, but I have a hard time seeing any. Rob

10 years, 2 months

4
3
0 0

Remote traceroute tool

by Tom Hayward

The other day I helped another 44net user troubleshoot his IPIP configuration by running a traceroute from our network. He asked, "what is the last working hop?" I decided it might be useful to the community at large to release a tool that allowed doing this test from our network without waiting for me to run a command. Here it is: http://trace.hamwan.net/ It is simply a web interface to mtr. I hope this allows people to confirm their IPIP tunnels are working properly. The tool is published on non-44net IPv4 and IPv6 addresses, in case your tunnels aren't working properly yet. (This plan might not be as good as I'd hoped, because the DNS is still on 44.24.240/20.) The source IP for the actual traceroute will be 44.24.241.98. If you would like to deploy this on your piece of 44net, or improve the code, the source is available here: https://github.com/kd7lxl/mtr-web Tom KD7LXL

10 years, 2 months

1
0
0 0

Re: [44net] Portal

by SP2L-wp

Hello Andrew et al. I would like politely remark, that although I participate in portal.ampr.org development, my only task (so far) to which I volunteered, is polish language version of portal.ampr.org Surely, working closely with the source code of portal I spotted some minor mistakes, misprints and so on which I always passed to Chris for review. But to be candid, myself I introduced to the code (fortunately ONLY in polish language version!) some mistakes which made this part of code temporary unusable; Chris needed to correct them! All of us, we are just(?) human beings. We make mistakes, we forget things... Also, all of us, we have our private life, family, health problems... And what Chris perfectly pointed out, sometime life unexpectedly, without any excuse - intervenes! Thus making our life much harder and tough... With best regards from Gdynia. _____ Tom - SP2L (ex sp2lob) __________________________ Send from Sony Xperia Z1 http://aqua-mail.com

10 years, 2 months

1
0
0 0

Re: [44net] Portal

by Bryan Fields

On 2/26/15 4:25 PM, Andrew Ragone (RIT Student) wrote: > To clarify, too, this would be not only for the portal but the website as > well ... in which everyone could contribute to web content / wiki to > describe aspects of 44net and IP in Amateur Radio. have you seen http://wiki.ampr.org/index.php/Main_Page ? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

10 years, 2 months

1
0
0 0

Re: [44net] 44.151.29.29/32 F4LTS

by Rob Janssen

> Subject: > [44net] 44.151.29.29/32 F4LTS > From: > "Marc, LX1DUC" <lx1duc(a)laru.lu> > Date: > 02/14/2015 12:21 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Good evening, > > is Eric F4LTS on this list or does anybody have his contact data? > > Eric has added network 44.151.29.29/32 with Gateway 44.151.29.29, once > the IPIP interface on my router comes up, the route for > 44.151.29.29/32 via 44.151.29.29 comes up, which in turn takes down > the interface which disabled the route, which allows the interface to > come up... a fine loop. > > I had to filter his network 44.151.29.29/32 from the results I fetch > via the API in order to keep my log size down. > > I'm not sure if the portal should allow the gateway for a network to > between inside that same network. I think it makes no sense but please > correct me if I'm wrong. > > 73 de Marc, LX1DUC It is certainly not correct... fortunately ampr-ripd ignores such routes after it was found that other people (like SA0BXI) had created them and they caused encapsulation loops. But of course you are right, the portal should simply refuse to store such incorrect information in the first place. It should issue an error message that makes the user think again about what they have requested. I am a bit disappointed about the progress in the portal development. Sure it can happen that people are temporarily busy and have to postpone things a bit until more time is available, but the portal as it is now has halted the development of amprnet and left everything in a stalemate situation. The DNS part needs to be finished, the allocation of subnets has to be much more flexible, overrides have to be made available to coordinators, and some address management tools have to be added. When it is decided that this cannot be done in the time available to the developer, it may be better to switch to another management system like the hamnet-db. 73, Rob

10 years, 2 months

3
2
0 0

question about iptables command not being accepted

by Rosalio Salas

In the wiki example... http://wiki.ampr.org/index.php/Ubuntu_Linux_Gateway_Example Under Protecting the Gateway... The following OUTPUT command is not accepted. sudo iptables -A OUTPUT -i lo -j ACCEPT The error reads: "iptables version 1.4.14 can't use -i with output" Any suggestions? -- Leo , N5JEP

10 years, 2 months

2
4
0 0

Re: [44net] Linux files purity...

by Bryan Fields

I'd propose a purity test. 😀 On February 15, 2015 12:35:30 PM EST, Mitch Winkle <mitchwinkle(a)gmail.com> wrote: >(Please trim inclusions from previous messages) >_______________________________________________ >Being a ^M "offender" I can tell you that the ax.25 and Uronode and >axMailFax software have no issues with said ^M characters in the >axports >file. The blank line issue has been well known for years but to my >recollection, only for NetROM's nrports file. I (until yesterday) had >a >blank end line on my axports file to no detriment. > >Tom thank you for following your hunch, and hopefully we can get that >documented for the "fbb" script for us newby types. > >Mitch >

10 years, 2 months

2
1
0 0

Linux files purity...

by SP2L-wp

To whom it may concern. As some issues lately discussed on both lists evidently show, there is not to much attention paid to REAL PURITY of all, or at lest some linux config files, in particular axports file. It is CRUCIAL, that axports file: - CAN NOT contain ANY EMPTY line at all! If additional space is necessary between lines then usual spaceholder "#" is fine, - CAN NOT contain ^M (CR - in hex 0x0D) code at the end of any line! NOT RESPECTING above two rules may result in unpredictable behavior of many AMPRNet software, not to mention FBB BBS, URONode. Presence of ^M (CR) code can be viewed and corrected, for instance, in Midnight Commander, VI and well known Emacs editors. >From the other hand, simple and friendly editors like nano and joe, apparently are useless... There are few nifty tools that may one use for removing ^M characters, even from bunch of files without editing. Best known is dos2unix available for all linux like distros. Best regards _____ Tom - SP2L (ex sp2lob) __________________________ Send from Sony Xperia Z1 http://aqua-mail.com

10 years, 2 months

2
1
0 0

Re: [44net] 44Net Digest, Vol 4, Issue 23

by f5pbg＠free.fr

Hello, his email is eric.f4lts(a)gmail.com I have already contact him. Best regards, Ludovic - F5PBG. Le 14/02/2015 20:00, 44net-request(a)hamradio.ucsd.edu a écrit : > Good evening, > > is Eric F4LTS on this list or does anybody have his contact data? > > Eric has added network 44.151.29.29/32 with Gateway 44.151.29.29, once > the IPIP interface on my router comes up, the route for > 44.151.29.29/32 via 44.151.29.29 comes up, which in turn takes down > the interface which disabled the route, which allows the interface to > come up... a fine loop. > > I had to filter his network 44.151.29.29/32 from the results I fetch > via the API in order to keep my log size down. > > I'm not sure if the portal should allow the gateway for a network to > between inside that same network. I think it makes no sense but please > correct me if I'm wrong. > > 73 de Marc, LX1DUC

10 years, 2 months

1
0
0 0

Bad route to 44.140.0.0/16

by Rob Janssen

What is it that makes this route: 44.140.0.0/16 via 192.16.126.18 dev tunl0 proto ampr-ripd metric 44 onlink appear and disappear all the time? The gateway 192.16.126.18 does not work. In the portal there is a gateway 44.140.0.1 for 44.140.0.0/16, also BAD of course. This has been discussed before. Why hasn't it been deleted? How can it be that there are TWO gateways for the same 44.140.0.0/16 network in the portal? And why is the 192.16.126.18 one appearing and disappearing every few hours? Please whoever is responsible for this, debug this. It has been an issue for many months, it has been discussed before, but nothing has happened. SA0BXI apparently is not reading the list. I thought that was a requirement for being a gateway. As he has never replied to any discussion about his network, why don't we simply delete his entries? Note that 44.140.0.0/16 is BGP announced, so when there is no faulty entry at least it will work for some setups. Right now it is just dead. Rob

10 years, 2 months

1
0
0 0

44.151.29.29/32 F4LTS

by Marc, LX1DUC

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good evening, is Eric F4LTS on this list or does anybody have his contact data? Eric has added network 44.151.29.29/32 with Gateway 44.151.29.29, once the IPIP interface on my router comes up, the route for 44.151.29.29/32 via 44.151.29.29 comes up, which in turn takes down the interface which disabled the route, which allows the interface to come up... a fine loop. I had to filter his network 44.151.29.29/32 from the results I fetch via the API in order to keep my log size down. I'm not sure if the portal should allow the gateway for a network to between inside that same network. I think it makes no sense but please correct me if I'm wrong. 73 de Marc, LX1DUC -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJU3obzAAoJELyI73cdFgugm20P+gJyN53Z3Gs+WPMhrK+erP+Y YolVkDxUbUHWEXIcT/pnYwSmv0oDw2DQYzGaES4vHeJgb1sTQrbyPXXi72dHSkLe 7NEjwYz2DH1R3udikQ1yGE24vlQAWWqQYgT4KJ5zOqwmX2INfv+3apgBGvWDUArv sUxPYkywkHLld+N1hGEtlrDjg6wm1FoRoEDdhsbSV1laJ+Nyra+EVn2VuIc5rJKN nDlqa3OYtP2cy0POEmUb3HGbTIszjaWNksrdEof9kNARGCpula/mI2iQpwtJeKqy iw+QtJv72vICHNYgwAdu/bzTvgAgbosfm6WYG/g3IgupPsZBdC64fZ0Z0pn8bB5x koWFGx9g/z/gWjUPuG0UPPzWlozftpiQWlz9qO3/5aSfy0Kn6koFjDl9cA0Q53kS zWI0cuDK4giJQ/fy/vDojzgNnZp511Rm3WScZx9ZI/WbRE696mnLEckADmlZGg0U dAFJDrJNYkujiZDFJWN0ZMjiZO9nEMwgSTLhr7f5xF4l3M7nfhw+dy13lqRPB68q Mhi+NfWz6Ko+jdjLEtBVxOB2UbfUVG+aY5QVa+ctWStigN8d3hyAZ2oiXgtho1m2 m+WK912ObDyzH4waPOyQiMuf3hbnk0064WkJdHvXN5N2ZvW/0ld5FSwe5qF2NEt5 WAP3tvG3Yhsx4YNSuHe6 =XilB -----END PGP SIGNATURE-----

10 years, 2 months

1
0
0 0

Incomplete table with ampr-ripd

by Rob Janssen

> Subject: > [44net] Incomplete table with ampr-ripd > From: > Brett Mueller <wa7v(a)wa7v.com> > Date: > 02/10/2015 06:14 AM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Greetings Marius and all, > > Just over a week ago, I finally compiled and installed ampr-ripd 1.13 on my > gateway firewall / router, a Slackware 13.1 with 2.6.33.4-grsec-smp > (home-rolled Grsecurity kernel). Compilation and execution seems to work just > fine, but I get an incomplete AMPRnet routing table (currently only about 30 > routes). > > Ideas what could be preventing me from getting a full routing table? Any place > besides the usual logging locations where I could find some clues? Debugging > arguments, perhaps? > You may have some systematic packet loss along the route to your system. I experienced some problems some time ago (although not as severe as you describe) and I changed EXPTIME from 600 to 7200 in the source. That helps when there is occasional packet loss. Of course when there is systematic loss due to a very small queue at some point, it will not help much. Rob

10 years, 2 months

1
0
0 0

portal dns page

by Don Fanning

Chris (or anyone), Any idea when the DNS portion of the web page will be online? Being able to manipulate my own DNS entries is the only thing keeping me from being on network. Thanks, -Don

10 years, 2 months

1
0
0 0

ampr-ripd password

by Libor Berka

I am using ampr-ripd for the node OK2KOJ-5 44.177.10.253 (As well as for node OK2PEN-5 44.177.10.10). The node is registered at amprnet but I cannot get the encrypted password for running correctly ampr-run.sh and find-pass.sh utilities. Can somebody tell me how can I get my encrypted password to configure it into those a.m. utilities ? Thank you Libor sysop of OK2KOJ-5 and OK2PEN-5 ampr nodes.

10 years, 2 months

1
0
0 0

Incomplete table with ampr-ripd

by Brett Mueller

Greetings Marius and all, Just over a week ago, I finally compiled and installed ampr-ripd 1.13 on my gateway firewall / router, a Slackware 13.1 with 2.6.33.4-grsec-smp (home-rolled Grsecurity kernel). Compilation and execution seems to work just fine, but I get an incomplete AMPRnet routing table (currently only about 30 routes). I use a separate kernel routing table for all my encap routes, and since I didn't want to interrupt my operational services while I tested ampr-ripd, I simply added a parallel 'test' table to rt_tables and had the daemon place its routes there. In order to see what has been populated, I manually run 'ip route ls table test' and observe the results. My command line argument to launch the daemon is ampr-ripd -t test -p <cRyPtIcPaSsWoRdHeRe> Interestingly, when I have it save routes to the encap.txt file, the file itself gets a MUCH longer list (400-something lines), even though the table has a small fraction of that. One more observation is that the routing table does not appear to change from whatever it initially populates with (and yes, the daemon is still visibly running). I do have iptables set to accept UDP 520 from 44.0.0.1 on the INPUT chain. Ideas what could be preventing me from getting a full routing table? Any place besides the usual logging locations where I could find some clues? Debugging arguments, perhaps? Many thanks! 73, Brett, WA7V

10 years, 2 months

1
0
0 0

Re: [44net] Contents of 44Net digest...

by Russ Garber

My first post to this list :-) > 1. Re: No luck with dotun.sh script (Mitch Winkle) > Many thanks to Brian N1URO for the diagnosis and necessary band-aid due to > the ISP, in my case Comcast. For what it is worth, I switched to Comcast blast awhile ago and could no longer update NTP from the Internet. Ping to servers worked. Funny, NTP was specified to pass their default firewall via a supplied rule. My solution was to call and turn their combo router/modem into a modem only and use my old router.. Life was good again :-) Russ, k4ziv

10 years, 3 months

2
1
0 0

Re: [44net] No luck with dotun.sh script

by William Lewis

Mitch: From my commercial IP address, I can ping your 44.62.1.9 address and get a response. I can not telnet into it though. From my 44.2.14.1 address I DO NOT get a response to ping attempts to 44.62.1.9. Bill At 01:28 PM 1/30/2015, you wrote: >(Please trim inclusions from previous messages) >_______________________________________________ >Hello all, and hopefully this will be a simple user head space error. > >I have an IP-IP gateway defined as ab4mw.noip.me in the portal >My address space is 44.62.1.8/29 (sova1.ab4mw.ampr.org - >sova6.ab4mw.ampr.org). sova1 is the host in question.

10 years, 3 months

2
2
0 0

F6CNB

by Brian Kantor

Does anyone have a valid email address for F6CNB? It is important that I contact him. - Brian

10 years, 3 months

2
1
0 0

JNOS2 vulnerable to outside hack

by vk1kw

Hello All, Please be advised that if you run FBB BBS with outside telnet access thru BPQ32 and have the FBB gateway enabled, someone may connect to JNOS via the gateway and the internal RS232 ports and execute the '@' command on the JNOS prompt line. This gives access to Linux Directories etc. I have not seen the '@' command mentioned in the JNOS2j documentation so not sure where it gets compiled in so if you could maybe help me there please? It does not seem to be in the DOS options and not the 'ED' definition as both are undefined. Also my compile of JNOS2j completes ok with no 'success' indications and produces a file it seems but suffers from the dreaded crash a few minutes after it runs - I suspect it is the open port problem but yet to check that out. Cheers Rob

10 years, 3 months

5
6
0 0

DXSpider link

by Brian

Greetings list; Is anyone running DXSpider I can link into temporarily? Contact me offline please. -- 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.

10 years, 3 months

1
0
0 0

glibc ghost checker

by Brian

I have a utility you may use to check your linux system for the GHOST (CVE-2015-0235) vulnerability. You may retrieve it at: ftp://n1uro.ampr.org/linux/ghost-check.tgz For brief info about this exploit: http://www.netfort.com/i-aint-afraid-of-no-ghost-cve-2015-0235/ -- 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.

10 years, 3 months

1
0
0 0

No luck with dotun.sh script

by Mitch Winkle

Hello all, and hopefully this will be a simple user head space error. I have an IP-IP gateway defined as ab4mw.noip.me in the portal My address space is 44.62.1.8/29 (sova1.ab4mw.ampr.org - sova6.ab4mw.ampr.org). sova1 is the host in question. I am attempting to get the first host online via IP-IP tunnel using 44.62.1.9 as the tunl0 address which also corresponds to the ax0 address (VHF link). I used Brian N1URO's straightforward dotun.sh script from this mailing list (and his web site at http://n1uro.ampr.org/linuxconf.dotun.html). No errors running the script. The rules are there, the RIP routes and the default route to UCSD are in table 1. However, I cannot seem to touch anyone on the 44/8 network from this host. My static IP address facing the cable router is 192.168.0.20 and 192.168.0.1 is the default inet gateway of course. This host is in the DMZ of my cable router. I have full internet access from this host as well. First, if someone could provide a valid host for me to ping/telnet, etc. to from here, that would help. None of the /32's I have tried from the encap.txt are reachable, nor is telnet n1uro.ampr.org 3694 which is my go to test host. Traceroute from n1uro.ampr.org's uronode shell was a complete bust as well as from ve1jot's system in Nova Scotia. Any help will be graciously appreciated. If anyone wishes to contact me off list to look at configs or rec'v a temporary ssh login to peruse my host, I'd be happy to oblige. I have been looking at this thing so long, my eyes are now permanently crossed I think. Also, any attempts to connect to me may provide help, so telnet sova1.ab4mw.ampr.org port 4000 connect to a std. node application for testing. Many thanks, MItch AB4MW mitchwinkle at gmail dot com -- Mitch Winkle http://ewamjlu.blogspot.com ...How long will you go limping between two different opinions? If the LORD is God, follow him... 1 Kings 18 ESV

10 years, 3 months

3
5
0 0

no more acces

by on4hu

since Christmas last year more access to 44net for my subnet 44.144.11.128/29 what can i do ??? with the help of Belgian IP Coordinator I used a PPP connection with a RouterBoard but since then pluis possible connection My Belgian coordinator does not respond at all to my requests which has a solution? thank you in advance André ON4HU -- http://on4hu.dyndns.org:81/ http://www.on4hu.be/ http://44.144.11.136/ ftp://ftp.on4hu.be/ ou ftp://on4hu.dyndns.org/ http://on4hu.eu/ COMPUTERS ARE LIKE AIR-CONDITIONERS THEY STOP WORKING PROPERLY AS SOON AS YOU OPEN WINDOWS.

10 years, 3 months

3
5
0 0

KE6I

by Brian

Does anyone have a valid email address for KE6I? If so, please send it to me offlist. There seems to be no response to the one I do have. Thanks. -- 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.

10 years, 3 months

2
3
0 0

https portal.ampr.org down?

by Marc, LX1DUC

Hello, I cannot access https://portal.ampr.org from 2 different commercial internet providers (e.g. not 44net). It seems that I can connect to the http version, which redirects to the httpS version. Does anybody else have this problem? 73 -- Marc, LX1DUC -- www.laru.lu - Luxembourg Amateur Radio Union www.emcomm.services - Emergency Communication www.ham-dmr.lu - DMR Infos for HAMs

10 years, 3 months

5
4
0 0

Debian 7 Wheezy latest update

by marius＠yo2loj.ro

Hello, Yesterday, I applied the latest updates on my Debian7 Wheezy (x64)system running, including a kernel update. I have a Kantornics TNC in kiss mode connected to a prolific USB serial adapter, working in single channel mode (no mkiss). The result was that my TNC doesn't work properly anymore: Rx works properly until the first transmission (which happens on the radio correctly). After that, no more data is received from the TNC - Tx working correct. After a TNC reset, it works again until the first Tx. I will try to find the exact cause of this behavior. I would suspect either an issue in the USB driver, or in the ax.25 stack. Please exercise caution on this update. 73s de Marius, YO2LOJ

10 years, 3 months

5
10
0 0

Public service uses for ham data networks

by Michael E Fox - N6MEF

All, I'm giving a presentation on the use of ham data networks for public service. I have in mind examples like: -- deploying mesh networks at art-and-wine festivals to provide VoIP connectivity to info booths, video surveillance of parking lots, etc. -- deploying mesh or other WiFi networks at a bicycle or foot race to report statistics, etc. But rather than just offering ideas of what COULD be done, I'd like to show the folks some examples of what others have ACTUALLY DEPLOYED. What I'm looking for is: -- Description of the event (event name, purpose, who attends, how big, etc.) -- Description of the data networking need (why bother? Why not use commercial facilities? etc.) -- What services you deployed: VoIP, video, file server, . -- What network you deployed: equipment, architecture, and why you did it that way vs. any other alternatives you considered -- Lessons learned -- Pictures and/or diagrams, if you have them, are important Although this is the right group to target with this request, I don't want to burden this list with replies. So please make replies off-list. Thanks much in advance, Michael N6MEF n6mef(a)mefox.org

10 years, 3 months

2
1
0 0

44 Network behind BGPed 44 Address

by lleachii＠aol.com

All, Happy New Year! A few months ago, an AMPRNet user requested 44Net allocations. One subnet is announced on the Public Internet using BGP. The other is a standard 44 gateway, with the exception that it's Public IP address is the BGPed 44/8 address. Since, on the ICANN Internet, 44/8 is one flat network routeed via BGP; and allocations within AMPRNet are often islands gateways with a non-44 IP (since, under ICANN logic, this means both the WAN and LAN interface are on the same network) routed using RIP44; this presented a problem with our current schema. Using Linux routing, I solved the problem by adding the 44 subnet to a special routing table, and adding the Public-facing gateway address to my Public-facing route table. Hence, these routes and rules ignore the "invalid" RIP44 gateway announcement. Here's the script: NOTE: make sure the BGPed IPs have a higher priority (lower number) than the standard AMPRNet ip rules. ######################################## ### SPECIAL CASE - FOR THOSE WHO BGP ### AND HAVE SUBNETS BEHIND 44 ADDRESSES ### THIS ADDS THE BGPed IP TO THE MAIN TABLE ip rule add to 44.24.221.1/32 table main priority 42 ### THIS ADDS THE ROUTE TO A SPECIAL TABLE ip route add 44.24.240.0/20 via 44.24.221.1 dev tunl0 onlink table 22 ### THIS TELLS THE ROUTER TO REFERENCE THE ### SPECIAL TABLE TO ACCESS THIS SUBNET ip rule add to 44.24.240.0/20 table 22 priority 43 73, -Lynwood KB3VWG

10 years, 3 months

5
11
0 0

Station down due to PC issues

by Jerry Kutche

Subnet 44.48.0.40/29 is down for a while.. ETA unknown. Problem unknown. Time to effect repairs not available. For a while.. Have backups.. standing by. 73 Jerry N9LYA HF Skipnet Coordinator HF Skipnet Midwest HUB ARRL Net Manager - Packet Indiana AmprNet IP Coordinator Indiana Indiana Packet Coordinator Sysop N9LYA/K9BBS/W9BBS/W9OTR W9OTR Hoosier Amateur Radio Digital Society W9HU Hoosier Radio Society ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5577 / Virus Database: 4257/8911 - Release Date: 01/11/15

10 years, 3 months

1
0
0 0

Setting up a 44net gateway/router

by Rial Sloan

New 44net user/coordinator here. Following the wiki (at ampr.org) I think I found an issue with the documentation when using Ubuntu 14.04. The ifconfig multicast command I believe has been deprecated. It didn't set multicast on my ampr0 device. I was able to set the flag on when I ran the following command after referencing the manpage ( http://linux.die.net/man/8/ip) - ip link set dev ampr0 multicast on Can someone help me figure out if that's the only line deprecated? I suspect the onlink route might also be awry because when i run 'ip route' I don't see the route to send traffic to amprnet gateway at UCSD Thanks! Rial F Sloan II KJ4IKD GA AMPRNet Coordinator

10 years, 3 months

1
1
0 0

Re: [44net] lots of telnet attacks from china, australia

by Gabriel Medinas

Hello Maiko, Is a general bruteforcing, root and admin attemps logins (telnet), see all hour of all days, very more attemps with "root" in all 44.152... 73 de Gabriel YV5KXE yv5kxe.ampr.org Message: 1 Date: Thu, 8 Jan 2015 09:37:29 -0600 (CST) From: Maiko Langelaar <maiko(a)pcs.mb.ca> To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: [44net] lots of telnet attacks from china, australia Message-ID: <alpine.LNX.2.02.1501080934570.12131(a)shodan.physics.umanitoba.ca> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Is it just my system ? I'm seeing many many login attempts as root on telnet. Are they targetting just 44 ? Maiko / VE4KLM

10 years, 3 months

1
0
0 0

Posting to the list (request)

by Bryan Fields

As we're a technically savvy bunch, can I ask that when posting to the list with a new message not to reply to another and then change the subject? This breaks threading and will cause issues when looking at the archives. I'm simply asking this as a user of the list who uses a threading MUA. Thanks & 73's W9CR -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

10 years, 3 months

3
2
0 0

Re: [44net] lots of telnet attacks from china, australia

by William Lewis

I run a software that watches the log book. It's called "Fail2Ban". I have it watch many system logs including JNOS. I have it set to look for 3 failed attempts from the same IP address and then it bans that IP address for a month. It must ban at least 20-30 ip addresses a day. Most are from China. Wm Lewis KG6BAJ At 07:37 AM 01/08/15, you wrote: >(Please trim inclusions from previous messages) >_______________________________________________ > >Is it just my system ? > >I'm seeing many many login attempts as root on telnet. > >Are they targetting just 44 ? > >Maiko / VE4KLM > >_________________________________________ >44Net mailing list >44Net(a)hamradio.ucsd.edu >http://hamradio.ucsd.edu/mailman/listinfo/44net

10 years, 3 months

4
3
0 0

Re: [44net] Tunnel mesh is (mostly) down

by Rob Janssen

> Subject: > Re: [44net] Tunnel mesh is (mostly) down > From: > "John Wiseman" <john.wiseman(a)cantab.net> > Date: > 01/04/2015 10:09 AM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Wouldn't the simplest solution be to modify the rip44 process so it doesn't > delete routes that haven't been announced for a while, or at least for a > much longer period? > > IPIP tunnels and RIP have the major advantage that they allow those who have > a dynamic IP address to participate in net44. I feel it is important that we > remember that we are radio hams first, and should use solutions that can be > used by the majority of hams, not just those network professionals who want > to play a being an ISP. > > 73, > John G8BPQ That sounds like a good idea, John. The ampr-ripd has a route lifetime of only 600 seconds. Routes are announced every 300 seconds, so when two subsequent announces are incomplete we lose the route. It happened again this morning at 08:05 local (07:05 UTC). My route again was lost, and recovered at 08:10. I think I'll recompile ampr-ripd with a bit larger timeout. Marius, what do you think? Does this have any negative consequences? (e.g. to change EXPTIME from 600 to 3600 or even 7200) However, aside from that, the source of the problem should be located, or it will bite us again in the future. There could be big packet loss on the link from UCSD, or maybe some buffer overflow internal to the RIP server (I think it sends big bursts of data rather than slowly throttled streams), or it could be the RIP server somehow sends shortened information because it temporarily does not have the full route list, e.g. because the portal sends an incomplete list. This has to be investigated or else it will come back. I predict. (I mention this because I recently had a long discussion with someone who thinks that we can live with malfunctioning solutions because we are amateurs. I think we should strive for correctly working systems anyway. And that a system that works well in practice is always better than a system that works well in theory but does not work in real life) Rob

10 years, 3 months

6
10
0 0

Re: [44net] Tunnel mesh is (mostly) down

by Rob Janssen

> Subject: > Re: [44net] Tunnel mesh is (mostly) down > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 01/05/2015 10:54 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Yes, the latest version drops subnets for which the gateway is set inside > their own subnet, sice this breaks routing. > > Marius > > -----Original Message----- > From:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu > [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Rob > Janssen > Sent: Monday, January 05, 2015 22:28 > To:44net@hamradio.ucsd.edu > Subject: Re: [44net] Tunnel mesh is (mostly) down > > ... > It could be that the latest version that I now downloaded hides that problem > with 44.140.0.1 > but I can easily see if other routes are appearing/disappearing regularly. > ... > > Rob There is still something wrong with that network. Now that the 44.140.0.1 gateway is rejected, a gateway 192.16.126.18 inconsistently appears in the route table (sometimes it is there, sometimes it isn't). But that gateway is not listed at all in the portal! In the portal there is a gateway at 44.140.0.1 that advertises to be the gateway for subnet 44.140.0.0/16, of course wrong. The 192.16.126.18 would be fine, but it does not appear in the gateway listing at portal.ampr.org. But it is broadcast (occasionally) in the RIP broadcast. Difficult to follow what is going on here, I would say there is insufficient error checking somewhere. Rob

10 years, 3 months

1
0
0 0

Re: [44net] Tunnel mesh is (mostly) down

by Rob Janssen

> Subject: > Re: [44net] Tunnel mesh is (mostly) down > From: > "Michael E Fox - N6MEF" <n6mef(a)mefox.org> > Date: > 01/06/2015 12:32 AM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hmmm. Given a 1 hour timeout, then any error would need to be detected and > corrected within that hour, or else routes will still be lost. Correct? > > It would seem that a timeout of something more like 24 hours would be more > practical. The rationale behind the 1 hour timeout is not to cover errors and outages, although it could cover cases where e.g. the server has to be relocated within the same room, or network maintenance occurs. The reason is that one of the hypotheses is that there is packet loss that drops the RIP packets, and when two subsequent RIP bursts would each loss the last (or n'th) packet e.g. because of a queue overflow somewhere the route would be already lost. The chance of this happening to 12 subsequent broadcasts (1 hour) is smaller. Further increasing the timeout would mean that a route that is no longer present would take much longer to disappear, unless a mechanism as described by Marius is added. (where a deleted route is announced in a special way) With that modification, the timeout could be safely set to something like 1 week. Rob

10 years, 3 months

1
0
0 0

Re: [44net] Tunnel mesh is (mostly) down

by Rob Janssen

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] Tunnel mesh is (mostly) down > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 01/05/2015 07:30 AM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hello, > > I don't think that increasing the route timeout the would have any bad side > effects (I think 7200 would be a good value). I have recompiled with 3600 before I read that. However, I'll keep a watch on it for some time to see if strange things still happen. It could be that the latest version that I now downloaded hides that problem with 44.140.0.1 but I can easily see if other routes are appearing/disappearing regularly. > > But maybe there is another mechanism that could be added to the ampr gateway > (And which is already implemented in ampr-ripd): > The daemon is capable of force exipring routes if they are received with > metric 15. > So adding the sending of deleted subnets with metric 15 fore a given time > AND increasing normal expire time to higher values (e.g. 10800 - 3 hours, or > even more) would make the system more stable. > > Marius, YO2LOJ > > That sounds like a good idea, in that case there could be a much longer timeout, but maybe it should then (as Brian suggested) log when it receives less packets than normal. E.g. count the received packets in a single burst and syslog a message when it is 2-3 less than in the previous burst. When we fix the problem that routes disappear too soon, but then nobody notices anything and 24 hours later we still have a problem because the routes are suddenly deleted, not much has improved. When there is some alert I can watch it in our nagios monitoring. Rob

10 years, 4 months

2
1
0 0

PP5ES

by Brian Kantor

Is PP5ES on this mailing list? If so, please contact me off-list. Thank you. - Brian

10 years, 4 months

1
0
0 0

Re: [44net] Tunnel mesh is (mostly) down

by Rob Janssen

> Subject: > Re: [44net] Tunnel mesh is (mostly) down > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 01/05/2015 07:26 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Mon, Jan 05, 2015 at 02:27:18PM +0200, Marius Petrescu wrote: >> >Let me get this right... You are talking about the encapsulated RIP >> >transmissions originating from 169.228.66.251 to each public gateway IP? >> > >> >-----Original Message----- >> >On Behalf Of Rob Janssen >> >Sent: Monday, January 05, 2015 11:11 >> >To: Brian Kantor >> >Cc:44net@hamradio.ucsd.edu >> >Subject: Re: [44net] Tunnel mesh is (mostly) down >> > >> >Maybe something else you can do is drop the extra transmission of RIP >> >packets from the public IP >> >address. I think nobody is really using those (if not because of the funny >> >destination port number), and >> >they only add to this problem by putting even more data in the queue. > Up until a few minutes ago, the amprgw system was sending the RIP data > twice - once UNencapsulated to the public gateway IP, once encapsulated. > > Since to the best of my knowledge, no one was using the UNencapsulated RIP > for anything, I've discontinued sending it. > > If I'm wrong and someone is using it for something, I'll turn it back on. > - Brian > > > Note that those transmissions were sent to a seemingly random destination port number, which made them kind of hard to use. The source port number was always 520. I don't know if that was a bug or a feature, but it puzzled me when I was trying to receive them and could not get the encapsulated transmission working in ampr-ripd. (an issue that I later located and Marius made a change that fixed that) Rob

10 years, 4 months

1
0
0 0

AMPR Portal Error for Coordinator

by William Lewis

Chris / Brian. I had a new request for an AMPR addresses allocation from the portal, but there seems to be a couple of issues. First, I never received the new request via email as I usually do. Not sure why I didn't get this request. Second, the user that submitted the request accidentally select my network of 44.002/16 when he should have selected Daniel Curry's network of 44.004/16. In the coordinators section of the portal, when I tried to DENY the request, the page refreshes and I get an error in red stating : "There are children but selected owner is not a coordinator." and I can not deny the request. I have contacted the user who submitted the request and informed him to make another request on the correct network. But, it appears there is a bug on the portal that is not sending me email notifications and not letting me deny requests. Thanks for looking into this. ---------- 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.

10 years, 4 months

1
0
0 0

Linux policy routing explained briefly

by Brian

There seems to be a bit of confusion as to how linux routes via policy routing. The tool which appears to be the most flexible is "ip" found in the iproute2 package. The two key switches are "route" and "rule", and they do exactly what they sound like; one manages routes and route-tables, while the other manages the ruleset in which these routes/tables are called upon. Linux begins with a main route table and a default ruleset in which that table is used. Typically you don't even notice this as it's created with the configuration of the standard network devices upon boot. Two rules will be applied for this main route table: 1) main 2) default The rules are such that the priority to these tables is so low almost any other rule will take priority over it. That's what makes amprnet routing for linux quite simple. The rule you want to make for amprnet is such that any inbound OR outbound routing sourced as 44-net uses it's own route table, with a priority higher than the main table rule. As long as the routes are in this matched table, the kernel will act as an amprnet router just fine even to entities such as xNOS, Xnet, etc. So if you want proper packet flow make sure all paths and rules match for the source you wish to route - in our case it's 44/8: A sample standard path would look like: commercial to commercial/nat inet/0 <----> linux-nat or com IP table main commercial to your ampr inet/0 <----> ucsd/bgp host ucsd/bgp host <---> linux 44-tunl0 via rule 1/table 1 <---> node/bbs/dxc ampr to ampr (tunnel only shown) 44/8-tunl0 <---> linux tunl0/rule 1/table 1 <---> node/bbs/dxc ampr to ampr to xNOS/Xnet (tunnel only shown) 44/8-tunl0 <---> linux tunl0/rule 1/table 1 <---> tun0/tap0-xNOS/Xnet This shows that the Xnet or xNOS tun/tap interfaces need to be included within the ruleset that matches table 1 or else it will become unroutable. Also you need to insure ip_forwarding is enabled, and your firewalling permits ip protocol 4 (ipencap), and ip protocol 93 (AX.25) A simple script which can do this for you is found at http://n1uro.ampr.org/linuxconf/dotun.html # --- dotun.sh --- #! /bin/bash # dotun.sh script written by N1URO # June, 2013 # enter in your information below, these are used for creating a # gateway and linking to the amprnet: AMPRIP='x.x.x.x' IPMASK='x.x.x.x' COMMIP='x.x.x.x' NOSIP='x.x.x.x' case "$1" in start) # Load your ipencap module in the kernel: modprobe ipip # Allow ip forwarding from amprnet to your ethernet interface echo "1" > /proc/sys/net/ipv4/ip_forward # load RIPv2 routing using the ampr-ripd daemon /usr/local/sbin/ampr-ripd -t 1 -a $COMMIP -p <password> -i tunl0 -v -s -r # Configure your ipencap tunnel interface - required for the amprnet ifconfig tunl0 $AMPRIP netmask $IPMASK up # Allow traceroutes to work on the amprnet: ip tunnel change tunl0 mode ipip ttl 64 tunl0 pmtudisc # If you run xNOS, configure a tun/tap interface: ifconfig tun0 $AMPRIP pointopoint $NOSIP up # configure your rointing accordingly: ip route add $NOSIP dev tun0 onlink table 1 src $AMPRIP ip route add default via 169.228.66.251 dev tunl0 src $AMPRIP onlink table 1 # configure policy routing so that frames from/to your 44-net IP # know how to route accordingly: ip rule add from 44/8 pref 1 table 1 ip rule add to 44/8 pref 1 table 1 # script is done, exit as a clean flush. exit 0 ;; stop) # Unload what we loaded above: ip rule del to 44/8 pref 1 table 1 ip rule del from 44/8 pref 1 table 1 ifconfig tunl0 down ifconfig tun0 down killall -TERM ampr-ripd modprobe -r ipip exit 0 ;; restart) dotun stop sleep 3 dotun start exit 0 ;; *) echo "Usage: dotun {start|stop|restart}" exit 0 ;; esac exit 0 --- EOF --- -- 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.

10 years, 4 months

5
6
0 0

Tunnel mesh is (mostly) down

by Rob Janssen

The tunnel mesh went down today at about 08:20 UTC. Most of our routes have disappeared, are no longer being advertised on RIP. The portal.ampr.org site is not responding anymore. It looks like the portal is no longer distributing correct information to the RIP server and so the RIP server sends incomplete broadcasts and the ampr-ripd deletes the routes. Is there some fallback scenario, e.g. loading a last correct list of routes by the RIP server to make the network come back up in the state it was just before the mishap? Rob

10 years, 4 months

12
15
0 0

Re: [44net] Tunnel mesh is (mostly) down

by Rob Janssen

> Subject: > Re: [44net] Tunnel mesh is (mostly) down > From: > Eric Fort <eric.fort(a)gmail.com> > Date: > 01/03/2015 05:35 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > how about eliminating this issue perminantly from ever happening and > moving to voluntary peering between gateways. Know thy neighbor and > be responsible foryourpeers androutesseems to work really well for > everyone else yet amprnet still relies upon route distribution from a > single source. > > Eric > AF6EP It is still not clear to me what exactly happened, and how it was resolved, but what I saw here is that the number of tunnel routes decreased dramatically and this disconnected the stations on IPIP including myself. We already are BGP announced. That is not the problem. But as a properly setup gateway, we are both on BGP and the IPIP tunnel mesh, and the latter we configured using RIP (ampr-ripd). What apparently happened is that we received RIP broadcasts with only a very small subset of the active routes, and over time most routes got deleted. So we still had full connectivity to internet for net 44.137.0.0/16 and our statically connected subnets, but the tunnel routes inside the country and to the rest of the world mostly vanished. We don't really need those tunnels to everywhere over the world, but we run them to remain compatible with the rest of the system. It would be sufficient for us to have only tunnels to our local users, and have the remainder of the traffic routed over plain internet. However: - there is no way in the portal to specify that you want to use tunnel routes only for your own subnets - there are access lists in use at other stations that would block traffic going outside the tunnel system, because they want to limit traffic to only net-44, so we would get obscure routing problems So for now we will keep running a tunnel mesh system, and I hope that everyone else who prefers functionality over other reasons will do the same. (I fail to see how a single-point-of-failure solution can be a worse choice than a configuration that does not work *at all* even when everything is up and running) In the meantime, I hope some people can find some time to debug what was going on here. I have seen a similar problem in the RIP broadcasts before, a set of routes that appears and disappears at random. They appear in some RIP broadcast sets, then do not appear in some, then re-appear, etc. There must be a problem somewhere, but it is unclear if it is in the RIP server or in the code that delivers info to it. Maybe the problem of this morning is caused by the same bug, as it appears to have affected only a subset of all routes. Rob

10 years, 4 months

1
0
0 0

Re: [44net] Tunnel mesh is (mostly) down

by Bryan Fields

On 1/3/15, 11:45 AM, Brian wrote: > On Sat, 2015-01-03 at 08:35 -0800, Eric Fort wrote: > >> > how about eliminating this issue perminantly from ever happening and >> > moving to voluntary peering between gateways. Know thy neighbor and >> > be responsible foryourpeers androutesseems to work really well for >> > everyone else yet amprnet still relies upon route distribution from a >> > single source. > Are you suggesting something such as a possible BGPv2 that all gateways > or designated regional gateways could perhaps tunnel broadcast between > themselves? This would be interesting and may help with other route > issues between those using RIPv2 <-> BGP amprnet sites. Why tunnel at the gateway level?, let the other gateways run BGP. Problem solved. How you get to the gateway could be IPIP, GRE, IPSEC, or you can run BGP yourself. Or even if you have a friendly peering location that lets you put a dish on the roof. Treating this like is some kinda special VPN really holds amprnet back. 73's W9CR -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

10 years, 4 months

4
3
0 0

Re: [44net] Should I worry about this crud coming in via the tunnel?

by Rob Janssen

> Subject: > [44net] Should I worry about this crud coming in via the tunnel? > From: > Arno Verhoeven <pe1icq(a)vrhvn.nl> > Date: > 01/02/2015 04:11 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hi, > > I have been monitoring traffic coming in via the tunnel and am a bit shocked how much bogus (?) traffic comes in from non-44 addresses. Yes, this is quite normal. Imagine how much comes in to the country gateway and gets dropped... The internet is full of people who only want to destroy it and there is not much that can be done about it. People use spoofed sender addresses (their provider should block that but many providers don't care), and others like to scan for all kinds of situations they can abuse, e.g. for DDOS. You need a good firewall. But maybe not what Tom suggests, because that ends your connectivity with the non-44 part of internet. Rob

10 years, 4 months

1
0
0 0

Should I worry about this crud coming in via the tunnel?

by Arno Verhoeven

Hi, I have been monitoring traffic coming in via the tunnel and am a bit shocked how much bogus (?) traffic comes in from non-44 addresses. I have these rules in my firewall script: /usr/sbin/iptables -P INPUT DROP # Drop all traffic coming from Internet addresses via the tunnel to PE1ICQnet, except port 8000:8001 to raspberry pi (Dire Wolf). /usr/sbin/iptables -A INPUT -i ampr0 -s 44.0.0.0/8 -d 44.137.27.123 -p tdp -m multiport --dport 8000:8001 -j ACCEPT /usr/sbin/iptables -A INPUT -i ampr0 ! -s 44.0.0.0/8 -d 44.137.27.112/28 -j DROP When I monitor traffic on the tunnel interface with tcpdump -i ampr0 -vvn then I see a lot of traffic like this: 15:47:54.172385 IP (tos 0x0, ttl 51, id 60643, offset 0, flags [none], proto ICMP (1), length 98) 119.206.12.19 > 44.137.27.125: ICMP 119.206.12.19 udp port 53 unreachable, length 78 IP (tos 0x28, ttl 234, id 31771, offset 0, flags [DF], proto UDP (17), length 70) 44.137.27.125.29327 > 119.206.12.19.53: [udp sum ok] 31771+ A? ocektarhe.www.2015yf.com. (42) Remarkable, because at the moment I do not even have ip address 44.137.27.125 in use on the LAN. How do I need to interpret the above traffic dump? Is it because 44.137.27.125 is spoofed? Is it an attack using bogus domain resolving? (I see a lot of variants in the 2015yf.com domain) Basically, my question is, should I worry? ;-) 73 PE1ICQ // Arno

10 years, 4 months

2
1
0 0

Attn. Brian ref IP address.

by trcarswell

I sent an email over a year ago...(it seems) to remove me from being an IP coord. I guess you missed it. I just got a email for a request...that was over a year old....the guy is pissed... as I would be....lol Pls remove me ...I hope someone can take my place... My wife got sick right after I became the the NC coord. Sorry. Trip - KT4WO

10 years, 4 months

1
0
0 0

How to make traffic coming in on the tunnel interface get answered from that interface?

by Arno Verhoeven

Hi, I am looking for help setting up a conditional routing table. I have my tunnel up and running. I can reach other 44-net host. amrp-ripd is used to fill the routing table. So far so good, but I would like one of the web-sites (apache httpd vhost) to be reachable from both 44-net and non-44-net. If i check with tcpdump I see traffic coming in when I try to access the web-site (pi8zaa.ampr.org) via the Internet (I used my phone connected to t-mobile network). But it doesn't work because my server routes the replies to my ISP's Gw where they get source filtered. Basically I want/need traffic that comes in via the tunnel to get answered from the tunnel interface. I Googled for a solution. Found lots of variant of this http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html but if I understand what is described there correctly, then that is not exactly what I need. Maybe I don't understand iproute2 and its routing table concept correctly. They way I understand it, those examples assume destination routing based on provider subnet, while in my case the destination is on the Internet, and in normal cases should be routed via my ISP except if it came in via the tunnel. Thanks for any help you can offer. 73 PE1ICQ // Arno

10 years, 4 months

8
36
0 0

Merry Christmas

by Brian Kantor

+ XXX XXXXX XXXXXXX XXXXXXXXX "BUON ANNO" "JOYEUX NOEL" "VESELE VANOCE" "MELE KALIKIMAKA" "NODLAG SONA DHUIT" "BLWYDDYN NEWYDD DDA" "GOD JUL" "FELIZ NATAL" "BOAS FESTAS" "FELIZ NAVIDAD" "MERRY CHRISTMAS" "KALA CHRISTOUGENA" "VROLIJK KERSTFEEST" "FROHLICHE WEIHNACHTEN" "BUON NATALE-GODT NYTAR" "HUAN YING SHENG TAN CHIEH" "WESOLYCH SWIAT-SRETAN BOZIC" "MOADIM LESIMHA-LINKSMU KALEDU" "HAUSKAA JOULUA-AID SAID MOUBARK" "'N PRETTIG KERSTMIS" "ONNZLLISTA UUTTA VUOTTA" "Z ROZHDESTYOM KHRYSTOVYM" "NADOLIG LLAWEN-GOTT NYTTSAR" "FELIC NADAL-GOJAN KRISTNASKON" "S NOVYM GODOM-FELIZ ANO NUEVO" "GLEDILEG JOL-NOELINIZ KUTLU OLSUM" "EEN GELUKKIG NIEUWJAAR-SRETAN BOSIC" "KRIHSTLINDJA GEZUAR-KALA CHRISTOUGENA" "SELAMAT HARI NATAL - LAHNINGU NAJU METU" "SARBATORI FERICITE-BUON ANNO" "ZORIONEKO GABON-HRISTOS SE RODI" "BOLDOG KARACSONNY-VESELE VIANOCE " "MERRY CHRISTMAS - - HAPPY NEW YEAR" "ROOMSAID JOULU PUHI -KUNG HO SHENG TEN" "FELICES PASUAS-EIN GLUCKICHES NEWJAHR" "PRIECIGUS ZIEMAN SVETKUS SARBATORI VESLLE" "BONNE ANNEBLWYDDYN NEWYDD DDADRFELIZ NATAL" XXXXX XXXXX XXXXX XXXXXXXXXXXXX Submitted by: Gordon Joly <G.Joly(a)cs.ucl.ac.uk> Nov. 30, 1994

10 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net