- 44net - mailman.ardc.net

Re: [44net] Strange Broadcasts...
by Rob Janssen 15 Jun '15

15 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Don Fanning <don(a)00100100.net> > Date: > 06/15/2015 12:35 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > >> >When you want to do something about a SPOF it is only required to do the >> >RIP transmission >> >from another system in parallel. E.g. from the system running the portal. >> > >> > > RIP still doesn't solve routing loops that occur. RIP doesn't converge > quickly (currently 44ripd takes 5+ minutes to send any new*static* change > - if your firewall is configured to receive said packets from said > source). I fail to see why that is a problem. Few gateway stations appear a day, and having to wait 5 minutes before they are routed is really no big deal. Before, many gateway stations loaded a routing table maybe once a day, or even less frequently. Again, we are a radio hobbyist network, not some financial trade network. > RIP has no concept of bandwidth limitations or multiple paths for > the same route (ie: load balanced connections with different ISP). Again, let's first set up something that is popular and has many users, and then we can always consider doing things like that. For now we, and many others, find ourselves fortunate to have found a SINGLE ISP that wants to sponsor us. When we setup radio connections to our neighboring countries we may achieve some redundancy. And I prefer that way over settting up a tunneling system over the internet. Or even over routing over the internet. Remember we are an amateur radio network, not some multinational company trying to setup a rendundant data network with zero failures. Rob

2 1

Re: [44net] Strange Broadcasts...
by Rob Janssen 15 Jun '15

15 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Bryan Fields <Bryan(a)bryanfields.net> > Date: > 06/14/2015 09:48 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On 6/14/15 3:35 PM, Rob Janssen wrote: >> >Your problem is that you want to try to talk us into believing that we have a problem with >> >reliability, while for most of us it is clear that we first and foremost have a problem with >> >existance. The amateur digital network is nearly dead, we are trying to revive it and make >> >it thrive like it did in the early days, a network built and operated by hobbyists, and you >> >are continuously trying to impress us with your knowledge about professional networks and >> >your concerns about failure modes. > Rob, take a chill pill. > > Take a look at the HamWAN, HAMNET, and what I'm doing here in the bay area. > It's very much alive, and we're educating people about high-speed ham packet > networks everyday. I had over 200 people at the TAPR forum at Dayton this > year for my talk. > I am not talking about the work you do locally but about the way you approach "us" after you have found some problem with your gateway implementation. Not even mainly about the discussion that just has started, but about a similar discussion that was started about the same topic some time ago. You continuously refer to Brian's system at UCSD as "broken", and I don't like that attitude. Especially not because it really is possible to fit in your system to co-exist in the network as it is now, as is demonstrated by our gateway. Rob

2 1

Re: [44net] Two questions
by Rob Janssen 15 Jun '15

15 Jun '15

> Subject: > Re: [44net] Two questions > From: > Bryan Fields <Bryan(a)bryanfields.net> > Date: > 06/14/2015 09:10 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > No, the issue is the_broken_ routing at UCSD. > > ARDC does not announce the 44/8, UCSD does it for them and has a static route > for 44/8 pointing at the gateway box. This is broken routing since the > gateway is unaware of the more specific networks. > > What needs to be done is the UCSD gateway needs to be made aware of the > subnets in the global table and only announce the subnets it knows about. > There are routing protocols that would make this easy. But that is already in place!! It is the IPIP tunnel mesh. As long as you provide an IPIP tunnel for the subnet you advertise yourself on BGP, with a tunnel endpoint on an internet address OUTSIDE 44.0.0.0/8, there is no problem at all! We do have the same situation as UCSD at our gateway. Our ISP does the BGP advertising of 44.137.0.0/16 and routes the traffic to the gateway. We have registered the same space on the portal, and we have an external address for that (213.222.29.194). All the routing is fine, also for people who send the traffic to UCSD. Because UCSD sees the more specific route 44.137.0.0/16 first and sends the traffic via IPIP to us, instead of sending it out to the default gw that would bounce it back. When you would set up the same configuration, you would be out of trouble. When you don't want a single system to be responsible for the IPIP tunnel you can setup some redundancy, as long as you don't "conveniently" take a subnet out of 44.0.0.0/8 for that, because that does not work. It is known it does not work. > > <tangent> > I'd argue the BGP networks would be better if 44/8 was split up in such a way > set aside a /12 (for example!) for BGP subnets and a /12 for the IPIP users. > This makes the routing much easier to configure on a IPIP encap gateway. The > present geographic area way of doing it leads to routing table bloat. > </tangent> I don't agree with that. It will just make a new configuration necessary for something that now works OK just by the mechanisms we already have. Rob

