The master DNS server for AMPR.ORG and 44.IN-ADDR.ARPA on gw.ampr.org
has been upgraded from ISC bind9.10 to bind9.11. (FreeBSD maintenance
of 9.10 is ending in a few months.)
This should not affect anyone. Let me know if you suddenly encounter
any host or address lookup problems from today on.
- Brian
There are two gateway systems with misconfigured routing
tables that are attempting to route all of net44 through
amprgw instead of using mesh connections. These may have
a default route instead of using the correct routing table.
Whatever the case, they aren't going to have much luck
reaching other net44 hosts. Those gateway operators
should check their configurations.
- Brian
Last update at Sun Oct 22 06:30:01 2017 PDT [-0700]
gateway inner src #errs indx error type
---------------- ---------------- ----- ---- -------------------------------
79.0.254.164 44.134.96.1 5408 [ 8] dropped: encap to encap
173.230.244.130 44.68.41.1 1349 [ 8] dropped: encap to encap
> That is, if your repeaters are at different sites, you'll probably
> need different tunnels for each site, and therefore different allocations,
> one per site. (It's a restriction of the portal/tunnel system that
> you can't further subnet an allocation for different gateways).
Really? We do have that, and it appears to work fine...
Or has there been a change that disallows new creation of subnets that way?
Hello,
I've mapped 2 blocks ( 44.158.128.0/20 & 44.158.158.0/23 ) in the AMPR
portal, to the gateway 193.137.237.9
Both blocks have the "Tunnel" checkbox active.
When I generate traffic from the Internet to the IP 44.158.128.1 I can
see some encapsulated (IPoIP porto 4) arriving but when the target is
44.158.158.1 (or any other IP from the 2nd IP block) no traffic arrives.
The routes are being advertised in the RIPv2 announces and in the
"encap" file, as expected.
I'm I missing something?
thanks for all the work done keeping this net!
regards.
tcpdump:
> 16:58:38.871024 IP 169.228.34.84 > 193.137.237.9: IP 194.210.189.129 >
> 44.158.128.1: ICMP echo request, id 19244, seq 1, length 64 (ipip-proto-4)
> 16:58:39.871090 IP 169.228.34.84 > 193.137.237.9: IP 194.210.189.129 >
> 44.158.128.1: ICMP echo request, id 19244, seq 2, length 64 (ipip-proto-4)
> 16:58:40.870884 IP 169.228.34.84 > 193.137.237.9: IP 194.210.189.129 >
> 44.158.128.1: ICMP echo request, id 19244, seq 3, length 64 (ipip-proto-4)
> 16:58:41.871032 IP 169.228.34.84 > 193.137.237.9: IP 194.210.189.129 >
> 44.158.128.1: ICMP echo request, id 19244, seq 4, length 64 (ipip-proto-4)
> 16:58:42.870926 IP 169.228.34.84 > 193.137.237.9: IP 194.210.189.129 >
> 44.158.128.1: ICMP echo request, id 19244, seq 5, length 64 (ipip-proto-4)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Callsign: CT7ABP
QRA: Pedro Ribeiro
GRID Locator: IM58mr
QTH: São Francisco, Alcochete, Portugal
NET: http://www.qrz.com/db/CT7ABP
CT7ABP is also home station of CR7AJI Diogo
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Greetings all,
I'm working on helping renovating a repeater system for the Southern
Catskill Amateur Radio Society (KC2AXO -
http://wireless2.fcc.gov/UlsApp/UlsSearch/license.jsp?licKey=421389),
and was interested in figuring out the rules for getting an AMPRnet
assignment for the club. I'd like to get a /24 though we could probably
work with smaller as long as it's a large enough allocation to subnet it.
Right now, we have a simple 2m repeater, but we're building two 33cm
links up to the repeater shack to get connectivity up there. Right now,
we're interested in setting up EchoLink/IRLP/AllStar for the repeater,
and pending a second antenna/additional equipment, possibly a
digipeater, APRS gateway, and packet BBS. Right now, we've got three
sites (the primary repeater, a fill-in site, and the base station in town).
The rough plan right now is as follows:
- svxlink up at the shack for repeater control
- 33cm downlinks to the fill-in repeater/club station
- svxlink instance in the club which terminates traffic going
to the internet (this acts as a Link Station, and keeps us within
Part 97 compliance w.r.t Internet traffic and RF links)
- aprsd running on the repeater, direct connection to APRS-IS
(since this is all ham-to-ham traffic with callsigns, this should
be legal per Part 97).
- As resources allow, RF link to AMPRnet in general
We'll have to get gateways to the other AMPR networks like HamWAN and
such for 44net traffic to be reachable elsewhere.
What I'd like to do is use an AMPRnet allocation from our base station,
and then pipe service up to the repeater via a second fill-in site we have.
AMPRnet seems like a logical way to do this, and as we expand the club,
also allow folks to play with packet radio. I looked through the
archives and the wiki and saw nothing about club allocations for AMPRnet
so I figured I'd try here before filling out the application form as
well as getting suggestions from the 44net community. I'm not the
trustee (N2TDX) for the club sign, but I'm acting w/ his permission and
can have him do the registration process if need be. Just trying to
figure out the process and get our feet wet with AMPRnet.
72 de KD2JRT
I'm currently planning to upgrade the operating system and packages on
amprgw (aka gw.ampr.org) Sunday morning Pacific time. This will take
the system from FreeBSD 10.3-RELEASE to 11.1-RELEASE, since the 10.3
version will be going end-of-life in early 2018.
There will be a few times where the system will be out of service while
it reboots. Each time, you may notice that packet forwarding is briefly
not working.
- Brian
--
44-announce mailing list
44-announce(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44-announce
> I'm currently planning to upgrade the operating system and packages on
> amprgw (aka gw.ampr.org) Sunday morning Pacific time. This will take
> the system from FreeBSD 10.3-RELEASE to 11.1-RELEASE, since the 10.3
> version will be going end-of-life in early 2018.
Good luck - and thanks for the effort you spend!
No drastic changes like putting VMware ESXi underneath? :-)
Rob
This appears to be somewhat serious; it will probably require people
to reflash the firmware in some or all of their wireless devices when
fixes become available. How one reflashes IoT devices is problematic.
- Brian
From ARSTechnica:
"The proof-of-concept exploit is called KRACK, short for Key
Reinstallation Attacks. The research has been a closely guarded
secret for weeks ahead of a coordinated disclosure that's scheduled
for 8 a.m. Monday, east coast time. An advisory the US CERT recently
distributed to about 100 organizations described the research this way:
"US-CERT has become aware of several key management vulnerabilities in
the 4-way handshake of the Wi-Fi Protected Access II (WPA2) security
protocol. The impact of exploiting these vulnerabilities includes
decryption, packet replay, TCP connection hijacking, HTTP content
injection, and others. Note that as protocol-level issues, most or all
correct implementations of the standard will be affected. The CERT/CC
and the reporting researcher KU Leuven, will be publicly disclosing
these vulnerabilities on 16 October 2017."
https://arstechnica.com/information-technology/2017/10/severe-flaw-in-wpa2-…
