44net

44net@mailman.ampr.org

3198 discussions

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net