1 0

Two questions
by Jann Traschewski 15 Jun '15

15 Jun '15

Hi! I have two questions: 1. Around 99% of all webcams on the HAMNET are *only* reachable if you establish the connection using a *source-44* ip address. Do you think this restriction is enough if you don't want to expose the webcam to the internet but want to share with other AMPRNet users? 2. We tell our HAMNET users to put the route 44.0.0.0/8 via <wireless router to HAMNET access point> into their DSL/cable routers. Some well-known internet services for radio amateurs are nowadays hosted on the internet using network44 addresses. Who needs to be blamed if the connection from the HAMNET user to the well-known internet service is not as stable as expected by the user? 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

6 12

Re: [44net] AMPRNet Interoperability with BGP (fwd)
by Tim Osburn 15 Jun '15

15 Jun '15

On Sun, 14 Jun 2015, Brian Kantor wrote: > Date: Sun, 14 Jun 2015 18:20:22 -0700 > From: Brian Kantor <Brian(a)ucsd.edu> > Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > Subject: Re: [44net] AMPRNet Interoperability with BGP > > (Please trim inclusions from previous messages) > _______________________________________________ > On Sun, Jun 14, 2015 at 05:26:26PM -0700, Tim Osburn wrote: >> This only requires at >> least 1 (or more) ISP (or companies running BGP) willing to setup a >> BGP over GRE tunnel to Brian's server to make this work. There are >> currently two ISP I know of willing to do this if Brian is willing to >> do this on the AMPRnet Server shown in the drawing. > > I'm willing but not able. The server 'amprgw' is an old FreeBSD system > that doesn't understand GRE. We have been discussing updating it to > a more modern system (both hardware and software) but at this point > it doesn't seem like that's going to happen. We've not been able to > identify ANY router product that can do what the gateway needs to do > in order to replace 'amprgw'. > > I have an alternative suggestion, which would be to find an ISP or two > that are willing to take over the IPIP tunnel routing. > > They would BGP advertise /24 summary routes for the smaller tunnels, as well > as appropriate routes for the wider tunneled subnets. That way there is > no fixed route that blinds the tunnels to the BGP subnets. UCSD could > still advertise the 44/8 overarching route (which I strongly believe is > essential to preventing prefix hijacks), but since there would be more > specific routes for the BGP and tunnel subnets, that wouldn't matter. > It would only be necessary for the tunneled gateways to change their > tunnel endpoint address -- there is no need for tunneled gateways to > suddenly have to change software or overall configuration. > > Flaws? > - Brian > If we did BGP over IPIP would that work? Are you able to run Quagga or something that can do BGP/Routemaps on your FreeBSD box? What version of FreeBSD is it? Is the CAIDA telescope a external system? Perhaps a SHIM box with quagga & GRE Tunnels between CAIDA & amprgw? Tim Osburn www.osburn.com 206.812.6214 W7RSZ

2 2

Re: [44net] Strange Broadcasts...
by Rob Janssen 14 Jun '15

14 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Don Fanning <don(a)00100100.net> > Date: > 06/13/2015 10:05 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Alright, let's take this a different route. > > What would it take to make IPIP mesh more robust? > > If BGP capable nodes were to announce and route for IPIP endpoints within > it's endpoint, that would remove the SPOF at UCSD. No, it will just make the system more complicated. Especially when you introduce yet another routing protocol, even worse, a manufacturer proprietary protocol. When you want to do something about a SPOF it is only required to do the RIP transmission from another system in parallel. E.g. from the system running the portal. Rob

2 1

44.161.239.0/24
by Brian Kantor 14 Jun '15

14 Jun '15

Will the person announcing 44.161.239.0/24 via BGP please contact me off-list. - Brian

1 0

Re: [44net] Strange Broadcasts...
by Rob Janssen 14 Jun '15

