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