I think I have asked it before but i see on the log a lot of incoming UDP port 5060 to all the hosts (even that are not active currently but defined in the AMPR dns and therefore have routing to my gateway ) from all over the world
What is it ? who have interest to look for SIP on my system ?
Is there a way to cut and paste part of the log of Mikrotik router ? i can not do it when i enter it from the web interface so could not copy the relevant log part
Thanks Forward
Ronen - …
[View More]4Z4ZQ
http://www.ronen.org
Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/>
www.ronen.orgronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com
[View Less]
I've been analyzing some of the encap traffic and finding
unexpected things.
Several sources of ipencap'd packets being received by amprgw
have non-44 inner source addresses.
Would you all agree that a protocol-4 (ipencap) packet reaching
the UCSD gateway should always have an inner (encap'd) source
address on the 44-net? And that those that don't should be
considered bogus and be discarded?
- Brian
> anybody knows how to filter this traffic with IPTables ?
> It would be very helpful.
Where is that traffic originated? Is that the address of your own system?
If so, it can help to set a preferred source address on your routes towards amprgw.
(add src 44.134.x.y to the route command)
Rob
Hi all,
I'm checking my configuration at the gateway ampr-italy-gw.ampr.org due
to an issue on routing.
This gateway is the main one in the Country and manages several subnets
interconnected via VPN (OpenVPN).
The ampr-italy-gw.ampr.org is the point of contact with the AmprNet and
it's handling the IPIP tunnel.
I would like to permit traffic from inet to 44-net and vice versa and,
of course, only for specific 44-net hosts
that have the corresponding entry in the Ampr.org DNS.
Well, it …
[View More]doesn't work :)
Here is how the ampr-italy-gw.ampr.org router manages the traffic
between inet and 44-net:
ip rule add from 44.0.0.0/8 table 44 prio 200
GW_ADDR="169.228.66.251"
#
/sbin/ip route add 128.0.0.0/1 via $GW_ADDR dev tunl0 onlink table 44
#128-255
/sbin/ip route add 64.0.0.0/2 via $GW_ADDR dev tunl0 onlink table 44
#64-127
/sbin/ip route add 0.0.0.0/3 via $GW_ADDR dev tunl0 onlink table 44 #0-31
/sbin/ip route add 48.0.0.0/4 via $GW_ADDR dev tunl0 onlink table 44 #48-63
/sbin/ip route add 32.0.0.0/5 via $GW_ADDR dev tunl0 onlink table 44 #32-39
/sbin/ip route add 40.0.0.0/6 via $GW_ADDR dev tunl0 onlink table 44 #40-43
/sbin/ip route add 46.0.0.0/7 via $GW_ADDR dev tunl0 onlink table 44 #46-47
/sbin/ip route add 45.0.0.0/8 via $GW_ADDR dev tunl0 onlink table 44 #45
--
[root@ks28006 ~]# ip rule list
0: from all lookup 255
200: from 44.0.0.0/8 lookup 44
32766: from all lookup main
32767: from all lookup default
The table 44 has a higher priority than the main table where the routes
for each gateway are contained (basically what comes
from the encap.txt).
It should mean that when a 44-net hosts wants to reach an inet host, it
happens through the amprnet router at UCSD.edu and not directly via the
eth0 interface.
Now, if I send ICMP packets from 2.238.198.249 to 44.134.160.1, the
following is what I see with tcpdump at the ampr-italy-gw.ampr.org:
eth0 (tcpdump -n -i eth0 proto 4)
21:36:36.915644 IP 169.228.66.251 > 91.121.90.186: IP 2.238.198.249 >
44.134.160.1: ICMP echo request, id 1, seq 51, length 40 (ipip-proto-4)
21:36:36.937888 IP 91.121.90.186 > 169.228.66.251: IP 44.134.160.1 >
2.238.198.249: ICMP echo reply, id 1, seq 51, length 40 (ipip-proto-4)
tunl0 (tcpdump -i tunl0 host 44.134.160.1)
21:36:36.915664 IP 2-238-198-249.ip245.fastwebnet.it > iw2ohx.ampr.org:
ICMP echo request, id 1, seq 51, length 40
21:36:36.937872 IP iw2ohx.ampr.org > 2-238-198-249.ip245.fastwebnet.it:
ICMP echo reply, id 1, seq 51, length 40
My understanding is that it's working correctly, because the icmp reply
is sent back to 2.238.198.249 inside the tunnel and towards the
amprnet router (169.228.66.251).
Unfortunately there's something wrong in the middle because no packets
are actually reaching 2.238.198.249
C:\Users\marco>ping iw2ohx.ampr.org
Pinging iw2ohx.ampr.org [44.134.160.1] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 44.134.160.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Any ideas ?
Thanks for the help
Marco
iw2ohx
[View Less]
> For me, most all of the bad stuff is coming in via the spoofed ampr gateway address of 169.228.66.251
When you see internet traffic as bad stuff, you will receive a lot of it from that address, but most of
it will not be spoofed. It is traffic from internet to your AMPRnet address(es) that is being relayed,
the intended purpose of amprgw.
Maybe there should be a separate filter for incoming traffic via the gateway. We have that on our
gateway: a local AMPRnet user can indicate if they …
[View More]want to receive incoming connects from internet and they are
placed in a bitmap ipset similar to the bitmap created from the DNS hosts. By default they are not
in that map, and only replies to outgoing traffic are allowed. Of course this is only possible because
we run connection tracking on our gateway, which is probably not done on amprgw.
It keeps out a lot of junk.
A simple version without connection tracking could block incoming TCP SYN and maybe some UDP traffic to
ports like 53 and 161 and others. That would still mean there has to be some registration capability
to turn this on/off per address. DNS is already used to control the strict allow/deny per address, so it
cannot be used for this.
Rob
[View Less]
> - make an IP tables rule AFTER (-A [APPEND]) your ALLOW IPENCAP from
> AMPRGWS - to DROP IPENCAP
> - let us know if you get any firewall hits by checking your running
> ipencap list
I have done that for a while and I do not see a lot of traffic, but there is some.
Part of it is from gateways with dynamic address. When their address changes it
takes a while for the update to bubble through DNS, the portal and AMPR-RIP, and
during that time the traffic from their new address is …
[View More]dropped. But that does not
matter, as return traffic would not arrive there either. A gateway with a daily
changing external address is really not workable.
Lately there has been a lot more bad GRE traffic. We run GRE tunnels as well, with
a similar protection, and the default drop rule has logged quite some traffic the
past months. Research indicates that it is related to a hacked video recording
system, although it is unclear to me what the purpose or cause of the GRE traffic is.
When browsing to the source address of these packets, one gets a logon screen of
some Chinese video recording (for surveillance) system.
Rob
[View Less]
> Tom and Ruben,
> traceroute to 44.165.2.4 (44.165.2.4), 30 hops max, 60 byte packets
> 1 kb3vwg-001.ampr.org (44.60.44.1) 1.385 ms 1.392 ms 1.593 ms
> 2 mail.sp2l.ampr.org (44.165.2.2) 154.783 ms 171.077 ms 171.653 ms
> 3 home.sp2l.ampr.org (44.165.2.4) 171.674 ms 171.668 ms 171.650 ms
I cannot ping, connect or traceroute you either.
When it works from your side and not from ours, are you sure you have a *working*
incoming IPIP protocol forward or DMZ host? …
[View More]It is all too common for stations behind
ISP NAT modem/routers to have IPIP tunnels that work only outbound (and replies), not
for unsolicited inbound traffic, because they only admit IPIP traffic as replies to
their own outging traffic, even when they have set a DMZ host in their router.
(which often only works for protocols like ICMP, TCP and UDP)
Rob
[View Less]
> Regarding the other thread about which firewall rules to use, the
> gateway is a little more complicated but for my home router I
> (normally, not last night in case you saw differently) have the
> equivalent to:
> iptables -t filter -A FORWARD -i tunl0 ! -d 44.131.14.128/26 -j REJECT
> iptables -t filter -A FORWARD -o tunl0 ! -s 44.131.14.128/26 -j REJECT
> I think this pretty much covers the requirements for a basic end network?
For the outgoing side, yes. It would …
[View More]be very helpful when everyone had a
filter like that. For the incoming side it is a bit too simple. It covers
the case where hackers send packets that you would then forward, but that can
also be covered with a
iptables -A FORWARD -i tunl0 -o tunl0 -j DROP
However, it would still be advisable to:
- only accept tunnel traffic from registered gateways (I have shown on
the list how to do that a couple of times)
- attempt to screen the source address of the tunneled traffic a little
(e.g. accept non-44 traffic only from the gateway, as shown earlier today,
and even better: to reverse path checking for tunnel traffic, i.e. only
accept traffic from each tunnel whose source address matches the subnets
registered for that tunnel)
> If the main gateway receives an invalid encapsulated packet from a
> known gateway or a 44net address, would it be helpful to return an
> error instead of dropping it? An ICMP Administratively Denied packet
> is more likely to generate an obvious error message than packets going
> missing. The gateway would probably need to rate-limit the number of
> errors it will send out to prevent abuse, though.
This does not bring much, it would only help when someone is actually watching
the traffic, and it appears not many people do. When a decapsulating gateway
sends an ICMP unreachable packet to the encapsulating gateway, that gateway
will not normally attempt to translate it into an ICMP packet related to
the inner packet and send that back to the originating system. So the
user behind the keyboard will never know.
Rob
[View Less]
In our tunnels, all traffic from a gateway should be encapsulated
and should NOT contain an encapsulated ipencap packet. The ipip
router at UCSD logs and discards these; I'm seeing such packets
from gateways
77.138.34.39
85.234.252.133
86.161.255.194
185.58.225.84
which suggests that they have a routing misconfiguration. The
operators of those gateways should examine their routing and
encapsulation rules to see why this is happening.
- Brian
Hey Guys,
Does anyone have any contact info for ON4SAX? He should be the maintainer for the Belgium subnets. But I'm not able to mail him through the contact info on qrz.com (on4sax(a)on4sax.be<mailto:on4sax@on4sax.be>) to make DNS changes for my hosts. The domain seems parked and has no MX record as far as I can see.
I also saw that the range for Belgium is routed through Wireless Belgium and as such not through ucsd so I am also wondering how I can get incoming traffic from the world (…
[View More]non 44net) to my 44net hosts and outbound from my 44net hosts towards the world.
Thanks in advance.
73,
Ruben - ON3RVH
[View Less]
> iptables -I FORWARD ! -s 44.0.0.0/8 -i tunl0 -j DROP
> iptables -I INPUT ! -s 44.0.0.0/8 -i tunl0 -j DROP
> "If the source address of packets entering tunl0 doesn't equal AMPRNet,
> DROP them."
The problem with that is that it will also drop the legitimate internet traffic that
is coming in via the gateway. So, when you want connectivity to/from internet, it has
to be more complicated than that. You will need to put a rule in the mangle table for
protocol 4 traffic arriving …
[View More]from the gateway, and add some packet mark to the packet,
then in the above rule you exclude the packets with that mark.
Like this:
iptables -t mangle -A PREROUTING -p 4 -s 169.228.66.251 -j MARK --set-mark 1
and in the above rules add before the -j:
-m mark ! --mark 1
When you are inside a BGP routed subnet that also is on the tunnel mesh (like 44.137.0.0/16)
you will have to change the 169.228.66.251 to the address of your local gateway.
And of course, now you make yourself vulnerable again for dedicated attacks that spoof the
address of the gateway to send tunneled packets. So it remains mandatory to treat the
traffic received via the tunnels as hostile from-internet traffic!
Rob
[View Less]
> What's peculiar about a lot of these non-44 is that they have
> the encapsulated (inner) source and destination apparently interchanged:
> Apr 19 21:28:27 <local0.debug> amprgw ipipd[66472]: NON44: len 40,
> os 91.121.90.186, od 169.228.66.251, is 91.223.133.13, id 44.134.209.15,
> ttl 237, proto 6
> Either that or they're encapping in the wrong direction.
> I can't offhand think of what would cause THAT.
When I see odd addresses on encap links they often are …
[View More]ICMP packets (e.g. TTL exceeded, a result of traceroute)
that are sent by encap systems themselves and have the wrong source address.
Also, there appears to be some traffic in the noise of Internet that is completely ridiculous. Things like this:
Apr 20 10:43:30 Packet DROP: IN=eth0 OUT=gre14 SRC=44.137.49.139 DST=44.137.49.139 LEN=56 TOS=0x00 PREC=0x00 TTL=245 ID=35377 DF PROTO=ICMP TYPE=11 CODE=0 [SRC=44.137.49.139 DST=80.92.136.89 LEN=69 TOS=0x00 PREC=0x00 TTL=1 ID=35377 DF PROTO=UDP SPT=34973 DPT=53 LEN=49 ]
Note that 44.137.49.139 is not a registered AMPRnet address so it can never have sent this query, but
there is a ICMP TTL exceeded with source and destination being that address about a query it has allegedly
sent to 80.92.136.89, an address at some broadband provider that often re-occurs in this (amongst others).
It is completely unclear to me whether this is part of some attack on 80.92.136.89, on us, or is due to some
bug in a router (that sends ICMP with the wrong source address).
W.r.t. tunnel traffic, it sure is a good idea to drop anything not-AMPRnet.
I also see a lot of RFC1918 addresses in those packets, and even when I mail the
gateway operator about them I usually get a mail back that they are going to do something about
it, but that rarely happens (i.e. it just continues). E.g. this repeat offender:
Apr 20 07:52:05 Packet DROP: IN=tunl0 OUT=gre3 TUNL=90.63.239.151 SRC=192.168.1.3 DST=44.137.41.178 LEN=52 TOS=0x18 PREC=0xA0 TTL=59 ID=16343 DF PROTO=UDP SPT=50001 DPT=50000 LEN=32
It is unfortunate that setups of a gateway system can vary so widely that it
is impossible to give a good firewall example that will work for everyone.
My feeling is that many of the gateway operators lack the network knowledge to
get the firewall setup correctly, and it would be nice if we could educate them.
However, I am not going to be the sysop for even more systems. Some generic help
would be a good thing, but it is hard to do.
Rob
[View Less]
OK, it's my understanding the source and destination ports are undefined.
I'll just leave the mesh DOWN at this time, as the cross compiler is
configured exactly as before, and I am able to compile other software.
Thanks,
-Lynwood
KB3VWG
I've made a few small changes to the ipip encap firewall in
the UCSD encapsulating router. If something has stopped working
today because of that, please let me know.
- Brian
Hi all,
As part of my gateway setup I am looking to get rid of my BT Home hub (which I am having to use with DMZ turned on) and put in an inexpensive but more capable router.
So I was looking for peoples thoughts on either Microtik or Ubiquiti Edge routers. Is either particularly better suited?
Kind Regards Marc (2W0PNT)
> An update - I had success using compiling using 'cpp' instead of 'gcc'
cpp is not a compiler. it will only resolve your #include #define etc but the output is still C.
> I now receive less error output, but there's still an error:
Your crosscompiler setup is seriously broken! It apparently misses critical include file contents,
the first error about IPPORT_ROUTESERVER was also caused by that.
Maybe you missed some step in setting it up, I remember from the past where I tried this …
[View More]for my
Dreambox that it is quite an involved procedure.
Rob
[View Less]
All,
I've been able to successfully compile ampr-ripd for the native OS (Ubuntu Linux x64); but I receive errors when trying to compile for MIPS:
--------------------------------------------------------------------------
user@ubuntu-comp:~/ampr-ripd-1.16.2$ make CC=mips-openwrt-linux-musl-gcc LD=mips-openwrt-linux-musl-ld
mips-openwrt-linux-musl-gcc -Wall -O2 -o ampr-ripd ampr-ripd.c
ampr-ripd.c: In function 'create_fwsd':
ampr-ripd.c:1536:23: error: 'IPPORT_ROUTESERVER' undeclared (first …
[View More]use in this function)
sin.sin_port = htons(IPPORT_ROUTESERVER);
^
ampr-ripd.c:1536:23: note: each undeclared identifier is reported only once for each function it appears in
ampr-ripd.c: In function 'on_alarm':
ampr-ripd.c:1629:27: error: 'IPPORT_ROUTESERVER' undeclared (first use in this function)
sin.sin_port = htons(IPPORT_ROUTESERVER);
^
ampr-ripd.c: In function 'main':
ampr-ripd.c:1864:13: error: 'struct udphdr' has no member named 'dest'
(udh->dest == htons(IPPORT_ROUTESERVER)) &&
^
ampr-ripd.c:1864:29: error: 'IPPORT_ROUTESERVER' undeclared (first use in this function)
(udh->dest == htons(IPPORT_ROUTESERVER)) &&
^
ampr-ripd.c:1865:13: error: 'struct udphdr' has no member named 'source'
(udh->source == htons(IPPORT_ROUTESERVER)))
^
Makefile:30: recipe for target 'ampr-ripd' failed
make: *** [ampr-ripd] Error 1
--------------------------------------------------------------------------
Any assistance is appreciated
73,
KB3VWG
[View Less]
> I've been able to successfully compile ampr-ripd for the native OS (Ubuntu Linux x64); but I receive errors when trying to compile for MIPS:
IPPORT_ROUTESERVER should be defined in <netinet/in.h>
When it isn't, you can work around that by inserting this line near the top of the ampr-ripd.c file near the other #define lines:
#define IPPORT_ROUTESERVER 520
Rob
Hi all,
Just to inform all of you about the special visit
at i0ojj.ampr.org/ir0rm-7.ampr.org by using the
following references:
fbi.gov. 0 IN TXT
Dgoogle-site-verification=L8cauHJF4MANoTCkMbrLkAVfHBta28ctva9n1IDekToQ
fbi.gov. 0 IN TXT
Dgoogle-site-verification=6UEk-jfg1xPNjz_rQGcRFJOBGxMy1aARDZUTXgSNAqw
fbi.gov. 0 IN TXT
XublrZj1CzpSEiwtiRFKDAyiek8hRqkqaTTApxvhwai14i8JqVBOauW4cA06i39H5Lhl3HnALCM/xfTxIPEXEpA==
fbi.gov. 0 IN TXT 625558384-8740534
--
…
[View More]73 and ciao, gus i0ojj
A proud member of linux team
Non multa, sed multum
[View Less]
All,
I did an upgrade of my OpenWRT device to LEDE 17.01.0. At this time,
everything is operation as before; except that I cannot execute the
ampr-ripd from the CLI or the scripts that worked in the previous versions.
I'm suspecting it may be missing dependencies; but while I troubleshoot,
I am only accessible from the Global Internet.
If anyone else is interested in upgrading and troubleshooting, I would
ask that you make a copy of a list of all your installed packages prior
to …
[View More]upgrading. In addition, please make an archive of your config before
and after your upgrade.
73 and good weekend,
- Lynwood
KB3VWG
[View Less]
> Just to keep everyone in the loop: there have been four DDOS attacks on the portal recently, two against just port 443 and late last night (UK time) two simultaneous attacks against 443 and 25.
> I have no idea why anyone is targeting the portal, nor who is behind it - as per your standard DDOS the attacks they mainly came from compromised PCs on the end of home DSL lines.
We had a DDoS attack that affected our gateway, but it targeted the "Brandmeister" servers for interlinking …
[View More]digital voice repeaters, that were hosted on our network.
(some on the same ESXi server as the gateway and some on another location linked by a radio link)
This took down our connectivity as we got >200 Gbit/s of traffic and the gateway only as a 1 Gbit/s connection.
The traffic in this case was "DNS reflection", i.e. DNS requests were sent by compromised PCs using a spoofed source address on AMPRnet,
and the DNS servers were sending their replies to our gateway. Due to the high packet loss and the large replies these were mainly
UDP fragments that would not re-assemble to complete datagrams.
Of course it is bad that there still are so many ISPs that do not implement BCP38. But what can we do?
However, more interesting is the cause of this attack: the maintainers of the Brandmeister system have a disagreement with the operators
of the French gateway in that system and decided to disconnect it. The DDoS was done as a retaliation against that, probably
by one or more French amateurs, not necessarily the gateway operators.
(the disconnection of that gateway of course affected the repeater users in France, not only the operators)
Like in your case, there were several waves of attacks. In the end, the affected addresses were nullrouted and the servers moved elsewhere.
It might be that these same people are still looking for things to attack, and maybe they researched a bit how .ampr.org works and decided
to attack the portal?
(not effective against Brandmeister as our network is BGP routed)
It is sad that people act this way, and the network operators do so little to prevent it.
Rob
[View Less]
> Instead of this debate -- why not spec what the software does and start an
> open source project to replicate its functionality.
Because this is a one-instance project. It does not bring much to opensource it and
have 5 different people working on it in 5 directions, because ultimately we need
one instance that governs the AMPRnet. Even when we want to replicate it for redundancy,
those copies need to run the same code or at least would have to have exactly the same
functionality.
…
[View More]Having said that, it appears to be a pretty mundane LAMP project and it has taken way more
time to discuss about the developments it needs than it would have taken to actually do
those developments. Maybe writing the specs and starting from scratch is not such a bad
idea, especially when done by someone who can actually spend some time on it.
I would have favoured integrating it with another AMPRnet application, HamnetDB, but
unfortunately it appears its developer has just as little spare time, so that probably
would be a tough project as well.
Rob
[View Less]
Hello,
I made some updates to the MT ROS script:
- The script now maintains an interface list named 'ampr-interfaces'
with all ampr tunnel interfaces. The list is persistent, and will be
created on first script run. Afterwards it will be maintained by each
interface add or remove. Useful for firewall rules.
- Corrected an error when tunnel endpoint host routes where not deleted
on interface removal.
- Added step by step instructions using winbox GUI (inside the zip file).
http://www.…
[View More]yo2loj.ro/hamprojects/ampr-gw-3.1.rschttp://www.yo2loj.ro/hamprojects/ampr-gw-3.1.zip
73s de Marius, YO2LOJ
[View Less]
During the night, amprgw fetched a copy of the encap file from the portal
which was truncated (it had 259 entries instead of over 600) and one of
the entries that was in the copy fetched had no gateway address. Viz:
route addprivate 44.131.168.128/29 encap
This caused the ipip daemon to segfault and so there was no routing
between Internet and tunnel subnets for an hour. The rip sender
was similarly affected.
Later fetches of the encap file obtained ones that appear to be intact
and all …
[View More]routing is again operational.
I've modified the code in the daemons to be more robust in the face
of a bad encap fetch, and taken steps to ensure that future fetches
are checked better.
- Brian
[View Less]
The Register reports a Linux/Android kernel flaw that could
expose you to remote privileged execution of arbitrary code:
http://www.theregister.co.uk/2017/04/14/new_critical_linux_kernel_flaw/
As a lot of the machines and routers on the Amprnet are based on
Linux, this may be incentive for you to update to the latest kernel.
- Brian
> During the night, amprgw fetched a copy of the encap file from the portal
> which was truncated (it had 259 entries instead of over 600) and one of
> the entries that was in the copy fetched had no gateway address. Viz:
> route addprivate 44.131.168.128/29 encap
> This caused the ipip daemon to segfault and so there was no routing
> between Internet and tunnel subnets for an hour.
For this particular issue it would help when the encap file had a trailer that
the script …
[View More]that fetches it could check for before loading it. Something like:
# EOF
Rob
[View Less]
So that time has come to get some DNS entries added.G1FEF seems to be my coordinator. Should I approach him about entries I cannot spot a contact address anywhere.
Regards Marc (2W0PNT)
Hello,
I made some small fixes without major functional impact to ampr-ripd:
- Routes where not cleaned up in debug mode, after hitting CTRL-C
- If RIP forwarding was used and the forward interface became
inactive/disappeared, the daemon would not be able to send any RIP
updates. This use case can occur e.g. if ampr-ripd is providing RIP
broadcasts for a jnos via a tunnel. On jnos crash the tunnel would fail
and would not receive route updates after restart (tnx. Gus, I0OJJ for
report …
[View More]and testing the fix).
If these issues have not bothered you until now, there is no urge to
upgrade.
There was also a bug in amprd, which would not set the needed host
routes if rip_set_routes was set to 'no'.
Also, the password is hard coded in amprd, too (like in ampr-ripd).
Sooo:
http://www.yo2loj.ro/hamprojects/ampr-ripd-1.16.2.tgzhttp://www.yo2loj.ro/hamprojects/amprd-1.6.tgzhttp://yo2tm.ampr.org/hamprojects/ampr-ripd-1.16.2.tgzhttp://yo2tm.ampr.org/hamprojects/amprd-1.6.tgz
Have fun!
Marius, YO2LOJ
[View Less]
> I've sorted the source address and am now originating with a source
> address of 44.131.14.255.
Now I can ping those two other mentioned addresses
> I guess this also highlights another issue, does anyone have a pointer
> to the correct way to set up filters for this? I have added some quick
> rules to prevent my gateway being a public IP relay, but it looks like
> many others have not. I am not sure the correct way to configure these
> filters for the general use case. …
[View More]I should now be discarding all
> packets that don't have a source or destination within my network, but
> I do not check for spoofing beyond that. This should be "good enough"?
> Clearly, others have gone further.
Well, what I have done up to now is a filter to allow IPIP traffic only
from registered IPIP tunnel hosts, but no further. There is no strict
"reverse path" checking yet, so anyone with a registered tunnel could in
fact spoof traffic for any source IP. Maybe I'll fix that later, but
for now I decide to allow traffic that may be routed somewhere else and
then forwarded in a tunnel. The main purpose of the filter is to keep
out the opportunists on Internet that could try to get around a firewall
using tricky tunneled packets, not to regulate what the AMPRnet users can do.
(I have seen examples of unwanted IPIP traffic, and lately GRE is a popular
target as well, so similar filters are in place to allow GRE only from
locally registered GRE endpoints)
The filter is done as a -x script called by ampr-ripd when it updates the
route table. The script is like this:
#!/bin/sh
# script called when ampr-ripd updates route table
# load encap.txt into ipipfilter list
AMPRGW="169.228.66.251"
gwfile="/dev/shm/gw"
cd /var/lib/ampr-ripd || exit 1
grep addprivate encap.txt | sed -e 's/.*encap //' | sort -u >$gwfile
if iptables -N ipipfilter 2>/dev/null
then
iptables -F ipipfilter
iptables -A ipipfilter -s $AMPRGW -j ACCEPT
while read ip
do
iptables -A ipipfilter -s $ip -j ACCEPT
done <$gwfile
iptables -A ipipfilter -j LOGREJECT
else
iptables -L ipipfilter -n | grep ACCEPT | fgrep -v $AMPRGW | \
sed -e 's/.*-- //' -e 's/ .*//' | sort | diff - $gwfile | \
while read d ip
do
case "$d" in
">")
iptables -I ipipfilter -s $ip -j ACCEPT
;;
"<")
iptables -D ipipfilter -s $ip -j ACCEPT
;;
*)
;;
esac
done
fi
rm -f $gwfile
This updates the "ipipfilter" chain that is used in the input firewall like this:
iptables -A firewall -p 4 -j ipipfilter
I use this method to have some statistics of traffic per endpoint as well, when you
don't need that it would be better to use ipset to maintain an address set to be
matched by a single iptables line.
Rob
[View Less]
> If you want to test it, 44.131.14.254 is a second loopback on the
> gateway that is used for status monitoring. 44.131.14.192 is a unicast
> node "inside" my network to check end to end connectivity.
Your network is OK in our routing table. I can ping 44.131.14.255 but not
those other addresses.
Rob
> Can you ping .254? .255 should go direct and .254 should be
> encapsulated to the same machine.
No
> Do you have an address I can test to? I have been doing a few tests
> and it would appear that there are some issues here.
44.137.0.1 should be fine, and 44.137.41.97 as well
> Previously I was able to access services that were public the same as
> an external host, but now many of those are not working. As an example
> 44.137.0.1 works fine from an external IP address,…
[View More] but not a
> 44.131.14/24 one. I have found at least 1 host responding to my
> encapsulated packets with ICMP Administratively Denied, which makes me
> suspect that the problem is actually my anycast setup with my source
> address not matching the gateway address.
It is. Now I see what is wrong, the firewall log is full of:
Apr 6 19:47:01 Packet REJECT: IN=eth0 OUT= SRC=45.63.97.98 DST=213.222.29.194 LEN=104 TOS=0x00 PREC=0x00 TTL=52 ID=19182 DF PROTO=4
That source address apparently belongs to you but it is not the tunnel endpoint.
We reject all protocol 4 traffic from hosts not in the RIP broadcast for tunnels.
Rob
[View Less]
> We do this for a large percentage of our customers without issue. We route public subnets to customer specific firewalls which then translate those addresses to internal hosts:
You are doing NAT. I know this is customary in commercial internet practice but in HAMNET/AMPRnet we don't like NAT.
(too much time is wasted by debugging the issues caused by inserting NAT into networks that also have direct routing)
Rob
> Now another question about directly connected 44net addresses - is there
> a way for them to reach tunneled addresses? I would prefer to have my
> services accessible from all 44net addresses when I start offering
> something serious later this year. ATM, it appears my /24 would be
> unreachable from these addresses, because even if there is a host route
> to an endpoint, the 44net address is not exposed to directly connected
> endpoints (they see the public IP of my …
[View More]router). And those direct
> connected addresses not running tunnels wouldn't reach me for obvious
> reasons.
When you get BGP routing on internet for a certain subnet, you should install
and register an IPIP tunnel gateway for the same subnet as well.
Until now this required a public (outside net 44) IP address on the gateway
system, but with the mod discussed in this thread you may be able to put the
tunnel endpoint inside your BGP routed subnet.
Of course it will take some time for all people to pickup the necessary
software and configuration changes for this to actually work. So you will
still be reachable for only part of the users for some time.
Rob
[View Less]
> Now, ampr-ripd does identify this host as directly connected, which
> appears to be the expected behaviour with the new version. All well and
> good from the Pi, but there is one significant implication - the source
> IP is no longer my 44 net IP, but it's the public IP of my router, and
> the internal IP is the 10.x IP of the Pi (my regular IP range. I think
> that's where things are breaking.
Ah yes, it would be better when ampr-ripd added a "src" option with the IP
of …
[View More]the tunnel interface to the /32 routes it adds to the table...
Rob
[View Less]
> Good morning all,
> I seem to have my gatway up (44.131.192.128)
> It responds to some of the ampr ping tools in the service list but not others. Could I ask a few of you to ping it and see if you can see it.
It works!
Note it is a bit controversial to use the first (and last) address of your subnet.
You may run into problems sometime. You have a /29 so you should use 6 addresses.
Also, please register DNS names for your addresses.
Rob
I have a small subnet I was assigned by the Florida administration. I
have since moved to Nevada. Should I return the assigned block and get
a new one from the Nevada coordinator, just to keep things square and
straight?
Mike, the problem is that the n8lrf gateway has an address on
the subnet instead of a commercial IP address and is therefore
not reachable.
- Brian
On Wed, Apr 05, 2017 at 07:43:15AM -0400, Michael Wolthuis wrote:
> Rob,
> I have managed that subnet since early 90's. What is your concern? You are welcome to be assigned ips on it in Kent County. I have several other subnets for our HamWan project and even an IPv6 assignment from ARIN.
>
> How can I help meet your goals?
> …
[View More]
> Feel free to call me at 616-422-5412 or on the 145.27 Lowell repeater
>
> Mike
> KB8ZGL
>
> Sent from my iPhone
>
> > On Apr 5, 2017, at 6:13 AM, Brian Kantor <Brian(a)UCSD.Edu> wrote:
> >
> > I think it's a mistake. It's confusing. The gateway belongs to
> > n8lrf(a)comcast.net but the subnet belongs to kb8zgl(a)kb8zgl.net.
> > I'm guessing that n8lrf entered a gateway hostname that belongs to the
> > ampr side of the gateway rather than the commercial IP.
> > - Brian
> >
> >> On Wed, Apr 05, 2017 at 11:53:40AM +0200, Rob Janssen wrote:
> >> But there also is a network 44.102.128.0/24 and it does not work. Is that one okay or is
> >> it another config mistake? I suppose so, as its gateway 44.102.128.1 is routed to amprgw.
> >>
> >> I'm afraid we need better directions and/or safeguards in the portal.
> >>
> >> Rob
> >> _________________________________________
> >> 44Net mailing list
> >> 44Net(a)hamradio.ucsd.edu
> >> http://hamradio.ucsd.edu/mailman/listinfo/44net
[View Less]
I have installed the 1.16 on our gateway (without the safeguard for now) and it appears
to be doing its thing. I can ping hosts on those test networks.
But there also is a network 44.102.128.0/24 and it does not work. Is that one okay or is
it another config mistake? I suppose so, as its gateway 44.102.128.1 is routed to amprgw.
I'm afraid we need better directions and/or safeguards in the portal.
Rob
> Wouldn't you achieve the same result by adding that network's IP/subnet
> to the -a list?
Yes, but then I would have to know the offender's IP beforehand :-)
However, it would be possible to just delete the route in the -x script that we already have.
I think ampr-ripd will not detect that and the route will not be added every 5 minutes, right?
Rob
> If the daemon encounters a 44 gateway in the RIP data, it creates a host
> route to that specific host via the default gateway of the system.
I was thinking about one specific issue: when we run this code on our gateway, which is
BGP-routed for our 44.137.0.0/16 network and is on the IPIP network as well and runs ampr-ripd,
and some portal user who does not understand the system well, they could add a gateway with an
endpoint address inside the 44.137.0.0/16 network and we would add a …
[View More]circular route for that
address to our table.
Of course users should not do that. But they have done so, in the past.
Maybe we would need an option to specify a (list of) subnet(s) where this new mode of operation
would not be performed. Then a gateway can set that to the BGP routed network(s) it serves.
(similar to the -a option)
Rob
[View Less]
Good morning all,
I seem to have my gatway up (44.131.192.128)
It responds to some of the ampr ping tools in the service list but not others. Could I ask a few of you to ping it and see if you can see it.
Many thanks
Marc ("2W0PNT)
> No, but it is quite simple.
> If the daemon encounters a 44 gateway in the RIP data, it creates a host
> route to that specific host via the default gateway of the system.
Aha ok that is a nice solution. It should fix the problem for those that have two routing tables.
In our gateway we are using a single routing table (with some different metrics) so we don't have
the problem for isolated gateways, but your solution would still fix the case where the endpoint
has an address …
[View More]inside the subnet being routed (Sweden??).
I'll try to install it soon.
Rob
[View Less]
> Today I released an update to ampr-ripd (1.16) and amprd (1.5) to
> support ipip encapsulation on subnets which have their endpoints BGP
> announced in the 44net space.
Is it described somewhere how that works?
Rob
Is anyone using pfsense as your gateway/router? If so how do you handle
rip44? Is anyone interested in testing a package if I compile ampr-ripd?
Tom/N2XU/BSCS/CASP, Security+ ce
--
73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified
Hi folks on the list,
The obligatory introduction email.
I am Marc (2w0pnt) based in the Vale of Glamorgan in Wales.Currently messing around with ax25 on 2m and wifi meshing using Ubiquiti equipment. All this is currently around serving an Synchonet bbs system.I have been collecting packet tnc gear for a few years now buying it cheap whenever it appears on gumtree/ebay/etc and now finally have moved to a location with the space for me to properly play with it all.
Cheers Marc
Hello ! I'm trying a node on linux I leave the data to see if you can
connect Your nodes to mine route lu9dce-2 lu9dce.ampr.org udp 93 b Can
also be used udp 10093 and tcp ============= 73
I currently use Proxmox, a virtualizing operating system. It uses OpenVZ
and I was wondering if there is a image for ham radio users. If not I was
thinking of using my web server and maybe hosting a image that I could
maintain. I currently have net44 [some what] running in a VM alone with
linBPQ32. It has a web based login to the shell and webmin for maintaining
the VM.
I would probably like to setup something like that for the VM. I'm by far
an expert with net44, but would be interested in …
[View More]providing this if there
would be a need for it. The road to net44 comes with alot of upward
climbing without much help.
73's
Shawn Bush
KD8NCV
[View Less]
> I am sorry about my multitude of questions but sometimes I can read
> things a million times and still not understand.
> Would I have to use either ampr-ripd
> <http://wiki.ampr.org/wiki/Ampr-ripd>, or rip44d
> <http://wiki.ampr.org/wiki/Rip44d> on the server to forward the traffic
> to my AMPRnet box? Would I have to use either ampr-ripd
> <http://wiki.ampr.org/wiki/Ampr-ripd>, or rip44d
> <http://wiki.ampr.org/wiki/Rip44d> to tell the server …
[View More]where to send the
> AMPRnet traffic cumming from the box.
Rip44 is not for forwarding. It is used to populate the routing table for
the IPIP tunnel system. The forwarding is done by the kernel and is configured
the usual way. I.e. forwarding is to be enabled in the kernel and the proper
interfaces and subnets are added.
You would be setting up the AMPR IPIP tunneling on your brother's computer
(first ask if he agrees with that) and you get a subnet from your coordinator,
e.g. a /28 network, where your brother's computer gets an AMPRnet address
and your own computer gets another address in the same subnet, you set your
brother's computer as the default gateway, and all AMPRnet traffic is forwarded
via your brother's computer that will tunnel it over the IPIP network.
The ampr-ripd running on your brother's computer will receive the AMPRnet RIP
packets and maintain a routing table with about 400 routes, plus it has the
locally attached AMPRnet subnet that was assigned to you. All AMPRnet traffic
is forwarded between the IPIP tunnels and your local subnet.
> Or can I use a "simple" tool such as BIRD Internet Routing Daemon
> http://bird.network.cz/ <http://bird.network.cz/> (the first thing that came up when I searched
> for ipip routing deamons).
No. That software only handles standard protocols, and RIP44 isn't one.
(well, it almost is, it is just RIPv2, but the handling of the information by
the routing daemon is different)
An alternative when you do not want to do as much on your brother's computer
and do have a Linux system yourself, is to just forward all IPIP traffic received
by your brother's computer to your computer over the local network, and run
ampr-ripd etc on your own computer.
Rob
[View Less]
> Subject:
> Re: [44net] Trouble creating a Gateway into 44net
> From:
> "Augustine Tabeling, W8AWT" <w8awt(a)qsl.net>
> Date:
> 03/24/2017 12:36 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
>
> "An alternative when you do not want to do as much on your brother's computer
>> and do have a Linux system yourself, is to just forward all IPIP traffic received
>> by your brother's computer to your computer over the local network, and run
>…
[View More]> ampr-ripd etc on your own computer. "
>> ---
>> This is exactly what I want to do but I have no Idea how to do it. By "all IPIP traffic" do you mean _only_ the IP Protocol 4 Traffic or do you mean effectivly all IP traffic (I dont think that would be ok.)? I ask this because my brothers
>> computer has several websites and a few other web services (IRC, SSH, FTP, Minecraft) running on it and everything that I do cannot interfere with them.
On a Linux system, this is easy.
IPIP stands for "IP in IP" which is the protocol that is used for AMPRnet tunnels. The outer IP packet has protocol 4, the inner IP packet is the actual packet to be transferred.
Use the following command to send all incoming IPIP traffic (IP protocol 4) to another system using a destination NAT rule:
*|iptables -t nat -A PREROUTING -p 4 -j DNAT --to-destination 1.2.3.4|*
Instead of the 1.2.3.4 you put the IP address of your own computer.
The replies to those packets can be sent directly to the router so it is not required to configure a reverse for this.
(assuming the router does NAT itself)
This command has to be repeated every time the computer is booted.
To do that, you can add it to the file /etc/rc.local
Rob
[View Less]
Hi All,
>
> I am new to 44net and I am trying to create a gateway into it. but I
> am running into problems.
> My brother runs a Ubuntu server on our LAN and has the router DMZ'd to
> it. I would like to create a gateway to 44net on the LAN but not on
> his server. Would it be possible to set up 44net access on the LAN and
> working with but not on his server. if possible I would like to start
> by using a Ubuntu Server Virtual Machine and later move to a Linksys
…
[View More]> wifi router If I get it working well.
> I am new to networking and learning slowly. My brother is willing to
> work with me if I tell him what I need him to do but wont put a lot of
> energy into figuring out how to make it work.
>
> 73!,
> Augustine, W8AWT
>
[View Less]
> While ago, just for fun, SUCCESSFULLY compiled JNOS-2.0k
> on Debian-8.7/64 bit with CFLAGS -m64
> This binary is running right now on desktop PC instance of JNOS:
> 2LPJNS:SP2L - simply flawlessly... Hi!
Ok, that is good! I once tried this with NETCHL and it failed, and I did not
want to spend the effort of going through all code to make it 64-bit secure,
and this is a waste for such a program anyway (it does not require large integers
or pointers that can access more than …
[View More]2GB).
So for NETCHL the -m32 flag is mandatory.
Of course, with Debian8.7 there still are several compiler options (4.6 - 4.9 and
maybe more) so there may be some issue with a different version of the compiler,
I have seen that happen in the past.
Otherwise I have no clue what could be happening, we would need at least the
stack backtrace and maybe more.
Rob
[View Less]
> A couple of weeks ago I downloaded and compiled jnos2.0K and found that
> while the compile appeared to be successful, jnos would crash when a nodes
> list was sent or I entered "netrom bc xxx"
> So I have learn a lot about linux since then but not yet found the problem.
> I compiled using Fedora 24 with the most latest updates on two different
> PC's and today downloaded the gz file again.
As you mention JNOS I presume you are not using the NET/ROM code built into the
…
[View More]Linux kernel, but run JNOS as a user program on some tun/tap device.
This means, this problem has very little to do with Linux. It is just a bug
in the code, maybe combined with a property of the compiler. It sometimes happens
that when you compile C code with a newer (or another) compiler than the original
developer used, bugs surface that have always been present under the carpet.
What happens when it crashes? Segmentation violation? That would indicate
a corrupted pointer or -memory. When you type "ulimit -c unlimited" before you
start the program you will get a core file (memory dump), and you can find out what is
happening using gdb. Of course you need some insight in programming, but
it could already help when you just print the stack backtrace (bt) and post it here.
I have no personal experience with JNOS under Linux but it kind of surprises me
that nowhere in the makefile or compile document there is mention of "64 bits".
I would compile a program this age in 32-bit mode (my NETCHL also requires this),
and that would be done by adding -m32 to the CFLAGS and installing the 32-bit
development libraries first. But I leave it to others to comment if this is
required. Unclean code could fail in the way you describe when compiled in 64-bit
mode and work perfectly in 32-bit mode.
Rob
[View Less]
Hi All,
A couple of weeks ago I downloaded and compiled jnos2.0K and found that
while the compile appeared to be successful, jnos would crash when a nodes
list was sent or I entered "netrom bc xxx"
So I have learn a lot about linux since then but not yet found the problem.
I compiled using Fedora 24 with the most latest updates on two different
PC's and today downloaded the gz file again.
A kind user has helped enormously and sent me a file he compiled last
December 11 (I think) and it runs …
[View More]well.
Jnos2.0i compiled here today also runs well with no problems using my same
config.h file.
So it seems that something has changed with the "netrom broadcast" source
file since around December.
I have discounted Fedora mostly as jnos2.0i still compiles good so a side by
side source file compare is the next do.
The question is then, has anyone else had netrom crashes after a recent
Fedora jnos2.0k compile please?
Regards
Rob vk1kw
-----Original Message-----
From: 44Net [mailto:44net-bounces+vk1kw=netspace.net.au@hamradio.ucsd.edu]
On Behalf Of vk1kw
Sent: Thursday, March 09, 2017 10:28 PM
To: 44net(a)hamradio.ucsd.edu
Subject: [44net] JNOS2.0K and Netrom problem
(Please trim inclusions from previous messages)
_______________________________________________
.
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
[View Less]
> What's the timeframe to get a block of IP's, I'd like to start testing
> and messing around with AMPRnet. I've got BGP routing available, and I
> can't wait to get connected.
> I am my Wireless ISP, so that won't be an issue. I have a few different
> routes, so I'm hoping for a /23, and put one on each end of my network.
Well, it should be mentioned that going directly for BGP routing and mentioning
that you are an ISP is probably not going to speed things up!
It would be …
[View More]advisable to start experiments with IPIP tunnels or other connectivity
and add BGP routing later, as a service to local hams only.
There are lots of requests for large blocks to be BGP routed for AMPRnet that really
are attempts from ISPs to get IPv4 space that they can no longer obtain from the
normal registries, so this kind of requests and formulation will make the
coordinator very wary...
Rob
[View Less]
What's the timeframe to get a block of IP's, I'd like to start testing
and messing around with AMPRnet. I've got BGP routing available, and I
can't wait to get connected.
KB3PEV
Michael W Rhone II
> We do service a handful repeaters, and I'm hoping to do a some sort of
> RF based TCP/IP solution, haven't found one I like yet. Any
> recommendations? I could go Wifi based, 900/2.4,5ghz, but I'm hoping
> to find something other then packet to use at 440 or 1.2.
Check out NW Digital Radio's UDRX-440 (56kbps IPv6 on 440 MHz)
MichaelN6MEF
Hello,
I have linbpq32 setup and would like to get more axip connections and chat
links. I also would like to get some messages flowing my direction.
Could anyone help? I can give you my MAP line...
73's
Shawn Bush
KD8NCV
Hi All,
Since compiling JNOS2.0 some years ago, I have always had problems with
Netrom transmits killing it back to the directory prompt.
I have been using JNOS1 version ? in its place for a long time because of
the same problem.
But today I downloaded and compiled the latest JNOS2.0k and have the very
same problem.
It all compiles ok on my Fedora (latest updates) it starts and runs
perfectly until it does a node transmit and dies immediately.
I can poke it with all the netrom commands until …
[View More]I do "netrom bcnodes port"
and it crashes.
It receives nodes ok and populates the list ok. It also does normal "Connect
XX VK1KW-5" ok.
So to try another idea, I removed all my netrom options from autoexec.nos
and used the defaults. (except interface /call/node name). Same problem and
crashed.
I notice also in this version, you need to type the whole word eg "connect"
vice "con" or "ifconfig" vice "ifc".
Maybe something in Fedora is not compiled in or is missing or I haven't read
enough yet.
There may be a conflict in my config.h but it's pretty much the same as
original.
So I am open to ideas.
Thanks in advance
Regards
Rob
Vk1kw
[View Less]
Last night launched fully functional mailing list
named xfbb-bis and currently widely available at:
http://www.sp2l.ampr.org/mailman/listinfo/xfbb-bis
I warmly invite everyone wishing/willing to test
performance and usability of this site.
Best regards.
--
Tom - SP2L
------------------------------------
It is nice to be important.
But it is more important to be nice!
The encap file currently contains a bogus entry:
route addprivate 44.8.1.16/28 encap 0.0.0.0
I've asked Chris to make it impossible to enter this into
the portal as it's clearly wrong. The ripsender and amprgw
encapsulating daemon discard this already.
- Brian
W4EWH de N2XU.
The 172.x.x.x space I use sits within the reserved RFC-1918 172.16.0.0/12
space reserved for private networks. I use it for my home LAN just as I
could use 10/8 or anywhere in 192.168/16 space. I use it because some folks
are unaware of the allocation and are more likely to see it as you have
which is intended to make them shy away from messing with it OR ask
questions which I welcome because it's an opportunity to help folks learn
something they might not know. Any time we …
[View More]learn more about networks and
networking to advance what we know is a good thing.
74 de N2XU
Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+ ce
--
73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified
[View Less]
> >/The list of UDP ports at Wikipedia(1) doesn't show port 93 or 10093, /> >/so I suggest we correct Wikipedia's list, since port 93 is shown as /> >/assigned to "Device Control Protocol" by the IANA(3). /
> Yes, our usage of port 93/UDP for AXUDP is completely unrecognized by
> IANA. There is no official document describing AXUDP so there is no
> way for us to claim a port - although there's no prohibition on
> using any port number we want, since port numbers …
[View More]are not absolutes.
> Still, it's not wise to double-up on port numbers.
In the "old days" it was quite easy to register port numbers, and in fact
I have registered a few myself that I still use for similar but not the same
purposes (459, 1535, 1536). However, it appears to be not as simple anymore
and looking at protocols that are in much more widespread use than AXUDP it
appears to be not common anymore to register ports used only by some proprietary
protocol at IANA (there are way, way more protocols in use than those with
IANA-registered port numbers).
Note that at the time I registered the above 3, IANA would not take suggestions
for the numbers to register. I claimed different numbers that were unregistered,
but they gave me those instead. Asking for port 93 to be registered is unlikely
to succeed, 10093 may be possible.
Registered port numbers are useful mainly for open protocols that are widely
implemented and that accept unsolicited incoming connections. So everyone knows
what port you have your wellknown services listening on.
There is not much that can go wrong when using a port number without registering
it, especially when the receiving application accepts data only from a
pre-configured peer. The port numbers used essentially don't matter in that
case, the only thing you need to make sure is that you don't have another
session with that same peer that would want to use the same port number.
(e.g. it would not be wise to use port 5198/5199 as these are used by Echolink,
another port usage that is not registered at IANA and is in much more widespread
use than AXUDP)
Rob
[View Less]
> I'm a bit confused by your post: since 172.29.x.x addresses are
> reserved for "Detached" networks, please clarify the source of the
> 172.29.60.0 IP range you mentioned. Is it provided by your ISP, or are
> you going through a corporate network to get to the Internet? TIA.
This range is from RFC1918 where the 192.168 addresses also come from.
He probably has those addresses on his LAN and uses NAT to connect to internet.
Of course it is possible to use NAT between such a range …
[View More]and the AMPRnet, but
I don't recommend it. It is better to assign net-44 addresses to AMPRnet devices,
maybe have 2 addresses on one device.
Understanding a mixed-network NAT configuration (NAT to internet and NAT to AMPRnet
in the same network router) is hard for most people, and often mistakes are made,
resulting it lots of RFC1918 traffic ingress in the AMPRnet.
I get lots of log entries like this in our gateway:
Mar 3 09:56:13 Packet DROP: IN=gre8 OUT=tun0 SRC=192.168.1.101 DST=44.137.25.148 LEN=590 TOS=0x00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=5060 DPT=5060 LEN=570
(you see, the timestamp is "current")
Apparently someone experimenting with SIP. My own SIP phone is at 44.137.41.104
so I don't have such issues, I can connect to that 44.137.25.148 SIP server without NAT.
Rob
[View Less]
I've bitten the bullet and started to make some progress getting on 44net.
I'm certain my current issues are firewall and I'll get it sorted out. My
non-ham network is in the 172.29.60.0/22 range. I don't think I'm leaking
internal stuff to my partially built tunnel but If anyone sees packets from
that block please let me know.
Status: Attempted to ping 44.0.0.1 on a system on the ampr enclave on my
network, With tcpdump listening on the gateway ampr0 interface I can see
packets going out on …
[View More]the interface but that doesn't mean the packets are
getting out of the box. I'm not seeing a response but like I said, I think
it's a firewall issue.
I just wanted to say Hi to to everyone and say I'm looking forward to
exchanging packets with everyone
73 de n2xu
Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+ ce
--
73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified
[View Less]
> Unfortunately, there are problems with AXIP and AXUDP ever since the
> revisions of AX.25 were published - the AX.25 frames may get too big
> to encapsulate in unfragmented IP and UDP frames. Any new document
> would have to discuss the fragmentation issues, and I'll bet they're
> not defined. (As far as I know, the same issue applies to ROSE, KISS,
> and Net/Rom encapsulation too.)
Is this an issue? The AXUDP protocol simply is "put AX.25 frames in UDP
datagrams" and an …
[View More]UDP datagram can be nearly 64KB in size so I would not
think there are any issues. UDP and IP handle the fragmentation and
reassembly and the receiver gets the original datagram to insert it into
the AX.25 stack.
Of course, AXUDP senders should not set the DF flag, and if they do, they
should not expect more than about 512 bytes maximum frame size. Which
still is enough for classic AX.25 packet radio.
> Do any of the various implementations of AX.25 encompass v2.0 et seq as
> published by TAPR? Ie, is anyone actually implementing jumbo frames,
> expanded frame sequence numbers, etc? Or should we just treat it as a
> bad idea that should be buried and go on with the old protocol?
The actual AX.25 version and extensions like jumbo frames and extended
sequence numbers should not affect AXUDP at all. The UDP layer only replaces
the HDLC layer normally used to transfer data over radio, and all things
happening in AX.25 should be compatible between the endpoints, as always.
Rob
[View Less]
Earlier I wrote:
> Well I did not get a mail from you, probably it has been lost somewhere due to spamfiltering.
I now found how that happened...
I use my @amsat.org address on this list, and I found that the forward address has been reset about 2 weeks
ago, back to a value that it was a few months ago. I had changed it since.
I still receive most of my mail because that other path still sort of works, but it tends to block a lot of mail that
from the amsat.org forwarder as spam.
So I …
[View More]now found a couple of mails in a spamfolder where I normally don't look anymore.
I'm not sure what happened, there appears to be no announcement on the amsat.org page, but it could be
that they had to restore a backup of the alias database. So when you use amsat.org and changed your
forwarding address, it might be worthwhile to check if it is still OK.
Rob
[View Less]
I have received repeated requests from a non licensed user. When I reject,
he resubmits. It is obvious that this person may have an alterior motive
as it is a hosting company.
What to do in such cases? I have just let the request sit. None of the
hams or it people in my area have ever heard of the hoster.
Any way to ban a submission?
Best,
Elias
Kd5jfe
On Feb 20, 2017 3:00 AM, "Rob Janssen" <pe1chl(a)amsat.org> wrote:
(Please trim inclusions from previous messages)
…
[View More]_______________________________________________
> I was thinking what would be helpful is if there was specific information
> required, it would be good to prompt for it ahead of time. In reading
> through these threads, it appears there can be some variance in what may be
> required by each coordinator. Perhaps instead of free form text block
> there could be a means to prompt for some of the information that would be
> considered qualifying fields.
>
That is a good point!
There should be an optional text record for each network, to be entered by
its coordinator, about the local requirements for allocation and that will
be displayed on the request form above the input section.
Rob
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
[View Less]
> I was thinking what would be helpful is if there was specific information required, it would be good to prompt for it ahead of time. In reading through these threads, it appears there can be some variance in what may be required by each coordinator. Perhaps instead of free form text block there could be a means to prompt for some of the information that would be considered qualifying fields.
That is a good point!
There should be an optional text record for each network, to be entered …
[View More]by its coordinator, about the local requirements for allocation and that will be displayed on the request form above the input section.
Rob
[View Less]
> Thanks Tom. The portal already automatically sends reminder notices
> to coordinators with outstanding allocation requests, twice a month.
> If all the coordinators agree, we could change that to weekly.
I don't think that will help. In the cases where I did not get a response from
others it usually turned out they were moving, busy at work, etc.
Overwhelming them with more notices is not going to solve that.
> I find that the coordinations which take more than a few minutes to …
[View More]handle
> are those where the requester is confused and asking for something that
> is not sensible, so an email exchange is necessary to get the request
> straightened out.
That is correct. There should be an option for the coordinator to abandon
the request and take the thing to e-mail. Now the only option is to reject
the request, which often upsets the requester and also (because of language barriers)
the requester often clicks all links in the message, causing it to be re-submitted.
I would like to see a button on that screen that just deletes the request without
further mail towards the requester, so I can then send mail and explain the situation.
Rob
[View Less]
> Hello Rob,
> I have receive your email this morning and reply to it before your send
> on the group, I also close my amprnet for the moment. I'm new with the
> mikrotik router and don't know all, I get information on the internet to
> get it work. Sorry for the bad packet this is not intentionnal.
> 73 de Pascal
> ve2hom
Hi Pascal,
Well I did not get a mail from you, probably it has been lost somewhere due to spamfiltering.
Good to hear you use a MikroTik router! …
[View More]It is possible to fix it on this kind of router.
When you go to the IP->Firewall page and open the NAT tab, you will find an existing NAT
rule that you use for your internet connection. It will probably show something like
"masquerade", chain srcnat, out.interface ether1.
You can just add another item like that, with the settings:
chain srcnat
src.address 192.168.0.0/16
out interface ! ether1 (click in the empty box for the ! to appear and select your internet interface)
action src-nat
to address 44.135.50.x (select an address you want to use for this)
That should fix your problem, assuming you use this router only for internet and hamnet and
have no other interfaces to other networks.
This rule will make any traffic from the 192.168 range to be translated to a fixed address in hamnet
(but only when it is not sent to the internet interface, that is where the other rule applies)
Rob
[View Less]
> This also provides an opportunity for peer review in cases of misguided
> allocation schemes
>(such as breaking up a state block by county).
>
>Tom
Tom.
Can you validate why using a county scheme is misguided?
----------
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 …
[View More]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]
Does anyone know how to reach VE2HOM? He is keeping his contact information well-hidden, it appears.
His gateway at 206.80.251.222 is sending a lot of traffic with RFC1918 source address:
Feb 19 15:00:53 Packet DROP: IN=tunl0 OUT=eth1 TUNL=206.80.251.222 SRC=192.168.0.5 DST=44.137.42.18 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=13455 DF PROTO=TCP SPT=40510 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0
Feb 19 15:00:57 Packet DROP: IN=tunl0 OUT=eth1 TUNL=206.80.251.222 SRC=192.168.0.5 DST=44.137.42.18 …
[View More]LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=38262 DF PROTO=TCP SPT=40512 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0
Feb 19 15:01:01 Packet DROP: IN=tunl0 OUT=eth1 TUNL=206.80.251.222 SRC=192.168.0.5 DST=44.137.42.18 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=14124 DF PROTO=TCP SPT=40480 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0
Everyone remember: when you are combining the routing of AMPRnet and other network traffic, make sure you
have the proper routing and/or NAT rules in place, and preferably also a filter, to make sure you don't send traffic
with a source address like 192.168.0.5 into an AMPRnet tunnel.
Rob
[View Less]
> I am trying to get a feel for how active AMPR is today.
This varies a lot by region. The old network (1200/9600 bps packet radio) is completely dead in most
regions and what is left over in those speeds is usually only APRS, so unrelated to IP used in AMPRnet.
However, in some places new networks are being built using WiFi technology. Much faster and much more
usable. Plus there is tunneling and direct routing of the net-44 space over internet to interconnect those islands.
Rob
Greetings,
I am trying to get a feel for how active AMPR is today. I am a software developer by trade these days and am relatively new to the hobby but not to IT / networking. Looking for a place to get involved and give back to the community.
Regards,
Jim KD8MTY
Sent from my iPhone
> Subject:
> [44net] Amprnet vpn
> From:
> Shawn Bush <daemon75joker(a)gmail.com>
> Date:
> 02/17/2017 01:18 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
> something
> that I couldn't figure out how to get a ubuntu vm to run with.
>
> In the ubuntu host, the ipip works just fine and there is a module for it.
> But the module isn't in the VM and I dont see why.
You probably are not running a full VM (hardware virtualization with a standard OS …
[View More]running in it)
but paravirtualization like Xen which runs a special kernel in the guest machine.
This is popular for providing virtual webservers and other "cloud" servers.
However, as those servers are normally not full-featured, the guest kernel is compiled with
limited selections in the kernel config, and it may well be that exotic features like IPIP tunnels
are not provided in that config.
When it is your own system, you could opt to compile your own kernel and modify the config
while doing that. It may be easier to run the IPIP tunnel gateway on a dedicated system, e.g.
a Raspberry Pi (as I do myself) or router (e.g. a MikroTik using Marius YO2LOJ's method.
Rob
[View Less]
Shawn,
I'm lost; but I guess my inquires sum up to:
- Are you running a stock installation of Ubuntu, or is it a version
offered by the Virtual Machine Provider?
- How are you "receiving the route information" and what do you mean by
"but that would be it"?
Did you receive route information via rip44d and confirm it by typing:
ip route show table 44 ?
Have you been successful at getting rip44d to run as a service?
If the routes are there, this indicates you may have already made great
…
[View More]progress.
Did you attempt to ping or traceroute any IPs from an interface assigned
an AMPR IP?
If so, did you receive a reply?
In any case, this means you are receiving the packets at the VM. We need
to determine if the tunnel interface Up. Please verify by typing: ifconfig
If you used startampr, you should see an interface listed as tunl0, it
MIGHT say IPIP or UNSPEC, but you will recall you configured it for
IPENCAP (this is because the Linux Kernel module for both are the same).
Also note the names of your other interfaces, as the names used in the
script must also be correct. Since Ubuntu 16.04, the Ethernet interfaces
were no longer named: eth0, eth1, etc. Since I used eth0 and eth1 in
documentation, you must account for variations in your system
configuration. The ifconfig command will be most helpful to that end.
You can also assign an IP to tunl0 (a commented-out line in the script
allows for that).
Lastly, have you ever received a copy of startampr from me? If you're
using a script from Internet, that might be your problem (earlier
versions contained less documentation). The current copy is only
available on AMPR at:
http://kb3vwg-010.ampr.org/amprnet_docs/start_ampr_version2/startampr
Since that presents a chicken-and-the-egg problem for you at this time,
contact me off-forum and we can arranging for you to get a copy.
- KB3VWG
[View Less]
Thanks for the detailed reasponce. I have work with the 44ripd daemon and I
was recieveing the route information but that would be it. In thr startampr
script that is show, it tries to setup mode ipip and that is just something
that I couldn't figure out how to get a ubuntu vm to run with.
In the ubuntu host, the ipip works just fine and there is a module for it.
But the module isn't in the VM and I dont see why. But I was told ipensec
is what I'm supposed to be using? I have no idea how to route diffrent
protocols....
Sean,
If you are using the AMPR VPN listed on the services wiki site, it uses
the allocation given to its operator.
You MUST setup an IPENCAP tunnel, or have your subnet routed over the
global Internet via BGP.
You might be able to have your allocation directed to the VPN operator
(callsign - OH7LZB) and then arrange for him to route your IPs to the
tunnel connection you have established between him. Please be advised,
out of all the options, this one is not regularly supported. In
…
[View More]addition, your latency would be extremely poor, since you appear to be
in the United States and the VPN endpoint is in Finland. Lastly, from
what I observed, the AMPR VPN appears to be a Layer 3 VPN (not Layer 2).
This means that more detailed configuration (on part of the operator)
may be required to route multiple IPs to your VPN instance - my
understanding is that the VPN is maintained on a volunteer basis.
What issue(s) are you having getting "[IPENCAP] over to the VM"?
I ran my AMPR router as an Ubuntu VM for many years before migrating it
to an actual hardware border router running OpenWRT; perhaps I can assist.
73,
Lynwood
KB3VWG
[View Less]
I recently setup a AMPR NET VPN with openvpn in a OpenVZ container due to
the fact I couldn't figure out how to get IPIP over to the VM.
My question is this, I have a weird ip a 44.x.x.x number and I want to be
able to use my given IP of 44.102.204.32, can I route my IP over the given
one from the VPN?
I'm using Ubuntu in the container and the routing for the VPN is working
just fine. I want to setup linBPQ32 with this IP and start routing this way
if I can.
I'm pretty good with Linux, but …
[View More]not so much with routing. I setup a ampr
interface and gave it my 44.102.204.32 IP, but from their I am stuck.
73's
KD8NCV
Shawn Bush
[View Less]
Hi there
We got permission to use our local university network for ham radio
We plan to connect our DMR repeater to this network (some ports needed to be opened to allow the repeater to connect to the server)
In adddiotion i want to place a AmprNET IPIP gateway there
The University protected by firewall no outgoing and no incomming packets free flow..
What should I tell the IT person to open in order to allow gateway to run ?
Does Firewall have IPIP protocole definition ?
if …
[View More]not ... what should they open ? Outbond and inbond and from /to UCSD 44 Net Router ?
Please Advice
Thanks Forward
Regards
Ronen - 4Z4ZQ
http://www.ronen.org
Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/>
www.ronen.orgronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com
[View Less]
> Subject:
> Re: [44net] 192.168.0.2 gateway
> From:
> Mark Phillips <g7ltt(a)g7ltt.com>
> Date:
> 02/06/2017 02:34 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> I would say "no".
>
> Y'see, we don't know what kind of network things are riding over. the
> network in question could be (for example) a mesh install configured
> similar to that of the local cable company. The users get real addresses
> but the …
[View More]infrastructure does not.
I think precisely this is the reason why such addresses should be rejected:
The user may have the wrong assumption that the address to be entered here is
the address of the system terminating the tunnel, while in reality it has to be the
internet-visible address that supposedly is NATted to the tunnel gateway.
So, what happens in the local infrastructure does not matter.
Rob
[View Less]
I just spotted this entry in the latest encap file:
route addprivate 44.74.0.128/28 encap 192.168.0.2
Unless you're doing something highly unusual, setting your
gateway address in the portal to 192.168.0.2 probably is a
mistake since it's not reachable from the Internet.
- Brian
First I wanted to mention I am glad to read Bjorn's message about
adding some content to the network.
Keeping in contact is key. Be that a coordinator or any host on the
amprnet. Seems every few months on here we are discussing how someone
is sending out random packets, and a straight forward way to get a
hold of people would be helpful.
Some time back it was brought up to have a whois server or something
like that. I bet I can guess the status of that.
As for everyone having an ampr.org…
[View More]email address, perhaps a forwarding
service like the arrl.net addresses? Then there is the possible spam
problem, and the fact that someone would need to set up such a
service.
Overall a lot of good ideas are brought up on this list, so few ever
happen. The only solution I am offering is everyone should help
spread the word and try and get more people involved with moving this
network forward. I wish I had better coding skills.
One of the core problems at least in my country where the ampr/44net
space is not well utilized is the lack of higher speed equipment to
build a network. You really have to be part of a well organized club
with site connections to do anything microwave on any big scale from
what I have seen.
[View Less]
Hello All,
I recently had a power supply problem and it has let the smoke out of my
PacComm TNC-320 packet modem.
While I have the manual, I do not have a circuit diagram and only have a
partial id on one of the cooked ICs U17.
The partial number is MC xxxxx06P (I think) and is on the main board across
the RS-232 D9 connector circuit.
Could you check your circuit diagram, parts list or slide off the cover and
have a look and let me know what the U17 IC is please?
Many Thanks
Rob
VK1KW
Hello all,
If you may have noticed, there is a recent IPIP tunnel with a 44net
gateway (which you may have seen flapping on your Mikrotik routers -
44.130.120.0/24 via 44.130.120.65).
This is a experimental setup to allow tunneling via BGP announced 44net
gateways, with no real hosts there yet.
Ampr-ripd newer than 1.13 will ignore this RIP broadcast (an update will
be available soon).
Our first step to make it run on Mikrotik routers (this will stop the
route flapping):
Announcing the …
[View More]Mikrotik RIPv2 AMPR Gateway Setup Script 3.0 (21.Jan.2017)
- Added support for tunnels with BGP announced 44net endpoints
If you already use v.2.x, only update ampr_gw and from the archive file
and add manually the new parameter "AmprDefaultGw" to your config file
(see the example file in the archive).
"AmprDefaultGw" can be set to your gateway WAN interface name or the
correct gateway IP for your router.
Download as usual:
RSC file: http://www.yo2loj.ro/hamprojects/ampr-gw-3.0.rsc
ZIP archive: http://www.yo2loj.ro/hamprojects/ampr-gw-3.0.zip
Greetings,
Marius, YO2LOJ
[View Less]
Is there a good forum to discuss packet, AX.25 and such things? After some 20 years of abstinence from packet I am really interested in getting something going. In my area APRS is alive and well, but packet on VHF or UHF is dead and has been dead for a long time. Lots of equipment is still out there, such as KPC-3 and the like, just not being used.
Although I am very interested in getting packet going again, I have no idea where to start. Got hardware to spare, but …
[View More]where to start? What’s out there for software (OpenBCM, JNOS, BPQ32, what else?)…
I realize that this is probably not the avenue to discuss, but perhaps someone can point me in the right direction of where to start looking, where to ask.
Thanks,
Adi
[View Less]
Hi Chris,
Life at Ofcom has overtaken amateur radio activity almost totally for the
last 3 1/2 years but I'm starting to "emerge" again, I'm sure that you
understand life's nasty way of getting in the way of hobby time.
A number of D-STAR services are still hosted on my servers, including the
central dsync reporting tool ( http://dsync.dstar.info/ is the public
reporting page but there is an extensive admin portal too) and also some
reflectors including REF006 ( http://ref006.dstargateway.org/…
[View More] ). The
servers are due to be re-homed to an A&A data centre, where a few of the
staff are amateurs. Some of the D-STAR gateway admins have previously asked
about accessing services via ampr.org IP addresses; do you think that this
would be an appropriate use of the resource?
Tentatively I asked A&A if they could BGP advertise a subnet of ampr.org
and they'd be happy to do that, so it's more of a question of whether
D-STAR services for hams would be okay to provide via AMPRNet? Are there
any rules that would prevent the dsync pages being dual homed via public IP
space and ampr.org IP space? Has anyone managed to regularly route digital
voice (UDP) over AMPRNet?
Sorry for all the questions but I know that you will know the answers...
73 de Darren
G7LWT
[View Less]
> With the BGP advertisement my subnet is reachable via internet and can reach anywhere via internet. Other 44 networks can reach my subnet as long as they are also advertised via BGP or have appropriate NAT rules to allow internet access. I can reach any BGP advertised 44 net addresses. However, I should not be able to reach any non-BGP advertised 44 net addresses unless there is a gateway (at USCD?) that allows for access to IPIP only 44 networks from 44 networks.
> I guess I don’t …
[View More]know the network topology of the 44 net or the functions that are provided at the UCSD gateway.
> I assumed that in order to reach IPIP only networks I would have to also establish IPIP tunnelling from each 44 host or gateway using subnets of my BGP advertised subnet.
When the system that handles the traffic that comes in on your BGP advertised route also has a public IP address and is made member of the IPIP mesh for the same subnet it advertises on BGP, you can talk to everyone that is on the IPIP mesh.
They will send traffic for you via the IPIP tunnel that they establish because you are in the list maintained via portal.ampr.org and transmitted using RIP from the gateway at UCSD.
You then only use IPIP for traffic between hosts on the IPIP mesh, not for the remainder of traffic to and from internet.
Rob
[View Less]
Hi,
I received a 44 net allocation and am successfully advertising it to the internet via my ISP.
I have been reading on the AMPRNet Wiki about IPIP tunnelling and Startampr. Are there best practices or anything else I need to be aware of before venturing into building the gateway?
On a related note, I have been using OpenVPN to provide publicly routable /32 IP addresses to individual Windows PC. I don’t see support for IPIP on Windows, are there any other tunnelling methods …
[View More]worth looking at, for Windows7 specifically, or is OpenVPN my best bet?
Thanks,
Adi
VA3ADI
[View Less]