14 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Bryan Fields <Bryan(a)bryanfields.net> > Date: > 06/13/2015 11:59 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On 6/13/15 4:05 PM, Don Fanning wrote: >> >IPIP would also get the >> >benefit of possibly routing EIGRP between IPIP mesh sites so that if one >> >BGP route were to have catastrophic failure, another BGP announced route >> >would already be announced and EIGRP would route to that end point. > This is a joke, correct? > > You're proposing fixing broken routing using a non-standard protocol. IIRC > EIGRP uses IP multicast for announcements (same as OSPF) so you'd need to run > it over some sort of tunnel (gre) interface anyways. > > Just use BGP with a private AS up to the edge Internet connected BGP nodes if > you're building tunnels. > > Tim Osburn and myself (and others) had proposed standards based way to move > the IPIP tunnels to a redundant gateway design a few years back. It's not > hard, but there is no movement from ARDC to actually move forward with it. > I'd be happy with a study of proposed ideas, at least it's forward movement. > Your problem is that you want to try to talk us into believing that we have a problem with reliability, while for most of us it is clear that we first and foremost have a problem with existance. The amateur digital network is nearly dead, we are trying to revive it and make it thrive like it did in the early days, a network built and operated by hobbyists, and you are continuously trying to impress us with your knowledge about professional networks and your concerns about failure modes. Furthermore, you try to enforce your ideas by criticizing the efforts of volunteers and trying to do a coup d'etat. It does not work that way. When you have a real improvement to introduce you should demonstrate how to do it in a way compatible to what others are doing, and understanding. What I find a joke is that you are concerned about having a single point of failure, and then roll out a solution that does not work *at all* under some static circumstances. Better have a single point of failure in a network that works most of the time, than a network that never works OK. (some pure theorist may disagree with that and claim that something that never works is more reliable that something that works 99.9% of the time, but I am not in that camp) Rob

2 1

Re: [44net] Strange Broadcasts...
by Rob Janssen 14 Jun '15

14 Jun '15

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] Strange Broadcasts... > From: > Nigel Vander Houwen <nigel(a)k7nvh.com> > Date: > 06/13/2015 09:30 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Rob, > > Thank you for making my point. The reason you cant use a 44/8 address for a tunnel endpoint is because routing is broken. > > Nigel > I don't agree with you. There is a problem with routing inside UCSD in that case, but there are other reasons why that should not be done. When you run an IPIP gateway on a source-address-filtered system (and in my opinion, ALL user connections should be soirce-address-filtered!! ISP's that don't to that just suck!) you need to route back traffic from net-44 to internet via the gateway. The only viable way of setting up policy routing rules to do that falls apart when tunnel endpoints are inside 44.0.0.0/8. So that should just be prohibited. (As Marius also explained, it is even worse when tunnel endpoints exist within subnets that are also advertised as being gatewayed) Rob

1 0

Re: [44net] Strange Broadcasts...
by Rob Janssen 14 Jun '15

14 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Bryan Fields <Bryan(a)bryanfields.net> > Date: > 06/13/2015 09:40 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > I agree, however the configuration of a single gateway announcing 44/8 without > the ability to reach more specific networks is_broken_ routing. Let me say > this again: > > _The UCSD Gateway has BROKEN ROUTING affecting the REACHABILITY of IPIP users._ > > If BGP users announce a subnet that 99.99999% of the internet can see, but > IPIP users behind the UCSD gateway can't reach it, it's not BGP users that > have broken routing, it's the silly UCSD gateway. This is INCORRECT, it is actually your own system that is broken. When you put up a system that announces a BGP route on Internet, you should also make that system part of the IPIP mesh for the same subnet that you advertise on BGP. Then, those that want to reach you on IPIP do not need to go via the UCSD gateway but can directly reach you on IPIP. Remember IPIP is a mesh, there is no "central gateway" other than that it has the largest subnet and attracts all traffic that is not otherwise routed. Routing the IPIP traffic is your own responsibility, don't shift it to UCSD or Brian. Rob

7 22

Radius
by Rob Janssen 13 Jun '15

