Il giorno mer 13 mar 2019 alle ore 16:43 Thomas Osterried <
thomas(a)osterried.de> ha scritto:
>
> It's always the best choice to use the official repo. See
> http://www.linux-ax25.org/wiki/GIT
> http://www.linux-ax25.org/wiki/Compilation
>
> It would always have been a good idea to send patches upstream.
>
Since three days ago, the official ax25 site is not available.... are
there any news?
Very recent, there were some updates... and there was a new release
…
[View More]canidates (RC5) - thanks to maintainers :)
May be they are are fixing all the issues that have been fixed in the
VE7FET repos and also others issues???
At the moment i would like to thanks and i'm hoping something new...
Lorenzo iw3her
[View Less]
> Google says it's my fault; I say Google has its collective head up
> its ass in marking a valid email as spam. Their official word is
> "Don't act like the bad guys" and you won't have problems. Never
> mind that it's 100% RFC-compliant, they say it's bad guy behaviour.
I agree. Sending mail to google (and also hotmail/outlook) has become
very unreliable. E.g. when using @amsat.org or other forwarding services
like @veron.nl or @vrza.nl (Dutch amateur radio societies) it will …
[View More]usually not work.
I do not really want to use my ISP mail address, so it looks like I have
to register my own domain to get this fixed. For now, I have set an autoreply
(from the ISP mail address) encouraging people to use a different address
and look in their spambox when they expect a reply.
I hear that it is customary in the circles of gmail/hotmail/outlook users
to send a Whatsapp message "I have sent you an e-mail"...
Rob
[View Less]
> Everyone happy with this? Any comments?
It would be nice if the mail had some info about what a gateway is and why you (don't) want it,
e.g. with a pointer to the wiki page.
I have found that some people add a gateway entry because they think this is some form of registration
of their existing (not IPIP mesh) router e.g. connected via radio or via one of the other VPN types
we support. They think it would be useful to be registered in some list. That is how the problematic
…
[View More]gateway came into existance, and there are several others like that registered in the Netherlands,
that did not become problematic only because they had no subnets.
When being listed is what they actually want, of course they should not register a gateway. But it is what
they do, partly because there is a lack of higher-level explanation of concepts. And after receiving
that mail message they probably still don't understand what they are doing wrong.
Maybe a pointer to HamnetDB could be useful. Registering there is probably what they want.
Rob
[View Less]
Hello,
To all amprd users (this does not affect setups using the kernel tunnel
driver and ampr-ripd).
Due to changes in the 4.x kernels, there's a problem with the system
replying with "icmp unreachable" to incoming IPIP traffic.
This will possible drop incoming traffic, including the RIP broadcasts
(resulting in incomplete route tables).
Please switch to an ampr-ripd setup or filter outgoing icmp messages on
your WAN interface, using a rule like the one below:
*iptables -A OUTPUT -o …
[View More]ethX -p icmp --icmp-type destination-unreachable
-m state --state RELATED -j DROP*
I hope I can find a workaround on this issue.
Marius, YO2LOJ
[View Less]
> I don't think folks would add a gateway if they haven't been approved for a block.
Well, actually they do.
The problem is that the visitors of the portal do not know at all what the whole concept
of the IPIP tunnel mesh looks like, how it is relevant within AMPRnet, and that it is
only one of the options for getting connected.
As there is no walk-through explanation of concepts like a registered subnet, a gateway,
the resulting IPIP tunnel mesh, etc, people just blindly click on menu …
[View More]items and fill
out forms.
Then they have a gateway but the still don't understand how that all works.
So they close the site and continue to look elsewhere for information, and when they find
it they never come back to delete what they created.
That is why it is good to remove that crud, but also it would be good to have some more
explanatory text and/or pointers to where that can be found. And some warnings that
this is not a system to voluntarily register some information about one's station, but
that it is actually used for something and that you can actually break things by entering
information.
(of course we should strive for a situation where one cannot break the network for other
users, but still one could break the routing of one's own subnet)
Rob
[View Less]
> I would replace DROP by REJECT. DROP means the system will wait till the packet times out.
> For outgoing connections this may cause issues as the daemon that sends the unreachable will also wait till the packet times out before continuing
No, outgoing ICMP "destination unreachable" is not an outgoing connect and it makes no sense to REJECT them...
(this kind of packet should not be replied to)
Rob
>
> Given this, perhaps you could add a note suggesting that one or the list
> of blocks should be added when they reregister their gateway, that would
> eliminate any confusion... just my two cents.
This better:
—8< SNIP >8---
Hello {givenName},
This is a system generated email from the AMPRNet Portal.
This is a courtesy notice to advise you that your gateway entry has been removed.
Your gateway was removed by an automated process that looks for gateways that have had …
[View More]no attached subnets for at least one week.
Your gateway has met this criteria and has thus been removed.
It is important that the Portal data is kept up to date and accurate.
If you still want to run a gateway, please feel free to add your gateway back to the Portal.
Your gateway's details were:
Title: {gwTitle}
IP: {gwIP}
Host: {gwHost}
Notes: {gwNotes}
You have the following subnets allocated to you:
{listOfSubnets}
If you add your gateway back, please ensure that you allocate at least one subnet to it, otherwise this process will remove your gateway again in a week!
Kind Regards,
The AMPRNet Team
—8< SNIP >8—
[View Less]
What is the final outcome of the discussion?
Will any changes be made to the Portal to validate user input for default users?
Will there be a change in functionality w.r.t. having gateways with external address within AMPRnet?
Will incomplete gateway entries be deleted?
I hope we can have some outcome of the bad situation and following discussion, instead of leaving
everything as it is.
Rob
Although I wanted to provide a freely accessible demo for ALL ham
operators as an configuration example on an EdgeRouter, I'm starting to
have my doubts.
Especially to w6ray...
What is the use of hanging on a router web interface for 24h now? What
new information could it give you by watching its interface?
Marius, YO2LOJ
> I am happy to implement BK’s suggestion to limit the setting up of gateway endpoints that fall within the 44/8 range to co-ordinators.
> I am also happy to go through and remove any currently empty/incomplete gateways. Perhaps I could also setup a cronjob that purge such entries on a regular basis, e.g. any that are over a week old with no subnets?
> I can implement the above fairly quickly if that is what is wanted?
I would certainly appreciate that.
Even better would be to …
[View More]implement the addition of a new property 'advanced user' (initially copied from 'co-ordinator' and settable by you and Brian) and also the re-introduction of checking the subnets being routed by the gateway, depending on that property.
But even with only the changes mentioned above we should have some improvement in reliability.
Brian: I also wonder if the return if ICMP unreachable messages on RIP broadcasts is somehow logged or stored in a form that allows gateways that have done this for extended periods of time to be automatically disabled or deleted.
Rob
[View Less]
> I would propose an alternate solution. Since the number of such
> valid gateways is so very few, perhaps it would work well enough that
> someone must *be* a coordinator to set up a gateway whose outside-world
> address is in network 44.
Note it also involves routing subnets that belong to others...
I don't know how difficult it would be to add an extra property to a user
record, should be a minute of work in a LAMP environment, I guess.
Maybe a shortcut would be to add the "…
[View More]advanced user" property and initially set
it equal to the value of the "coordinator" property.
Then it can start operation quickly and should it turn out that really users
require this without being a coordinator then later some kind of UI can be
added to allow setting that. (by the users themselves, by coordinators, or
by admins, whatever seems best)
Rob
[View Less]
> I think somewhere less obvious (like under ones user profile) there
> should be a place to check a box to enable "advanced user options."
> And if that is checked then such abnormal things would be accepted?
> Not sure how feasible/easy that sort of thing is for Chris to code though.
I think that is actually the best idea. Adding a flag to each user (default false)
and using it to enable those things (checks that were present before!) should not
be that difficult.
At least it …
[View More]should be easier than adding an extra step in the workflow.
Rob
[View Less]
> and who would be responsible for turning the flag on/off?
> The user themselves? In which case aren’t we back to square one (with some/most users at least).
> or perhaps a coordinator?
> Do they want the extra responsibility?
When you fear that will be a problem I would suggest to set the flag to false
for everyone except experienced users like VE3TOK, DG8NGN, N1URO etc, and await requests to
enable it for others. I would be OK with managing that for my area as a coordinator.
…
[View More]I don't think that users are especially malicious, they just don't know what they want and
what they are doing. An extra procedure provides the opportunity to explain things more
clearly (in native language) and most users would not require the extra functions anyway.
I also suggest to remove all gateways that have no subnets (those are likely the result of experiments
that never went anywhere) and all gateways related to user accounts that have expired.
They are easy enough to re-add when desired.
There could be logging which gateways returned "ICMP - dest unreach" on the RIP broadcasts,
if so those that did so for a long time could be removed as well.
Then it is easier to have a closer look at what remains, to check if there are likely config errors.
Rob
[View Less]
All,
I'm getting consistent traffic from these gateways:
19:09:47.158200 IP (tos 0x0, ttl 244, id 38837, offset 0, flags [none], proto IPIP (4), length 150) 89.67.160.225 > 71.246.224.8: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 130) 0.0.0.0.5678 > 255.255.255.255.5678: [udp sum ok] UDP, length 102
19:10:27.498793 IP (tos 0x28, ttl 241, id 46236, offset 0, flags [none], proto IPIP (4), length 159) 66.109.219.132 > …
[View More]71.246.224.8: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 139) 0.0.0.0.5678 > 255.255.255.255.5678: [udp sum ok] UDP, length 111
19:10:37.633539 IP (tos 0x0, ttl 242, id 10069, offset 0, flags [none], proto IPIP (4), length 166) 91.241.24.251 > 71.246.224.8: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 146) 0.0.0.0.5678 > 255.255.255.255.5678: [udp sum ok] UDP, length 118
19:11:07.231425 IP (tos 0x0, ttl 246, id 59661, offset 0, flags [none], proto IPIP (4), length 174) 72.192.148.49 > 71.246.224.8: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 154) 0.0.0.0.5678 > 255.255.255.255.5678: [udp sum ok] UDP, length 126
Is this a discovery protocol of some sort?
Do we have knowledge on how to turn it off?
73,
- Lynwood
KB3VWG
[View Less]
Eloy,
I had the same issue and you need to do MSS Clamping. At least that’s what I was told and it fixed mine.
Roger
VA7LBB
>
>
>
> From: Eloy Ritter de Monredont <eritter(a)me.com>
> Subject: Re: [44net] RIP problems?
> Date: April 7, 2019 at 3:47:13 PM PDT
> To: AMPRNet working group <44net(a)mailman.ampr.org>
>
>
> Bob, following your reply I remembered that that the gateway (44.98.7.1) is setup to not respond to pings and that, for now, the …
[View More]44.98.7.2 is assigned to the WAN interface of a virtual router running Untangle which also does not respond to pings. I though the management interface of the hypervisor was connected and using that IP but that was a confusion on my side, it’s using my ISP’s IP.
> I’ll be changing that later on.
>
> Now the issue is that the virtual machines on the LAN side of the virtual Router do browse the internet fine when the WAN is connected to the VLAN that correspond to my ISP, but when connected to the 44/8 network most sites load well but some don’t, I can ping them though.
> The issue is the same using my personal computer when connected to the 44/8 network.
>
> Anyways, I just wanted to comment on my experience as a new user. I think that it could help improve the site.
> The browsing issue could be addressed in a different thread.
>
> Eloy
> W5ERP
>
[View Less]
Hi,
A while back I wrote a routing daemon for receiving RIP broadcasts and
installing them in to the routing table. I turned this in to a
complete setup script which worked on OpenWRT without needing to
compile architecture-specific binaries.
I kind of stopped working on it after I got it working, as my prefix
is BGP routed so I don't have much need for it myself, however I just
got back to it and have created a package for easy install. This
single package should work on any OpenWRT/LEDE …
[View More]device as it only
contains platform independent scripts and dependencies that are in the
standard repositories.
http://wiki.ampr.org/wiki/RIP44.lua
If anyone is interested in testing it, I would appreciate any
feedback. If it works well then it might be easier for new users to
install than the current OpenWRT instructions requiring a binary build
of ampr-ripd.
The source is up on github (although technically the package contains
the "source", as it's a Lua script!) if anyone wants to take a look.
It does a very rudimentary job of executing the required commands to
set up the interface, binding to a UDP socket, then parsing the
received routes.
https://github.com/NotMikeDEV/RIP44/
Thanks,
Mike, M6XCV
[View Less]
> I was just going through some of the portal pages and Chris has some
> extensive online help next to the various text/check boxes in the "?"
> circles. We can't hold Chris accountable for people not comprehending
> what they read on the portal. The online help did seem pretty accurate
> and well written.
It is not to hold Chris accountable, but some extra text above the form
(that also explains what a gateway is and that setting up a one may not be
what you want to do as a …
[View More]beginner) could be helpful.
Still, there can be problems.
> People will always make mistakes. I've seen some enter in their internal
> 192 or 10-net space IP as their commercial IP. Perhaps some sort of data
> checker can be put in place? That may help.
I hope the RFC1918 check is already made. If not it could be added.
As I wrote before, there have been reasonable checks in place but people here
have asked them to be removed because they wanted to do what the checks prevented.
(like setting up a gateway with external address in net-44)
Rob
[View Less]
> If there are any additional checks that can be put into the Portal, I’m happy to add them if we can reach a consensus on what those checks should be...
> Regards,
> Chris
Do you think it is viable to add another manual validation step for any gateway config
that has one of these properties:
- external gateway address is within 44.0.0.0/8
- advertised subnet is not owned by the gateway operator
This would at least prevent mishaps like we had this week, because especially a gateway
…
[View More]address within 44.0.0.0/8 should be throughly validated so that it is properly BGP routed
to somewhere, and the operator of that destination can properly process the IPIP packets
and not route them in a loop.
Rob
[View Less]
> The portal has made it easier for those to request blocks and for
> routing to become a bit more efficient through RIP vs having to download
> the encap.txt file and having to reload it every so often so the
> automation is definitely welcomed in this regard. The whole concept of
> ip encapsulation under ip is what confuses most people. Take OpenVPN for
> example - people don't want to know it's using ip encapsulation, they
> just want to configure it and have it work.
…
[View More]Well, that is the issue. We provide OpenVPN certificates for local amateurs
to connect to our gateway, and there rarely is any issue with that.
(apart from people making 2 connections at the same time, which of course does
not work because the certificate is directly bound to the user's IP address)
But I think what happens is: people hear about this AMPRnet/HAMNET thing, they
google a bit for information, and they get lost in technical documents not in
their language, talking about something that is not their expertise, and
expecting them to enter information in forms that they do not understand at all.
Then it is not so surprising that some bogus information ends up in the system
unless validation is improved, either in the software or in a manual step.
The whole thing with RIP was definitely a good idea, and much better than
regularly downloading and loading an encap.txt file.
However, what can be improved is the entering and maintenance of the data
that actually gets transmitted there.
> That could turn into something a bit too time consuming as well for
> those who would be in charge of taking responsibility for the
> functioning systems of others such as coordinators.
I'm not too worried about that, the assignment of IP addresses is also mostly
a manual process here (from mail to hosts file), helped with some scripts to
mail the update to the DNS robot and to place updated files on the server.
The number of updates is relatively small, I get maybe one a week or up
to 3 a week when it is a busy time.
For gateways, this should be even less.
Rob
[View Less]
> Rob et al;
> This user is flagged RADIO only in his config and should not be a listed
> "gateway" at all:
> ...
> If this is causing an issue, let me know and I'll send him a note asking
> him what he's looking to do and point him to a few things that may help
> him out.
Well, the recurring issue is that users do not really understand the whole
system and still are expected to manage it themselves via the portal.
This does not work well. They experiment with entering …
[View More]some data, see it
appear listed under their account, but do not understand what it is for.
They leave it there and move on to another experiment.
I do not blame them, it is a complicated matter and there are many options
of connecting to the network. On my own pages I strongly advise against
using the portal and instead mail me with the request they have, usually
they do not want to use IPIP anyway and registering on the portal does more
harm than good.
Of course it could be improved in the portal user interface, but it has been
claimed before that restricting people to making valid entries (i.e. the
external gateway address is NOT in net-44 and the advertised subnets are
owned by the gateway operator) causes issues in some niche situations.
Hence those checks have been removed, and users are no longer guided towards
what they should and should not (and probably don't want to) do.
Users get an address from me, and register a gateway in the portal with that
address as external address (this is what caused the mishap this week!).
Moreover, they have to add advertised networks and they do not understand
that they first have to request a network to be assigned to them, and they
pick a random network from the pulldown list (this happened with the same user).
So I am all for a change towards a system where people like coordinators or
other experienced users have to validate the entered gateway configuration
before it becomes active.
But recognizing that this would require more programming work in the portal
(and thus in practice will not happen), I am for a reduction of the complexity
and vulnerability of the system by removing dangerous capabilities that
almost nobody uses, such as having the gateway address within net-44 and the
advertisement of networks not owned by the user. They could still be allowed
for existing users and could still be modified by administrators of the portal,
but not by end-users.
Rob
[View Less]
Rob et al;
This user is flagged RADIO only in his config and should not be a listed
"gateway" at all:
44.118.1.1 2018-03-01 18:16:04 N1QX View
<https://portal.ampr.org/gateways_list.php?a=view&id=1403>
44.118.1.2 2018-03-01 18:16:12 N1QX View
<https://portal.ampr.org/gateways_list.php?a=view&id=1404>
44.118.1.3 2018-03-01 18:16:19 N1QX View
<https://portal.ampr.org/gateways_list.php?a=view&id=1405>
44.130.104.1 2017-10-02 18:…
[View More]34:13 DG8NGN View
If this is causing an issue, let me know and I'll send him a note asking
him what he's looking to do and point him to a few things that may help
him out.
I know in Maine, they prefer to use M$ and software that's 100% GUI
based. The problem however becomes that the sysop doesn't learn what
they're doing because the GUI hides the technical information.
--
I won't be like a Texas official and call Ocasio-Cortez a bimbo
but she does think Roe vs Wade are two different ways to cross a river.
-----
73 de Brian N1URO
IPv6 Certified
n1uro-dawt-ampr-dawt-org
uronode-dawt-n1uro-dawt-com
[View Less]
> Until a decision is made about what to do long term here, maybe the AMPR
> Portal web interface can change this name from "gateway" to "public
> Internet IP (gateway)". I think that would help some people avoid this
> issue.
Either that, and/or a descriptive text above the form that explains what a gateway
is, why you want to have it (and why not), and where to read more about it.
There are those "hover" type help texts but I am afraid it is not enough.
I think several "…
[View More]gateways" now listed (with no subnets) are the result of people
wanting to register/publish their system information in a way that is more like
what HamnetDB does.
It should be clearer that creating a gateway here actually sets up routes and
when done incorrectly can mess things up pretty badly.
The announced subnets list has similar risks. For a while it was limited to
subnets registered by the person logged in, there were people wanting to route
subnets for others (probably to forward them internally) and this check was
removed, and now people who do not completely understand what is going on are
randomly announcing other people's subnets without anyone knowing.
Perhaps best would be when all gateway setup had to be validated by someone with
more experience (a coordinator, an old hat in AMPRnet, etc) before it becomes
finalized, similar to the subnet allocation.
Rob
[View Less]
Talked to network people at the ISP, they indicate that they have changed something w.r.t.
the routing via Eurorings. It should be researched and hopefully fixed.
In the meantime I am thinking about relaying the RIP packets from my own colo host to our
gateway as an extra safeguard against things like this.
I see that ampr-ripd has options -E and -F that should relay the raw packets to a specified
address, good. That should work.
But I don't think it is possible to make ampr-ripd …
[View More]receive and act upon those relayed packets,
isn't it? Should I NAT them at the receiving system so they again have 224.0.0.9 as destination?
Has anyone tried such a setup and does it work without nasty issues?
(normally all RIP packets will be received twice in this case)
Rob
[View Less]
Does anyone else find it useless to have a password reminder email sent out
every month where you're told your password is [****] ?
-------- Forwarded Message --------
Subject: mailman.ampr.org mailing list memberships reminder
Date: Mon, 01 Apr 2019 05:00:19 -0700
From: mailman-owner(a)mailman.ampr.org
To: wlewis(a)acscalifornia.org
This is a reminder, sent out once a month, about your mailman.ampr.org
mailing list memberships. It includes your …
[View More]subscription info and how
to use it to change it or unsubscribe from a list.
<SNIP>
List Password // URL ---- -------- 44net(a)mailman.ampr.org ****
[View Less]
Since yesterday, or maybe earlier, we do not receive the full RIP table
anymore and our route table for IPIP routes has almost emptied.
A trace of UDP port 520 shows only 2 RIP packets per cycle.
Has something changed? Or does this have to be some rate-limiting on
the path to here?
Rob
I did further debugging...
It is indeed our 213.222.29.194 gateway that has the issue, it misses most
of the routes at least since yesterday (I notice because I have some mail
in the queue routed over IPIP that has stalled since yesterday).
But I do have another independently hosted IPIP host in the Netherlands
that receives all the normal routes. It is at IP 89.18.172.156
and is located in another datacenter.
So likely it is a routing issue on the internet...
Rob
Hello,
I'm setting up a gateway on a linux server, I have added NAT and firewall
rules to send protocol 4 over to my server at 10.0.2.1. Here's some output
from tcpdump. Does this look right to you? Under it I have the output from
ampr-ripd, showing nothing coming in.
0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 102
15:41:24.153222 IP (tos 0x50, ttl 242, id 15047, offset 0, flags [none],
proto IPIP (4), length 174)
ip72-192-148-49.sd.sd.cox.net > 10.0.2.1: IP (tos 0x0, ttl 64,…
[View More] id 0,
offset 0, flags [none], proto UDP (17), length 154)
0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 126
15:41:35.790028 IP (tos 0x50, ttl 232, id 5104, offset 0, flags [none],
proto IPIP (4), length 166)
dhcp-91-241-24-251.zc.net.pl > 10.0.2.1: IP (tos 0x0, ttl 64, id 0,
offset 0, flags [none], proto UDP (17), length 146)
0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 118
15:41:40.735505 IP (tos 0x50, ttl 233, id 5482, offset 0, flags [none],
proto IPIP (4), length 150)
89-67-160-225.dynamic.chello.pl > 10.0.2.1: IP (tos 0x0, ttl 64, id 0,
offset 0, flags [none], proto UDP (17), length 130)
0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 102
15:42:24.169078 IP (tos 0x50, ttl 242, id 15303, offset 0, flags [none],
proto IPIP (4), length 174)
ip72-192-148-49.sd.sd.cox.net > 10.0.2.1: IP (tos 0x0, ttl 64, id 0,
offset 0, flags [none], proto UDP (17), length 154)
0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 126
15:42:35.827618 IP (tos 0x50, ttl 232, id 5105, offset 0, flags [none],
proto IPIP (4), length 166)
dhcp-91-241-24-251.zc.net.pl > 10.0.2.1: IP (tos 0x0, ttl 64, id 0,
offset 0, flags [none], proto UDP (17), length 146)
0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 118
root@rigel:~/ampr-ripd-2.4# ./ampr-ripd -d -i tunl0
Using gateway 10.0.0.1 for direct 44net endpoints via interface enp2s0.
Waiting for RIPv2 broadcasts...
Any help would be greatly appreciated. Thanks and 73,
-Nate, KJ7DMC
[View Less]
Hi Brian,
I am trying to reach you off-list but the message keeps bouncing at your bkantor.net o365 mailbox due to security settings.
I have a question about re-routing my BGP subnet.
Would it be possible to contact me off-list please?
Thanks!
73,
Ruben - ON3RVH
Hello All!
I just got my /24 setup over at vultr. Im trying to follow a generic
VYOS guide to setup bgp. Im getting some errors when trying to setup the
bgp network command. Im used to working with cisco stuff, never really
configured anything else.
Has anyone used VYOS for bgp? Or is there another router OS thats better
to use.
73,
Brian
Hi
hoping won't be OT for "44 Net" mailing list, I would like to ask for yours
experience with current AX25 support on Debian and specifically on Linux
(Raspbian) based (Raspberry PI) node.
At the moment my node should have 1 radio port (1 6pack interface to TNC)
and one AXIP link via 44 net.
In a previuos post I can see some warnings about "... many kernel issues
with the AX25 stack and newer kernels that cause the kernel to simply lock,
panic, and other nasties ..." and so the downgrade …
[View More]advice.
On the other hand I can see AX25 kernel patch mailing list with some recent
kernel little patches about AX25 ... someone know the real recent kernels
conditions?
It is absolutely necessary to downgrade from current stable 4.14.98 to
previous 4.1.21 (for example ...)? In this case, is there a more recent
"good" downgrade kernel?
It is better to use "Jessie" instead of "Stretch" distro?
Again about AX25 packages AX.25 Apps, AX.25 Tools, AX.25 Library: It is
always the best choise to recompile and use VE7FET packages (thanks to Lee
VE7FET for bugs fixed and reorganizing) instead of official repository
(APT) ?
It's a pity that there is no way to have a single good source ...
Thanks for sharing your experience... may help to shorten the time to right
configure a new node for more than someone ;)
'73 de Lorenzo iw3her
[View Less]
> This is another drawback : all outgoing traffic (to Internet) has to go
> through one of our gateways, and can not be forwareded to Internet
> directly by an endpoint via its local (NATted) ISP.
Yes of course. In our case that is not very important because our gateway is in
a datacenter in Amsterdam, where most of the internet traffic passes anyway, and
the ping time to typical internet hosts nearby is like 2ms. I have a 5.5ms
ping time to our gateway via my VDSL connection, and …
[View More]~9ms via the radio links.
That isn't an issue.
In Germany it should not really be a problem to do it like this, they could have
several datacenters across the country too. The trick is of course to find
something that is inexpensive enough to pay it out of someone's pocket, as
setting up a donation or contribution system is quite difficult, especially
in the amateur radio community.
(in Dutch a Ham is called "zendamateur" which is often written as "centamateur"
in situations concerning financing community projects. it is funny that many
amateurs have no problem paying like 2000-4000 euro for a transceiver, but won't
consider paying 20 euro/year to sponsor a community project)
Rob
[View Less]
> Since many on this group have the peculiar knowledge on AX.25,
> on amateur packet radio and related stuff, it could be effective
> and proficient to re-compact the efforts to support, repair,
> improve and revamp the linux kernel, the NET/NOS and so on.
The problem with code in the kernel is that it is very difficult to get any improvements available
to the user. Assuming that not everyone wants to compile their own custom kernel from source,
you need to get the …
[View More]improvements implemented in the standard kernel and then you have to wait
until the distribution(s) of choice add this new fixed kernel into their distribution. Then you have to
wait until this distribution is widely used by the users.
This can easily take a year, maybe more! And when you discover problems or want to make additions
the cycle starts again. Worse: when others make changes and break things, it takes a long time
before this impacts users and then again a long time to fix it.
So the approach really should be to take the stuff out of the kernel. Or maybe move it into an
indepently developed loadable kernel module, maybe via dkms or so.
Rob
[View Less]
> - We are an island, so our network will be managed as a "closed" network, with only two gateways to "the rest of the world", in two data centers located in the two the main cities.
It should be possible to get it working correct in that setup.
The main problems of the German network are:
- the use of many exitpoints towards internet that use consumer lines and NAT
- the reliance on consumer routers that offer no flexibility in routing and connection marking (AVM Fritzbox etc)
- the …
[View More]separation of different connection technologies in different routing tables evaluated sequentially instead of from smallest subnetsize up
- (motivated by some of the above points) the naive routing that does not take connections into account, so it cannot differentiate between outgoing and incoming connections
When you (and it looks like you do) abolish those internet connection points with NAT, most of the problems are already solved even in cases where the routing is asymmetrical and not optimal.
At least it works.
Rob
[View Less]
> And then you'll have issues in at least parts of the German networks.
You will have issues with them no matter what. Their network design just isn't suitable
for connection to internet. No matter if you do or don't use tunnels, you will always have
issues in some way.
Rob
> The challenge is that by loosing the protocol stack in the kernel, all the existing Linux packet applications break. Maybe if a new libax25 library was created that could redirect all those calls to something in userland, that would work but that
doesn't exist today. By also moving out of the kernel, we loose most of the advanced routing abilities in playing around with AX25/Netrom/Rose, etc.
It should be possible to make a usermode program that handles socket calls made by …
[View More]other programs.
I.e. you continue to use a socket interface but the protocols are not in the kernel but in that user program.
Solutions like this are used for many exotic services that cannot live in the kernel for maintenance reasons.
(although for technological reasons they should be in the kernel)
> Btw.. I don't understand your "put only device drivers in the kernel". If we did that for say IPv4, IPv6, etc... that would dramatically reduce the functionality of Linux as it stands today. So much would need to change to accomodate a wholesale
shift to Userland.
Well of course it has been a discussion since (before) linux was first developed. The monolithic vs microkernel discussion.
However, you should not compare it to IPv4 or IPv6.
The issue is not whether network protocols technologically belong in the kernel, but whether it is sustainable
to keep protocols that are used by about 100 users out of a Linux user population of billions can be kept in
the kernel and survive every restructuring of the kernel without being damaged beyond usability because people
are making changes and don't (because they cannot) test them in real use.
Apparently not. So it is better to go for a solution that works.
I have been running my version of NET on top of the kernel SCC card driver for quite some time, and there were
no issues like this. It had a separate IP address and was connected to the kernel IP stack via tun/tap.
Of course that is not a solution for socket applications using AX.25 but something similar could be done.
Rob
[View Less]
> I'm writing a DVB-GSE receiver block for GNU Radio. It will be used in a
> future software defined DVB-S2 receiver. I've pretty much completed the
> block, but I'm stuck on how to forward packets written to the TAP
> interface into the Linux network stack.
That happens automatically. The tap interface has two sides, one exists as
a Linux network interface that you configure just as any network interface
and the other side is accessed via the socket in your application.
…
[View More]Forwarding is done as on any network: you assign IP addresses and subnet masks
to either side and send your packets to addresses living on the other side.
Rob
[View Less]
Brian Kantor:
I tried sending you two emails (off list). Both got bounced:
-----------------------------------------------------------------------------------------------------------------------------
Remote-MTA: dns; bkantor.net
Diagnostic-Code: smtp; 550 5.7.1 Disposition Notification Denied:NOYGDB
--------------------------------------------------------------------------
Can you contact me off list to verify any change in your email address?
Thank you.
----------------------------…
[View More]--------------------------------------------
Wm Lewis (KG6BAJ)
AMPR Net IP Address Coordinator - Northern and Central California Regions
(A 100% Volunteer Group)
------------------------------------------------------------------------
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.
[View Less]
I'm writing a DVB-GSE receiver block for GNU Radio. It will be used in a
future software defined DVB-S2 receiver. I've pretty much completed the
block, but I'm stuck on how to forward packets written to the TAP
interface into the Linux network stack.
I'm guessing some sort of bridge or virtual Ethernet interface is
required, but I just can't find a coherent example.
I'm hoping the brain trust here on 44net can help. The source code is here:
https://github.com/drmpeg/gr-dvbgse/blob/master/…
[View More]lib/bbheader_sink_impl.cc
The block parses a baseband header frame from the DVB-S2 receiver,
builds an Ethernet frame, and writes it to the tap1 interface.
https://github.com/drmpeg/gr-dvbgse/blob/master/lib/bbheader_sink_impl.cc#L…
But I want that packet to be injected into the network stack. How can
that be done?
Ron W6RZ
[View Less]
> Is there a place where we can get the latest unofficial patches? Has anyone considered a fork to keep it relevant to modern kernels?
I would say it is best to remove all AX.25 code from the kernel and use one or more userspace programs to provide the functionality instead.
It is just too difficult to keep some seldomly used feature working in the kernel working without testing (as outlined by David).
And once there is a problem, it is almost impossible to get it fixed and very difficult …
[View More]to propagate fixes to end-user systems.
Put only device drivers in the kernel, not the actual protocol code.
Rob
[View Less]
> - May I encounter routing issues with some clients ?
> - Is it recommended to deploy ampr-ripd in parallel with BGP ?
You won't encounter problems with traffic to other systems on internet and also not with other
AMPRnet systems routed via BGP, but some of the traditional AMPRnet networks that are only
routed via IPIP will be unreachable when you do not run IPIP tunnels in parallel to your BGP
announcement, or at best they will be routed via San Diego, USA which of course affects …
[View More]delay
and packet loss values.
I cannot judge if this will affect your system.
However, when your router system is capable of running ampr-ripd or another solution for
IPIP tunnels (e.g. the scripts for RouterOS or the recent solution for Juniper) I think it is always
a good idea to install one of them.
Rob
[View Less]
> What's this "snow" thing? And can it be routed over the 44 net? ;P
It can sometimes affect the routing over UHF/SHF radio links.
But is anyone using those, or is only internet routing used?
Here we have had lots of rain and strong winds over the past week.
The antennas are shaking and I cannot work on my OSCAR 100 uplink.
My WiFi AMPRnet link to the radio tower nearby is affected due to a tree in the path.
Rob
> If you have a 44net subnet behind your router, machines that do not have DNS entries at ampr.org will not be able to reach BGPed networks, because amprgw requires any host passing traffic through it must have such a DNS entry.
> At the moment, simply removing the default route in your ampr table solves this and routes those hosts vis ISP NAT.
> By automatically creating individual routes for BGP subnets make this a little more diffcult, and breaks existing working setups. Even if …
[View More]this is not a big issue for people with good networking knowledge, it breaks things for those that should
have expected a simpler setup and are not profficient in networking, contrary to the initial goal of the proposal.
I think it is a little broader than this.
When you have a BGP routed subnet yourself, and you run ampr-ripd in parallel to improve connectivity to IPIP-only subnets, you force the traffic to other BGP routed subnets via amprgw where they would much more efficiently be routed directly.
(without NAT)
Of course a special version of ampr-ripd could be made that ignores those routes when some flag is given.
You could release such a version and advertise its existence here, give everyone involved the opportunity to install it, and only then make the change.
Rob
[View Less]
Hi there
does anyone know what ver of server (1 2 3) i have to put on my cisco SNTP if i want to use the following NNTP server s ?
44.24.244.4 and 44.60.44.1
Thanks Forward
Ronen - 4Z4ZQ
So I would be one of those with weak networking knowledge :( That said, would the proposed change have improved connectivity? I’m finding that not everyone is able to connect to my tunnel setup. I even noticed 3 days last week where N1URO.amor.org, was not reachable from untunnelled devices, like my cellphone and isp. If the changes would improve connectivity, even if people like me would need some instruction and tutoring, maybe it should be considered.
Roger
VA7VH
> On Mar 12, 2019, …
[View More]at 12:00, 44net-request(a)mailman.ampr.org wrote:
>
> Send 44Net mailing list submissions to
> 44net(a)mailman.ampr.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mailman.ampr.org/mailman/listinfo/44net
> or, via email, send a message with subject or body 'help' to
> 44net-request(a)mailman.ampr.org
>
> You can reach the person managing the list at
> 44net-owner(a)mailman.ampr.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of 44Net digest..."
> Today's Topics:
>
> 1. Re: BGP routes in RIP transmissions -- CANCELLED
> (Toussaint OTTAVI)
> 2. Re: BGP routes in RIP transmissions -- CANCELLED (Brian Kantor)
> 3. Re: BGP routes in RIP transmissions -- CANCELLED (Marius Petrescu)
> <mime-attachment>
> <mime-attachment>
> <mime-attachment>
> _______________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
[View Less]
> Of course a special version of ampr-ripd could be made that ignores those routes when some flag is given.
Or rather: add a flag that specifies an alternate route table number where those routes will be stored
instead of the main table or the table specified with -t
A special value (0, -1) could be used to entirely ignore those routes.
Rob
Hello,
Beginning on March 15th, the pseudo-RIP transmissions from amprgw
will include the various subnet prefixes which are being advertised
by BGP. They will show a next-hop address of 169.228.34.84, which
is amprgw.
Marius assures me that this will cause no harm, and will enable
tunnel-only AMPRNet hosts to reach those destinations via the tunnel.
He says that many tunnel-connected hosts have a semi-default route
to amprgw that has to be manually installed when the system is set
up; this …
[View More]would now be automatic when employing the various ampr-rip
programs.
Quoting Marius:
So, wouldn't it make sense to publish BGP routed networks that
do not have 'tunnel ' set in the portal as RIP routes using
amprgw as gateway?
This would solve some issues: - Users could actually see all
reachable destinations in their route list
- Users could easily identify BGP networks by checking 169.228.34.84
as their gateway
- they could drop the setting of that 'default' route in the
ampr routing table, allowing a (implicit) throw to the main
table. This will make it easier to reach local or directly
connected ampr networks (which now need routes placed in the
ampr table). Also, unknown destinations would be NATed to the
system's gateway, without putting any additional traffic to
amprgw.
- it would also allow to have all routes in a single routing
table while being able to reach tunneled and BGPd networks using
their AMPR address without policy routing.
Existing set-ups would not affected by such a change in any way.
Marius, YO2LOJ
Please be sure to let me know if there are any problems with this
change; it can be reverted in a matter of moments if an unexpected
difficulty does arise.
- Brian
[View Less]
I connected via VPN.
IPv4 Address. . . . . . . . . . . : 44.139.11.22
Subnet Mask . . . . . . . . . . . : 255.255.255.252
My DHCP server is 44.139.11.21. I am not able to ping that server.
I can't ping ampr.org.
Actually, I tried pinging several IP addresses and nothing is returned.
I'm trying to figure out if connecting via VPN is of any useful value?
Mike N9MS
Marius,
Ok that is an interesting solution!
It solves the "route lookup" issue, but in the case of using BGP there isalso the issue that
BGP only distributes the subnet route when there is an actual matching route in the table that it is
managing. Of course this can by circumvented by unchecking the "synchronize" option.
And on our local AMPRnet we distribute the default route via the same BGPinstance as the
remainder of the routes. So that would have to be changed.
I'm inclined …
[View More]more towards a script that reads the interface routes from the main table and copies
them into the amprnet table...
Rob
[View Less]
> The forwarded packets
> that were supposed to go to my 'inner' server were also routed back to
> the AMPR GW, which of course did not know anything about my local
> addresses (192.168...).
> However, after adding this line:
> ip route add 192.168.19.0/24 dev enp0s6 table 44
> everything felt in place and I'm now a happy man.
Unfortunately this is a detail that is soooooo easy to oversee that it frequently happens.
But of course it is always educational to …
[View More]encounter this and fix it yourself!
E.g. I recently helped someone with a MikroTik router to setup this kind of policy routing
and on that router the direct routes to attached interfaces also only appear in the main
routing table and not in those additional ones. There really should be an option to do that
automatically, but until then indeed you have to add them manually.
The kernel would lookup the route in the main table when it cannot find a route in the
additional table, but of course that only works when there is no default route there.
And autorouting protocols like BGP won't distribute the route when it is in the wrong table.
Rob
[View Less]
There were 2 RSA keys in my n9ms keys file. The 2nd one was the correct
one. Then I got an error message telling me that OpenVPN couldn't connect
due to a weak algorithm. Adding the following line to the .opvn file fixed
it.
Mike
tls-cipher "DEFAULT:@SECLEVEL=0"
I'm already using OpenVPN and it works great.
Now, I'm trying to use OpenVPN to establish a tunnel to AMPR.ORG.
I followed the instructions at: http://wiki.ampr.org/wiki/AMPRNet_VPN
I get the following message in my OpenVpn Log:
Tue Mar 05 12:19:13 2019 WARNING: --ns-cert-type is DEPRECATED. Use
--remote-cert-tls instead.
Tue Mar 05 12:19:13 2019 SIGUSR1[soft,private-key-password-failure]
received, process restarting
Tue Mar 05 12:19:13 2019 MANAGEMENT:
>STATE:1551813553,RECONNECTING,…
[View More]private-key-password-failure,,,,,
Tue Mar 05 12:19:13 2019 Restart pause, 5 second(s)
--- and it repeats ---
[View Less]
Hi
I have acquired myself a problem. Recently I decided to move all web
services away from the gateway to an ‘inner’ server. This is easily done
by using port forwarding in the firewall on the gateway. Thus I forward
all web services by using this line:
iptables -t nat -A PREROUTING -p tcp -m multiport --dport $Services -d
$EXT_IP -j DNAT --to $webserver
where $Services is defined as
Services="smtp,domain,www,https,submission,imaps",
$EXT_IP is my external IP address and $webserver …
[View More]is the IP address of
the ‘inner’ server.
I do the same for the ampr interface:
$iptables -t nat -A PREROUTING -p tcp -m multiport --dport $Services -i
ampr0 -j DNAT --to $webserver
In this case it is only the www and https services that are relevant
since I do not do mail on the 44-address.
All of this works of course as it should for ordinary IP addresses
(non-44) and it also works fine when comming from a 44-address.
Furthermore it works fine when I ping my 44-address from any IP address
(which isn't surprising as ICMP is not forwarded). But it fails
miserablywhen accessing my 44-address (44.145.40.3) from an ordinary IP
address. The incomming request comes nicely in on the ampr interface,
but the reply goes out the WAN interface to the Internet at largeand is
thus not recognized as a reply on the originating host.
I have spent quite a bit of time trying to findout why this is so. I’m
convinced it is something in my setup that is the cause of this
behavior, but I’m at a loss as what it may be, so I hope some of you
eagle-eyed people out there can spot the error.
Here are somedetails of my setup.
Routing rules:
$ip rule list
0: from all lookup local
44: from all to 44.0.0.0 /8 lookup ampr
45: from 44.145.40.3 lookup ampr
32766: from all lookup main
32767: from all lookup default
Main routing table:
$ip route list
default via 86.48.99.33 dev enp0s7 metric 3
127.0.0.0/8 via 127.0.0.1 dev lo
192.168.19.0/24 dev enp0s6 proto kernel scope link src 192.168.19.6
‘ampr’ routing table (table 44) (excerpts):
$ip route list table ampr | head -n4
default via 169.228.34.84 dev ampr0 onlink
44.2.0.1 via 191.183.136.1 dev ampr0 proto 44 onlink window 840
44.2.2.0/24 via 216.218.207.198 dev ampr0 proto 44 onlink window 840
44.2.7.0/30 via 98.208.73.100 dev ampr0 proto 44 onlink window 840
My gateway is a Soekris Net5501 running Gentoo Linux updated to the
latest versions last Monday.
I do hope I have expressed myself clearly enough and provided details
enough so that one of you can point at something and say: ‘there is your
error’. If some information is missing or lacking please ask for it and
I’ll provide as much as I can.
Best 73 de Bent/OZ6BL
[View Less]
Hi, I'm new to this forum. Several years ago I used Packet Radio and had an
IP address (it is still active: n9ms.ampr.org [44.72.58.62]).
Now, I'm getting active on the AREDN Mesh Network. I'm wondering if my
n9ms.ampr.org would be useful on our mesh network -- maybe it's strictly a
Packet Radio thing? I'm just curious.
I looked at the Gateway information, but I didn't see anything in there for
my IP address -- but I could be wrong.
Thanks for your help.
Mike N9MS
Greetings,
My gateway bit the dust and I need to start from scratch. I have two possible approaches.
1. I have an older Edgerouter Lite. Has anyone cracked the nut on connectivity to other AMPR nodes in the mesh?
2. I’m considering buying a new microtik router. Is there a suggested model?
Would like to get back on 44net but want to stay away from the “roll your own” Linux system as Ubuntu has changed their network manager to netplan.
Suggestions welcome.
— tom
Tom Cardinal / MSgt USAF (…
[View More]Ret) / N2XU / BSCS / CASP+
[View Less]
Hi folks,
Trying to get my pfSense firewall to talk directly on AMPRnet and am
wondering about GRE. Do we support this? It looks like the only way I can
get pfSense to do AMPRnet is to forward everything to an internal host and
do things there. I can do BGP but I don't have enough addresses space for
that (I only have a /27).
Thanks
Mark
G7LTT
>From time to time testing various setups I need to determine if the
remote 44 host is IPIP or BGP so that I can verify everything is
working etc.
I used to grep this, but apparently this is not current?
http://thyme.rand.apnic.net/current/data-add-ARIN
Does anyone know of an up to date source?
I used to test new installs against hambook.de.ampr.org
(44.225.164.16) as I know this is not reachable via the normal
internet, but is via 44net. It used to be via an IPIP tunnel. I
don't see it …
[View More]in my routes, so it must be via BGP now, but I don't see
it from the above source.
Thanks
[View Less]
So very sorry everyone. Sometime after I sent my message, the computer I was using for 44Net had issues so everyone that tested found they couldn’t reach me. Please try again, this time;
VA7LBB.ampr.org or 44.135.179.19.
It is up. Port 80 is open. It does work! It just doesn’t seem to work on Cellular networks. At least not for me. Please let me know what you find, and if you have any suggestions.
Roger
VA7LBB
There are a few entries in the encap file which are for subnets
that are NOT indicated as tunnel-routed subnets. They are
apparently in the portal database with the Tunnel attribute
UNchecked, but they have a gateway associated with them.
Perhaps this is because they at one time *were* tunnel-routed
but converted to direct (BGP) routing.
Anyway, I believe they should NOT be in the encap file because
they are NOT IPIP tunnel-routed.
These are
44.48.8.0/22
44.56.128.0/24
44.131.7.0/24
44.182.…
[View More]62.0/24
If any of these are your network, please delete their association
with a gateway, or check the Tunnel box.
- Brian
[View Less]
Hello,
I finally got my AMPRnet tunnel up and running. I have dns and a few A names. Everything seemed fine until I tried reaching one of my machines using my cellphone over the Cellular Network. It just times out. Here’s a test page. Ve7mov.ampr.org.
Is this normal. I can’t imagine this is a config problem on my end
Thanks
Roger
VA7LBB
> An interesting report on the adoption of IPv6 by the Internet at large.
Very interesting indeed! It discusses all those aspects that have slowed down IPv6
adoption.
My ISP (which also hosts our gateway system) was amongst the early adopters and I have
also experimented early, but abandoned it due to the "no benefits and only problems"
situation. But later, when those were mostly cured, I again enabled IPv6 on my network.
Problems caused by running dual-stack are now rare, but still it …
[View More]does not really have
any benefits. So it is understandable that it is adopted so slowly.
Unfortunately it is not only ISPs that affect it. Our beloved router manufacturer
MikroTik has mostly left IPv6 as an orphan. There is an add-on package with some
basic IPv6 functionality but most of the nice features available everwhere in the system
are only for IPv4. This has held me back to experiment with IPv6 on our section of
AMPRnet, as these routers are widely used.
Rob
[View Less]
Hi there
We consider to advertise part of our Country AMPRNET IP Network allocation via BGP to a small DataCenter
We want from there to allow users to have a gateways that will have IPIP tunnel to it.
By that we will decrease the latency of the IPIP tunnel that goes to UCSD and back and also hopefully get a much bigger bandwidth (from the data center and not from the UCSD limitations)
What Do we need to have in the Data Center in order to Support it ?
Is there any expert here that may …
[View More]direct the Software person (if it is a software solution) in our team ? to do it ?
any info would be appreciated
Regards
Ronen - 4Z4ZQ
http://www.ronen.org
Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/>
About me . Some of my projects . My Family . My Friends . The Quiz , what is the following Picture ? What I have to say about the Year 2000 bug . Few words in memory of King Hussein (JY1)
www.ronen.org
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]router:
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes \
protocol=tcp tcp-flags=syn
Rob
[View Less]
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 …
[View More]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
[View Less]
> 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 …
[View More]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
[View Less]
>>/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 …
[View More]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
[View Less]
> 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 …
[View More]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
[View Less]
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
Quoting from the web site at https://dnsflagday.net/
What is happening?
The current DNS is unnecessarily slow and suffers from inability
to deploy new features. To remediate these problems, vendors of
DNS software and also big public DNS providers are going to
remove certain workarounds on February 1st, 2019.
This change affects only sites which operate software which is
not following published standards. Are you affected?
On that web page, there is a Domain Owner's …
[View More]test. I have already
tested AMPR.ORG, and it passes except for one test on one of our
secondary servers times out. I am working with the person who so
kindly runs that secondary server [in Thailand] to get this fixed.
Please don't run any more tests on the AMPR.ORG domain.
But if *you* operate servers for a subdomain of ampr.org, such as
'se.ampr.org', you may wish to test your subdomain and see if there
are things you need to fix. In fact, the "se.ampr.org" subdomain
does indeed have a few problems that probably should be addressed.
(In particular, it looks like the DNS server software for that domain
may not be listening on the IPv6 addresses for those servers.)
- Brian
[View Less]
1.
As you all observed yesterday, I still run OpenWrt - currently on a Cisco Meraki MX60W device. I also use OpenWrt to create a separate VLAN for AMPRLAN traffic (those configs are in the Wiki). I can use routing, masquerade and NAT in another VLAN - if I need to temporally assign a device a 44 Public IP for testing and use.
2.I am running the firewall on my tunnel, which is iptables and zone-based in OpenWrt. Only relevant inbound ports for known services are allowed (e.g. 80/tcp …
[View More]for HTTP from 0.0.0.0/0 and 53/udp for DNS from 44.0.0.0/8). For additional security, I use a script ran with ampr-ripd updates - to only allow Pings and IPENCAP traffic from the IPs located in the Portal (script available on the Firewall Wiki page - someone offered an update to the script, but it has not yet been tested or implemented in the one found at the Wiki).
I currently only use Apache, HTML and some PHP on the visible web server. The "largest" concern here is the PHP-based APRS Code recovery tool (someone in this forum previously helped me better sanitize the input, as to prevent command injections).
3.I do monitor traffic with softflowd package in OpenWrt. I collect and record the data with NfSen (http://nfsen.sourceforge.net).
I also run snmpd for bandwidth statistics.
* Would you be willing to share the SANS IP script you have?* What threats does this list block?
4.PFsense also implements Snort, perhaps you can route traffic through a Virtual Machine to test?
5.When needed, I previously used a firewall rule that only allows x SYNs from given IP in x minutes. If greater than x attempts - REJECT.
6.Regarding DNS, I do not open my server to the outside world. Only those at 44.0.0.0/8 are able to reach and use it.
[View Less]
Folks,
Please remember that when you set up a host, computer, or device
on the AMPRNet, it is exposed to the big bad evil environment of
the Internet without any form of protection such as a firewall or
traffic filter, UNLESS YOU PROVIDE IT.
In recent days we've had a some more complaints about systems being
used as DNS amplification attack vectors, others as having been
compromised and turned into a spam bot, and so on. I wish these
were unusual events, but they're not rare enough.
Yes, …
[View More]you're being thrown into the network security swamp, and having
to learn to swim while trying to keep your head above water.
Please be careful. Practice safe networking!
- Brian
[View Less]
I think that script is OK, except of course this line:
AMPRGW="<AMPRGW>"
Should be edited to the actual address of AMPRGW instead of that <AMPRGW>.
I think it is better to just put the literal address in the example code as this kind of substitutions
confuses people. When it changes, the Wiki can be updated. It is of course also possible to
look it up using DNS but that will require another dependant package e.g. "dig" and again may
confuse people.
>I tested it …
[View More]and it seems to work. Also believe diffutils doesn't need to
> be installed, either. I'll update the OpenWrt Wiki.
Correct, the diffutils was only required for the iptables version which uses the diff command to
generate changes once the table is initially loaded instead of replacing it from zero every time
as the ipset version does.
> I only noted it in this particular best practices/tools thread due to
> messages in SEP2018:
Yes that was a case where I actually received some "malicious" IPIP traffic, but ir happens quite
seldomly.
Of course it never hurts to lock down as well as possible, but I wanted to indicate that installing
this filter is not the full response to the security reminder that Brian posted. I hope people do
not think "Oh, Brian posted a security advisory and now there is this script that I do not yet
have so let's install it so my system is secured", as this is only a very small and probably
insignificant part of that whole security solution.
When someone wants quick-and-dirty solutions to the security problem, it is much better to
install some firewall rules according to this pattern:
- accept ESTABLISHED/RELATED
- accept new outgoing traffic
- accept new incoming traffic matching some specific addresses/ports/protocols
- drop everything else
It is usually easiest to have two of those rulesets, one that applies to traffic incoming on the
internet interface (where you want to accept protocol 4 using your ipset and not much else)
and one that applies to traffic incoming on the tunnel interface (where you are basically handling
AMPRnet traffic and may allow a bit more, but often you allow more from 44.0.0.0/8 than from other
addresses).
How complicated that ends up to be is of course dependent on what services your system(s)
should expose, but at least it drops everything that you usually do not want to serve to the outside,
like SNMP and DNS.
Rob
[View Less]
> All,
> I implemented the code update. It's been added to Firewall Wiki under the ipset-based script.
> http://wiki.ampr.org/wiki/Firewalls#ipset <http://wiki.ampr.org/wiki/Firewalls#ipset>
> Thanks Rob!
Those scripts were adapted from mails that I sent to the list, but there are some funny things
in the versions on the Wiki.
The first version (with iptables) has comments that really aren't correct.
You must have had other problems while debugging this, as neither "the if …
[View More]iptables ... construct
does not work" nor "there must be no spaces or empty lines here" are true.
Maybe you had files with CRLF line endings (Windows editor) and/or other issues that were resolved
by other changes and this comment was left in there.
if command
then
is the same as:
command
if [ $? eq 0 ]
then
there may be empty lines between the command and if, this is no problem,
but of course there should be NO thing like "echo $?" between those lines!
maybe you did that during testing. that will make it fail because the echo command will
not only display the value of $? but also the new value of $? will then be set to the result
of the echo command! -> always 0
In the second example, using "ipset", there is an "if ipset" command (see, here it is OK!)
but the "then" and the "else" branch contain exactly the same code.
I don't know how that came about, but of course in that case you can just remove the if, then and else
and put 1 instance of the code left-shifted under that.
Of course in this case you don't need the tempfile and can do everything in one go like this:
ipset -N ipipfilter hash:ip 2>/dev/null
ipset flush ipipfilter
ipset -A ipipfilter $AMPRGW
grep addprivate encap.txt | sed -e 's/.*encap //' | sort -u | while read ip
do
ipset -A ipipfilter $ip
done
In my own systems I use a temporary ipset and swap them after completing the above, to avoid
the small time interval where the ipset is being filled and packets could be dropped.
For an ordinary user gw it probably isn't worth the trouble as this interval is quite short.
Of course, those filters are very useful against abuse of the gateway by people who send ipip
packets but are not part of AMPRnet (they could use it to hide their IP or to work their way
around parts of the firewall) but in practice I have found that most cases where this actually
happens are in fact hams who have misconfigured their gateway.
(e.g. the IPIP output goes out on another IP than they have configured as incoming for their gateway)
Don't think that adding this will solve any problems you have been faced with unless you are certain
that it was via IPIP abuse. There probably is another error in the firewall.
Rob
[View Less]
If your mailbox is located at or relayed by any of these domains:
att.netbtinternet.comestesvalley.net
free.fr
icloud.comlaposte.netmac.comn5kh.orgstpetebeach.net
thbt.fr
you may not have been getting some or all 44net email messages over
the past few days. What seems to have happened is that the mailing
list host, 'mailman.ampr.org', somehow got on …
[View More]somebody's spam list,
and some or all of the above domains started rejecting deliveries
from it.
Since it is often difficult and time-consuming to get back off such
a list, I've implemented a workaround for these domains that should
restore deliveries for you folks.
73 and Happy Computing!
- Brian
[View Less]
If you sent a message to the 44net mailing list in the last hour
or so and haven't seen it distributed, it likely got lost in a
mailer glitch that I think I've fixed.
Please resend it.
Sorry for the hassle.
- Brian
Roger,
I wrote the OpenWrt Wiki and my allocation has been live at 44.60.44.0/24 for years on my devices. Getting the tunnel interface active is the first step.
* I'm not sure what network and firewall configs you want, as MY EXACT CONFIGS ARE ALREADY POSTED IN THE WIKI (I will re-post them in this email)
* Again, AMPRGW should be replaced with the IP of AMPRGW. The IP is located here: http://wiki.ampr.org/wiki/Services
| AMPRNet Gateway(AMPRGW) | 169.228.34.84 |
* If you created …
[View More]the interface and added the IP, I'm lost at how ampr-ripd is saying tunl0 doesn't exist. Are you sure that you followed the Wiki instructions and added the script to STARTUP???
-------------------------------------
Pipermail did not permit me to post the configs, I emailed the configs directly to your personal inbox.
73,
- Lynwood
KB3VWG
[View Less]
Hi,
I’m following the instructions at the below link to use OpenWRT as a 44Net gateway. I’m confused about some of the instructions. What should <AMPRGW> be replace with in the route.
This has me confused as well:
“an interface instance for a new VLAN and bridge (the example above uses AMPRNET), add it to its own firewall zone using Input: Accept (if you wish for you AMPRLAN devices to reach the router), Output: Accept and Forward: Drop (or Reject). Assign an IP from your allocation to …
[View More]this interface, you will configure this IP on your devices as the Default Route/Gateway address.”
I created the AMPRNET interface but i put the 44Net allocation ip in the gateway of that interface, reboot after doing everything else, I get an error from Ampr-ripd that the interface doesn’t exist.
If anyone has done this on a OpenWRT router, would you be willing to share your firewall and network config files so that I can learn what I’m doing wrong.
http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_OpenWRT
Thanks
Roger
VA7LBB
[View Less]
Also - from your post, did you follow the steps to install IP-full so the startup script would create the tunnel interface?
In addition, did you compile ampr-ripd?
null
Roger,
AMPRGW should be replaced with the IP of AMPRGW.See: http://wiki.ampr.org/wiki/Services for those details.
You don't need a "Gateway" to the tunnel, as it's a Layer 3. You do need to assign an IP from your range to a VLAN/bridge if you will make a: VLAN, port/ SSID, etc. for your allocation to "live."
What issues are you having with network and firewall configs?You never actually said what's wrong.
Feel free to ask me any more questions, or private email me for landline.
73,
- …
[View More]Lynwood
KB3VWG
-----Original Message-----
From: 44net-request <44net-request(a)mailman.ampr.org>
To: 44net <44net(a)mailman.ampr.org>
Sent: Tue, Jan 8, 2019 3:00 pm
Subject: 44Net Digest, Vol 8, Issue 3
Send 44Net mailing list submissions to
44net(a)mailman.ampr.org
To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.ampr.org/mailman/listinfo/44net
or, via email, send a message with subject or body 'help' to
44net-request(a)mailman.ampr.org
You can reach the person managing the list at
44net-owner(a)mailman.ampr.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of 44Net digest..."
Today's Topics:
1. OpenWRT AMPRNet config (Roger)
----------------------------------------------------------------------
Message: 1
Date: Mon, 7 Jan 2019 12:32:53 -0800
From: Roger <va7lbb(a)rezgas.com>
To: 44net(a)mailman.ampr.org
Subject: [44net] OpenWRT AMPRNet config
Message-ID: <CC7E3091-3982-478B-A5C2-7F83E5D0AE30(a)rezgas.com>
Content-Type: text/plain; charset=utf-8
Hi,
I?m following the instructions at the below link to use OpenWRT as a 44Net gateway. I?m confused about some of the instructions. What should <AMPRGW> be replace with in the route.
This has me confused as well:
?an interface instance for a new VLAN and bridge (the example above uses AMPRNET), add it to its own firewall zone using Input: Accept (if you wish for you AMPRLAN devices to reach the router), Output: Accept and Forward: Drop (or Reject). Assign an IP from your allocation to this interface, you will configure this IP on your devices as the Default Route/Gateway address.?
I created the AMPRNET interface but i put the 44Net allocation ip in the gateway of that interface, reboot after doing everything else, I get an error from Ampr-ripd that the interface doesn?t exist.
If anyone has done this on a OpenWRT router, would you be willing to share your firewall and network config files so that I can learn what I?m doing wrong.
http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_OpenWRT
Thanks
Roger
VA7LBB
------------------------------
Subject: Digest Footer
_______________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
------------------------------
End of 44Net Digest, Vol 8, Issue 3
***********************************
[View Less]
Hi,
I’m following the instructions at the below link to use OpenWRT as a 44Net gateway. I’m confused about some of the instructions. What should <AMPRGW> be replace with in the route.
This has me confused as well:
“an interface instance for a new VLAN and bridge (the example above uses AMPRNET), add it to its own firewall zone using Input: Accept (if you wish for you AMPRLAN devices to reach the router), Output: Accept and Forward: Drop (or Reject). Assign an IP from your allocation to …
[View More]this interface, you will configure this IP on your devices as the Default Route/Gateway address.”
I created the AMPRNET interface but i put the 44Net allocation ip in the gateway of that interface, reboot after doing everything else, I get an error from Ampr-ripd that the interface doesn’t exist.
If anyone has done this on a OpenWRT router, would you be willing to share your firewall and network config files so that I can learn what I’m doing wrong.
http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_OpenWRT
Thanks
Roger
VA7LBB
[View Less]
> AWS instances have private IPs that are mapped (elsewhere) to a public
IP, at no point does the public IP/Network exist on the AWS instance.
That was true for legacy EC2. Now days, instances are launched in VPCs
where you can choose to use your own public or private IPs directly on the
network interfaces. You can also now have multiple interfaces on an
instance.
On Mon, Jan 7, 2019, 07:14 Jim Popovitch via 44Net <44net(a)mailman.ampr.org
wrote:
> On Mon, 2019-01-07 at 16:06 +…
[View More]0100, Toussaint OTTAVI wrote:
> > The right question would be :
> > On an AWS instance, is it possible to have another public (non-
> > AMPRNet) IP, so that we can build a tunnel to where we want, and route
> > our AMPRNet subnet through it ?
> >
> > Moreover, I never tried Amazon cloud services, but Microsoft Azure has
> > a built-in VPN system. It's possible to established IPSec tunnels
> > between Azure VMs and a local router. I saw Amazon has a feature
> > called "VPC" (Virtual Private Cloud). I don't know it it's the same
> > thing, and if it's suitable to connect AWS instances with local
> > resources via a VPN.
> >
>
> I think the general problems with doing any forwarding/routing on an AWS
> instance is their layer 3 abstraction foo. AWS instances have private
> IPs that are mapped (elsewhere) to a public IP, at no point does the
> public IP/Network exist on the AWS instance.
>
> -Jim P.
>
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
>
[View Less]
Hi all,
We are already announcing a subnet with BGP via a low-cost virtual
instance at Vultr. It works fine. As we'll soon deploy our second data
center, and we'll start migrating from our old-style 10.44.0.0/16
private addressing to full AMPRNet addressing, I was wondering if I
could find a second low-cost BGP provider for redundancy.
I saw that Amazon now provides "Bring your Own IP" features :
https://aws.amazon.com/fr/blogs/networking-and-content-delivery/introducing…
Did someone …
[View More]already tried it ? Would it be suitable for AMPRNet
announcement ? Is this feature available outside of the U.S ? Amazon
seems to provide free account during one year. Are there any volunteers
to try out ?
73 QRO & Happy New Year de TK1BI
[View Less]
I am trying to setup a Cisco 2921/K9 router. The router has 3 gigabit ethernet ports and a CISCO EHWIC-4ESG 4-Port Gigabit WAN Interface Card<https://www.ebay.com/itm/CISCO-EHWIC-4ESG-4-Port-Gigabit-WAN-Interface-Card…>. I can not get a static IP address from Spectrum so I need to set up a tunnel. Does anyone has have any dealing with this type of setup. I am looking for a way to where to start from.
73's
David A. Pechon Sr. KA5TTZ
U.S. Army Retired (SSG/SS)
Cell # (985)520-1748
HAMSHACK HOTLINE #4525
Since taking on a BGP routed /24 several weeks ago I've occasionally
watched my gateway firewall logs in realtime to get a sense of how much
traffic I get from the Internet at large for my little section of the
AMPRNet.
I get an average of 2.7 packets a second in random scanning traffic.
Scaling this up to the /8 that comprises AMPRNet, I surmise that the UCSD
gateway must get something like 176k packets a second. Assuming an average
SYN packet of 20 bytes, this is something like 283 …
[View More]gigabytes per day.
Is that about right, Brian?
-J
[View Less]