44net

44net@mailman.ampr.org

3196 discussions

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net