13 Jun '15

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] Strange Broadcasts... > From: > "Sam VK4AA" <vk4aa(a)vk4aa.com.au> > Date: > 06/13/2015 01:27 AM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Morning Gang > > Has anyone done authentication for paket stations connecting to our network > by using radius? > > > Sam > VK4AA I have tried, although not very persistently, but until now I have not succeeded. I thought it would be easy (having some experience with radius in combination with VPN routers), but until now I have not succeeded in getting a configuration with WiFi APs operating in EAP mode and freeradius server on Linux to actually work. It should be possible, though. Rob

1 0

Re: [44net] Strange Broadcasts...
by Rob Janssen 13 Jun '15

13 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Tom Hayward <esarfl(a)gmail.com> > Date: > 06/11/2015 08:45 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Forget about this; it's just syntax. Who cares if we have to have > hundreds of P2P interfaces instead of a single P2MP? The script > creates them, so the burden of both methods is equivalent. > Well, I think it is much better (at least, cleaner) to have a single IPIP interface (P2MP) and have a route table (separate or merged with the main table) updated by a routing protocol. What you have made will work, but requires frequent downloading of a file and patching of the configuration to process changes. I did that before on Linux, but after having installed ampr-ripd I would not want to go back to that method... About routes: in Linux it is possible to have routes bound to an interface that has a broadcast nature (e.g. ethernet) and with a gateway that is outside the subnet served by the system itself. So you can partition a subnet and still have only a single gateway. This can be useful on ham networks where everyone in a local area has a Point-to-Point link to a node, and everyone routes to others via the node, but the node does not have an address in each subnet. RouterOS cannot handle this, but Linux can. E.g.: node has subnet 44.137.40.0/23 and has address 44.137.41.254 user has subnet 44.137.41.96/28 and has address 44.137.41.110 on eth0 then: ip route add 44.0.0.0/8 dev eth0 gw 44.137.41.254 onlink To do this in RouterOS (and in many other routers) you need to set the subnet mask to /23 on the eth0, but that means it will try to contact the others directly, not routing via the node. This will work when the local area is switching/bridging. Otherwise you will need to have a node address in everyone's subnet. The same situation occurs when setting up the P2MP IPIP tunnel interface: you assign it the subnet of your local system, so all the routes are outside the interface's subnet and need the "dev" and "onlink" parameters. RouterOS does not support them. But Linux does. Rob

7 10

Re: [44net] Strange Broadcasts...
by Rob Janssen 13 Jun '15

