I tried to follows the instructions that written here
http://www.yo2loj.ro/hamprojects/ampr-gw-README.txtwww.yo2loj.ro<http://www.yo2loj.ro/hamprojects/ampr-gw-README.txt>
www.yo2loj.ro
Setup example - please adapt ===== (ASSUMPTIONS: public ip is 89.122.215.236, router's ampr ip 44.182.21.254, WAN interface is PPPoE-In): You ...
I have a working tunnel on the router called UCSD (the tunnel interface have no IP adress)
my router is in bridge mode because it connect to cable modem before of it and sit on a DMZ address of the cable modem
It uses ether1-gateway interface as the 44 net address (4.138.1.1)
it uses ether2-master-local as the ip connected to the Cable modem (it uses 192.168.1.180 and default gateway to the cable modem ip which is 192.168.1.1)
I have no firewall working and i get no RIP routes
I have changed the tunnel interface name in the instructions to meet my interface name ..
on the VRF if i chose the tunnel interface the routes (or maybe the tunnel) stop and i cant access anymore the 44 net hosts from the outside world and i see no rip info
when i change the interface to the ether1-gateways (the one that have the 44 net address) the routes are ok the hosts are accessible from the outside world but i still not seeing any rip info
what is wrong ?
how can I debug it ?
if needed i can provide password to the router since it is accessible from the outside world
Thanks Forward
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
> Let's not forget...
> If you are unable to get RIP broadcasts for any reason, you can get the
> encap data from the portal as a json file via its API.
Sure, but please note that this does not solve the underlying problem of not being able to
receive unsolicited IPIP traffic I mentioned. When that is the reason (rather than inability
to follow installation and debugging instructions), the result will be a partially-working
gateway.
That gateway will be usable to contact other stations on the AMPRnet, but those other stations
will not be able to contact your systems. Outgoing connects are OK, incoming connects are not.
While some people my consider that a usable system, it is not a desirable situation.
The AMPRnet is more peer-to-peer than the internet in general, in that anyone is expected to
be both a participant and a consumer, not only a consumer as is usual on the internet.
Rob
> So the password is sent from UCSD and compered with the password i put locally and if they identical then the data is processed ?
> one more thing i understand the data is sent from UCSD ... how often is it sent ?
> I dont see any advertisement here do i need to define something in the portal ?
> normal tunneling work well
Of course you need to have a gateway entry in the Portal. I.e. you need to have a subnet, and
a gateway with external address and that subnet defined.
The RIP packets are sent every 5 minutes.
When you can manually make a tunnel and ping the remote, but you do not receive anything including
RIP broadcasts, the cause often is a stateful firewall inside your internet modem/router.
It accepts replies to outgoing packets, but it does not accept unsolicited incoming packets.
This is designed as a security feature.
To use IPIP tunneling, your modem/router must be able to unconditionally forward protocol-4 traffic
to your gateway system. In advanced modem/routers you can forward a protocol, but usually it is only
possible to forward TCP and UDP ports. That is something different. It is useless to forward port 4,
you have to forward protocol 4.
When that cannot be done you can often set a "DMZ host" that is said to get all incoming traffic,
however there are examples of modem/routers where this does not work correctly. The DMZ host receives
all TCP and UDP traffic but not all other traffic (including IPIP).
It does receive (like any host) replies on its own IPIP traffic, but not the unsolicited incoming traffic.
When you have such a modem/router, and when it cannot be replaced (e.g. because your provider requires
you to use this modem/router), you cannot use IPIP tunnels.
Rob
Hi there
can i get the ripv2 data from ucsd gateway by connecting to its non ampr address ?
what about from connecting it from my internet (non ampr) adress as well ?
any info welcome
Thanks forward
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
> Subject:
> [44net] ip44 argentina
> From:
> Eduardo Castillo <lu9dce(a)gmail.com>
> Date:
> 09/07/2016 06:10 PM
>
> To:
> 44net-owner(a)hamradio.ucsd.edu
>
>
> Hello !!
>
> we are trying to set up a debian linux pc
>
> and we fail to find settings
>
> ip we have is 44.153.32.97
>
> PC IP is 192.168.0.50
>
> and dynamic IP Internet
> lu9dce.dynu.com
>
> how to make a script
> to a ip44
You can find directions on the WiKi:
http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_Linux
Hello !!
we are trying to set up a debian linux pc
and we fail to find settings
ip we have is 44.153.32.97
PC IP is 192.168.0.50
and dynamic IP Internet
lu9dce.dynu.com
how to make a script
to a ip44
73
---------
Hola !!
estamos tratando de configurar un pc con linux debian
y no logramos dar con la configuracion
la ip que tenemos es 44.153.32.97
la ip del pc es 192.168.0.50
y la ip de internet dinamica a
lu9dce.dynu.com
como hacer un script
para poder unas ip44
73
--
======================================================================
Yo, el solitario, soy siempre el más rico y el más envidiado
porque os he poseído y vosotros me poseéis aún.
Friedrich Nietzsche, "Así habló Zaratustra".
======================================================================
__ __ __ __
| / \(__\| \/ |_ BBS GF05OM TORTUGUITAS 145010Mhz
|__\__/ __/|__/\__|__ TELNET LU9DCE.DYNU.COM PORT 6300
== power by linux === NODO LU9DCE.DYNU.COM PORT 3694
*** https://www.facebook.com/groups/newpacketradio/
/EX
I have configured a Cisco router, duel Ethernet interfaces on on of my static Internet addresses. The IPIP tunnel comes up and with wireshark I can see traffic in both directions to 169.228.66.251 pinging devices in the wider 44. network I never see anything being returned. Does the gateway router automatically have the reciprocal return tunnel / routes added (as per the Encap file) or is this something that needs requesting?
Is there a good 44.131.x.x address to test against?
73 Paul - G1DVA
Ronen,
Most consumer routers only pass TCP and UDP without customized firmware.
If you have the Version 1 device, it is compatible with OpenWRT, see:
https://wiki.openwrt.org/toh/netgear/dgn2200
I suggest using devices known to pass IPENCAP traffic.
73,
Lynwood
KB3VWG
hi there
One of our gateway got 8 IP ADDRESSES 44.138.0.8/39
Can the first address 44.238.0.8 be used ? or it reserved for networking only ? and i have to choose ip address only in the range of the 9-14 ?
if the answer is that it can not be used how the main router at UCSD treat for ping attempts coming for 44.138.0.8 ?
does it pass it ? or ignore it ? all is assured that the IP is defined at the AMPR DNS...
What about the tunnel itself doesit have any connection to what ip the gateway have ? or it exist anyway and has no meaning for the ip of the gateway ? (because the tunnel defined with only Commercial IP one is local and other is the AMPRGW commercial ip)
Its the first time i play with so small network and its not clear to me how its done at the AMPR system
I know that on ampr /24 network we didnt use the first and last .. dont know if it was necessary or not but that was the fact
Thank for any clarification
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
Hi there
Does anyone know if netgear DGN220 router may pass IPIP to its DMZ ?
the router have a fire wall that ca not turned off and one rule in it that can not be deleted as follows
any any drop always 10.0.0.20 never log
i have placed before it rule as follows
any any always pass 10.0.0.20 always log
i suspect it know only TCP and UDP and not recognize IPIP
on the log there is no sign of AMPRGW IP
does anyone have experience with it ?
Thanks for any help
Regards
Ronen - 4Z4ZQ
http://www.ronen.org
> sorry this is the correct config
I think we have explained you many times that this is NOT a correct config.
People have helped you with setting up working alternatives, someone has even gone all the
way to write software for a commercial router to work as an AMPRnet tunnel router.
All that effort seems to have gone to waste. You are still deploying those Cisco routers
with only a default route. It's a shame.
Rob
________________________________
Its cisco
i tried to send print screen of th show interface tunnel0 but the message didnt go with it ...
config is as follows
the cisco sit on the DMZ of the DSL router
the relevant part of the config is as follows
this router was working t my home and only the fellow changes his IP to meet his network
the router can ping the 169.228.66.251
interface Tunnel0
ip unnumbered Ethernet0
tunnel source Ethernet0
tunnel destination 169.228.66.251
tunnel mode ipip
!
interface Ethernet0
ip address 44.138.1.1 255.255.255.0 secondary
ip address 44.138.0.8 255.255.255.0 secondary
ip address 10.0.0.20 255.255.255.0 secondary
ip address 192.168.2.140 255.255.255.0
ip route-cache flow
ip tcp adjust-mss 1360
hold-queue 100 out
!
!
ip classless
ip route 0.0.0.0 0.0.0.0 Tunnel0 169.228.66.251
ip route 8.8.8.8 255.255.255.255 Ethernet0 10.0.0.138
ip route 169.228.66.251 255.255.255.255 Ethernet0 10.0.0.138
!
________________________________
From: 44Net <44net-bounces+ronenp=hotmail.com(a)hamradio.ucsd.edu> on behalf of Todor Kandev <todor(a)kandev.com>
Sent: Tuesday, August 23, 2016 11:28 PM
To: AMPRNet working group
Subject: Re: [44net] ipip tunnel problem for new gateway
(Please trim inclusions from previous messages)
_______________________________________________
Having issues with my crystal ball this morning... :D
What is your friend using (openwrt, mikrotik, cisco, linux, washing
machine, toaster...?) and how it's configured?
73,
LZ1ETE
On Wed, Aug 24, 2016 at 9:23 AM, R P <ronenp(a)hotmail.com> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
>
>
>
> ________________________________
>
>
> ________________________________
>
>
> Hi there
>
> im helping a local ham to set up a gateway and i get strange behave
>
> the amprgw is accessible from his router the ipip table at the portal
> POINTfor the correct ip
>
> the router accessible from the outside world
>
> the tunnell interface according to the cisco is up but it look like that
> no data flow to the income
>
> how can i track where the problem is ?
>
> any help is appreciated
>
> thanks forward
>
> 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
>
> Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/>
> www.ronen.org<http://www.ronen.org>
> ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com
>
>
>
>
________________________________
________________________________
Hi there
im helping a local ham to set up a gateway and i get strange behave
the amprgw is accessible from his router the ipip table at the portal POINTfor the correct ip
the router accessible from the outside world
the tunnell interface according to the cisco is up but it look like that no data flow to the income
how can i track where the problem is ?
any help is appreciated
thanks forward
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
Hi
can anyone explain why i get every second ping missing packets from AMPRGW ?
it happen not only from my PC also from other places ...
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
C:\Documents and Settings\customer>ping 169.228.66.251
Pinging 169.228.66.251 with 32 bytes of data:
Request timed out.
Reply from 169.228.66.251: bytes=32 time=336ms TTL=40
Request timed out.
Reply from 169.228.66.251: bytes=32 time=286ms TTL=40
Ping statistics for 169.228.66.251:
Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
Minimum = 286ms, Maximum = 336ms, Average = 311ms
C:\Documents and Settings\customer>
Hello,
as far as I know, 44.128.0.0/16 is reserved for testing and experimentation and should be treated much like an RFC1918 subnet. That means it will not be routable to anyone (although it is advertised on BGP). So I have a few questions about its use:
1. Can an AMPRNet member use 44.128.0.0/16 in their home instead of, let’s say, 192.168.1.0/24? Note that I am not talking about routing these addresses, just use them in a non-connected place.
2. Can a non-ham use 44.128.0.0/16 in their home instead of, let’s say, 192.168.1.0/24?
3. Can a company use 44.128.0.0/16 for their intranet, instead of, let’s say, 10.0.0.0/8?
Note than in all three cases, nobody is connected to 44net gateways and just use the network like any other private address. I am aware that there’s no technical limitation in doing this and there are hardly any benefits from doing this, however I am asking for informational purposes.
Thanks!
Waldek,
Have you enabled connection tracking for the relevant
bridge/VLANs/tunnels, etc. that pass traffic (as this is disabled by
default on some systems for non-masqueraded traffic)?
In addition, is your default iptables forwarding policy REJECT or DROP,
instead of ACCEPT?
73,
Lynwood
KB3VWG
That "Requesting a Block" page has a lot of personal opinion it and also contains directives that may
be valid for some regions but not for others. This already starts with the first line.
Here in the Netherlands we don't use the portal for requesting blocks, only for registering blocks that are to be
used for IPIP tunnels. So requesting a block does not start with the portal, but with mailing a request for a block
to me and allocation of the block in the hostsfile for 44.137.0.0/16 followed by updating the DNS via the robot.
Once that is done, it can optionally be registered in the portal. I recommend users not to do this unless they
want to setup a gateway, because registered subnets that are not claimed by a gateway are up for grabs by
other gateway operators, and given that we have widely varying skills among out users it has repeatedly happened
that users (who often not even understand what it means and requires to run an IPIP gateway) create a gateway
entry and add someone else's subnet to it by mistake. This then cannot be corrected by either the owner of
the subnet or the coordinator of the IP space. It requires a "contact the portal admin" form entry to correct it
and that may take a long time to be acted upon. (I still have two open requests of that type)
I also don't agree with the "don't waste space" adagium. I allocate whatever is required for the experiment,
and now that we are using BGP internally on the radio network, that also includes /30 and /29 networks for
point-to-point links (/30 for links with only a router at each end, /29 when it is desired to have AP managment
addresses). Unlike on the internet, we have no lack of IPv4 space on AMPRnet!
There is no point in using RFC1918 addresses for this, and it causes problems with ICMP messages returned
from those routers, e.g. when using traceroute. I also don't agree with "an ISP uses unroutable addresses for
routers". Maybe some ISPs do that, but probably most do not.
About RFC1918 filtering: YES, everyone should filter RFC1918 addresses at every entry and exit into the network.
There are many configuration mistakes in ham networks, and I often see log results on those filters (which I
have configured with logging on our gateway). RFC1918 addresses come in via IPIP tunnels from all over the
world and also from radio. Of course it requires detailed knowledge of networking, policy routing, and NAT rules
to get a mixed net44/rfc1918 LAN correctly connected to AMPRnet (with NAT or blocking for the RFC1918 systems)
and let's face it: many users simply don't have that knowledge and are just trying.
So, everyone else should filter that traffic so that at least it does not get propagated far. I sometimes send mail
to repeat offenders and they often promise me that they will look at it, but it rarely stops completely.
Rob
> I have use tcpdump to check how working iptables
> I have try block this traffic by
> but not working for me
Again: you can NOT test it this way!
tcpdump will show you all packets even when you are dropping them in the filter.
I know this is sometimes a nuisance. It is difficult to test if your filters are working.
When your filter has the structure of:
- some packets dropped
- some other packets dropped
- more packets dropped
- all remaining packets accepted
(note that this is normally not a preferred structure of your blocklist)
you can work around it by inserting a rule like this just before the last ACCEPT rule
(or at the end of the table when the default setting is ACCEPT, again not a preferred situation):
iptables -A INPUT -i tunl0 -j NFLOG --nflog-group 44
This will send the packets to a "netfilter logging" interface where you can trace it with:
tshark -i nflog:44
(I don't think tcpdump supports dumping nflog interfaces but this may depend on version)
The result of this is that all packets that have already been dropped above that rule will
not reach the NFLOG target and will not be traced when you trace nflog:44.
However, it is normally preferred to work with a "default drop" setup. You accept all
packets that you know you want to accept, and drop everything else at the end of the table.
This makes it less likely that things pass by that you did not think about, like other
protocols than TCP and UDP.
It is still possible to have NFLOG logging of everything that is accepted, by first
creating a helper table like this:
iptables -N NFLOGACCEPT
iptables -A NFLOGACCEPT -j NFLOG --nflog-group 44
iptables -A NFLOGACCEPT -j ACCEPT
Then you setup your filter table like this:
iptables -A INPUT -i tunl0 -..... -j NFLOGACCEPT
iptables -A INPUT -i tunl0 -..... -j NFLOGACCEPT
iptables -A INPUT -i tunl0 -j DROP
Rob
> I have try block non 44/8 traffic via tunnel IPIP with iptables but without
> success
> I have use ampr-ripd to create port 'tunl0'
> I have add to firewall rule:
> iptables -A INPUT -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP
> iptables -A FORWARD -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP
> but I have still a lot of traffic via tunl0 non 44/8 ip address and it is
> look like this not working for me
How did you validate that you still have the traffic?
Does such traffic still reach an open port on your system or a system behind it?
E.g. when you have telnet or ssh running, can you still telnet or ssh from internet?
Note that using a trace tool like "tcpdump" or "tshark/wireshark" is NOT a valid way
of testing of those filters work!
When you do "tshark -i tunl0" with the above filters in place, you will still see the traffic.
This is because tshark and tcpdump trace the real traffic on those interfaces BEFORE the filters
have been applied.
Rob
Hi
I have try block non 44/8 traffic via tunnel IPIP with iptables but without
success
I have use ampr-ripd to create port 'tunl0'
I have add to firewall rule:
iptables -A INPUT -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP
iptables -A FORWARD -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP
but I have still a lot of traffic via tunl0 non 44/8 ip address and it is
look like this not working for me
I have add one more rule like where eth0 is my internet port
iptables -A OUTPUT -o eth0 -s 44.0.0.0/8 -j DROP
and it is help me to not send to internet 44/8 ip traffic but I would like
block incoming non 44/8 IP address via tunnel
--
Waldek sp2ong
It appears the the iptables rule is incorrect.
In my previous configuration I had a border device NATing to a
downstream device running as my AMPRNet Gateway. When I first set it up,
I had THE EXACT SAME ISSUE YOU ARE EXPERIENCING. I could only receive
packets after first initiating them. When asking for advice, I continued
to receive information that the iptables rules were correct...
THEY WERE NOT!!!
Why???
As you are receiving this traffic the router interface, IT IS CONSIDERED
INPUT since there are no routing rule to forward the packet (this is
only done the subsequent DNAT rule added to the iptables firewall).
This is an example from my DD-WRT device when I DNATed to a IPIP gateway
downstream (so, this is a known working configuration):
# iptables -t filter -I INPUT -p 4 -i eth0.1 -j ACCEPT
# iptables -t nat -I PREROUTING -p 4 -i eth0.1 -j DNAT --to-destination
192.168.0.11
Further, on the INPUT rule, you could use the -d argument and the IP
address if your WAN interface has a static address.
Also, after I added this rule to my device, the issue Rob describes
doesn't occur (except when I explicitly added a rule to block Pings).
73,
- Lynwood
KB3VWG
> It is behind my ISP cable modem, I had to get it setup in bridging mode
> after the last time they upgraded it. My router is showing all the
> tunnel traffic (via tcpdump) so I'm fairly certain the modem isn't the
> issue.
Ok. I heard before from other members of this group that they had a similar
setup, yet I was never able to ping them unless they first pinged me.
> Central to my confusion at the moment is the rule in the nat PREROUTING
> isn't counting packets.
Remember that iptables NAT processing in Linux is stateful. It only sees
"new" traffic for a connection. Once a connection is in the NAT table, the
traffic goes "around" those rules much like Established/Related traffic in
the filter tables, but without an explicit visible rule for that purpose.
So, when you ping outward over a tunnel, you will not see those rules matching
yet the traffic is forwarded as reply to your outgoing pings.
Only when you ping from somewhere else, those rules are going to be of influence.
But of course they only see traffic when it actually arrives on your router.
Rob
> The latest reboot had me digging deeper to try to find the real problem
> and I have discovered that only the rule in FORWARD chain of the filter
> table is firing, not the DNAT in the nat table. I suspect the firewall
> is only working when some connection (outgoing ?) wakes up the
> masquerade rules but haven't actually found the rule that is active.
Are you sure the OpenWRT box is actually seeing the incoming packets?
Is it directly on the internet, or is there another box before it, e.g. an ISP
provided modem/router?
Even though you might have forwarded the protocol or even set the OpenWRT
box as the "DMZ device", it may still do stateful firewalling on non-TCP/UDP
protocols. That is a known problem with NAT routers.
Try to run a trace on the OpenWRT box to verify that you can receive IPIP
traffic from sources that you have not recently contacted with outgoing
traffic.
Rob
> I think with much larger address space and the availability of /56 or
> larger spaces for many connections means many of us already have excess,
> the second approach is worth investigating. Come up with DNS management
> and a system for automatically configuring AMPRNET6 routers to share
> trust information to tie the network together securely. As I said
> before, I could easily allocate part of my /56 to this project. I'm
> using less than 1% of my address range (1/256th to be exact :) ).
Address space is not an issue with IPv6. Everyone here gets a /48 with their
home internet connection. I use only 3/65536 of mine :-)
For a "global IPv6 space for amprnet" we would get a /32 and map it 1:1
with the existing net-44 addresses. That will give every net-44 IP user a
/56 network on IPv6.
However, I too don't think is the way to go. Just use the space you get on
your own internet connection for your own purposes on AMPRnet (and nag the
ISP when they don't provide IPv6, give you only a /128 or /64, or assign
dynamic prefixes - bad concepts in IPv6 rollout!).
Extend the current DNS server and robot with AAAA records, and find or design
some method of sharing the prefix list. Could be done using a BGP server.
(not the internet BGP but a server on AMPRnet that distributes prefixes)
Then we can interconnect on internet without the hassle we have now, and still
are able to route the same addresses over wireless networks.
Rob
Hello,
I seem to have something broken on my firewall for redirecting incoming
ipip packets to my gateway box. It appears to work fine at times but
fails periodically, typically after a reset/power failure. Usually it
comes back after several reboots of firewall and router but this process
is inconsistent.
The latest reboot had me digging deeper to try to find the real problem
and I have discovered that only the rule in FORWARD chain of the filter
table is firing, not the DNAT in the nat table. I suspect the firewall
is only working when some connection (outgoing ?) wakes up the
masquerade rules but haven't actually found the rule that is active.
The firewall is running on OpenWRT using iptables (old version 1.3.8)
and the rules as I think they should work are
## for ampr.org tunnels
iptables -t nat -I PREROUTING -p 4 -i eth0.1 -j DNAT \
--to-destination 192.168.99.66
iptables -t filter -I FORWARD -p 4 -i eth0.1 -j ACCEPT
As I understand it, the first re-writes the destination for ipip packets
to my gateway and the second allows them to be forwarded however the
counter on first stays stuck at 0.
A reference to what sounds like a similar problem:
https://sourceforge.net/p/ipcop/mailman/message/17780204/
It would be really nice to get this sorted properly, any debugging hints
appreciated. In particular, am I correct in expecting both rule counters
to match ?
thx ...
... Niall
Hi folks,
I have a /29 subnet allocated and have been with interconnecting a few systems but want to expand that connectivity to other systems round the world.
Last time I experimented with amprnet was 15 years ago and I had a ipip tunnel to a packet node that also had amprnet connectivity. That node is long gone so looking for something else to use.
Reading info on the wiki, it sounds like I can now use rip and connect via the UCSD router. Have I under stood this correctly?
Any idiot guides out there on how to do this or any suggestions on other ways I can connect to a gateway?
Thanks
Jon
M1CQO
I'm unable to attend the 2016 TAPR DCC next month in St Petersburg
Florida. If anyone on this mailing list is going to be there, could
you please let us know the substance of any discussions relevant
to the AMPRNet.
Thank you.
- Brian
Hello,
I know the people on this maillist work on the real internet infrastructure types of networks,
but I was wondering if anyone thought an overlay network, such as CJDNS [1],
that uses cryptographic-generated addressing to ensure an FC::/8 address corresponds to a public certificate.
would be more practical for everyday hams who only have a behind-the-ISP or dynamic IP connection to the internet.
[1] https://en.wikipedia.org/wiki/Cjdns
!!Dean
KC4KSU
> It's frustrating when one has deployed IPv6 and has to keep battling
> with the evils of NAT. :/
But we have a large IPv4 space available so why would we battle with NAT???
It should not be a problem to get an IPv4 address from net-44 for any of your
experiments and not have to use NAT.
Not that I am against experimenting with IPv6, but I am not sure which way
that should go:
- somehow get an "own" IPv6 range that we can manage in a similar way as
the net-44 space
- just use the IPv6 space everyone can get from their local provider and
have only DNS support for it in ampr.org and maybe some service for listing
of prefixes in use on ampr hosts to be used in firewall address lists.
Having an own range appears nice, but it means we will again have the problems with
internet tunneling and BGP routing that we are having now.
Rob
I have replaced my cisco with mikrotik
the ipip works ok
i have two questions (for time being)
1) how do i synchronize the time ? do i need to install ntp client ? i see no ntp under the system in the gui window
2) i want to run the routing script that Marius wrote but it say it need a password ? what is the password for ? how do i get it ?
Thanks forward
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
Hi there
when Connecting amprnet via openvpn
is it limited to USA only users ?
what is the IP the one that connect get ? is it a special IP assigned for the vpn server ? or the user get his country IP allocation ...and can a block of ip pass ? or only single ip ?
What PC software can be used ? or only linux supported ?
thanks forward
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
Because many of the people on this list run Linux, I mention
the following article:
http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_comm…
"Linux security backfires: Flaw lets hackers inject malware into downloads, disrupt Tor users, etc"
If you're running Linux kernel 3.6 or later and your system is
exposed to the internet, this is something you should consider
taking care of.
- Brian
Hello,
I have some problem with requesting an alocatation block.
I sent two alocation request on portal.ampr.org on 44.181.0.0/16 (Slovakia)
one week ago.
My requests are still in "waiting for coordinator" status.
I tried to send "Contact us" message to portal two day ago, but my request
is without changes.
I am not sure that my coordinator is active on portal.
Please, Who can help me with this issue, or give advice, or some mail
contact.
Is possible to activate some subregion block witout my inactive coordinator
to me ?
Thanks.
73, Marcel OM0ATE
Hello,
I had a problem to let rip44d after an OpenWrt Chaos Calmer 15.05, but was
dropped dmz traffic ipencap 169.228.66.251 not passed to the second
router.
In openwrt menu: Network -> Firewall -> Custom Rules
I add:
---
iptables -A INPUT -p 4 -j ACCEPT
iptables -A INPUT -p udp --dport 520 -j ACCEPT
iptables -t nat -A PREROUTING -p 4 -j DNAT --to 192.168.1.2
---
192.168.1.2 is ip of second router or 44 gateway with rip44d
After adding these lines and reboot the router all problems are corrected.
Let's hope it will be useful.
73, Miro, LZ4NY
-------------------------------------
P.S Вместо да разпитваш приятели и познати как се прави онлайн магазин, тествай безплатно 14 дни Shopiko – за да започнеш да продаваш.
https://www.superhosting.bg/web-hosting-compare-shop-plans.php?utm_source=M…
[Apologies for the repost: I meant to have a useful Subject:
header and accidentally omitted that earlier.]
[Forgive the top-posting: I include the full text of what I'd
written several weeks ago below for refresher and reference.]
To recap, I've set up IPENCAP tunnels to AMPRNet networks on a
Ubiquiti EdgeRouter Lite running OpenBSD: there is one gif(4)
interface per tunnel and routes are kept in a dedicated routing
table (like Linux, OpenBSD supports multiple routing domains on a
single system); firewall rules are used to go from one routing
domain to another.
The biggest piece missing was a daemon to handle receiving 44net
RIP packets and use that data to maintain tunnels and routes. I
thought about porting one, but decided of write my own instead.
It has been running for a few weeks now on my node and while it's
still not quite "done" it seems to work well enough that I decided
it was time to cast a somewhat a wider net and push it up to
GitHub for comment from others.
A couple of quick notes on implementation:
1. The program maintains a copy of the AMPRNet routing table in
a modified PATRICIA trie (really a compressed radix tree).
Routes are expired after receiving a RIP packet.
2. A similar table of tunnels is maintained.
3. Tunnel interfaces are reference counted and garbage collected.
A bitmap indicating which tunnels are in use is
maintained.
4. The program is completely self-contained in the sense that I
do not fork/exec external commands to e.g. configure tunnels
or manipulate routes. That is all done via ioctls or writing
messages to a routing socket.
There is more to do; I'm sure there are a few bugs. I'd also like
to query the system state at startup to initialize the routing and
tunnel tables. Exporting and/or parsing an encap file would be
nice. Logging and error checking can, I'm sure, be improved.
It's about 1200 lines of non-comment code, compiles down to a 28K
MIPS64 executable (stripped). The code is at
https://github.com/dancrossnyc/44ripd
Please have a look and let me know what you think!
- Dan C.
On Fri, Jun 17, 2016 at 5:46 PM, Dan Cross <crossd(a)gmail.com> wrote:
> On Tue, Jun 14, 2016 at 12:51 PM, Dan Cross <crossd(a)gmail.com> wrote:
> > I'm trying to set up an AMPRNet gateway at home and am running into
> > some problems. Has anyone successfully configured a BSD-based gateway
> > that would be willing to give me some pointers?
> >
> > [snip]
> >
> > It seems like what I want to do is configure a gif(4) interface
> > for tunnel traffic, but my attempts at doing so all seem to fail,
> > and documentation for setting up an IPENCAP tunnel is related to
> > setting up IPsec gateways; my attempts at transliterating from the
> > examples for e.g. Linux and Cisco et al have failed.
> >
> > If someone has gone down this road before and has a working
> > setup, that would be tremendously helpful. If someone could send
> > me output from 'ifconfig -a' and/or 'netstat -rn -f inet' and
> > possibly some 'tcpdump' output, I could probably muddle through the
> > rest. If there are any caveats in setting up a 'pf' based firewall,
> > that would be helpful as well. If not, I suppose my next step will
> > be to reinstall RouterOS on the ERL, try and get everything configured,
> > and then see if I can replicate under BSD.
>
> Folks,
>
> I just wanted to do a quick followup to this for the archives.
> I am now successfully transferring traffic between my 44net subnet
> (44.44.107.0/24) and the rest of the world using my OpenBSD-based
> router.
>
> A quick recap of my setup:
> 1. I have a Comcast business class circuit.
> 2. I have a dedicated static IP address to use as an endpoint for
> 44net traffic.
> 3. My comcast router is just a router; no NATing, no firewalling.
> 4. My (non-comcast) edge router is a Ubiquiti EdgeRouter Lite
> running OpenBSD 5.9. It has three ethernet interfaces:
> a. cnmac0 is the external interface connected to Comcast's network
> b. cnmac1 connects to my internal network
> c. cnmac2 is my internal gateway to 44.44.107.0/24.
>
> On OpenBSD, tunneling interfaces for IPENCAP are provided by
> 'gif' pseudo-devices. Unlike Linux, it appears that one creates a
> separate 'gif' interface for each tunnel, but one seems able to
> create an arbitrary number of such interfaces: I created a thousand
> as a test. I'm sure there is a limit but it seems sufficiently
> high that practically routing AMPRNet traffic won't run up against
> it. (Again, if someone knows of a different way to configure a
> single 'gif' interface so that it could support multiple tunnels,
> I'd be happy to know about it). In other words, don't worry about
> scalability because you are creating a separate 'gif' interface for
> each tunnel to another AMPRNet site.
>
> On AMPRNet, the UCSD gateway *will not* pass traffic for an
> IP address that does not have a corresponding entry in the AMPR.ORG
> domain. Also, 44.0.0.1 does not respond to 'ping' from 44/8 IP's.
> Caveat emptor as one tries to test: make sure you have DNS entries
> for your addresses and try pinging something other than 44.0.0.1
> or you'll suffer contusions banging your head against a desk trying
> to figure out why nothing appears to work....
>
> Once I had a tunnel up to UCSD, I found that I could ping my
> 44.44.107.1 machine from a host on my internal network, but not
> from arbitrary machines. This was interesting; it turns out that
> hosts on my internal network get NAT'ed to another IP address on
> the small subnet I got from Comcast (through another, completely
> separate router -- not comcast's router but another ERL). What was
> happening was that as I ping'ed 44.44.107.1 from e.g. my laptop,
> ICMP echo request packets got NAT'ed to this other address and
> routed over to amprgw.sysnet.ucsd.edu and tunneled back to the
> external interface of my AMPRNet gateway. The gateway accepted the
> encapsulated ICMP echo requests (I have a PF rule that explicitly
> allows ping) and forwarded them across the tunnel interface where
> they were unencapsulated; the IP stack saw that the result was
> addressed to an IP address on a local interface (i.e., they were
> for the router) and generated an ICMP echo response packet with a
> *source* address of 44.44.107.1 and a *destination* address of the
> external address of my other router (that is, the address the ICMP
> echo request was NAT'ed to). This matched the network route for
> my local Comcats subnet and so my AMPRNet router realized it could
> pass the packet back to my other router directly. It did so and
> the other router happily took the packet, matched it back through
> the NAT back to the original requesting machine (my laptop) and
> forwarded it: hence, I got my ping responses back. But note that
> the response was not going through the tunnel back to UCSD: it was
> being routed directly through the external interface.
>
> Now consider what happens when I tried to ping 44.44.107.1 from
> a different machine on some other network. The ICMP echo request
> packet gets routed through the UCSD gateway and tunneled back to
> my gateway as before, but since responses don't go through back
> through the tunnel, the response packet matches the default route
> of my gateway and get's forwarded to comcast's router. Comcast
> would look at it, see that 44.44.107.1 wasn't on one of it's known
> networks that it would route floor, and discard the response. Oops.
>
> The solution was to set up a separate routing table in a different
> routing domain specifically for AMPRNet traffic, and tie the two
> together using firewall rules. In the AMPRNet routing table, I
> could set my default route to point to the UCSD gateway, so any
> traffic sent from one of my 44.44.107.0/24 addresses that doesn't
> match a route to a known tunnel gets forwarded through
> amprgw.sysnet.ucsd.edu. With that in place, I could ping my gateway
> from random machines. This must seem obvious to a lot of folks
> here, but it took me a little while to figure out what was going
> on. Things are working now, however.
>
> So far I have encountered two other caveats: I decided to
> configure two tunnel interfaces statically at boot time: 'gif0'
> goes to the UCSD tunnel, and 'gif1' sets up a tunnel to N1URO for
> his 44.88 net. Under OpenBSD, I assumed that the natural way to
> do this would be to add /etc/hostname.gif0 and /etc/hostname.gif1
> files and this does in fact create the tunnels at boot time. However,
> traffic going out from my gateway doesn't seem to get sent through
> the tunnels; I did not bother to track down exactly why, but I
> believe it has to do with some kind of implicit ordering dependency
> when initializing PF. When I set up the separate routing domain,
> it struck me that the language accepted by /etc/netstart in an
> /etc/hostname.if file was not sufficiently rich to set up tunnels
> in a routing domain, so I capitulated and just set up the static
> interfaces from /etc/rc.local; imperfect but it works.
>
> The second caveat is that I seem to have tickled a kernel error
> trying to set up an alias of a second IP address on my 44.44.107.1
> NIC; I get a kernel panic due to an assertion failure. It looks a
> bug to me, but I haven't had the bandwidth to track it down. In
> the meanwhile, simply don't add aliases to interfaces in non-default
> routing domains.
>
> I'll try to go through my notes and type up something for the
> wiki.
>
> The next step is to write a modified version of rip44d for BSD.
> I may take a stab at that this weekend if I can get some time. As
> near as I can tell, the wire format of the protocol is strictly
> RIPv2; the difference is what the gateway does with the data in the
> RIP packet (it sets up tunnels in addition to maintaining routes).
>
> Anyway, I hope this can be of some small help to someone else
> who wants to run an OpenBSD-based gateway!
[Forgive the top-posting: I include the full text of what I'd
written several weeks ago below for refresher and reference.]
To recap, I've set up IPENCAP tunnels to AMPRNet networks on a
Ubiquiti EdgeRouter Lite running OpenBSD: there is one gif(4)
interface per tunnel and routes are kept in a dedicated routing
table (like Linux, OpenBSD supports multiple routing domains on a
single system); firewall rules are used to go from one routing
domain to another.
The biggest piece missing was a daemon to handle receiving 44net
RIP packets and use that data to maintain tunnels and routes. I
thought about porting one, but decided of write my own instead.
It has been running for a few weeks now on my node and while it's
still not quite "done" it seems to work well enough that I decided
it was time to cast a somewhat a wider net and push it up to
GitHub for comment from others.
A couple of quick notes on implementation:
1. The program maintains a copy of the AMPRNet routing table in
a modified PATRICIA trie (really a compressed radix tree).
Routes are expired after receiving a RIP packet.
2. A similar table of tunnels is maintained.
3. Tunnel interfaces are reference counted and garbage collected.
A bitmap indicating which tunnels are in use is
maintained.
4. The program is completely self-contained in the sense that I
do not fork/exec external commands to e.g. configure tunnels
or manipulate routes. That is all done via ioctls or writing
messages to a routing socket.
There is more to do; I'm sure there are a few bugs. I'd also like
to query the system state at startup to initialize the routing and
tunnel tables. Exporting and/or parsing an encap file would be
nice. Logging and error checking can, I'm sure, be improved.
It's about 1200 lines of non-comment code, compiles down to a 28K
MIPS64 executable (stripped). The code is at
https://github.com/dancrossnyc/44ripd
Please have a look and let me know what you think!
- Dan C.
On Fri, Jun 17, 2016 at 5:46 PM, Dan Cross <crossd(a)gmail.com> wrote:
> On Tue, Jun 14, 2016 at 12:51 PM, Dan Cross <crossd(a)gmail.com> wrote:
> > I'm trying to set up an AMPRNet gateway at home and am running into
> > some problems. Has anyone successfully configured a BSD-based gateway
> > that would be willing to give me some pointers?
> >
> > [snip]
> >
> > It seems like what I want to do is configure a gif(4) interface
> > for tunnel traffic, but my attempts at doing so all seem to fail,
> > and documentation for setting up an IPENCAP tunnel is related to
> > setting up IPsec gateways; my attempts at transliterating from the
> > examples for e.g. Linux and Cisco et al have failed.
> >
> > If someone has gone down this road before and has a working
> > setup, that would be tremendously helpful. If someone could send
> > me output from 'ifconfig -a' and/or 'netstat -rn -f inet' and
> > possibly some 'tcpdump' output, I could probably muddle through the
> > rest. If there are any caveats in setting up a 'pf' based firewall,
> > that would be helpful as well. If not, I suppose my next step will
> > be to reinstall RouterOS on the ERL, try and get everything configured,
> > and then see if I can replicate under BSD.
>
> Folks,
>
> I just wanted to do a quick followup to this for the archives.
> I am now successfully transferring traffic between my 44net subnet
> (44.44.107.0/24) and the rest of the world using my OpenBSD-based
> router.
>
> A quick recap of my setup:
> 1. I have a Comcast business class circuit.
> 2. I have a dedicated static IP address to use as an endpoint for
> 44net traffic.
> 3. My comcast router is just a router; no NATing, no firewalling.
> 4. My (non-comcast) edge router is a Ubiquiti EdgeRouter Lite
> running OpenBSD 5.9. It has three ethernet interfaces:
> a. cnmac0 is the external interface connected to Comcast's network
> b. cnmac1 connects to my internal network
> c. cnmac2 is my internal gateway to 44.44.107.0/24.
>
> On OpenBSD, tunneling interfaces for IPENCAP are provided by
> 'gif' pseudo-devices. Unlike Linux, it appears that one creates a
> separate 'gif' interface for each tunnel, but one seems able to
> create an arbitrary number of such interfaces: I created a thousand
> as a test. I'm sure there is a limit but it seems sufficiently
> high that practically routing AMPRNet traffic won't run up against
> it. (Again, if someone knows of a different way to configure a
> single 'gif' interface so that it could support multiple tunnels,
> I'd be happy to know about it). In other words, don't worry about
> scalability because you are creating a separate 'gif' interface for
> each tunnel to another AMPRNet site.
>
> On AMPRNet, the UCSD gateway *will not* pass traffic for an
> IP address that does not have a corresponding entry in the AMPR.ORG
> domain. Also, 44.0.0.1 does not respond to 'ping' from 44/8 IP's.
> Caveat emptor as one tries to test: make sure you have DNS entries
> for your addresses and try pinging something other than 44.0.0.1
> or you'll suffer contusions banging your head against a desk trying
> to figure out why nothing appears to work....
>
> Once I had a tunnel up to UCSD, I found that I could ping my
> 44.44.107.1 machine from a host on my internal network, but not
> from arbitrary machines. This was interesting; it turns out that
> hosts on my internal network get NAT'ed to another IP address on
> the small subnet I got from Comcast (through another, completely
> separate router -- not comcast's router but another ERL). What was
> happening was that as I ping'ed 44.44.107.1 from e.g. my laptop,
> ICMP echo request packets got NAT'ed to this other address and
> routed over to amprgw.sysnet.ucsd.edu and tunneled back to the
> external interface of my AMPRNet gateway. The gateway accepted the
> encapsulated ICMP echo requests (I have a PF rule that explicitly
> allows ping) and forwarded them across the tunnel interface where
> they were unencapsulated; the IP stack saw that the result was
> addressed to an IP address on a local interface (i.e., they were
> for the router) and generated an ICMP echo response packet with a
> *source* address of 44.44.107.1 and a *destination* address of the
> external address of my other router (that is, the address the ICMP
> echo request was NAT'ed to). This matched the network route for
> my local Comcats subnet and so my AMPRNet router realized it could
> pass the packet back to my other router directly. It did so and
> the other router happily took the packet, matched it back through
> the NAT back to the original requesting machine (my laptop) and
> forwarded it: hence, I got my ping responses back. But note that
> the response was not going through the tunnel back to UCSD: it was
> being routed directly through the external interface.
>
> Now consider what happens when I tried to ping 44.44.107.1 from
> a different machine on some other network. The ICMP echo request
> packet gets routed through the UCSD gateway and tunneled back to
> my gateway as before, but since responses don't go through back
> through the tunnel, the response packet matches the default route
> of my gateway and get's forwarded to comcast's router. Comcast
> would look at it, see that 44.44.107.1 wasn't on one of it's known
> networks that it would route floor, and discard the response. Oops.
>
> The solution was to set up a separate routing table in a different
> routing domain specifically for AMPRNet traffic, and tie the two
> together using firewall rules. In the AMPRNet routing table, I
> could set my default route to point to the UCSD gateway, so any
> traffic sent from one of my 44.44.107.0/24 addresses that doesn't
> match a route to a known tunnel gets forwarded through
> amprgw.sysnet.ucsd.edu. With that in place, I could ping my gateway
> from random machines. This must seem obvious to a lot of folks
> here, but it took me a little while to figure out what was going
> on. Things are working now, however.
>
> So far I have encountered two other caveats: I decided to
> configure two tunnel interfaces statically at boot time: 'gif0'
> goes to the UCSD tunnel, and 'gif1' sets up a tunnel to N1URO for
> his 44.88 net. Under OpenBSD, I assumed that the natural way to
> do this would be to add /etc/hostname.gif0 and /etc/hostname.gif1
> files and this does in fact create the tunnels at boot time. However,
> traffic going out from my gateway doesn't seem to get sent through
> the tunnels; I did not bother to track down exactly why, but I
> believe it has to do with some kind of implicit ordering dependency
> when initializing PF. When I set up the separate routing domain,
> it struck me that the language accepted by /etc/netstart in an
> /etc/hostname.if file was not sufficiently rich to set up tunnels
> in a routing domain, so I capitulated and just set up the static
> interfaces from /etc/rc.local; imperfect but it works.
>
> The second caveat is that I seem to have tickled a kernel error
> trying to set up an alias of a second IP address on my 44.44.107.1
> NIC; I get a kernel panic due to an assertion failure. It looks a
> bug to me, but I haven't had the bandwidth to track it down. In
> the meanwhile, simply don't add aliases to interfaces in non-default
> routing domains.
>
> I'll try to go through my notes and type up something for the
> wiki.
>
> The next step is to write a modified version of rip44d for BSD.
> I may take a stab at that this weekend if I can get some time. As
> near as I can tell, the wire format of the protocol is strictly
> RIPv2; the difference is what the gateway does with the data in the
> RIP packet (it sets up tunnels in addition to maintaining routes).
>
> Anyway, I hope this can be of some small help to someone else
> who wants to run an OpenBSD-based gateway!
Can the person who maintains the "Services" page contact me offlist
please? Thanks much.
--
I was going to go see a Guns 'n' Roses concert...
until the liberals took away ALL the guns. Now I'm
only going to see Roses *sigh*
-----
73 de Brian - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, New Jersey, Pennsylvania,
Rhode Island, and Vermont.
> That is when all work fine without errors
> but before you have to grab all the gcc enviourment into the PI
That is done with this single command:
apt-get install build-essential
Maybe you need to type: sudo apt-get install build-essential
(when you are logged in as user pi)
> I know how hard it was to More experts from me to compile for me the Firmware for the arduino
Sometimes these things are hard, but not in the case of ampr-ripd.
And when you don't try, you'll never learn...
Rob
Hi Fellows
Since compiling is hard task for me
Is it possible to take from a working PI the RipD and run it on my pi ? or the only solution is to compile ?
I know on Unix some programs can run when taken from another systems ...
If that can be done where can I get the RIPD executable ?
Thanks Forward
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
> Hi Fellows
> Since compiling is hard task for me
Incredible...
To compile it, you only need to type: make
To install it, you only need to type: make install
Rob
Hi there
Since yesterday I have a Raspberry Pi unit connected to Arduino doing MMDVM (a project that allow making digital repeater from two analog radios)
I know that a Gateway can be done with raspberry Pi
1) What exactly needed to be done (some software to add to what i have now ?) in order to deal with IPIP and make a gateway ?
can it run on RASPIAN ?
2) what about making TNC from Raspberry ? i know thare is a board that stick to it and make TNC ... Or (preferred) using the Internal sound card for making TNC ?
can this be done on Raspian ? and where can i get info how to do it ?
Thanks For any Info
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
Hi,
I'm trying to get an allocation of IPs (a /28) for some projects here.
The /28 is to be split between the LAN (and perhaps HSMM type wifi), and
more traditional low speed RF (i.e. 2 /29s). Looking through the
Australian lists, there were no existing regions within VHF range of
here that I could see (I'm in Bendigo, central Victoria).
Anyway, I applied over 2 weeks ago and haven't heard anything, just
wondering what the normal wait time is.
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
think the English language is not a problem for the Belgian coordinator but that person is too busy it seems to me it is what emerges from
the last conversation that date two year with him
what to do to restore our 44net now ???
vy73s
André ON4HU
http://on4hu.dyndns.org:81/http://www.on4hu.com/http://www.on4hu.eu
ftp://ftp.on4hu.be/ ou ftp://on4hu.dyndns.org/http://on4hu.eu/
COMPUTERS ARE LIKE AIR-CONDITIONERS THEY STOP WORKING
PROPERLY AS SOON AS YOU OPEN WINDOWS.
Coordinateurr for Bekgium NEVER answer deAR Ludovic, i have no contact wIth
44net from more than one year now, our Begium Coordinateur answer ONLY with
Flemich people and never with French and do not understood our language
André ON4HU
http://on4hu.dyndns.org:81/http://www.on4hu.com/http://www.on4hu.eu
ftp://ftp.on4hu.be/ ou ftp://on4hu.dyndns.org/http://on4hu.eu/
COMPUTERS ARE LIKE AIR-CONDITIONERS THEY STOP WORKING
PROPERLY AS SOON AS YOU OPEN WINDOWS.
> I try to contact him before i create the "44.151belgium subnet" and no
> anwer.
> ON3LA, ON3LX and ON2CQ had no answer too...
O dear... my fears I would get in a similar situation as with PJ2 are becoming true...
Yesterday I sent an e-mail in Dutch (should be close enough to Flemish) to the address
Brian mentioned, but I have heard nothing yet. I'll try to contact someone who knows
people active in the network there (which is quite widely deployed).
Rob
Is anyone aware of the procedure to allocate addresses in Belgium?
I entered a request on the Portal a month ago, but got no reply.
Is there some website that explains a local procedure?
(like my site for the Netherlands)
Rob
> Your portal request should have gone to Robbie,on4sax at on4sax.be <http://hamradio.ucsd.edu/mailman/listinfo/44net>
> Perhaps you could write to him and see what's going on.
> - Brian
Yes I saw he is the contact for that range, but obviously he got my request by e-mail
on that same address. So I wonder if there is another method in use there.
(e.g. I still process IP allocation requests on my amsat.org mail, and in other countries
in EU it is sometimes done via hamnetdb.net)
Any users from ON on the list? Hopefully the situation does not turn out to be similar
as in PJ2 :-) (but that one is now allocated and working well)
Rob
Dear Folks,
I'm trying to set up an AMPRnet gateway at home and am running into
some problems. Has anyone successfully configured a BSD-based gateway
that would be willing to give me some pointers?
Some details of my setup:
* I have a comcast business-class circuit with a static IP address that
I've dedicated to 44net traffic (23.30.150.141).
* I have an AMPRnet network allocation (44.44.107.0/24).
* The Comcast router is configured as simply a router: all NATing and
firewalling is disabled and I can see tunneled traffic arriving at the
external NIC of my (non-comcast) router (specifically, I see RIPv2
packets with 44net routing information in them).
* My "real" router is a Ubiquiti EdgeRouter Lite running OpenBSD 5.9. I
have the three ethernet interfaces on the ERL configured as follows:
cnmac0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
lladdr 44:d9:e7:9f:a7:64
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 23.30.150.141 netmask 0xfffffff8 broadcast 23.30.150.143
cnmac1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 44:d9:e7:9f:a7:65
priority: 0
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 192.168.129.4 netmask 0xffffff00 broadcast 192.168.129.255
cnmac2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 44:d9:e7:9f:a7:66
priority: 0
media: Ethernet autoselect (none)
status: no carrier
inet 44.44.107.1 netmask 0xffffff00 broadcast 44.44.107.255
Where I'm getting tripped up is in figuring out where to go
from here.
It seems like what I want to do is configure a gif(4) interface
for tunnel traffic, but my attempts at doing so all seem to fail,
and documentation for setting up an IPENCAP tunnel is related to
setting up IPsec gateways; my attempts at transliterating from the
examples for e.g. Linux and Cisco et al have failed.
If someone has gone down this road before and has a working
setup, that would be tremendously helpful. If someone could send
me output from 'ifconfig -a' and/or 'netstat -rn -f inet' and
possibly some 'tcpdump' output, I could probably muddle through the
rest. If there are any caveats in setting up a 'pf' based firewall,
that would be helpful as well. If not, I suppose my next step will
be to reinstall RouterOS on the ERL, try and get everything configured,
and then see if I can replicate under BSD.
Much thanks in advance! 73 de AC2OI,
- Dan C.
> Has anyone else noted problems with the ethernet alias functionality in
> recent Linux kernels ? I've just done an update on my tunnel server
> (pogoplug E02 running Debian 8 with kernel 4.4.0-kirkwood) and within a
> day or so the 44net alias disappears. Nothing I can see in any of the
> logs. Replacing the alias via 'ip addr add 44.135.190.17/32 dev eth0:1'
> is enough to fix it, might have to hack into a cron job :-/R
Why are you still using ethernet aliases? This was originally a hack to
be able to have multiple IP addresses on a single interface (using ifconfig)
but since the introduction of the iproute2 package (which you apparently use,
as it provides the "ip" command) this is really not required anymore.
You can add addresses to eth0 without making an eth0:1 alias first.
Rob
> In any case, your subnet will be connected to the Internet by at most
> ONE method: Radio, Tunnel, or Direct, and might not be connected at all,
> so select at most ONE of the connection method boxes in the allocation
> request. (I have asked that these selections be changed to a pulldown
> list or radio buttons so that it is impossible to select more than one;
> until that happens, requests having more than one box checked are likely
> to be rejected.)
> - Brian
Why is that??
We have been happily connected on both BGP and Tunnel for some time.
The gateways that are part of the tunnel mesh route to us by Tunnel and
the remainder of internet routes directly. What is wrong with that?
Some gateways do not want to route directly ("only AMPRnet") so it is
preferred when they can use the Tunnel to the same network.
Rob
> The idea here is to support IPIP and BGP concurrently while preferring IPIP. Additionally we also
> run BGP over other tunnel protocols ( GRE, SSTP, etc) with more specific preferences depending on the
> agreement between the Ops. AFAICT this setup is the only way wich allows both the IPIP-only and the BGP-only
> sites to reach our networks.
> vy 73 de Marc, LX1DUC
I agree, that is the way it works best. We do that here as well, however now we just have a single routing
table where routes of different origin are stored at a different metric, so there is no fixed priority between
protocols anymore. The first decision is always made on subnet size (smaller subnet has preference), the
metric only comes into play when for some reason there are routes over two different protocols for the same
subnet, and then the metric decides what path to take (e.g. there is both an IPIP tunnel and a a route announced
with internal BGP on HAMNET). Normally these are error conditions.
The difference between those methods becomes important when e.g. a /20 subnet is IPIP tunneled and out of
that a /28 subnet is routed another way, e.g. over a GRE tunnel. This works without problem for us now.
(on systems that are both on the normal internet and on the IPIP mesh reachable from the entire internet,
with source address filtering at the provider, I normally have at least two different routing tables and
policy routing, but on a directly routed system this is not required)
Rob
> On Wed, Jun 15, 2016 at 11:46:30PM +0200, Rob Janssen wrote:
> >/A quick check returns the following subnets being both BGP and Tunnel routed: /
> I stand corrected.
> - Brian
Well, before I made that list I hoped that it would be much longer...
Maybe I made a mistake, it was quick cut-and-paste followed by edit and comm of the
list of bgp routed subnets and the routes in my personal gateway.
Anyone with a BGP subnet who has a full-featured system as a router should consider
to announce the same subnet on the IPIP mesh, I think.
(with a tunnel endpoint address outside net-44, certainly outside the subnet)
Rob
> I'm not saying you can't be connected in more than one way, I'm saying
> that it's a special case that is unusual enough that it ought not to be
> easy to mistakenly claim you're going to do. As far as I know, Rob, at
> the current moment you're the only one doing this.
Hmm... disappointing. I would hope everyone who is BGP routing would be
doing that. I am not the only one, your gateway is doing the same thing :-)
A quick check returns the following subnets being both BGP and Tunnel routed:
44.135.193.0/24
44.136.227.0/24
44.137.0.0/16
44.161.230.0/24
44.161.252.0/22
44.188.128.0/20
44.208.0.0/16
44.48.16.0/24
> Two or three times a week I get applications which have simplemindedly
> checked all three boxes. Most of these people have no idea what they're
> asking for
Most applications of portal registrations I get are wrong or strange.
It appears that the thing is confusing to newcomers.
> I'm open to any suggestion that will keep me from having to go through
> this process over and over again. Perhaps making 'Direct' a link which
> brings up an intermediate page which presents a blurb about what checking
> Direct actually means and demands that they confirm that they're really
> going to get a BGP announcement from their ISP? Other ideas?
It could be done with a simple Javascript on the page that presents a pop-up
or reveals some explanation on the page when the checkmark is set ON.
Hi there,
I actually have a /32 IP.
I plan to connect a few new machines to the network. So, I would need 3
or 4 new adresses.
I went to the web page, the the network tab, and click on 44.0.0.0 / 8
<https://portal.ampr.org/networks.php?a=request&id=1> Global link.
the smallest block that I can request through this link is a /24. but I
don't need a /24, only a /29
how can I send my request directly from the web site ?
thank you
--
73,
Pierre-Philippe
F4MZI
> Subject:
> Re: [44net] block allocation
> From:
> "Bill Buhler - AF7SJ" <af7sj(a)buhlerfamily.org>
> Date:
> 06/15/2016 06:47 PM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
>
> Sorry if I'm unclear, so what I'm envisioning is setting up tunnels to the
> other participants of the 44 net who aren't directly internet routed and
> using RIP advertisement for them. Then traffic between me and them can
> bypass the main AMPR 44 net router, reducing latency and reducing bandwidth
> requirements at the root node.
>
> In other words, if anyone on my subnets access the internet it would route
> through our BGP connected uplink. If they were communicating with another
> subnet on the AMPRNet it would tunnel directly to them.
>
> What do you think?
>
> Bill Buhler
> AF7SJ
>
Indeed that is how we route here as well.
Please don't remove that from the Portal!
Rob
Pedro,
I use the following iptables rules on my router (this will work for any
console-based connection using TCP):
# DROPS MULTIPLE SSH CONNECTIONS FROM SAME IP
iptables -t filter -I FORWARD -p tcp --syn --dport 22 -i tunl0 -m
connlimit --connlimit-above 5 -j DROP
# DROPS MULTIPLE SSH ATTEMPTS FROM SAME IP WITHIN FIVE MINUTES
iptables -t filter -I FORWARD -p tcp --dport 22 -i tunl0 -m state
--state NEW -m recent --name sshconnect --update --seconds 300
--hitcount 5 -j DROP
iptables -t filter -I FORWARD -p tcp --dport 22 -i tunl0 -m state
--state NEW -m recent --name sshconnect --set
The first rule drops any connections greater then five. The last two
rules mark and drop more than five attempts from the same IP, for a
period of five minutes. You may wish to increase the time frame. I've
also added rules to block IPs that attempt to connect (or portscan) on
certain TCP and UDP ports (3389/tcp, 123/udp and 161/udp are common, for
example) for which I not post services as available to the AMPR
Community or the Public Internet connection.
In essence, even if an unauthorized person discovered the the port
without being firewalled by the portscan rule, they only get 5 chances,
with up to 5 concurrent connections at any given 5 minute interval (the
amount of attempts vary by implementation of server and client; but once
portscanned or disconnected from a given series of attempts, it counts
at one connection). Each reattempt after 5, restarts the 5 minute clock.
I also block Bogon IP addresses from entering tunl0:
# DROPS BOGONS ENTERING AMPRNet
# SEE http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt
iptables -t raw -I PREROUTING -s 0.0.0.0/8 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 10.0.0.0/8 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 100.64.0.0/10 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 127.0.0.0/8 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 169.254.0.0/16 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 172.16.0.0/12 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 192.0.0.0/24 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 192.0.2.0/24 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 192.168.0.0/16 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 198.18.0.0/15 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 198.51.100.0/24 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 203.0.113.0/24 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 224.0.0.0/4 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 240.0.0.0/4 -i tunl0 -j DROP
I should note that in addition to this, console-based connections that I
use for administration only are moved to non-standard ports. So I added
another layer of protection with Security Through Obscurity (hence a
portscan rule).
73,
Lynwood
KB3VWG
Pedro:
I use Fail2Ban as well, and created my own Jail to help with this.
First, you will need to created jail. In the Fail2Ban directory "filter.d"
create a new text file called "jnos.conf"
In the file called "jnos.conf" place the following text.
_____________________________________
# Fail2Ban configuration file
#
# Author: Wm Lewis - KG6BAJ
#
# $Revision$
#
[Definition]
# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
# host must be matched by a group named "host". The tag "<HOST>" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values: TEXT
#
#
#
#
#
failregex = ^.* <HOST>:.*bad login.*$
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
#
ignoreregex =
___________________________________
Next, after creating this file, in the main Fail2Ban directory, add the
following to your "jail.local" file.
______________________________
#
# Custom Made Bans
#
[jnos]
enabled = true
port = anyport
filter = jnos
logpath = /jnos/logs/nos.log
banaction = shorewall
action = %(action_mwl)s
maxretry = 2
______________________________
***
Note #1 : Your BANACTION may be different, depending on what your box is
using as a default ban method. Look at some of the other jail entries, (
like [postfix] ). You may need to change the BANACTION to match the others.
If your other jails are working with Fail2Bans default settings, you could
comment out the "banaction = shorewall" with a hash so it reads "#banaction
= shorewall" Obviously I use shorewall for my firewall. Your system may be
using something else.
Note #2 : Your path to your jnos log file may have to be tweaked to
something like "/jnos/logs/filename.extension"
I am using a version of jnos where I can specify that jnos logs are called
"nos.log" and rotated every 24 hours. Your jnos may be custom built to call
the logs something else.
After you've install the "jnos.conf" jail file, and added the jnos jail
settings, then restart Fail2Ban. Assuming you've made any appropriate
directory tweaks needed to what I supplied, and assuming you've also
adjusted your "jail.local" files email address to be your own, you should
start getting emails telling you when Fail2Ban bans an IP address from the
jnos logs for a bad login attempt.
Note, I put MAXRETRY = 2. This tells the jail to allow 2 bad login tries,
and then ban on the third bad attempt.
Hope this helps. I currently show over 1300 banned IP addresses from jnos
using this method.
73
Bill Lewis / KG6BAJ
At 11:39 AM 6/12/2016, you wrote:
>(Please trim inclusions from previous messages)
>_______________________________________________
>Hello,
>
>Since last months my JNOS MBOX is being attacked:
>
>15:24:59 94.53.236.39:55248 - MBOX (supervisor) bad login
>15:25:07 113.162.86.77:35247 - MBOX (support) bad login
>15:25:09 190.140.17.22:53348 - MBOX (root) bad login
>15:25:14 92.27.102.224:38887 - MBOX (support) bad login
>15:25:14 114.109.125.48:42069 - MBOX (administrator) bad login
>15:25:35 190.140.17.22:54146 - MBOX (root) bad login
>15:25:50 92.27.102.224:40191 - MBOX (support) bad login
>15:26:33 182.184.71.162:41259 - MBOX (root) bad login
>15:26:49 182.184.71.162:41259 - MBOX (sh) bad login
>15:26:50 89.22.213.165:33979 - MBOX (root) bad login
>15:27:52 89.22.213.165:34979 - MBOX (root) bad login
>
>None of the users tried have granted permit.
>
>Installed fail2ban but not avail.
>Attacking IPs change continuosly, routing to loopback no help
>Due heavy load jnos eventually hangs.
>
>Is it there any way/suggestion to stop this ?
>
>Appreciate any help.
>73, lu7abf, Pedro Converso
>44.153.0.1 or conversoft.com.ar
>pconver(a)gmail.com
>_________________________________________
>44Net mailing list
>44Net(a)hamradio.ucsd.edu
>http://hamradio.ucsd.edu/mailman/listinfo/44net
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Hello,
Since last months my JNOS MBOX is being attacked:
15:24:59 94.53.236.39:55248 - MBOX (supervisor) bad login
15:25:07 113.162.86.77:35247 - MBOX (support) bad login
15:25:09 190.140.17.22:53348 - MBOX (root) bad login
15:25:14 92.27.102.224:38887 - MBOX (support) bad login
15:25:14 114.109.125.48:42069 - MBOX (administrator) bad login
15:25:35 190.140.17.22:54146 - MBOX (root) bad login
15:25:50 92.27.102.224:40191 - MBOX (support) bad login
15:26:33 182.184.71.162:41259 - MBOX (root) bad login
15:26:49 182.184.71.162:41259 - MBOX (sh) bad login
15:26:50 89.22.213.165:33979 - MBOX (root) bad login
15:27:52 89.22.213.165:34979 - MBOX (root) bad login
None of the users tried have granted permit.
Installed fail2ban but not avail.
Attacking IPs change continuosly, routing to loopback no help
Due heavy load jnos eventually hangs.
Is it there any way/suggestion to stop this ?
Appreciate any help.
73, lu7abf, Pedro Converso
44.153.0.1 or conversoft.com.ar
pconver(a)gmail.com
I'm in the process of uploading an image of jessie for the RPI 3 to
https://sourceforge.net/projects/uronode/files/?source=navbar
If you wish to give it a go, that's where it'll be in approximately an
hour from this post. It's made from the kit sold near the TAPR booth at
this year's Hamvention at Dayton. You'll need to edit files
in /etc/ax25, /etc/postfix, and the file /usr/local/bin/ax25
other than that it should be ready to go. I did notice the main
repositories that came with it failed but an apt-get update fixed those
issues.
It was made using the uronode-pi.tgz script available in the tools
section of the same sf.net site.
--
<rhetorical> Why is it linux users can install and operate *any* version of M$
Windoze but the same can't be said in reverse?</rhetorical>
73 de Brian - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
Greetings;
Is it me or does the Jessie version of the Banana Pi OS fail to include
kernel modules for the ax25 stack?.. and if so would a custom compile of
the kernel work?
Curious as if anyone else has gone through this one before. I know it's
fine with the Raspberry Pi but I'm not that familiar with a Banana Pi.
--
<rhetorical> Why is it linux users can install and operate *any* version of M$
Windoze but the same can't be said in reverse?</rhetorical>
73 de Brian - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
Repeat (sorry about the formatting in my previous reposting)
-------- Forwarded Message --------
Subject: [Uronode] FCC serves Comcast
Date: Tue, 07 Jun 2016 13:19:12 -0400
From: Brian <n1uro(a)n1uro.ampr.org>
Reply-To: n1uro(a)n1uro.ampr.org
Organization: Amateur Radio Services
To: uronode(a)tapr.org, eastnet(a)n1uro.ampr.org
With regards to my dealings with Comcast and the faulty firmware
installed in their CPE devices, the FCC has informed me that they've
officially served Comcast with a direct order to resolve this problem or
respond to the complaint within 30 days of receipt of the complaint.
Since Comcast has admitted to me about their firmware bugs it'll be
interesting to see how this is accomplished and if it's within their 30
day window. A copy of their communication is included below.
"
Your Ticket No. 950514 was served on Comcast Cable Communications on Jun
7 for its review and response.
Comcast Cable Communications will likely contact you in an effort to
resolve your issue.
A response is due to the FCC no later than 30 days from today. Comcast
Cable Communications will respond to you directly by postal mail.
You can view a list of frequently asked questions at:
https://consumercomplaints.fcc.gov/hc/en-us/articles/205082880.
We appreciate your submission and help in furthering the FCC’s mission
on behalf of consumers.
This email is a service from FCC Complaints. Delivered by Zendesk
[NKGKWV-K6P1] "
This is somewhat positive news for us on the amprnet.
--
<rhetorical> Why is it linux users can install and operate *any* version of M$
Windoze but the same can't be said in reverse?</rhetorical>
73 de Brian - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
I repost this from the UroNode list with permission from the author.
-------- Forwarded Message --------
Subject: [Uronode] FCC serves Comcast
Date: Tue, 07 Jun 2016 13:19:12 -0400
From: Brian <n1uro(a)n1uro.ampr.org>
n1uro(a)n1uro.ampr.org
With regards to my dealings with Comcast and the faulty firmware
installed in their CPE devices, the FCC has informed me that they've
officially served Comcast with a direct order to resolve this problem or
respond to the complaint within 30 days of receipt of the complaint.
Since Comcast has admitted to me about their firmware bugs it'll be
interesting to see how this is accomplished and if it's within their 30
day window. A copy of their communication is included below. " Your
Ticket No. 950514 was served on Comcast Cable Communications on Jun 7
for its review and response. Comcast Cable Communications will likely
contact you in an effort to resolve your issue. A response is due to the
FCC no later than 30 days from today. Comcast Cable Communications will
respond to you directly by postal mail. You can view a list of
frequently asked questions at:
https://consumercomplaints.fcc.gov/hc/en-us/articles/205082880. We
appreciate your submission and help in furthering the FCC’s mission on
behalf of consumers. This email is a service from FCC Complaints.
Delivered by Zendesk [NKGKWV-K6P1] " This is somewhat positive news for
us on the amprnet. -- <rhetorical> Why is it linux users can install and
operate *any* version of M$ Windoze but the same can't be said in
reverse?</rhetorical> 73 de Brian - N1URO email: (see above) Web:
http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2:
http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax &
URONode http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland,
Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.
> On Tue, 2016-06-07 at 13:25 -0400, James Sharp wrote:
> >/I haven't run in to 443 "filtering", but I have run into instances where /> >/the ISP will drop TCP connections that are active for more than a few /> >/minutes, forcing openvpn to restart the connection. /
> Chances are your issue is the same as mine was. The CPE (router) has a
> built in watchdog timer that cuts all sockets after a few minutes. Using
> port 443 wouldn't make any difference. To the average web user this
> isn't an issue because each time a page is opened/refreshed a new socket
> is created, thus a new timer engages. The same may be said for services
> such as pop3/smtp/etc. where you're engaging a new socket each time you
> pop or send email. As long as the attachments aren't that big where you
> may exceed the watchdog's timer you'll never notice this.
So you can never download a file that takes more than a few minutes to complete?
Terrible! Now I understand why some companies try to enforce a "download manager"
to download a file of a measly 30 MB. So I can continue where I left off, yeah sure.
Well it is clear that everyone should devise their own solution for tunneling
and we should not change the global system to cater for limits that certain
users encounter. There will always be a more severe limitation found by someone.
It is better to solve these issues locally, where you have fellow users (victims)
that can understand what is and what isn't possible.
Colocated (virtual) servers with small storage capacity are very cheap today.
Usually they are the entry level of server location, the hoster advertises
their $3.99/mo server and knows that "everyone" will upgrade to more storage
and pay a lot extra. But for a gateway these are perfectly usable, you can
perfectly run it with 512MB RAM and 8GB disk. Put it in the IPIP mesh with
the usual tunl0 and ampr-ripd, and then everyone in the area can make their
VPN connection to there. Without NAT problems, and working round nasty ISPs.
(you can make a VPN over almost anything if you wish)
Rob
> Ok... all important points to understand and we absolutely rely and
> appreciate all your help on running the current AMPRGW solution. Before
> even jumping to conclusion, we'd need to know if GRE really would be
> more successful than IPIP. In Brian, N1URO's situation, I'm curious if
> a Comcast "Business" class service would remove some of these
> intentional filtering issues.
I don't think it will be an appreciable improvement.
I have experimented with GRE as the tunneling protocol (chosen exactly for this reason)
to connect local stations to our Dutch gateway, and at first the results looked promising,
but it did not take long before I got to the first case where plain GRE would not work
over a consumer NAT router. I think it is (at least here) never caused by intentional
ISP filtering, it is just caused by limitations of NAT routers that were only designed
for typical outgoing TCP and UDP connections only. In the mentioned case the router was
not even provided by the ISP, making malice even less likely.
I then changed setup to GRE over IPsec which works fine until now when in NAT-T mode,
but of course this is only suitable for use in a star configuration with connections
initiated from the users to some gateway. Not a replacement for the tunnel mesh.
I heard in Germany L2TP is used, I'm not sure if it is over IPsec or not.
Anyway, I use L2TP over IPsec (sometimes over NAT-T) at work, it works over any connection
but here as well it is a star topology.
We also offer OpenVPN connectivity at our gateway, in UDP mode only, and this too is
problem-free w.r.t. ISP routers. I don't believe a provider would (or even can?) filter
OpenVPN, certainly not when it would be run in TCP mode on port 443.
However, what is common in all these solutions is the star topology where the user behind
the crippled router connects outward to a well-connected system.
Of course we don't want to make the entire network into a star, but it could be an
idea to deploy more regional gateways like our national gateway, that are interconnected
by IPIP tunnels and optionally are BGP-routed on internet, and that offer services like
mentioned above and discussed before in this thread to regional users who for some reason
cannot run IPIP.
It works well here.
It is possible to deploy these on virtual servers that are quite inexpensive these
days, certainly when not doing BGP (not all those hosters will offer BGP of a /16 or
similar network via their routers, at an affordable price)
In my experience it is possible (although not for "I am not a programmer" types) to get
this working well on a Linux box. Setting up the VPN services and routing is quite well
described. Setting up a firewall requires some thought and monitoring, see the recent
incident with portmap. But this list is available for exchange of such information.
Rob
Thanks Brian, for your update.
Yes, the Portugese hamnet site is still under construcction. I notice you when this is up and running for update the link.
73’s
EB5JEQ
Message: 5
Date: Mon, 6 Jun 2016 09:22:08 -0700
From: Brian Kantor <Brian(a)UCSD.Edu>
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] Suggestions for the portal and the wiki
Message-ID: <20160606162208.GA28893(a)UCSD.Edu>
Content-Type: text/plain; charset=us-ascii
On Mon, Jun 06, 2016 at 02:31:39PM +0200, Miguel Bahi wrote:
> Please , I suggest add in this paragraf
> http://www.ampr.org/publications/
> add : Spanish hamnet www.hamnet.es
I have added the Spanish HAMNET to the list of links on the
publications page of www.ampr.org.
There is a link on the Spanish hamnet page to the Portuguese
hamnet page, but that site is still under construction so I
did not add that link to the link list on www.ampr.org.
- Brian
> A possible option could be SSTP, which works over regular TCP connections
> on port 443. But this is not well supported by the Linux world.
> Marius, YO2LOJ
SSTP is a star as well. In the open world there is OpenVPN over TCP port 443
when you want to run a VPN over TCP (I would not want that, but that is another topic).
However what it seems to come down to is that these issues can be solved locally.
A local Linux server or (e.g. MikroTik) router can be configured to be part of the
IPIP mesh and possibly be BGP routed, and then it can serve as a VPN server for
local users using whatever protocol(s) is or are locally preferred due to local
situation w.r.t. internet routers and/or filtering.
Rob
I concur with Bob. I've had Comcast before (though, I always used my own
device - connecting to a DOCSIS-to-Ethernet bridge/Cable Modem). I've
never had success using a consumer-grade router, unless it had DD-WRT or
OpenWRT installed, or I used a Linux server. Some D-Link devices permit
forwarding of protocols other than TCP/UDP, select the 'Other' option,
and place the number 4 in the box for IPENCAP.
Otherwise, most DMZ settings on consumer routers only forward TCP and
UDP traffic. Since 44net (including RIP44) packets are encapsulated
within IPENCAP (IP Protocol No. 4), you must forward that protocol. The
Iptables Firewall is the same as on other *nix devices. If you are
NATing to a device inside your LAN, the commands are similar to:
# iptables -t filter -I INPUT -p 4 -i eth0 -j ACCEPT
# iptables -t nat -I PREROUTING -p 4 -j DNAT --to-destination 192.0.2.8
Ensure that you are in fact seeing IPENCAP traffic entering your Local
Network at your device (e.g. the to-destination address specified).
Within the IPENCAP packets, you should see the password.
I should also note, that I currently use Verizon FiOS; and I noticed
when using their router as my border gateway, that the IPENCAP entry I
make is administratively removed (Verizon has a back-door into their
routers on tcp/4567) from upstream at intermittent times (I've been told
this is because it's 'hard' for the carrier to track and/or rate-limit
non TCP/UDP traffic). So be certain that your carrier it not removing
firewall entires, especially if you were successful in the past.
73,
- Lynwood
KB3VWG
> Subject:
> Re: [44net] Unable to Receive rip44d Datagram
> From:
> "Boudewijn (Bob) Tenty" <bobtenty(a)gmail.com>
> Date:
> 06/06/2016 08:23 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> He can check or dd-wrt or OpenWrt firmware is available for his router as these
> can forward ipip or can can be set in bridge mode (dd-wrt and OpenWrt are linux based)
> and much more.
Well, dd-wrt is available for some commercial ethernet/wifi routers but I don't think it exists for any
combo-modem-router as is normally used by cable or dsl providers. The dd-wrt people don't have
the drivers/software for the modem chips used in those modem-routers.
So in this case (a DOCSIS cable provider) it can only be done when he is already using a separate
modem and router.
>
> Some firmwares in these consumer routers even don't allow to be put in bridge mode at
> all. The tabs for it are just missing or they don't have an option for it in their menu.
Sometimes the ISP can switch the modem-router into modem mode (bridge) from their central
management system on user request.
It will probably have some strings attached like "no helpdesk support for network problems".
After the switchover, the internal ethernet interface will be plain ethernet or PPPoE or PPTP.
So you will need an extra router that indeed can be running dd-wrt.
However, with today's internet speeds on cable and dsl you also have to consider the router
performance. The typical WRT54 routers from the days dd-wrt was created cannot keep up with the
internet speeds of today.
Rob
> I have a strong suspicion that my ISP (Charter Communications) has implemented
> some kind of filtering on my home cable-based (DOCSIS) internet connection. My
> reception of the RIP44d table broadcase has all but ceased. ip-ip tunnel
> communication to a friend's machine in a neighboring county only seems to work
> for a limited time, and only AFTER I initiate a connection from my end. It's
> as if they're using some kind of NAT or port knocking filter, and only opening
> the gate for incoming proto 4 traffic for a limited time after I initiate an
> outgoing request to a specific host.
It is, as Brian N1URO also wrote, an issue in your home router.
Other routers have shown this phenomenon for some time.
Even when you set a "DMZ" (meaning: forward all unknown traffic to this host),
there still is a stateful firewall in place for all protocols except TCP and UDP,
requiring you to send outgoing traffic before incoming traffic is accepted.
You will need to have the router put in bridge mode (making it only a modem) and
install a better router in front of that. With a suitable router, it can also
do the IPIP encapsulation. A Linux system of course is a suitable router as well.
Rob
Good Morning Guys:
I have been working to get my chunk of .44 active for a little while
now. I've become quite familiar with the concepts of how the network
is set up etc.
That being said, no matter what I do I cannot seem to get the RIP
password that is supposed to be broadcasted from 44.0.0.1. I have go
as far as to monitor, log, and filter every packet coming in the cable
modem from anything AMPRNet to verify it is arriving. It just seems
like the packet is never making it to my public IP.
I've gone through all the basics - protocol 4(IPIP) forwarding, UDP
port 520 forwarding etc. Like I said, I've even captured all packets
pre firewall and I'm not seeing anything AMPRNet.
Is it possible that even though my gateway/public IP is registered,
the packets aren't being sent out?
The last portion of getting this going is that elusive RIP pass.
Any suggestions?
Thanks,
Jason - KD4CBM
'73
Has anyone else noted problems with the ethernet alias functionality in
recent Linux kernels ? I've just done an update on my tunnel server
(pogoplug E02 running Debian 8 with kernel 4.4.0-kirkwood) and within a
day or so the 44net alias disappears. Nothing I can see in any of the
logs. Replacing the alias via 'ip addr add 44.135.190.17/32 dev eth0:1'
is enough to fix it, might have to hack into a cron job :-/
44 net tunnels are being setup via a script from KB3VNW/LX1DUC, I
suspect a few people out there would be using it ...
Ideas ?
... Niall
Please , I suggest add in this paragraf
http://www.ampr.org/publications/
add : Spanish hamnet www.hamnet.es
and for the wiki http://wiki.ampr.org/wiki/Main_Page in the “how to connect to amprnet” title it would be interesting add one easy guide like “ setting up a Jnos Linux gateway”
73’s
------------------------------------------------------
Miguel Bahi Cruz
EB5JEQ Amateur Radio Station www.eb5jeq.es
ECB03KBQ "galaxia5" CB RADIO STATION
Elche Alicante Spain
email y skype : miguelbahi_cruz(a)hotmail.com
LOCAL VHF : 144.550mhz / UHF : 436.300mhz
Echolink: Conference **ESPAÑA**
AX25 Packed VHF 144.950mhz AX25mail eb5jeq#ea5dv.eaa.esp.eu
APRS chat: 144.800 mhz, monitoring CQ group
WWconv ampr.org **Elche_ES**
BPQ32net conv **GENERAL**
http://www.hamnet.es
eb5jeq(a)piserver.eb5jeq.es.ampr.org
http://piserver.eb5jeq.es.ampr.org email/forum/wiki/conference XMPP
Sysop of
EB5JEQ-1:BPQELX AX25 Node BPQnet BPQ32 144.825MHZ
EB5JEQ-6:ELXMPR TCPIP Node Ampr.org Net JNOS, 144.825MHZ ( in test )
QRUEB5JEQ Aprs QRUserver ( APRSIS32 )
EB5JEQ-24/ELXNOD24 node HSMM-mesh 2,4 ghz in test
EB5JEQ-50/ELXNOD5 nodo HSMM hamnet.es 5 ghz in test
> Same here as there is just too much garbage coming in and it is very
> labour intensive, I just block it.
> Bob
Well, here there is a lot more garbage coming in on other ports like 22 and 23
but I don't block that as there might be the occasional user who actually
uses it. For the listed completely-blocked ports there appears to be no valid use
from internet to amprnet.
Internal to amprnet we are a lot more transparent, but at the gateway I do block
all traffic to/from addresses without a registration within 44.137.0.0/16.
This cuts the noise as well because currently about 2.8% of the addresses is registered.
(after the big cleanup)
Rob
Thanks Brian, I was already filtering that port for traffic outside AMPRnet.
It would not have affected us much because we forward new incoming traffic from internet
only to users who have explicitly requested this. This list now includes 10 /28 subnets
and 29 individual hosts. (189 addresses out of the 65536 address network)
All other users receive new traffic only from 44.0.0.0/8, and replies to their own outgoing traffic.
I added this after the SNMP DDOS incident.... in case there are other problems like this.
Ports filtered here on input from internet are:
135:139,445,1025:1028 TCP and UDP (SMB)
53 TCP and UDP (DNS)
111 UDP (portmap)
161 UDP (SNMP)
1900 (SSDP)
Rob
Can someone please direct me to the right place where I can purchase a
complete kit so that I can setup an IP Ham network system. I would like to
experiment with using using the 44Net as a fall back network in times of
disaster.
Any assistance / direction will be very appreciated as I am new at this.
Thanks
Arnold Villeneuve
www.networkologist.com <http://www.networkologist.com>
Change is the end result of all true learning.- Leo Buscaglia
Thanks Marius. It looks like the instruction are jumbled up a bit to me,
and don't include the creation syntax for the tunnel interface, on the
Wiki. Maybe someone could make an edit to that??
I will try this when I get home later, and see if I can get it to play!!
More to come after that!
--
Rod Ekholm
kc7aad(a)gmail.com
Folks, I have begun blocking the portmapper port (UDP 111) at the UCSD
amprgw gateway. This is to mitigate a new DDOS exploit that is taking
place on the Internet.
This would prevent the use of various RPC services across the
amprgw gateway, but I don't think anyone is currently using NFS,
NIS, or the like in that context. The performance would be very
poor in any case.
You might consider blocking this port in your firewalls.
I recommend that everyone running their own BGP'd subnet insert a
blocking filter rule for this port as well.
More information:
http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper-an-…
Thanks.
- Brian
Where are you located? Most important (unless you want to build a set of portable nodes that you
can all deploy yourself during an emergency) is to have others to link to. So you need to check what
others are doing in your area, to be compatible with the systems they use.
In the old days, everyone built their own modems and sometimes even radios, and connected them
to general purpose computers running special software.
However, today you can buy ready wireless link and routing equipment from manufacturers like
MikroTik and Ubiquiti for prices much below what we spent on homebrew equipment, and if you wish
you can build an IP network by just plugging those together and do basic routing and linking configuration.
Others have taken existing hardware from Linksys and those same two and replaced the firmware
with own developments that e.g. go beyond the point-to-point linking by offering automatic routing
in a mesh configuration. This may be more convenient in a temporary deployment during an emergency,
but the point-to-point range of such a system is less than with directed links using dish antennas.
Rob
I get all the way to the section where it says I need to run 'sudo
./findpass.sh', and it gives me output of 'Tunnel Socket: Setting
SO_BINDTODEVICE: No suck device'.
The instructions I am following are at:
http://wiki.ampr.org/wiki/Ubuntu_Linux_Gateway_Example#Setting_up_the_Tunne…
And I am to the section of ' Finding the password for AMPR-RIPD"
The only section that had an issue during this process is the
isc-dhcp-server will not start. I don't believe this should make any
difference, other than if I have a client on my Ham Network that needs
DHCP, but I plan to statically assign those devices.. so I believe that
point should be moot.
My installation is Ubuntu 14.04.4 LTS
I only have 2 interface.. eth0 (outside WAN address from ISP. One of my /29
allocations) and eth1 (inside 192.168.44.0/24)
I know enough to make my way around, but am not normally a linux guy!! Let
me know what other info would be helpful to share out, so we can get this
one going.
Thanks guys!!
--
Rod Ekholm
kc7aad(a)gmail.com
Thanks for the reply's guys. Lynnwood.. I have Ubuntu installed and working
on my network (outside address as to not have anything blocking right
now!!), but when it came time for the box to listen to the AMPR RIP
broadcasts, I never did see anything. The notes say to let it sit for a
little bit.. I let it sit for two days before I got back to it! :)
So.. I haven't been diligently working on it, that's on me. But something
seemed to go awry. Dangit. That's on me toooooo!! :(
I'll try and get back to it over the next few days, and report back again.
But if there are any ideas off the tops of ones heads.. Hit me with your
best shot.. Fire Away!!
Thanks.
--
Rod Ekholm
kc7aad(a)gmail.com
Yes, but since the machine is a standard Ubuntu Linux Server machine,
I'm not sure how an OVA will help you. You still have to assign your IP
addresses, turn on routing, etc. per the instructions in the Wiki.
In the time it would take you to transfer it the file, you could simply
have the same thing by running the ISO on a fresh VM.
Are you having issues with setup?
73,
Lynwood
KB3VWG
Has anyone built an OVA of a VM used for an AMPR Gateway yet? Or has anyone
Exported their local VM that they would be willing to share?
*Disclaimer:* Yes.. I realize it is easy to build a host(though my attempt
so far has failed). But If someone has already put in the work to build a
VM, I'm willing to piggyback in their expertise in what they've built.
Thank you!!
--
Rod Ekholm
kc7aad(a)gmail.com
> two ways to solve this as well.
> 1. NAT the 44. address out the public internet. That is what I am doing
> here.
That only works when you have made special arrangements (policy routing)
to make sure the Echolink traffic is ALWAYS sent to the NAT device and never
routed directly. See what I explained to Gustavo.
> 2. have the server have two NIC cards. One with a 44 address and the
> other a local non-routable which is then NATed ouot your public internet IP.
That does not require 2 cards (you can put 2 addresses on 1 card), and it is
basically the same as the policy routing method, in this case using the IP
address as the base for the policy routing.
In practice it can be more difficult to implement because you need to force
the Echolink application to bind to the correct card address. Fortunately
Svxlink can do that, but many other programs cannot.
Rob
> The fact is that, actually the repeater is networked to the EchoLink
> server and this can be obtained ONLY by using the commercial
> IP number, i.e. IP address 79.47.199.234.
Look at our repeaters, e.g. PI2NOS
It is registered on the Echolink system using its own address 44.137.72.130 (pi2nos.ampr.org).
Therefore this problem does not occur here.
> the incoming IP results 44.137.41.97; so I understand that the
> internet server act as the real gateway in a similar way as our
> ampr.org gateways. It function very OK!
Yes, for "normal traffic" it works OK. But not for Echolink.
This is because Echolink has a directory server that registers your repeater
by IP address, and this address does not match the actual address.
When you get connected by someone from plain internet, it works OK because the route
back is through the same NAT router, where you have defined port forwarding for the
5198 and 5199 ports, and the users sees the same translated address as the Echolink system
registered.
However, when I connect from my address 44.137.41.97, the repeater or another part of
the system thinks it is being clever and routes the traffic through a IPIP tunnel,
the address does not get translated, and the connection fails.
The quick way to solve it is to give your repeater some RFC1918 address (10.x.x.x, 192.168.x.x)
so its traffic is always forced through the NAT router. Alternatively, you can setup some
policy routing so the Echolink traffic is always sent to the NAT router, not routed directly.
Then you can still use AMPRnet on the same computer for other things.
The way we solved it here is by applying for BGP routing of our subnet, so our net-44 traffic
is routed directly on internet and it is no problem to run an Echolink repeater on it.
(the subject of this thread: will routing through UCSD cause problems with VoIP. yes it will,
but we don't route through UCSD so we don't have that problem)
Rob
> Subject:
> Re: [44net] AMPRNET katency in VOIP connections ?
> From:
> "'Gustavo Ponza'" <g.ponza(a)tin.it>
> Date:
> 05/30/2016 07:12 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
> On 05/30/2016 05:55 PM, Rob Janssen wrote:
>> (Please trim inclusions from previous messages)
>> _______________________________________________
>>> I don't know how they do the job... but as all of you can see,
>>> also iPAD/iPhone can do it by using my small ampr.org facility :)
>>
>>> 73, gus
>>
>> Which repeater is this log from? It is on an AMPRnet address?
>
> It is from IR0AAB (ER-IR0AAB). It is on (or better, it should be on)
> 44.134.32.240/44.208.58.1
Ok but it registers on Echolink using IP address 79.47.199.234
So there is some NAT between its 44-address and internet!
This is no problem as long as the repeater always routes its traffic via that NAT,
but in practice those operators often route 44-net traffic directly and then it does not work.
I have tried to connect it from my 44-address and indeed it fails!
I connect to the node on address 79.47.199.234 as directed by the Echolink server,
and I get replies from 44.134.32.240:
Spurious audio packet received from 44.134.32.240
So I cannot connect that repeater from AMPRnet.
Rob
> Subject:
> Re: [44net] AMPRNET katency in VOIP connections ?
> From:
> Brian Kantor <Brian(a)UCSD.Edu>
> Date:
> 05/30/2016 06:25 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> As far as I know there are no active AMPRNet users in Asia.
> - Brian
>
> On Mon, May 30, 2016 at 05:55:47PM +0200, Rob Janssen wrote:
>> >It would be welcome when a volunteer a lot more east (near Japan/Korea/Thailand)
>> >could setup another set of Echolink relays. This requires a Linux machine
>> >with 5-10 IP addresses available to it, either plain internet or BGP-routed AMPRnet.
A host somewhere in a datacenter with a /28../24 subnet would be OK as well.
There are a couple of Echolink proxies in the far east, e.g. from JH1PGO but I have been unable
to contact the operator.
Rob
> I don't know how they do the job... but as all of you can see,
> also iPAD/iPhone can do it by using my small ampr.org facility :)
> 73, gus
Which repeater is this log from? It is on an AMPRnet address?
Those 44.137.75.24x addresses are our Echolink relays that serve the
mobile users in this part of the world.
It would be welcome when a volunteer a lot more east (near Japan/Korea/Thailand)
could setup another set of Echolink relays. This requires a Linux machine
with 5-10 IP addresses available to it, either plain internet or BGP-routed AMPRnet.
When some 20-200 addresses are available, it can also run Echolink proxies.
A combined proxy/relay server written in C (1000 times more efficient than the
echolink.org Java version) is available on my site:
http://pe1chl.nl.eu.org/Softw/elproxy.tar.gz
Bonus points when you find the race condition that makes it sometimes leak proxy
instances when it is rapidly scanned by a web proxy scanner :-)
Rob
> The easiest way would be to put an Echolink system server on a 44.x.y.z
> IP...
> Anybody working on this?
> This will avoid NAT and proxies, but problem with bandwith and latency
> staies the same if serveral "44 islands" are connected via tunnels.
> You then have to consider the bandwith of the tunnels and the
> performance of the peers.
> Micha, DD2MIC
The main issue is that many users of the system are on plain internet and so the
Echolink repeater has to be on a BGP-routed subnet or the users will all enter
via the UCSD router.
When you are not on a BGP-routed subnet I think it is better to use a proxy to
register using the plain internet address, so at least the user traffic remains
local and does not all go via UCSD.
Rob
> The basic idea would be that AMPR to AMPR traffic is a go since it is
> tunneled directly.
> Public IP to AMPR is a no-go for tunneled networks.
> They have a public Gateway IP anyway, so you should use that one for access
> from the internet.
> Marius, YO2LOJ
When you use Echolink from within AMPRnet but want to use a public IP you should
be very careful how to implement it. Some people configure an Echolink repeater
on an AMPRnet address and then route the traffic to some gateway where this address
is translated using NAT.
However, this does not work correctly! The Echolink repeater will register itself
with the Echolink system server which is on public internet, so the registration
address in the Echolink system is the address of your NAT router.
But internally, the repeater has a 44.x.x.x address so when someone from a 44.x.x.x
address connects the reply will come from the wrong address and the connection
does not go through.
This manifests itself when some other systems are natively on AMPRnet not using NAT.
For example, here in the Netherlands we have several repeaters with a true AMPRnet
address that is BGP routed, and we also run several Echolink proxies and relays
on AMPRnet addresses. In neighboring Germany, the NAT method is often used, where
the repeaters have a 44.x.x.x address but connect to the Echolink server via NAT.
As a result, no connections between the repeaters in these two areas are possible,
and worse: people using our Echolink proxies and relays cannot connect to German
repeaters or users.
It can be solved by not using NAT to translate the Echolink traffic to public
addresses, but instead run an Echolink proxy on the gateway system which converts
the internal AMPRnet address of the Echolink repeater to the public address of
the gateway. Unfortunately only a single proxy can be run per public IP address,
so a "normal" gateway with a single external address can only host a single repeater.
To solve this, a number of proxies can be run e.g. in a datacenter where an IPv4
subnet is available for them (more and more difficult, of course!).
This has now been done in Germany.
The disadvantage of this solution is that all users that are on AMPRnet still connect
to the outside address. On a BGP routed AMPRnet network where no proxies or
translations are used, local users can connect the repeater directly.
Rob
Hi there
Is there anyone that use AMPRNET for connecting VOIP gear (such as echolink alients (or even Digital repeaters (DMR D-STAR etc) and can tell how is the fact that every packet goes back and forth to UCSD router effect the connections ? is the latency not making any problem ?
any comments from anyone that has tried that is appreciated
Thanks Forward
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
Please contact me off list please.
Thanks much!
--
<rhetorical> Why is it linux users can install and operate *any* version of M$
Windoze but the same can't be said in reverse?</rhetorical>
73 de Brian - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
I've gone through several router changes recently all requiring IP
changes due to changes of MAC. Can a good handful run:
ip route get 44.88.0.1 and show me the commercial IP listed? I've seen
several who run rip listener daemons that have failed to update my IP
(and I do have remote access to these points).
Thanks.
--
<rhetorical> Why is it linux users can install and operate *any* version of M$
Windoze but the same can't be said in reverse?</rhetorical>
73 de Brian - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
Thanks all who answered.
--
<rhetorical> Why is it linux users can install and operate *any* version of M$
Windoze but the same can't be said in reverse?</rhetorical>
73 de Brian - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
Hi All,
Sorry for the OT noise, someone emailed me some weeks back (
maybe a couple of months )
looking to link to my Node, I wonder if that person is on this list ?
If so, could you please contact me again, off list.
Thanks ..... Peter ZL2BAU
I'm presenting at the TAPR forum 9am on Friday about HamWAN and some 44net
topics.
Love to meet up with any of the other 44net users and chat after, please hit
me up of shoot me an SMS at my number below.
I'll most likely be on 223.48 simplex as well.
73's W9CR
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
Hi,
Is anyone still using CONVERS? I can only see autologged-in sysops in all
channels and no users.
---
73 Δημήτρης - SV1UY
73 de Demetre - SV1UY
IP Coordinator for AMPRNet in Greece
e-mail: demetre.sv1uy(a)gmail.com
Radio e-mail: sv1uy(a)winlink.org
AMPRnet e-mail: sv1uy(a)sv1uy.ampr.org
PACKET mail: SV1UY(a)SV1UY.ATH.GRC.EU
WEB: http://www.qsl.net/sv1uy
