HI every one, I have an alocation and registered a gateway to do ipip encapsulation to finally be able to run a gateway inside my local lan.
The gateway is a debain 9 computer with 2 nic. one connected to my lan (eth0) and another wich will have the 44 net address network (eth1) I already put the first adress of the 44 allocation that I have on eth1. eth0 is for now on dhcp.
Now I've been reading, reading and re reading the wiki. there are so much stuff that I am lost.
In my case, what deamon do I need? looking at this web page: http://www.yo2loj.ro/hamprojects/ so is it ampr-ripd 2.4?? amprd 2.1??
there are also script that I found out about.. http://wiki.ampr.org/wiki/Startampr#Script
I got this configured. But I am really not sure of what I am supposed to do with it. And on the wiki page there are allusion to some hourly script running to backup the rip table. where are those?
Anyone can point me in the good direction so that I can finally have this running?
Thanks
Pierre
VE2PF
Hi - I requested a block via the portal and I noticed that my call is on gateway list, however I didn’t get any indication that I had sent in the request. I know they said that everything was volunteer and to be patient, but just wondering if my request went in as I didn’t get any email. Thanks.
.michael, ve7ki
> Hi all,
> I’m having an issue with my 44Net tunnel. It works beautifully incoming and almost as good outgoing. For some reason, while on a 44Net IP’ed computer, I can’t reach yahoo.com. > All other locations I’ve tried work well and off the 44Net, yahoo.com is reachable.
That kind of problems is usually caused by over-active network admins that block all ICMP and thus kill PMTU discovery.
You can work around it by doing "TCP MSS clamping" at your end.
E.g. when you have a MikroTik router:
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes \
protocol=tcp tcp-flags=syn
Rob
Hi all,
I’m having an issue with my 44Net tunnel. It works beautifully incoming and almost as good outgoing. For some reason, while on a 44Net IP’ed computer, I can’t reach yahoo.com. All other locations I’ve tried work well and off the 44Net, yahoo.com is reachable. On the 44Net, it times out. DNS seems find and I can ping the address. I’ve tried both chrome and Firefox and cleared the cache on both. Is anyone else having issues with that site, or any other? Solutions?
Roger
VA7LBB
>Contacting Debian will always yield the same results as they've stated
>for decades now. They fix end-user affecting bugs, but they don't
>introduce new versions, features, etc. At one time there was the
>Debian Volatile project that hosted "fast moving" versions of software
>(spamassassin, clamav, etc), But that project was disbanded years ago.
It is what most distributions do.
And frankly I am not that unhappy with it.
Sometimes it is nice to have a recent version of something but when a system
is continuously updating everything it requires constant attention because things
are breaking all the time.
Unfortunately most open source developers do not consider backward compatibility
very important, they just declare some feature you are using as "deprecated" and
you will have to find a workaround or abandon some functionality.
I prefer to do that at my own convenience, not at the time the distribution maintainer
forces it upon me.
>As of today, the authoritative voice is ISC for whether or not bind
>v9.5.x should be used.. and they say don't. Are you using v9.5.5 as
>an authoritative server, if so as a master?
We are not using version 9.5.5 and I never wrote that. It is version 9.9.5.
Rob
> The problem lies outside of Linux distributions, the problem lies with
> over aggressive firewalls (or poorly designed firewalls) that don't
> allow or understand DNS Extensions.
And with old DNS server versions that do not allow them either, I think.
And that seems to be the case for the abovementioned domains.
(or there is such an overly agressive firewall in front of them)
> This email was sent to you from a Debian Stretch (earlier in the food
> chain than Jessie) server using DNS servers running various versions of
> Linux DNS software behind simple iptables firewalls that don't strip
> off DNS Extension bits.
I am running Debian Buster on my own machine at home, even newer, and I have
no problems either. But on our AMPRnet gateway (which has Debian Jessie)
there is a DNS server/resolver (bind 9.9.5) which logs EDNS warning about
the abovementioned domains, and it was my impression that after this flag
day those warnings would be turned into errors for those domains.
But of course that would only happen when Debian decide to replace the bind
package on Jessie with a new version that has been amended according to the
message that Brian sent (9.14.0). I am not so convinced that this is going to
happen, but I have not researched that fully.
When I understand correctly, major resolvers like 1.1.1.1, 8.8.8.8 and 9.9.9.9
would make that change on Feb 1st, so those that use these resolvers will be
affected immediately on Feb 1st.
Well, we will see. The number of EDNS warnings (and warnings about DNSSEC issues)
has gone down quite a bit in the last months, so apparently work has been done
in a lot of places already.
Rob
>>/But on our AMPRnet gateway (which has Debian Jessie) />>/there is a DNS server/resolver (bind 9.9.5) /
>Ouch. Bind v9.9.5 is ~10 years old... sure Debian applies patches, but
>man that's way too old, even ISC would heavily advise against it. Why
>can't that gateway be upgraded to Stretch or Buster? I'm willing to
>help if help is needed.
Debian Jessie is only some 3.5 years old and it is fully supported.
We keep it uptodate. When you think the package is too old you better
contact Debian instead.
I know how to update the system, but it involves work, downtime, and risk.
And when I do this on sunday afternoons (a convenient time for me to do it)
I get nagged about interruptions in the AMPRnet/HAMnet service during times
others are using it. So it has to be planned at some time when it is not
used so much and I still have time to do it. Other less critical systems
will likely be done first, also to gain experience with this particular
version upgrade.
>I can assure you that that your thoughts are correct on this. Debian
>will patch patch patch bind v9.5.5, right up to the end of LTS support,
>but never move to a newer major version. It's not in their mindset to
>do such. ;-)
It is how most distributions work. What we will have to see is whether
they will patch this change into their version of bind or will just ignore
it because it is not a security issue. Same for the "stretch" version.
The "Buster" version will maybe get an update. But even that is not so
certain as it is currently at version 9.11.5 so not the leading version
either.
Rob
> Rob,
> Both domains you speak of do not rely on AMPRnet DNS infrastructure
> So Brandmeister and Dstar.su are not effected by any DNS issues within AMPRnet
> 73s,
> Rudy (PD0ZRY)
That is exactly what I wrote: it is not related to 44Net. There is nothing we can do about it.
But it is related to amateur radio and it could affect people reading the list because they are
involved in amateur radio networking. So it is good to know it so we know where we could look
when problems appear.
See the topic of this thread: DNS Flag Day, Feb 1st, 2019. that is when problems could occur.
Although I don't expect that all the Linux distribution maintainers will suddenly rush out
resolver updates on Feb 1st, especially not on stable versions. So it could take longer until
it becomes visible in our network. It will likely hit those that use 8.8.8.8 sooner than e.g.
the resolver on our gateway (44.137.0.1) which will only get updated once Debian Jessie receives
an update.
Rob
While not really related to 44Net, note that there are serious issues with the DNS servers
used by amateur radio related services like brandmeister.network dstargateway.org dstar.su etc.
Not much we can do about it, but at least it is known...
Rob