13 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > "Marc, LX1DUC" <lx1duc(a)laru.lu> > Date: > 06/12/2015 05:06 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > > I do think that regardless of the OS it is much more important that anybody using 44net addresses shall support the IPIP mesh, regardless of any other routing procedures (e.g. direct BGP announcement, etc) in use. I have the "luxury" to be able to > do direct BGP announcements, so I can reach BGP-only 44networks without NATing my 44net to my commercial IP address, others don't have this luxury but would eventually like to reach those 44etworks without the requirement for NAT. Our country gateway is BOTH on BGP and on the IPIP mesh. It advertises the entire 44.137.0.0/16 network on both BGP and IPIP. My systems at home are on net 44.137.41.96/28 and are linked to a local node for 44.137.40.0/23 via RADIO (unusual, I know...) and that node is again linked to the gateway system via our HAMNET. So my system is reachable both for BGP and for IPIP systems (and radio-connected systems) without me running IPIP myself. Hence I don't need to do that at home. When my radio link fails, I can setup an IPsec or OpenVPN VPN connection to our gateway, and routing in the network will automatically adapt (the gateway and the nodes talk BGP on a private ASN# on the HAMNET side and the gateway will advertise my 44.137.41.96/28 subnet when I setup an IPsec or OpenVPN link). So there is no need to worry! Rob

2 1

Re: [44net] Strange Broadcasts...
by Rob Janssen 12 Jun '15

12 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Jeroen Massar <jeroen(a)massar.ch> > Date: > 06/11/2015 09:03 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > >Forget about this; it's just syntax. Who cares if we have to have > >hundreds of P2P interfaces instead of a single P2MP? > ntpd cares about it and also the Linux and FreeBSD kernels. > > ISC ntpd listens on each interface automatically, hence after ~200 > interfaces it breaks as it runs out of file descriptors (each interface > gets a separate socket as it uses it that way to be able to properly > select the interface to reply to packets on that interface). I know about that problem! Silly ntpd listens on a separate socket for every address, instead of just listening on a wildcard socket. It caused havoc on our gateway because it has over 200 addresses assigned to a dummy0 interface, used by an EchoLink proxy farm running on the machine. Fortunately in recent versions of ntpd it can be solved by config like this: interface ignore all interface listen lo interface listen eth1 interface listen tun0 interface listen tunl0 i.e. you can direct ntpd what interfaces to watch and to ignore the rest. I think it would be better when it listened on 0.0.0.0 instead (of course you CAN set the source address of outgoing packets on a wildcard socket, at least in Linux you can), but I saw there already has been a heated debate about that on the mailinglist so I chose not to suggest that and use the abovementioned workaround. Rob

1 0

Re: [44net] Strange Broadcasts...
by Rob Janssen 11 Jun '15

11 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 06/06/2015 09:48 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hi Rob, > > I was quite active in the Mikrotik community and tried to push a little our > ampr tunnel stuff. > But the results are actually null. People are friendly but not interested. Ok... at the moment I am reading the forum to see how change requests actually are to be posted and how they are handled, as I have some other requests. > The missing element is a way to create an IPIP interface without a specific > peer IP, and add routes to specific peers on a given IPIP interface to get > it in multipoint mode. That is clear, yes. I already found that the do not support static routes being bound to interfaces, let alone "onlink" routes. So even when you would want to load routes using a script, it still cannot be done. They must have a reason for this (probably they want to keep the routing entirely clean according to common practices), as the Linux kernel can do a lot more than what they expose via the config interface. > > The easiest way to get ampr up fully is actually to set up a metarouter on a > mipsbe routerboard (they have a xen virtualization on those), and run a > OpenWRT in it, to do IPIP encap and run ampr-ripd. I have tried that, it > works, but at the moment I use a PPC based routerboard which doesn't offer > virtualization. > But your RB2011 is a good candidate for this kind of setup, being mipsbe > based. Others would be the RB45x, the RB75x, the RB95x and the OmniTik > series. As I wrote, I have no need for this because my RB2011 has a radio link to HAMNET and as a backup I can setup an IPsec VPN to our gateway. So I don't need to be on the IPIP mesh. And I still have a Linux system in colocation (a Raspberry Pi) that is on IPIP. But for others, this approach can be interesting. Some systems e.g. www.pe1chl.ampr.org and hampi.pe1chl.ampr.org are routed over this radio link and the MikroTik (but there is no useful content on them). > > Regarding to linux: They run a proprietary distribution on a 3 kernel, but > shell access is unfortunately not available, and there is no way to add 3-rd > party extensions. > The device can be "rooted", though. You get a busybox shell. I have not done that yet, it will probably make it difficult to get support in case I encounter some bug I want to be fixed. Rob

4 5

My talk from Dayton 2105
by Bryan Fields 09 Jun '15

09 Jun '15

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

1 0

Re: [44net] Strange Broadcasts...
by Steve L 07 Jun '15

07 Jun '15

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

6 5

Re: [44net] Strange Broadcasts...
by Rob Janssen 06 Jun '15

06 Jun '15

> 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

2 1

RIPE Atlas Probe on 44net?
by Bryan Fields 06 Jun '15

06 Jun '15

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

1 0

Strange Broadcasts...
by jerome schatten 06 Jun '15

06 Jun '15

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

3 4

Re: [44net] Bad MX records in the ampr.org DNS
by Rob Janssen 03 Jun '15

03 Jun '15

> 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

1 0

Re: [44net] Bad MX records in the ampr.org DNS
by Rob Janssen 03 Jun '15

03 Jun '15

> 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

3 2

Re: [44net] Bad MX records in the ampr.org DNS
by Rob Janssen 02 Jun '15

02 Jun '15

> 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

11 23

Re: [44net] Bad MX records in the ampr.org DNS
by William Lewis 28 May '15

28 May '15

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

3 8

Re: [44net] Bad MX records in the ampr.org DNS
by Rob Janssen 28 May '15

28 May '15

> 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

4 3

hu.ampr.org DNS
by Rob Janssen 26 May '15

26 May '15

> 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

4 4

Re: [44net] Bad MX records in the ampr.org DNS
by Rob Janssen 25 May '15

25 May '15

> 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

1 0

hu.ampr.org DNS
by Norbert Varga 25 May '15

25 May '15

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/

2 1

ampr-gateways.org
by G1FEF 25 May '15

25 May '15

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

1 1

Bad MX records in the ampr.org DNS
by Rob Janssen 25 May '15

25 May '15

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

2 1

Re: [44net] ampr-gateways.org
by Rob Janssen 23 May '15

23 May '15

> 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

1 0

Re: [44net] ampr-gateways.org
by Steve L 23 May '15

23 May '15

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.

1 0

44net connection with RaspberryPi behind NAT
by Fred Boogaard 14 May '15

14 May '15

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

3 2

Re: [44net] easy amprnet attachemet and connection - seeking peers for cost sharing
by Rial Sloan 13 May '15

13 May '15

> > > 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

1 0

Re: [44net] easy amprnet attachemet and connection - seeking peers for cost sharing
by Rob Janssen 13 May '15

13 May '15

> 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

1 0

BGP VPN access
by Bryan Fields 13 May '15

13 May '15

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

1 0

easy amprnet attachemet and connection - seeking peers for cost sharing
by Eric Fort 13 May '15

13 May '15

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

4 6

Re: [44net] easy amprnet attachemet and connection - seeking peers for cost sharing
by Bryan Fields 13 May '15

13 May '15

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

1 0

Ampr Wiki
by Brian 12 May '15

12 May '15

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.

2 1

expiring old routes
by Niall Parker 05 May '15

05 May '15

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

2 2

Port Forwarding
by gm4upx＠gb7jd.co.uk 22 Apr '15

22 Apr '15

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..

2 3

encap.txt to Cisco script
by Nick G4IRX 13 Apr '15

13 Apr '15

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.

3 3

(no subject)
by Don Moore 11 Apr '15

11 Apr '15

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

2 2

gateways downlad
by Don Moore 06 Apr '15

06 Apr '15

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

1 0

ve3clg 4
by Boudewijn (Bob) Tenty 03 Apr '15

03 Apr '15

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

1 1

Re: [44net] Gateways
by Kevin 27 Mar '15

27 Mar '15

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

5 10

Re: [44net] Gateways
by Kevin 26 Mar '15

26 Mar '15

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+

2 1

Gateways
by Kevin 26 Mar '15

26 Mar '15

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+

3 2

Pls help! on adding subnet
by Pedro Converso 26 Mar '15

26 Mar '15

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

1 0

help for changing an existing allocation
by F6CNB 24 Mar '15

24 Mar '15

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)

2 1

Re: [44net] Multicast problem?
by lleachii＠aol.com 23 Mar '15

23 Mar '15

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

1 0

Proposal on using the "Radio" flag
by marius＠yo2loj.ro 17 Mar '15

17 Mar '15

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

8 8

Re: [44net] TUNNEL vs DIRECT connection of subnets
by Rob Janssen 14 Mar '15

14 Mar '15

> 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

2 1

TUNNEL vs DIRECT connection of subnets
by Brian Kantor 14 Mar '15

14 Mar '15

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

3 3

Re: [44net] TUNNEL vs DIRECT connection of subnets
by Bryan Fields 14 Mar '15

14 Mar '15

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

1 0

Re: [44net] Portal changes
by Rob Janssen 13 Mar '15

13 Mar '15

> 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

1 0

VPN tunnel FAIL
by Mathison Ott 13 Mar '15

13 Mar '15

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

2 1

Portal changes
by Chris 12 Mar '15

12 Mar '15

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

6 8

Re: [44net] portal changes
by F6CNB 12 Mar '15

12 Mar '15

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

2 1

Re: [44net] Portal IPIP Mesh Announcements
by Brian Kantor 05 Mar '15

05 Mar '15

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

1 0

Portal IPIP Mesh Announcements
by Jann Traschewski 05 Mar '15

05 Mar '15

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

2 1

Multicast problem?
by Rob Janssen 02 Mar '15

02 Mar '15

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

5 6

Re: [44net] Multicast problem?
by Rob Janssen 02 Mar '15

02 Mar '15

> 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

1 0

Re: [44net] Portal
by Rob Janssen 28 Feb '15

28 Feb '15

> 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

7 9

Re: [44net] Portal
by Rob Janssen 28 Feb '15

28 Feb '15

> 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

1 0

Re: [44net] Portal
by Bryan Fields 28 Feb '15

28 Feb '15

+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

1 0

Re: [44net] Portal
by Rob Janssen 27 Feb '15

27 Feb '15

> 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

4 3

Remote traceroute tool
by Tom Hayward 27 Feb '15

27 Feb '15

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

1 0

Re: [44net] Portal
by SP2L-wp 26 Feb '15

26 Feb '15

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

1 0

Re: [44net] Portal
by Bryan Fields 26 Feb '15

26 Feb '15

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

1 0

Re: [44net] 44.151.29.29/32 F4LTS
by Rob Janssen 25 Feb '15

25 Feb '15

> 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

3 2

question about iptables command not being accepted
by Rosalio Salas 21 Feb '15

21 Feb '15

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

2 4

Re: [44net] Linux files purity...
by Bryan Fields 15 Feb '15

15 Feb '15

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 >

2 1

Linux files purity...
by SP2L-wp 15 Feb '15

15 Feb '15

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

2 1

Re: [44net] 44Net Digest, Vol 4, Issue 23
by f5pbg＠free.fr 15 Feb '15

15 Feb '15

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

1 0

Bad route to 44.140.0.0/16
by Rob Janssen 14 Feb '15

14 Feb '15

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

1 0

44.151.29.29/32 F4LTS
by Marc, LX1DUC 13 Feb '15

13 Feb '15

-----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-----

1 0

Incomplete table with ampr-ripd
by Rob Janssen 10 Feb '15

10 Feb '15

> 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

1 0

portal dns page
by Don Fanning 10 Feb '15

10 Feb '15

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

1 0

ampr-ripd password
by Libor Berka 10 Feb '15

10 Feb '15

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.

1 0

Incomplete table with ampr-ripd
by Brett Mueller 10 Feb '15

10 Feb '15

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

1 0

Re: [44net] Contents of 44Net digest...
by Russ Garber 03 Feb '15

03 Feb '15

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

2 1

Re: [44net] No luck with dotun.sh script
by William Lewis 02 Feb '15

02 Feb '15

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.

2 2

F6CNB
by Brian Kantor 01 Feb '15

01 Feb '15

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

2 1

JNOS2 vulnerable to outside hack
by vk1kw 31 Jan '15

31 Jan '15

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

5 6

DXSpider link
by Brian 31 Jan '15

31 Jan '15

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.

1 0

glibc ghost checker
by Brian 31 Jan '15

31 Jan '15

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.

1 0

No luck with dotun.sh script
by Mitch Winkle 31 Jan '15

31 Jan '15

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

3 5

no more acces
by on4hu 27 Jan '15

27 Jan '15

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.

3 5

KE6I
by Brian 22 Jan '15

22 Jan '15

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.

2 3

https portal.ampr.org down?
by Marc, LX1DUC 16 Jan '15

16 Jan '15

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

5 4

Debian 7 Wheezy latest update
by marius＠yo2loj.ro 15 Jan '15

15 Jan '15

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

5 10

Public service uses for ham data networks
by Michael E Fox - N6MEF 14 Jan '15

14 Jan '15

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

2 1

44 Network behind BGPed 44 Address
by lleachii＠aol.com 12 Jan '15

12 Jan '15

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

5 11

Station down due to PC issues
by Jerry Kutche 11 Jan '15

11 Jan '15

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

1 0

Setting up a 44net gateway/router
by Rial Sloan 10 Jan '15

10 Jan '15

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

1 1

Re: [44net] lots of telnet attacks from china, australia
by Gabriel Medinas 08 Jan '15

08 Jan '15

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

1 0

Posting to the list (request)
by Bryan Fields 08 Jan '15

08 Jan '15

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

3 2

Re: [44net] lots of telnet attacks from china, australia
by William Lewis 08 Jan '15

08 Jan '15

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

4 3

Re: [44net] Tunnel mesh is (mostly) down
by Rob Janssen 07 Jan '15

07 Jan '15

> 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

6 10

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net