> I have sendmail's 'greetdelay' function enabled, which delays sending
> the initial greeting herald by 5 seconds after the connection opens,
> and flushes any mail where commands arrive before that time has elapsed.
> This pre-greeting-flush catches one or two senders a day, presumably
> spammers because they don't come back.
That isn't much... but maybe a lot of those clients have implemented a workaround
for that sendmail trick, because it has been around for a while and is part of the
default config on some systems. So this particular check might not be effective anymore.
However, I did other things in my mailserver:
- sending intermediate replies (a minus sign immediately after the 3-digit code)
and checking for a few seconds if that makes them send the next command (it shouldn't)
- doing the delaying not only on the greeting but also on other commands
- perform rigid syntax checking (e.g.: there should NOT be a space after the colon
in the "mail from:<address>" and "rcpt to:<address>" commands, according to the RFC,
but a popular free smtp client that is often used by spammers puts it there)
The outcome of those tests only added to the spamscore so faulty mail clients were
not completely blocked.
Rob
> The problem is that the large email purveyors like AOL, Yahoo, Microsoft, etc,
> use large server farms that balance the load between multiple hosts, so
> when the mail retries it comes from different IP addresses on every retry.
> Microsoft, for example, lists thousands of IP addresses as part of their
> email service.
> Greylisting by IP address hasn't got a chance of working in that
> environment.
When I ran my own mailserver I had greylisting that only worked by sender mail address.
Additionally, it did the usual SPF checking etc.
This did not cause the abovementioned problem, but I'm not sure it added much spam prevention.
I had other methods to detect trojaned PCs with bad SMTP senders (e.g. doing PIPELINING without
having negotiated it) and that was much more effective.
Rob
Hi Ronen,
Yes I can make my ntp server available to non amprnet host just let me know the ips its comming from.. I can expect to receive from. host name: kc3ipf-01.ampr.org.
Philip KC3IPF
>What about the kc3ipf server ? is it available also to non amprnet hosts ?
>
>
>Ronen - 4Z4ZQ
Thanks Lynwood. Could you change the location of ntp.vk2hff.ampr.org from UK to AU please?
Josh VK2HFF
-------- Original message --------
From: lleachii--- via 44Net <44net(a)mailman.ampr.org>
Date: 11/10/2017 01:54 (GMT+10:00)
To: 44net(a)mailman.ampr.org
Cc: lleachii(a)aol.com
Subject: Re: [44net] new ntp server for amprnet
All,
I've added the NTP servers in this email thread to the Services Wiki (I
didn't include Bigben since that's not on AMPRNet, let me know if you
think I should add it, Brian).
Also, my NTP server is a Stratum 2 that pulls from various military,
industrial, government and educational Stratum 1 servers in North
America (including AMPRGW).
John, be sure to let us know when you've assigned a 44 IP to your server.
For reference, my NTP Server address is: kb3vwg-001.ampr.org (44.60.44.1)
73,
- Lynwood
KB3VWG
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
> The Motorola device has no NMEA output, but can produce 2.5, 5, 10,
> 12.5, or 25MHz reference frequencies depending on jumper settings inside
> the box.
> I wish I had a use for them. Right now they're just another piece of
> the junk piled up in my garage. I use the NTP-syncronized clocks in
> my computers as my primary time reference because they're on all the
> time anyway.
Not so useful as a time reference but you could use it as a frequency reference
for a microwave station, a beacon or a repeater.
Rob
> In the US, the surplus equipment market occasionally had GPS-trained
> oscillators that could provide 10Mhz and 1pps clocking as well as NMEA
> output. They were parts of CDMA cellphone base stations, each of which
> had at least two. The one I have was made by HP. I also have one that
> is a Motorola device that was used to synchronize simulcast transmitters
> in repeaters.
That is the kind of box (from other manufacturers) that we use as well, attached
to a PC with 1PPS and NMEA and to the repeater with 10 MHz.
Chrony on the PC keeps the Linux clock within 10us (usually within 1-2us) which
we require for the simulcast, and 10 MHz provides the exact transmit frequency
reference.
Power... well, maybe it has an oven stabilized crystal oscillator. Or very
old digital logic that is a bit too power-hungry. Of course a lowcost uBlox/
SiRF module is easy to get going and provide 1PPS for ntpd.
The LeoNTP box is a plugin-and-forget network clock, of course not the cheapest
solution. A Raspberry Pi can be used, I have one in the IPv6 NTP pool at
2a00:f10:103:201:ba27:ebff:fefd:984
Rob
> I also have a stratum 1 NTP server, it is on 44.13.151.3 (ntp.g1fef.ampr.org) and it is open to 44/8
> It’s a Symmetricom S200 with Rubidium clock and GPS and is located in the UK for anyone in Europe it would be better choice than the US based clocks.
For people who want an easy stratum 1 server and don't have money for such gear, have a look at the LeoNTP.
It is made by a UK radio amateur and it is a GPS locked NTP server in a very small package.
It costs "only" 300 pounds (about $400). We have considered it for repeaters but unfortunately it cannot
provide 10 MHz and 1PPS at the same time, which we do require.
Rob
Hi team,
My name is is Philip (KC3IPF) and I'm making my network ntp server available to the amprnet. All I ask is pre-notification of the subnets being served so I can open my firewalls and permit the ntp daemon to service the networks. You can contact me pm1183 at messiah dot edu. It is a stratum 3 server and all I ask is don't be abusive. The address is kc3ipf-01.ampr.org.
Philip
I remember well from when I started in electronics how much money had to be spent on measurement
equipment, e.g. a multimeter or a scope. Today, there are some very interesting devices available
from Chinese suppliers e.g. via Aliexpress or Ebay. Can be very useful for quick measurements/testing
in the amateur radio station, to get new (young) people interested in electronics, etc.
For about $25 you can get the Aneng AN-8008 DMM that has 4 digits (9999 count) and measures
DC and AC (true RMS!) voltage and current, resistance, capacitance, frequency and can even generate
audio tones. It has very low ranges, the least significant digit displays uV or uA on the lowest range.
Very useful, as long as you don't use it to measure dangerous voltages or currents.
I also got a kit for a 200kHz (1 MSPS) single-channel storage scope for less than $25. Takes about 2hrs
to assemble, and you have a pocket size storage scope that I would really have liked to have back in the
days of packet radio, you can have one of them connected to each receiver and see the audio quality
all the time. It can display peak and RMS voltage, frequency etc on-screen.
JYE TECH Digital Oscilloscope DIY Kit (can be found with or without case)
Another nice toy is the M328 LCR-T4 component tester. Based on a design originally published in a
magazine, there are several different versions available that differ in connections and if it does/does
not include a case. I have one that uses a ZIF socket for the connection. It has 3 test terminals and
you can connect a transistor, fet, triac, resistor, capacitor, inductor, diode, zener etc to the test terminals
and it will display the type of component, pinout, and value on the LCD screen. Includes other useful info
like the ESR of a capacitor, capacitance of a diode, etc. Can be found for less than $10.
Of course it all isn't professional test equipment, but it is a lot of fun for the money if you ask me...
Rob
> Now it's back..
>http://wiki.ampr.org/wiki/Services
The server gw-44-137.pi9noz.ampr.org (44.137.0.1) mentioned on that page is also still available
to AMPRnet users, but of course it is in Europe (Amsterdam) so not as accurate for users
in the USA as a more local server would be. It has about 150 clients.
The server itself is usually within 300us of UTC, it is referenced from 8 GPS clocks of
different types (Datum 9390-52054, Trimble Thunderbolt, Meinberg) used in our same-frequency
repeater network, plus various other external sources. It automatically fetches the leap-second
announcement file from IERS once a month to handle leap seconds smoothly.
Rob
I added a collection of notes I have had locally on IPv6 to the wiki.
I am not much of a wiki guy, so I encourage others to edit its layout
and make it look pretty. But its a start to put the info in one
place. And others can add to it as we progress.
http://wiki.ampr.org/wiki/Ipv6
Brian/Chris:
Also, is there any chance it could be changed so that PDF's could be
uploaded to the wiki? Looks like it only accepts images presently.
Steve, KB9MWR
Brian.
I don't believe a correct updated ipip route table is transmitted by the rip broadcasts of ucsd/ampr.org.
A friend has now a static ip since yesterday and the portal has the correct ip and updated encap.txt.
but he is not receiving the rip broadcasts and I have still his old commercial ip in my route table.
73,
Bob VE3TOK
Code-execution flaws threaten users of routers, Linux, and other OSes
Bugs in widely used Dnsmasq give attackers remote control of vulnerable
systems.
DAN GOODIN - 10/3/2017, 3:56 PM
Google researchers have discovered at least three software bugs in a
widely used software package that may allow hackers to execute malicious
code on vulnerable devices running Linux, FreeBSD, OpenBSD, NetBSD, and
macOS, as well as proprietary firmware.
Dnsmasq, as the package is known, provides code that makes it easier for
networked devices to communicate using the domain name system and the
Dynamic Host Configuration Protocol. It's included in Android, Ubuntu,
and most other Linux distributions, and it can also run on a variety of
other operating systems and in router firmware. A blog post published
Monday by security researchers with Google said they recently found
seven vulnerabilities in Dnsmasq, three of which were flaws that allowed
the remote execution of malicious code.
Rest at:
https://arstechnica.com/information-technology/2017/10/code-execution-flaws…
> Quick question as to what methods you guys are using to "send in
> exceptions" Is there a way of contacting hotmail support that doesn't
> involve an endless loop of "we see no problems" with their tier 1 techs?
I would say the contact with support should be made by the hotmail subscriber.
They can claim they don't receive their important mail and want that situation
rectified. They have a customer relation with hotmail.
My experience is that contacting services where you are not a customer yourself
is usually very difficult and will often not result in any action.
> FYI I do already have SPF, PTR and DMARC records published in DNS which
> has ensured reliable delivery to gmail addresses, but hotmail seems to
> have their own internal scoring system
Another problem is that hotmail uses a cache for SPF and DMARC and it takes
very long to expire. I have seen mail problems in hotmail at least a month
after an SPF record was changed to include more valid addresses, and they were
still considered invalid (resulting in postmaster report via DMARC info).
Rob
We're having some problems with 44net email to and from
hotmail.com. Mail from that domain is getting delayed,
sometimes for hours, and mail going to addresses in that
domain is received by the server but not delivered to the
users mailbox.
I think I've fixed the delay problem by adding more IP addresses
to the greylister 'whitelist', but I don't know of anything
I can do about the delivery problem.
- Brian
Greetings everyone!
I would like to first say that i am new to the Mailing list and this is
my first email on this list.. If you wish to learn more about me and ham
radio you can visit http://kc9zhv.com or http://lorentedford.com
Technology wise i am involved heavily in Gaming Live Streaming and I
rent a Rack Server from SoYouStart out of Canada a derivative of OVH
Data Centers. I am curious if it is possible to route a /27 of ips to
one single static ip from my web and email server that also handles my
routing vpn services and many other things.. I use a specialized distro
called Neth Server I am particularly running on Neth 6.8 for reliability
reasons basically Centos or Red Hat distro..
So i suppose in closing how does everyone else route ip's around? Do you
rent a server like i do and point it at the ip? I know in my Data center
I have 14 dedicated public ipv4 ips to my disposal.
Also will they issue a /24? If so I could use it not only in combination
with my 14 Allstarlink nodes but handle some of my echolink servers and
stuff as well.. Maybe put up some Echolink Proxies for others to use its
not like that takes up any processing power in Linux environment..
Anyway thanks for the time 73 for now
--
Loren Tedford (KC9ZHV)
Phone:618-553-0806
Fax: 1-618-551-2755
Email: lorentedford(a)gmail.com
Email: KC9ZHV(a)KC9ZHV.com
http://www.lorentedford.comhttp://www.kc9zhv.comhttp://forum.kc9zhv.comhttp://hub.kc9zhv.comhttp://Ltcraft.nethttp://voipham.com
***************************************************
CONFIDENTIALITY NOTICE: Confidential information, such as identifiable
patient health information or business information, is subject to
protection under state and federal law. If you are not the intended
recipient of this message, you may not disclose, print, copy or disseminate
this information. If you have received this in error, please reply and
notify the sender (only) and delete the message. Unauthorized interception
of this e-mail is a violation of federal criminal law.
**************************************************
> We're having some problems with 44net email to and from
> hotmail.com. Mail from that domain is getting delayed,
> sometimes for hours, and mail going to addresses in that
> domain is received by the server but not delivered to the
> users mailbox.
I sometimes have similar problems with gmail.com. I send replies to
allocation requests to the user's gmail address and they never receive
it, and become impatient and repeat the request. Sometimes I can fix it
by using a different sender mail address.
It looks like those big guys (who of course get billions of spam messages
a day) use a lot of sender profiling and low-volume senders like @amsat.org and
@*.ampr.org get low in their reputation score. So with a *.ucsd.edu sender
address you had a quite higher reputation score. Mentioning IP addresses in
the mail body does the rest. (often considered an indication of spam)
Rob
All,
The DNS servers that I copied the zones AMPR.ORG and 44.IN-ADDR.ARPA
from, are no longer responding.
My DNS server at 44.60.44.3 (dns-mdc.ampr.org) is still up and available
for client DNS resolution; but the AMPR.ORG and 44.IN-ADDR.ARPA zones
are no longer local copies.
Just an FYI. If anyone else is running DNS, ensure that your AMPR.ORG
and 44.IN-ADDR.ARPA zones are up-to-date.
73,
- Lynwood
KB3VWG
> At the cost of sacificing the independence and survivability of the
> mesh structure that is the current AMPRNet, one or more central v4 to
> v6 gateways could be established. I believe it would be too much to
> expect each of the 600 or so subnet gateways to become "dual-stacked".
I will certainly consider adding IPv4-over-IPv6 tunneling to our gateway for 44.137.0.0/16
when there is demand for it. We are already IPv6-connected but at the moment this is
only used for out-of-band management (to prevent locking myself out of the system when
doing work on the complicated IPv4 routing and firewall)
Of course that would indeed mean it is not meshed over IPv6 but of course it still
participates in the IPv4 mesh.
When there is sufficient uptake in other parts of the world, additional meshing over
IPv6 could be considered. I agree that some method, preferably an internet standard,
should be used to disseminate IPv6 tunnel information. It would decrease the difficulty
of adding a gateway for those that e.g. want to use surplus commercial routers.
Rob
It's been interesting going over historical documents, RFCs, and some
personal correspondence with people who were involved with the AMPRNet
at various times. I think we've now got a pretty good picture of the
history of the AMPRNet up to the current day.
Let me recap the history as I know it:
In 1981, Hank Magnuski, KA6M, got the network with a phone call to Jon
Postel at USC-ISI, later the SRI-NIC.
Around 1983, Hank passed it on to Phil Karn (KA9Q), then at BellCoRe.
Phil managed it until he left to go to work at Qualcomm in San Diego,
and gave it to Wally Linstruth (WA6JPR) [RIP 2010]. Phil is now retired,
and continues to be involved with AMPRNet.
Around 1988, Wally passed the network on to me to manage, and I've been
doing so ever since.
In 2011, it seemed wise to legally formalize the ownership, so we
incorporated our organization, Amateur Radio Digital Communications
(ARDC), as a non-profit 501(c)(3) tax-exempt charitable organization,
and I became its president.
The American Registry of Internet Numbers (ARIN) and Internet Assigned
Numbers Authority (IANA), which are the authority in these matters,
recognizes us (ARDC) as the legal owner of the AMPRNet, 44.0.0.0/8.
If there's any corrections needed in the above brief history, please
let me know.
- Brian
Hi All,
AMPRNET consists of IPv4 addresses 44.x.x.x. Tunnels used to support
AMPRNET use IPv4 hosts as destinations for the tunnels, creating a
"mesh-like" network.
Bent OZ6BL and I have been experimenting with using an IPv6 host to
carry AMPRNET traffic. The reason you might want to do this is that
IPv6 addresses, particularly static addresses, can be much more readily
available than with IPv4. Also, it's an interesting thing to try! We
have working tunneled 44.x.x.x connectivity between three different
IPv6 hosts. However, there are some issues that arise, mainly due to the
way in which AMPRNET functions.
Tunneling IPv4 inside IPv6 (ip4in6) is easily done and is well
documented. In Linux, commands like these are all that's needed:
/sbin/ip -6 tunnel add ip6tnl1 mode ip4ip6 \
remote 2001:0DB8:112:35c::5630:6324 \
local 2001:0DB8:1245:5200::ca0c:5902
/sbin/ip link set dev ip6tnl1 up
/sbin/ip route replace 44.145.40.32/32 dev ip6tnl1 src 44.136.170.20
It's very similar to how conventional AMPRNET is set up. However,
the first issue is that with ip4in6 you cant (unlike ip4in4) leave the
"remote" address empty, and then use routing commands to set the
destination for different AMPRNET hosts (you'd be trying to add an IPv4
route to an IPv6 gateway destination). So there's a scalability
problem - you'd need to set up a different tunnel device for each subnet
you communicate with!
The second issue is interoperability - if Alf, Bob and Charlie each only
have IPv6 hosted AMPRNET, and Doug, Ed and Fred have only IPv4, then A,
B, and C can communicate with themselves, as can D,E,F, but the two
groups cannot interconnect from tunneled addresses. Of course, A,B and
C could host IP4 tunnels as well, but that would somewhat defeat the
purpose! Alternatively, one or more gateways (G) could host both IP4 and
IP6 based tunnels, and route between the different type of network, a
bit like this:
A,B,C <----> G <----> D,E,F
Could/should amprgw be configured to do this? Or maybe some hosts
elsewhere do that function? But it adds complexity to the overall
routing setup (and starts to become a more centralised network).
The final issue is dissemination of the information - can the portal be
modified to support IPv6 hosts, or do we need another mechanism? Can
encap.txt be used still? Would facilities such as ampr-ripd and ripd44
need modifications?
So there's plenty to think about....
Steve, VK5ASF
I am in need some guidance. I have a number of ways I can use this and I
dont want to set it up wrong from the beginning.
I was assigned a subnet in Denver, Colorado where I am working with local
groups to get on some tower sites, but I have a Data Center in New Jersey
that has a large VM infrastructure. I live in Colorado but since the data
center is in New Jersey should I get another allocation? I still plan to
use the Denver/Colorado Springs subnet, but that upstream ISP is being
difficult at the moment since I am a subtenant, and my MOU is only for
tower space and a two routers in the cabinet there.
I was going to just route the Colorado IPs to my New Jersey Data Center
then tunnel back to the Colorado Gateway, but am not sure what the policies
on that are.
My plans are to offer some free VMs and VPN tunnels to HAMS on my back end
systems as well as VPN gateway points, etc. Those would be in NJ, but once
I finish my migration into a dedicated cabinet here in Denver I would offer
additional VMs / Gateways here as well. Future plans include California and
Croatia.
Please let me know if anyone has any ideas about what direction I should
go. My provider in NJ is ready to add the routes next week (as soon as the
go ahead authorization from AMPR).
Thanks,
Mike Vespoli
Denver Colorado
KE0HFH
> Yes, I'm now aware that there are nameservice problems
> and I'm working on it. It won't be fixed quickly because
> it requires manual intervention by several people in many
> different places around the globe, including the registries.
> Thanks all for bringing this to my attention.
> - Brian
Well, it appears that the originally envisioned problem (not all servers uptodate) has
been fixed. The 2nd problem (incorrect servers in org zone) is still open, but that
should affect only the lookup time. It probably explains why ampr.org lookups are
often so slow.
However, when I checked before there were only some servers that were at most 24h behind.
Maybe they synchronize only once per day.
Was that the "slave nameservers are not updating" issue that you were after?
Or was there another slave that had not been updating for a much longer time?
Generally, 24h out of date should not be that much of an issue. Of course, when it stopped
syncing completely that would be bad.
Rob
Through the kind courtesy of John, KI5D, mailman.ampr.org has a new
home, on a virtual host in Fremont Calif. It is now at IP address
199.249.223.193, and has a revised SPF record. This should significantly
reduce the spam filtering problems we've been having. The hostname and
web URLs have not changed.
Because of long times-to-live in the ampr.org DNS tables (1 day), your
mailer may still attempt to connect to the old address of 44.0.0.1 if you
send mail to the 44net(a)mailman.ampr.org or 44-announce(a)mailman.ampr.org
mailing lists. It's been about 12 hours since the address change, so
about half of the cache entries people may have should have expired by
now, but some will not have yet.
I've reduced the TTL on ampr.org DNS records to 1 hour from the previous
1 day to help prevent this sort of long cache delay from occuring in
the future.
If you send mail to the 44net or 44-announce mailing lists and the
connection is refused, you have the old address still and your mail
should be delivered on some subsequent retry when that entry has expired.
Or you might be able to flush the DNS cache on your mail host and retry
for faster delivery.
Similarly, if your web browser has the old address in its cache, you
will get a 404 error attempting to access the mailman web interface.
Flush the cache or wait.
Thanks John!
- Brian
--
44-announce mailing list
44-announce(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44-announce
Ever since I moved the 44net mailing list from 'hamradio' to 'mailman'
it's been running into spam filters.
This is caused in part by the fact that 'mailman' is actually an
alternate (duplicate A record) name for 44.0.0.1. The machine serving
as 'mailman' is itself dual-homed to both 169.228.34.84 and 44.0.0.1
but uses 169.228.34.84 as its outgoing email IP address, and I can't
change that. And UCSD blocks inbound SMTP to 169.228.34.84 as part of
THEIR spam filtering.
Another part of it was that the mailer on amprgw was identifying itself
as 'gw.ampr.org' instead of 'amprgw.ucsd.edu' which is its name when
looked up by the outgoing mail IP address of 169.228.34.84. This was
tripping spam filters which believed that the mail was coming from a
forged address.
Among other people, Marius wasn't getting 44net mail because of his site's
spam filtering objecting to the misidentification of amprgw's mailer.
I've corrected the mailer name issue; it now identifies itself on
incoming and outgoing mail as 'amprgw.ucsd.edu' which is its primary
name in the DNS. Mail to it as 'amprgw.ucsd.edu', 'amprgw.ampr.org',
'gw.ampr.org', or 'mailman.ampr.org' will all be accepted. (Although mail
to amprgw.ucsd.edu will be processed by UCSD's spam filters. Arrgh.) Mail
from it will come from a connection from 'amprgw.ucsd.edu'. This may
result in the need to adjust a few spam filters but will make other spam
filters happy.
The mailing list sender address will still be 'mailman.ampr.org'. I have
updated the SPF record for that hostname to include all the MXs for it,
and both addresses of it (169.228.34.84 and 44.0.0.1):
"v=spf1 +mx +a ip4:169.228.34.84/32 ip4:44.0.0.0/24 ?all"
With any sort of luck, this will appease the other spam filters.
The reason for all this complication is that I've had to condense two
machines, hamradio and amprgw, into one because hamradio is going away.
The reason for using 'mailman' as the hostname in the mailing list headers
is that we may someday move the mailing lists to their own machine with
that name (and it's own IP address!) and I don't want to go through the
pain of renaming the mailing list once again and having everybody have
to change their filters and address books again.
So if you encounter difficulties with the mailing list I apologize for
the confusion. If this is the first message you've received since the
list moved, then I've fixed your problem. If you find this message in
your spam mailbox, then I've broken it for you.
The basic problem is that there is no good solution for getting rid
of spam. SPF is incomplete and DKIM is just broken itself because it breaks
years-old tradition of mailing list formats. (It checks the Author address
['From:'] instead of the sender ['Sender:'] or error-return address
['MAIL FROM:' or 'From '] address.)
So people, including myself, resort to kludges of various kinds, all
of which are not fully satisfactory, and some mail just doesn't get
delivered.
It's a mess. Sorry.
- Brian
> I'm not sure it wasn't premature to go production on, but since this is
> also an experimental network, they could just be giving it a try.
I agree it is all about experimentation and learning. Learning that adding
an IPv6 address may unexpectedly break some things is part of that, and it
is better to experience it here that at work on some client visible site :-)
Rob
> >/I get 404 too, and I am IPV6. /> Same here, looks like an issue with incorrect IPv6 DNS information?
Same here on my dual-stack network. It is probably a result of the recent changes
that allow registration of AAAA records in ampr.org, and people experimenting by
adding an AAAA record for their hostname to see if that is working.
Not a good idea to do that when it either does not point to the same system, or
the services on that system (like http/https) are not configured to actually handle
the IPv6 case. I have seen this problem before when I added IPv6 capability to
my own network and the proxy at work: even some of the "big guys" got this wrong
especially in the early days. AAAA record in DNS but IPv6 not actually working,
or only for some protocols and not for others. And often no monitoring for IPv6,
so nobody noticing.
Usually, when this became obvious a slightly different domain name was used for
IPv6 testing (e.g. adding a 6 or .ipv6. somewhere), and that is probably what
people testing IPv6 on .ampr.org should do as well.
Rob
> The reason for all this complication is that I've had to condense two
> machines, hamradio and amprgw, into one because hamradio is going away.
> The reason for using 'mailman' as the hostname in the mailing list headers
> is that we may someday move the mailing lists to their own machine with
> that name (and it's own IP address!)
It should not be that difficult to run a mailservice on the same machine but
with a different address and name. I.e. add 44.0.0.2 to the machine, move
mailman.ampr.org there, and run all SMTP services on that address and corresponding
name. Then the move to the new machine is transparent.
But otherwise, it is a good idea to use virtualization as much as possible.
This can be classical hardware virtualization like we use (VMware ESXi)
but there are also leaner methods. That way, you can keep the different
tasks on separate virtual machines, on separate addresses with their
corresponding hostname, and there is also a lot less impact when one
time you want to update the OS or switch to another OS.
(e.g. you could run the mailman on Linux and the gw on BSD, and maybe
experiment with a new gw running on Linux, all on the same hardware)
Rob
Hi,
I'm moving my 44net connection from an OpenWRT device to a BeagleBone Black, because I've got a TNCblack to connect directly to a radio.
However, in testing I'm finding the 44net connection doesn't stay up, max about 36hours before a reboot is required.
Any ideas why this is, or how I could diagnose further. The device is always accessible via the local WiFi connection.
Currently I've just got this tacked onto the end of my rc.local
#Start 44net
/usr/sbin/amprd -d -v 2> /var/log/amprd/amprd_err.log > /var/log/amprd/amprd_std.log &
sleep 30
ip route add default via 169.228.34.84 dev ampr0 onlink table default
ip rule add from 44.131.170.1 table default
ip rule add from 44.131.170.1 to 44.131.170.0/30 table main
sleep 10
ping -Iampr0 -c10 gw.ampr.org > /dev/null
Device is on m1bkf.ampr.org - sometimes!
Thanks. Bill (M1BKF)
--
Red to red, black to black, switch it on, but stand well back.
> Because of the high volume of traffic on the 44net list as of late,
> Jann suggested creating an announce-only moderated list. That list is
> now online at44-announce at mailman.ampr.org. <https://mailman.ampr.org/mailman/listinfo/44net> It's separate from this
> list, so subscribers to 44-announce only won't see all the traffic on
> the 44net list.
And how about the reverse? Will announcement messages be sent to 44net as
well or do we all have to subscribe to the announce list to still get them?
In that case, it may be better to subscribe everyone to 44-announce that is
now subscribed to 44net?
Rob
The host 'hamradio.ucsd.edu', which is the current home of the '44net'
mailing list, is planned to be decommissioned in the next few months.
If everything goes right, on September 19th (Tuesday) morning (Pacific
time), I will move this mailing list from hamradio.ucsd.edu to its
new home on mailman.ampr.org, which is currently an alias for amprgw.
After the move, all future submissions should be sent to
44net(a)mailman.ampr.org, and the outgoing mail will be sent from that
host too.
Please be prepared to update your address books and spam filters.
All subscriptions will remain the same.
The archives will move there too.
I'll set up forwarding on 'hamradio' so that postings, replies, and
such sent to the old address will be forwarded to the new address for
some time, until 'hamradio' is decommissioned.
This is supposed to be simple. Wish me luck!
- Brian
Because of the high volume of traffic on the 44net list as of late,
Jann suggested creating an announce-only moderated list. That list is
now online at 44-announce(a)mailman.ampr.org. It's separate from this
list, so subscribers to 44-announce only won't see all the traffic on
the 44net list.
https://mailman.ampr.org/mailman/listinfo/44-announce
All postings to the 44-announce list will be held for review and
approval by the list moderators, so there will be some delay in message
distribution. I anticipate very low volume on that list.
I've set 44-announce to be a public list. The list will show up in
the general mailing list index on the mailman.ampr.org machine, and
the archives of the list will be available publicly so it's likely that
various search engines will index them. I've had significant problems
resulting from this policy in the past, but those were non-moderated lists
so maybe this will work better. The list of subscribers is not public.
Note that whether a list is public or private, fake names can subscribe
and harvest poster's addresses from postings and use them for spam.
Not much I can do about that if we're to still have the option of replying
to the individual poster.
It's a new list, so please be patient while I tune the parameters.
- Brian
I like the MIME version of the digest, but I am seeking advice on how to
add an option that I need.
On the "digest" version, when I turn on "Display Attachments Inline",
the emails appear looking like this:
... but in order to reply to an individual message, I have to find the
same email among the .eml files in the "Attachments" menu, and use that
to preserve the threading. I'd like to have a button I could click to
reply to an individual message from the screen shown above. I hope
someone else on the list has cured this in the past few days.
Bill, W4EWH
I like the MIME version of the digest, but I am seeking advice on how to
add an option that I need.
On the "digest" version, when I turn on "Display Attachments Inline",
the emails appear looking like this:
... but the .eml files which _are_ the individual emails do not appear
in the "attachments" bar unless I turn the option to display them in
line off, and there doesn't seem to be any way to reply to the
individual messages displayed as part of the digest, since when I click
the "reply" or "Reply to List" choices, I get a draft email which is a
copy of the digest, not the individual email I want to reply to.
The question is, then, how I can add (or turn on) an option to give me a
clickable link to reply to an individual post without having to turn off
the "display attachments inline" option.
Sorry to clutter the list: I hope someone else has come across this in
the past few days.
73,
Bill, W4EWH
Bill, W4EWH
> It's a single mbox format file that is broken up into individual messages
> which are stored in directories by date. A script to feed them into an
> NNTP posting program. There are currently over 10,000 such messages.
Well OK, it is not the kind of data volume that you could not afford to store in two different native formats.
(given today's size of disk drives etc)
> There are difficulties.
> The Mailman authentication data is stored as a Python 'pickle' (compressed
> dictionary file). There is a program to export a list of users, but
> it does not permit querying a single specific user, nor does it export
> passwords.
> NNTP has a Perl hook for authentication. Someone would have to write a
> Python program that could extract the necessary per-user data from the
> Python dictionary, and be called from the Perl NNTP authenticator.
Again a case where it would be so convenient to have a central store of authentication info that
could be queries by many different services...
E.g. when one of the APIs would be LDAP (as someone already suggested), it would be really
simple to write a Perl hook that does an LDAP query.
> Across the Atlantic. The NNTP server is in England, the Mailman mailing
> list is in San Diego.
My suggestion was to run INN on the gw server that now runs mailman, and keep it local.
You could run a couple of servers around the world, but of course each of them would
be facing the authentication issue. There should not be yet another "register here
for access" thing.
Rob
> >/A good project on AMPRNet would be to setup a user authentication /> >/system that can be /> >/used for our services without running the risk that some (ab)used /> >/party suddenly /> >/draws back the support, or delays validation of new applicants (if /> >/only due to lack /> >/of volunteers to do the validation). /> Now, this is a great idea. Could also be used for IPv6 netblock
> validation.
Yes, although a more dynamic method like BGP appears to be more suitable for that.
Such an authentication system should offer a method to authenticate users that want
to log on to some service and it should have some attributes for each user that
can be used in queries for authentication.
Things that come to mind:
- does the user have a (verified) amateur radio license
- category of the license (preferably with allowed band ranges)
- client certificate(s)
- password(s)
Probably more can be added.
The problem of course is the manual work required for license validation.
We could devise some method to use earlier validations by Echolink and LOTW,
but when we want to do our own validation we require the volunteers that look
at scanned license documents and accept/reject them.
An issue is the storage of so much personal information in a database, which
requires compliance to rules for personal data protection that are (or are
becoming) quite strict in many countries.
When we would have such a system on AMPRNet (preferably also usable from internet)
it could be used for many purposes where we are now limited in practice.
E.g. to set up a next-generation Echolink-like system that is open/free.
Rob
Maybe after the dust has settled it would be worth investigating to install a local NNTP server (INN)
and the mailman-to-usenet gateway? Or some way to give an NNTP server access to the mailman archive?
(I don't know how the archive is stored in mailman... is it just a collection of mail files, 1 message per file?)
Of course it would require some study and maybe some hacks, it would e.g. be nice when the NNTP
server authenticates the users using the mailman accounts (until we have that general authentication
service, at least...)
Rob
Thanks Brian
For all your hard work - very much appreciated here over all these decades
as well as those others that provide support to the amprnet
(Just making sure this works for me)
73 Paul G4APL(GB7CIP)
--
paul(a)theskywaves.net
On 9/16/17 4:44 PM, Chris wrote:
> Ah that old chestnut, it's a shame you choose to continue to be rude and
> obnoxious even though you know nothing about me or my circumstances. You
> know if I thought I could actually trust you to have a private conversation
> instead of broadcasting my private emails to a mailing list I would be
> happy to answer all your questions.
I cannot have a private conversation as a means to stifle debate on a subject
which affects all members of 44net.
The only option we will consider is to release the source code. To do
anything else when claiming to be for openness is hypocrisy.
You dangle a sword over all users of 44net and think we should be grateful for
not dropping it upon us. You recognize the difference between leading through
coercion and leading with better ideas, no?
--
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
Please note, I'm replying onlist as Chris wants to keep this "private" so
can't see how messed up this is.
On 9/16/17 5:17 PM, Chris wrote:
>> On 16 Sep 2017, at 21:55, Bryan Fields <Bryan(a)bryanfields.net> wrote:
>>
>>> You know if I thought I could actually trust you to have a private
>>> conversation instead of broadcasting my private emails to a mailing
>>> list I would be happy to answer all your questions.
>>
>> I cannot have a private conversation as a means to stifle debate on a
>> subject which affects all members of 44net.
>
> I was not offering to debate anything, just have a private chat and answer
> your questions.
>
>> The only option we will consider is to release the source code. To do
>> anything else when claiming to be for openness is hypocrisy.
>
> That is your opinion, based on assumptions.
Gee, if only there was an easy way to refute said "assumptions".
License your code under a free software license and submit it to the users.
>> You dangle a sword over all users of 44net and think we should be
>> grateful for not dropping it upon us. You recognize the difference
>> between leading through coercion and leading with better ideas, no?
>
> More opinion and assumption. FYI several other people have copies of the
> source code (which incidentally is not copyrighted by me)
It is. You wrote it and under federal copyright law you own it.
I would refer you to https://portal.ampr.org/site-terms.php
"AMPRNet refers to the group of individuals responsible for maintaining this
website. "
Assuming this is valid, you would be stating you own it as you are the person
responsible for maintaining that website. I'll ignore the several other
offensive claims on there for the time being.
> and the backend
> database is replicated in real time and under the control of other people.
Who?
> If anything were to happen to me, or indeed if I simply chose to walk away
> from it,
You walking away would be a good thing. The sort of "help" you've given is no
different than a drug dealer giving free heroin samples.
> 44Net would not suffer at all, it would just need someone else to
> host the portal, and I'm sure that would not be an issue. So I fail to see
> what this hypothetical sword you refer is.
You own the copyright of what you wrote. You have not licensed it as free
software. Under federal law you can revoke our right to use it at any time.
You've now got us hooked on your non-free software and we can't function
without it. When you decide things are going to change due to petty desires,
we're screwed. It's bitkeeper/pf/ZFS history repeating itself.
--
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
> There is another option. And I am kind of surprised it doesn't exist,
> or maybe it does and I am not aware of it.
> Someone who has a BGP announced allocation, like HamWan (for the US)
> could create their own (open source) portal for remote (non RF-LAN)
> users. They could also support things like OpenVPN in addition to
> IPIP, etc. I envisioned a series of regional portals, where non-RF
> users would hook up with the one closest to them. If you are in
> Europe for instance, I am pretty sure there is someone over there with
> a BGP announcement, and there could he a Europe portal for IPIP (and
> possibly other types of connections) to register with rather than back
> all the way to UCSD.
Yes, we do have that here in the Netherlands and I think it is also available
in a couple of outer countries (Germany, Finland come to mind).
For IPIP we require registration with portal.ampr.org, because IPIP is a full
mesh and we only participate in that, but for other protocols no such
registration is required and the tunnel definition is just created locally
at our gateway. We offer GRE, GRE/IPsec, L2TP/IPsec, IPsec tunnel, OpenVPN,
and of course our radio network.
Rob
> A private, ham only OpenID server? that should provide authentication
> as well as authorization for assorted servers. Make it stand alone &
> not tied to any particular service like amprnet or echolink or LOTW.
> make it freely accessible to anyone who wants to authenticate a ham
> anywhere.
Yes, that is the basic idea, but it should not be limited to website usage
and it should be possible to retrieve attributes such as "is this a verified
licensed hamradio operator". The user list could contain outsiders,
unverified hams and verified hams, and the facilities available to them could
be different. E.g. a user who is not a verified ham would not be able to use an
Echolink-like service, but they could read and contribute to a mailinglist.
The service should offer some different APIs, e.g. RADIUS for user/password
authentication and maybe something like OpenID for website logon.
When a user has a valid account, he should be able to obtain client certificates
for use in services where that is appropriate.
The PKI design has to be careful, with some attention to detail a lot of
mishaps can be avoided. This requires expertise in the matter.
Rob
Hi Chris,
I just tried your 44.131.151.2 NNTP server from my 44.135.92.10 machine
and was refused.
Ron
VE3CGR
> We've been running a news server (inn) for years. I've already put reader access in for ampr.org hosts to provide the same service that Brian provided on the machine that has died and is being decommissioned, it's on 44.131.151.2 or on the public Internet as nntp.comgw.net
> It wouldn't be difficult to setup some local groups just for amprnet use, it would also be fairly trivial to pipe this mailing list into a local group if that is of interest to anyone?
> Chris
> A private, ham only OpenID server?
This is similar to an idea I had several years back (2012 according to the
registration for my unused domain hamauth.com), but I couldn't find anyone
else at the time who was interested in it. As a result, it never won any
battles for my limited availability of time to work on it. :(
The basic idea was to define various assurance levels that people could
meet using various methods. Then, allow amateur radio websites and
services to define what level of assurance they need and allow them the
option to easily authenticate their users using a hosted service (using
things like OpenID or OAuth).
Those levels could be something like:
- Identity, call sign, operating privileges, and mailing address all
verified
- Call sign, operating privileges, and mailing address verified (LotW
gets us here)
- Call sign and operating privileges verified (We can verify their
license is valid, but only assume they're the legitimate holder of it until
it's challenged, somewhat like how qrz.com does it)
- Call sign claimed (not all countries have license info online for
verifying privileges)
- Non-amateur (not yet licensed)
For example, if a user can prove to us they have control over a valid LotW
certificate, they would get one of the highest levels of assurance because
we know the ARRL has already confirmed the validity of their license and
that they can receive mail at the license address. The user would then be
able to login with their call sign on just about any site that chooses to
use our service for authentication. However, some sites may not choose to
trust our third party service directly, so we could also be a resource on
how they could setup their own authentication and verification schemes.
While it might be a pain to get a LotW certificate, they are the only
organization I'm aware of that offers to authenticate amateurs from any
country. It's essentially a service they created to be globally trusted in
order to protect the integrity of their contests. In the past they've also
expressed a willingness to allow their service to be used for other general
amateur authentication purposes, so I don't think we need to worry about
them objecting to anything like this.
Also, there's no reason why the ARRL has to be the only source of that
trust. For example, if you have a valid client certificate loaded in your
browser with your call sign in the right place, we'll accept it on the
HamWAN portal ( https://encrypted.hamwan.org/ ) whether it's signed by
ARRL, or of it's signed by HamWAN's own certificate authority.
If there are other organizations in other countries that can authenticate
licenses in an easier fashion, we can definitely include them in the
process. They way other amateur services would just need to check a box
that says they trust that entity to validate users from that country.
I'm exceeded to see several others interested in this, but since it's
off-topic for this reflector, please join me in the new hamauth group. ;)
Click:
https://groups.io/g/hamauth
or
Email:
hamauth+subscribe(a)groups.io
Cory
NQ1E
Hello, I posted here a while back but have not made much progress.
I am a new Ham operator interested in packet and digital modes. I have
a small home setup with a terminal node controller attached to a vt100
terminal, I have been using it to reach the only other 2 packet
stations i was able to find in my area.
I have an interest in tcp/ip and wanted to try and connect to the 44
network if possible. I have had trouble finding information and
getting started.
I have a big interest in using some big older ibm gear. I have found
many programs that should get the job done, of interest is ka9q net
nos.
I have the hardware, the tnc, the computer, I am just uncertain of how
to go about using the software. Im having a real hard time finding any
local help on the subject. Ive tried no less than 3 of the local
clubs, none seem to have any members that even know much about packet
or tcp/ip over radio.
Ive asked around on a couple of the local repeaters as well, asked
some questions at the end of the weekly nets, only to find that there
does not to be anyone around with much knowledge on the subject.
I want to get started with this, i look to have all the hardware
needed to get it working but need advice on how to proceed. Any help
is much appreciated.
> Why not use LOTW for authentication?
> It's been done before and if you are LOTW verified it means that you are a radio amateur
It has also been done before (ab)using Echolink for authentication.
However they do not seem to like that, and probably rightly so.
(it puts the burden of license validation on them)
The same is probably true for LOTW when it would be heavily used outside its scope.
Some services require some form of client certificate, others (like NNTP) are better
off with a username/password. Both have to be catered for.
A good project on AMPRNet would be to setup a user authentication system that can be
used for our services without running the risk that some (ab)used party suddenly
draws back the support, or delays validation of new applicants (if only due to lack
of volunteers to do the validation).
Rob
I don't use the e-mail client to "reply". I have set the list to digest mode, the daily digests
I move to a separate folder that effectively is a trashcan, and I read the topics via the mailman
archive site where I cut and paste parts into a new mail message every time.
So no threads from me.
I don't like mailing lists. At ALL. Precisely because thread management is so difficult,
uninteresting threads cannot be killed, and traffic comes in between normal mail.
I would propose setting up a small USENET server with one or a couple of groups and then
use a newsreader to read and reply to the threads.
But that is apparently considered old-fashioned as well by some, and newer methods
are considered unacceptable.
So, no change. Live with it. Make a processing rule in your mailclient that dumps the 44net
mail in a separate folder, so your Inbox is left clean.
Rob
> >/The problem is that many readers get the "Digest" version of this list, /> >/which means that they don't have any easy way to respond to a post from /> >/a digest, without breaking the threading info that needs to be included /> >/in the reply's headers. /
> This is rather easy, and incumbent on the digest users.
> 1. In your list preferences, "Get MIME or Plain Text Digests?" needs to be set
> to MIME.
> 2. In the digest now you will have a link to click on as a reply.
The problem with that is the digest only arrives once per day, so you will
be replying quite late and the whole discussion becomes very difficult to
track when some people reply right away and others reply after receiving the
digest.
Rob
So if he was not run off from all of the Social media vs email list stuff.
Sherman W4ATL joined the list to answer any Data Radio questions. Sherman
was the chief engineer at DR when I was there. His knowledge is going to
be pre-cal amp take over. So any of the current off the shelf stuff is
going to use proprietary information that I doubt Cal-Amp will publish.
Even the older stuff uses proprietary code mmunitariona protocals, but the
ability to hack these is likely as they are just Z80 processors. So
Sherman if your still here and are willing to answer any questions go for
it....
Lin N4YCI
Applying for a LOTW cert is a rather painful and intrusive process outside of the USA.
Josh
-------- Original message --------
From: Ruben ON3RVH <on3rvh(a)on3rvh.be>
Date: 15/09/2017 20:01 (GMT+10:00)
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] USENET news on AMPRNet
Why not use LOTW for authentication?
It's been done before and if you are LOTW verified it means that you are a radio amateur
73,
Ruben - ON3RVH
-----Original Message-----
From: 44Net [mailto:44net-bounces+on3rvh=on3rvh.be@hamradio.ucsd.edu] On Behalf Of Rob Janssen
Sent: vrijdag 15 september 2017 11:43
To: 44net(a)hamradio.ucsd.edu
Subject: Re: [44net] USENET news on AMPRNet
> Don't solve a problem that doesn't exist.
> Usenet access is readily and economically available. There are enough
> providers that there are sites that review which is best.
> Google for 'usenet providers' and see for yourself.
The idea of course (at least I think) wasn't to provide generic usenet access on AMPRNet. Instead, it would be used for closed access discussion like this mailing list. Only a couple of hamradio related groups.
Of course this immediately shows the practical problem: the authentication of valid users. You would need to maintain a table of users similar to what the mailing list now has, and when you want a couple of news servers around the world, you would want this access information to be somehow synchronized between them.
Additionally, you may want some groups accessible to "any radio amateur".
But then you run into the problem that has been encountered so often: how to authenticate a radio amateur without maintaining yet another user list where new applicants have to be validated by people who would prefer to do more valued work.
Rob
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
> Don't solve a problem that doesn't exist.
> Usenet access is readily and economically available. There are
> enough providers that there are sites that review which is best.
> Google for 'usenet providers' and see for yourself.
The idea of course (at least I think) wasn't to provide generic usenet access
on AMPRNet. Instead, it would be used for closed access discussion like this
mailing list. Only a couple of hamradio related groups.
Of course this immediately shows the practical problem: the authentication of
valid users. You would need to maintain a table of users similar to what the
mailing list now has, and when you want a couple of news servers around the
world, you would want this access information to be somehow synchronized between
them.
Additionally, you may want some groups accessible to "any radio amateur".
But then you run into the problem that has been encountered so often: how to
authenticate a radio amateur without maintaining yet another user list where
new applicants have to be validated by people who would prefer to do more
valued work.
Rob
> If you're one of the very few people who have ever taken advantage of
> the ability to read USENET news via AMPRNet and the news.ucsd.edu server,
> you should be aware that that server is failing from old age and will be
> taken out of service soon. We don't plan to replace it; Usenet itself
> is fading away. I co-authored the NNTP protocol some 31 years ago;
> that's a pretty good run for any internet standard.
I wasn't aware that there was any special service from news.ucsd.edu towards
AMPRNet... does it carry any special groups other than rec.radio.amateur.*?
Fortunately my ISP still maintains USENET servers, two separate clusters
even, one for what we used to use for news and another one dedicated to
moving large blobs of gibberish :-)
Indeed I see your name above RFC977! Great!
I once maintained a CNEWS server for a company, which used a UUCP batch
feed over a 9600 baud phone modem. The group list had to be trimmed all the
time so it would not get behind so much it would never catch up, and the
200MB spool had to be carefully watched as well. Those were the days...
Greetings, friends, allow me comment on this topic and after having seen
all the comments, I would like to express too.
Many of us who are already time in the Amprnet understand the rules to be
followed by our great friend Brian Kantor as proyect lider who for many
years now does much to keep the Amprnet 44 together with many contributions
from many other colleagues. Gentlemen, the world has advanced a few years
since IRC, Usenet, etc, we are in time to think that social platforms are
now important or more than before, more powerful than the conventional ways
of communication, and I think, that we should use for Amprnet chat in
privately (private group).
If the information is more confidential for any reason the social networks
are not used, and exits now other routes that are used now. But Facebook,
for example, would serve to us as a more "real" link between all the
Coordinators and people with whom we can share general information of this
activity of this tecnical HOBBY and sure may to grow in friends and should
not be confused with our professional activities in this environment.
In my case I would like to have contact via Facebook with Brian or any
Regional Amprnet Coordinators and have a more relaxed arena to be able to
speak general topics of our Hobby.
73 de Gabriel YV5KXE.
Venezuela Amprnet Coordinator
----------------------------------------------------
1. Re: New Facebook Group (Richard Chycoski)
*************************************
> Bandwidth, no data, but it's likely low. Email is a low-bandwidth
> application. There are about 700 subscribers.
> The entire Mailman installation, including the contents of the archive,
> is small, about 200 MB. Most of that is the archive.
> You could probably host the whole thing on a Raspberry Pi with a USB
> stick, but I wouldn't want to.
When you need hosting for that kind of service we can offer a VM on our VMware ESXi 6.0
host in Amsterdam (on 44.137.42.0/27, BGP routed via 44.137.0.0/16).
There are 2 HPe Proliant servers each with local RAID-1 disks, a VM image is copied from
one host to the other nightly and we can change over manually on catastrophic hardware
failure. Offsite backups of the VM images are made as well.
It is connected to Internet at 1 Gbit/s and to our radio network at 40 Mbit/s.
Network access is via a MikroTik CCR router providing firewall configurable at port level.
This is where gw-44-137 runs.
Rob
All,
I've noticed some pings from portal.ampr.org:
> 2017-09-11 17:32:25.846 48.191 ICMP 81.174.235.134:0 ->
> 44.60.44.10:8.0 38 3192 1
Is this an automated software pinging?
- Lynwood
KB3VWG
Personally, I think Facebook is a terrible choice. User information there is not protected and is monetized. As a discussion forum it is useless. It is ad laden, tracker laden and not user friendly. I don't have a Facebook account anymore and I am not interested in getting one.
This forum email list works fine for me. If we need another email server there are several in the amateur radio community to chose from, including TAPR. If we want a commercialized product, there is groups.io which has a large community of ham radio related lists, mostly migrated from yahoo.
Just my opinion.
73 de bill K7WXW
> How about we start a second email list to discuss where to have future
> discussions?
The advantage of a USENET server is that you can create groups for different types of
discussion. Clients also typically offer "kill thread" functionality that makes them
ignore future postings in the same thread.
Rob
Bill,
The best person to answer is Brian Kantor. Till he chimes in...
I don't expect to see IPv4 switched off on the general internet in my
lifetime. The adoption rate of v6 is pretty sad. We don't even have
everyone dual stacks yet.
There has been some casual discussions from foreign hams to try and
get an IPv6 allocation for ham radio from RIPE ( I believe).. but
there will be so many addresses available I am not even sure ham radio
needs its own allocation.
Moving forward the whole online ham authentication thing (that OH7LZB
has pointed out) makes more sense in my opinion. Use one of your
many-many IPv6 addreses from your ISP, but add some sort of
authentication to the process of interacting with other ham services.
That is presently a lure of 44net.. knowing the guy on the other end
is a ham, and whatever traffic is being generated (VOIP, data etc)
should it key an actual transmitter it will be legit.
[There was a proposal in 1998 to encode a "call sign" into IPv6
address titled "Take the Next Step with the Next Generation Protocol"
by Naoto Shimazaki. And in 2012 a few members from the Mesa Amateur
Radio Club of Arizona took this to code.)
I guess the more pertinent questions I have for Brian would be:
Are there a plan so that folks who only have IPv6 commercial address
or are suck behind carrier grade IPv4 with no firewall access (some
cellular carriers presently) can participate with the amprnet? In
other words are there plans to make amprgw dual stack?
73
Steve, KB9MWR
>OM,
>
>I'm a bit behind the times, so please bear with me. Is there a plan
>and schedule for ampr.net to convert to IPv6?
>
>Is there a consensus on the conversion? We're a pretty small part of the net, after all, and my first >reaction to thinking of IPv6 is "Do I have to?"
>
>BTW, will ucsd be able to tunnel IPv4 44/8 addresses over IPv6?
>
>As I said, I'm out of practice with networking, and I just realized that I don't know if/when the ampr.net >will switchover, nor how it will affect the existing 44/8 allocations. Brian?
>
>Thanks for your time.
>
>73,
>
>Bill, W4EWH
Not a fan of facebook either. this email list works just fine for me.
73 Russ WL7LP
--------------------------------------------
On Sun, 9/10/17, Brian Kantor <Brian(a)UCSD.Edu> wrote:
Subject: Re: [44net] New Facebook Group
To: "AMPRNet working group" <44net(a)hamradio.ucsd.edu>
Date: Sunday, September 10, 2017, 6:16 PM
I think this was a bad idea.
- Brian
On
Sun, Sep 10, 2017 at 09:24:38PM -0400, Bill Horne wrote:
> I've put up a new group on Facebook,
called "AmprNet." The title is short
> and to the point, but doesn't call out
our IPv4 history.
>
>
Feel free to join and comment.
>
> 73,
>
> Bill W4EWH
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
-----Inline Attachment Follows-----
Ronen wrote:
> Idont understand the huge objection you all have for facebook its much better you can post Photos Videos files ETC
In 25 years being involved with net 44, I don't ever remember a photo or video being required.
I cannot think of any way that it is better than a concise archive of technical text which is searchable
and cached onto my PC as a mail file. It can't be manipulated or deleted without my consent.
I don't wish to be exploited/monetised so will not do business with Facebook. Reminder:
https://notallbits.files.wordpress.com/2011/10/facebookandyou.jpg
Therefore I shall not consider visiting any Facebook material.
Jason G7OCD
Except that it excludes all of us that don't use facebook from those discussions, which seems like a high price to pay for a formatting change.
Josh
-------- Original message --------
From: Lin Holcomb <LHolcomb(a)clearqualitygroup.com>
Date: 11/09/2017 12:46 (GMT+10:00)
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] New Facebook Group
Brian,
It is a much cleaner discussion format than email.
Lin
On Sun, Sep 10, 2017 at 10:16 PM, Brian Kantor <Brian(a)ucsd.edu> wrote:
> I think this was a bad idea.
> - Brian
>
> On Sun, Sep 10, 2017 at 09:24:38PM -0400, Bill Horne wrote:
> > I've put up a new group on Facebook, called "AmprNet." The title is short
> > and to the point, but doesn't call out our IPv4 history.
> >
> > Feel free to join and comment.
> >
> > 73,
> >
> > Bill W4EWH
> _________________________________________
> 44Net mailing list
> 44Net(a)hamradio.ucsd.edu
> http://hamradio.ucsd.edu/mailman/listinfo/44net
>
--
Lin Holcomb
Office: +1 404 806 5412
Mobile: +1 404 933 1595
Fax: +1 404 348 4250
> Well Bill, what has happened is that USENET has condensed into
> a few central sites exchanging the articles, and accepting subscriptions
> from people who still want to read/post to the newsgroups. It's the
> distributed model that's died.
But that is just the "story of the internet". It has happened to (almost)
all services on internet. Even e-mail, traditionally a very distributed
service, is now mostly offered by a few central sites like gmail.com and
outlook.com/hotmail.com.
Sure, in implementation those central sites still often are distributed
(being hosted in many different datacenters on many servers all serving the
same domain name), but it no longer is the big peer-to-peer network that
it once was. This also explains the slow take-off of IPv6: there is rarely
a need anymore for a different address for everyone.
Rob
Hi guys,
Could you please check if your email clients do support threads
properly? At least some of you are using ones that do not answer in a
same thread but create a new one. For me it makes this list unreadable
and a whole mailbox cluttered.
I'm looking mostly at (random order, just what I've came across) Daniel
Curry, Steve L and Rob Janssen, but it's important that we all keep the
high standards ;)
--
All the best
Paweł SQ9PID
I was working at Sun Micro system with Sunos 3.2 and up to Solaris 4.x.
That thing I did not like about 3.2 and 3.5 is that you had to mount the
ND partion user home directory to fixed a problem. There was no CD
directory command.
--
Daniel Curry
California American Legion Amateur Radio
Area 2 Commission and Chairman.
US Air Force Veteran
IPV6 Sage Certified
PGP: AD5A 96DC 7556 A020 B8E7 0E4D 5D5E 9BA5 C83E 8C92
San Francisco/Silicon Valley AmprNet Co-coordinator [44.4.0.0/16]
For those of you who are or have been users of the Solaris OS, you
should find the following article interesting. Among other things,
it once again points out some of the advantages of open source.
http://dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-and-eternal-life-of…
I mention this because there are those who have the impression that
'amprgw' is running on Solaris. It is not; it never has. It ran on the
predecessor, SunOS, for some years, but has been running on FreeBSD for
a long time.
- Brian
Lin,
Some time back I picked up a pair of Gemini G3 Dataradios on ebay,
hoping to be able to use them. I quickly learned they really cannot
be used point to point, and you need the expensive base station to act
as a controller between them.
I swear I have read that some models of the radios are capable of
point to point/ peer to peer use. Do you or anyone else know which
models would be good candidates for such a thing?
I ended up giving them to a friend who documented them the best he could:
http://www.qsl.net/n9zia/gemini/index.html
> Y'know, there is some relevance in a significantly asynchronous circuit
> with this stuff.
I think the correct label is "asymmetric" but many people call it "asynchronous"...
> Put the High speed TX on the top of the mountain and have it push high
> speed frames in broadcast or multicast mode whilst the outlying stations
> listen to the stream and write down the packets relevant to them.
This is of course what I had in mind. We don't have any mountains here but we
have a 3cm ATV repeater at 220m in a broadcast tower transmitting a DVB multiplex
where we could use some bandwidth (or e.g. the bandwidth remaining after the
several variable-rate encoded ATV channels have had their share) to transmit
IP over DVB. Both broadcast/multicast traffic (like IPTV streams from the repeater) and
traffic to a single endpoint (after all, we do not hide traffic from eachother).
The return channel could be much slower indeed, depending on the kind of traffic
and the required return traffic. Maybe even a 9600+ baud packet link, or one of
those newly developed 70cm links of about 400kHz width.
At the moment the repeater is not operating, but we are working on getting it back
on the air.
Rob
While I applaud Ron's experiments, it would have a very long road to
becoming something practical for the masses. Heck I can say the same
for the NWDigital radio. They have been trying for quite some time to
make the thing happen. I fear by the time either would come to
fruition, the whole market / tech landscape could be different. (I.e,
56k is not as appealing at the price point as it was 10 years ago when
they started, etc)
As for the ARRL, I am the only one who pounces on their staff
virtually every chance I get (at ham fests and by email), about
getting some of these changes though their heads? I think a
coordinated approach, can help our cause. In addition, anyone can
make comment directly to the FCC. How seriously they take things
without someone waving money in their face is a whole another issue.
I wrote this paper quite some time ago, that covers quite a few of the issues:
http://www.qsl.net/kb9mwr/projects/wireless/70cm-ATV-HSMM.html
Basically they way I see it, one has three ways to experiment:
1.) Pay for/file for a STA, which gives you 6 months
2.) Include some element of image transfer, so what your doing can be
classified as an image transmission rather than data. (most
logical/easiest to do)
3.) Develop a data mode that uses multiple carriers, as each carrier
can be 100 KHz wide.
#3 is something I joked with friends about when I was in high school.
That was long before SDR, so we envisioned taking a few TNC's and
radio's on different frequencies, RF combiners and tons of filters to
make it actually work, and from there channel bond/load balance all
the data streams to achieve better throughput.
Do we have anyone who holds a ARRL position on this list?
Steve, KB9MWR
Mark Phillips <g7ltt at g7ltt.com> wrote:
>
>"Maybe someone at ARRL ...."
>
>Ha! Funny.
>
>It's been many folks' experience that the ARRL does nothing that is not in
>its own interest. Unless they can be persuaded that XYZ technology is good
>for them and Ham Radio they won't lift a finger. It should also be noted
>that the ARRL speaks for less than 20% of the US ham population (see
>membership figures posted in QRZ). We are 700K+ hams here in the US. ARRL
>has less than 100K members. That said, they are the only group able to
>engage the FCC and push for changes etc. It's an expensive proposition!
> Setting up a NNTP server is easy in JNOS. Pretty tricky on Linux...
Actually it is easy, just "apt-get install inn" and editing a couple of config files.
Of course you first need to understand the architecture of USENET and the INN software
but there is documentation available. It is comparable to the complexity of configuring
JNOS when you have not done that before.
Rob
> USENET is obsolete. Don't waste your time on it.
Well, not as obsolete as a mailing list...
A closed news server would be much more convenient to use for discussions like this than a list...
(and of course you could run it on a Raspberry Pi :-)
Rob
If you're one of the very few people who have ever taken advantage of
the ability to read USENET news via AMPRNet and the news.ucsd.edu server,
you should be aware that that server is failing from old age and will be
taken out of service soon. We don't plan to replace it; Usenet itself
is fading away. I co-authored the NNTP protocol some 31 years ago;
that's a pretty good run for any internet standard.
If you really need your Usenet fix every day, you might want to
investigate www.eternal-september.org, which offers free Usenet access
(but has very limited resources).
- Brian
Brian,
Can we make this list open to just those named in the description of the group… amprnet users and gateway operators for ops related items.
--
Fredric Moses - W8FSM - WQOG498
fred(a)moses.bz
> I think you meant /48’s or at least a /63 -- a /64 is meant to be the
> smallest subnet -- it is not meant to be sub-divided any further. Because
> some ISPs are allocating /64’s to their customers, I also think a ham-radio
> allocation would be good.
A /64 would be enough for a radio amateur with a simple network who wants to join
a ham-radio network. It would surely not be optimal, but I would not expect an ISP
that is that clueless (to allocate a single /64 to their customers) to be willing
to route foreign network space to their customers. So what use would it be to
have portable address space as a solution for that?
Rob
It's important to be aware of the timeline but this anniversary might
also be a good time to look back at the history and think about the
impact this assignment has made.
What *new* technologies has been developed because of this network?
Which crises have been mitigated using this network? Have it helped to
spread the HAM radio "spirit" to the young people? What other good
things have this network done?
It's very sad for me to say that the only thing I can see about this
network is a bunch of guys trying to stick with old technology (RIP?
please.) at all cost and arguing who is more important in a tree of
people allocating numbers.
A /8 network is a great value nowadays, the IPv4 especially in Europe is
in a huge crisis and getting new addresses is nearly impossible. From
the other hand most of the address space in this network is unused but
when you try to request allocation for yourself you can easily get
rejected because of silly reasons. (I didn't even try to request one for
myself after my friends showed me the coordinator responses.)
There might be some things going on the used parts of the network but I
couldn't find any example that could be genuinely useful to the world.
Could you please prove me wrong or if I'm right try to consider sharing
the address space with a "new" movement of hacking and hackerspaces? HAM
radio should be all about hacking [1] but frankly speaking I don't see
much of it in HAM radio space these days. There are some exceptions -
i.e. "OFDM modem" thread from the last days but there are as rare as
freakin' unicorns.
This message is not meant to be mean. I'm just trying to pinpoint some
things I've seen as an observer of this network and HAM radio (mostly in
Poland but also the "worldwide" parts) and share some ideas how the
things can be done better and provide a better value to the whole world.
[1] https://en.wikipedia.org/wiki/Hacker_culture
--
I wish you all the best
SQ9PID
Hi,
Try "sixornot" for IPv6
status: https://addons.mozilla.org/en-US/firefox/addon/sixornot/
It works great for me with FF release 55 and 56 beta.
Depending upon what version of Firefox you're using the web site may
say "This add-on is not compatible with your version of
Firefox.". This is due to Mozilla killing off all add-ons not
implemented with WebExtensions starting with FF version
57. sixornot will still run fine up through FF version
56. Download it anyway! After FF 56 you'll have to switch to the
PaleMoon browser (sixornot works great on it for me too).
73,
-Tom WS7S
At 12:16 PM 9/4/2017, you wrote:
>Does anyone know of nifty little firefox add-on that will denote that
>you are connected via IPv6 to the site? I'd like to be more aware of
>what all supports it in the course of my general browsing. I think
>that could really bring an awareness. Kind like the more recent "This
>site may not be secure" when Browsers detect login details over a non
>HTTPS connection.
>
>Having to sniff it with netstat to tell if its 4 or 6 is less than appealing.
John,
I see IPv6 to http://nw7dr.ampr.org/ with netstat:
TCP [2605:a000:1508:c178:78a8:fe60:2b78:1495]:65219
[2001:470:b:40f::3]:http ESTABLISHED
TCP [2605:a000:1508:c178:78a8:fe60:2b78:1495]:65220
[2001:470:b:40f::3]:http ESTABLISHED
TCP [2605:a000:1508:c178:78a8:fe60:2b78:1495]:65221
[2001:470:b:40f::3]:http ESTABLISHED
Pinging k7ve.ampr.org [2001:470:b:40f::2] with 32 bytes of data:
Destination host unreachable.
Destination host unreachable.
Pinging nw7dr.ampr.org [2001:470:b:40f::3] with 32 bytes of data:
Reply from 2001:470:b:40f::3: time=99ms
Reply from 2001:470:b:40f::3: time=102ms
Reply from 2001:470:b:40f::3: time=117ms
Does anyone know of nifty little firefox add-on that will denote that
you are connected via IPv6 to the site? I'd like to be more aware of
what all supports it in the course of my general browsing. I think
that could really bring an awareness. Kind like the more recent "This
site may not be secure" when Browsers detect login details over a non
HTTPS connection.
Having to sniff it with netstat to tell if its 4 or 6 is less than appealing.
> Phil Karn, KA9Q, invented the /N network-bits-width notation back in ham
> AMPRNet-related documents in the 1980s, so it should be more properly
> known perhaps as "Karn notation" rather than "CIDR notation".
That certainly would be good, he has done tremendous work for the acceptance
of internet protocols.
> I like to bring this up from time to time to remind people that inventors
> deserve credit especially when they don't charge for their inventions.
Some time ago I noticed that my hack in PE1CHL-NET version 950819 (Aug 19, 1995):
TCP SYN packets are examined when routed, and the MSS option will be
adjusted down to the maximum MSS possible on the incoming and outgoing
interfaces. Thus, a more optimal end-to-end MSS is chosen, and
fragmentation is avoided (e.g. when running IP over NET/ROM somewhere
inbetween the endpoints)
pre-dates the addition of this feature in e.g. Cisco routers (ip tcp adjust-mss)
by several years.... that would certainly have been patentable...
> I'm reminded of this because Phil and I had dinner last night (he's
> doing well, thanks) and got to chatting about the old days of packet
> and AMPRNet.
Great to hear that!
Rob
>> I guess the more pertinent questions I have for Brian would be:
>>
>> Are there a plan so that folks who only have IPv6 commercial address
>> or are suck behind carrier grade IPv4 with no firewall access (some
>> cellular carriers presently) can participate with the amprnet? In
>> other words are there plans to make amprgw dual stack?
>
>(I think you meant 'stuck', not 'suck'. Is that a Freudian slip?)
>
>There's no plan to make amprgw dual stack. I'm not sure that the question
>is meaningful; what would it DO with an incoming IPv6-only packet?
>It's not going to be a NAT64 gateway, that's for certain.
Okay, its just something I have been wondering. I feel as commercial
IPv4 addresses become more scarce, and more carrier grade NAT comes
into play there will be more hams looking for solutions for the
various internet ham radio services (IRLP, Echolink, D-Star etc),
where they need the ability to control their port forwarding/firewall
stuff. Basically I see a large number of folks seeking commercial VPN
services.
>
>Interoperability of IPv4-only and IPv6-only hosts is a sticky wicket
>that in my opinion NO ONE has solved satisfactorily.
>- Brian
I am slowing learning what a complicated mess it is (going to be) myself.
> My interpretation of the question was whether the gateway would support
> tunnels running over IPv6 to carry 44/8 traffic. That way, endpoints on
> DS-Lite, for instance, could tunnel their 44/8 traffic over IPv6, and
> those of us with dual stack might be able to avoid the usual issues with
> routers that don't support IPIP encap packets over NAT properly.
I'm not sure amprgw is the place to do that. The IPIP tunnel network is a mesh, and
such endpoints would not be able to participate in the mesh.
On the other hand, local gateways could offer this service to local users, when
they are both on IPv4 (to participate in the mesh) and IPv6 (to service local users).
E.g. we offer connectivity to local users on our gw-44-137 using various different
protocols (all over IPv4):
- IPsec tunnel
- GRE (with or without IPsec)
- L2TP/IPsec
- OpenVPN
Some IPv4-over-IPv6 protocol(s) could be added to that when the need arises.
However, all ISPs offering IPv6 locally that I know of, offer dual-stack.
There have been some requests to offer IPv6 inside our hamnet, but we are not
quite ready for that yet (depending on support in routers etc). However, I
never received a request to setup a tunnel over IPv6.
Rob
> Someone else with a more thorough understanding of the IPv6 address
> allocation procedure can explain why there will never be a ham-radio-only
> block of IPv6 addresses akin to the IPv4 AMPRNet 44/8.
It would not be a good idea to have that, because we would again be faced with the difficulty
to get it connected and routed. The whole tunneling and BGP issue all over again.
When we just want some IP space on internet it is much easier to have everyone use the IPv6
netblock they get from their local ISP, and compile some list of netblocks that are assigned
to hamradio that way. So everyone just connects their stuff to internet, and where required
imports some list of netblocks that they want to talk to.
The distribution of that list can be done using similar mechanisms as are now being used
for the tunnel mesh:
- use a file that is posted somewhere and that can be downloaded
- use some API to retrieve the data (like on the portal)
- use a central system that sends the info using some routing protocol (like the RIP daemon)
- setup an ad-hoc mesh network that distributes the info peer-to-peer
I think the latter option is the best. We can use multihop BGP where everyone connects to
a couple of friends and maybe some higher-tier service in the country or continent and they
advertise their local netblock(s) there. BGP will compile a table of all netblocks advertised
by hams, without any need of a central service or authority. You only need to setup a couple
of peerings (a full mesh is not required) so most outages will be covered. This table of
netblocks will not be used for routing, only for source-address filtering for ham-only
communication.
The actual routing over-the-globe will be done directly by the ISPs, no tunneling or special
arrangements required, the netblocks are just part of their standard allocation.
Locally, you can route over radio in additional to this, using whatever routing protocol is
locally customary. When properly configured, radio paths will be taken where possible and
other traffic will be routed over internet.
I am not the only one proposing this. Daniel Estévez EA4GPZ and others have written about it
as well.
The reason this is possible on IPv6 is that you normally get a large chunk of addressing space
from your ISP so you can easily carve out netblocks to be used for different purposes.
When getting IPv6 from your ISP, you should check that they DO assign you multiple netblocks,
as is recommended in all IPv6 deployment strategies, but not all ISPs do understand that.
(also, it is of course best when your allocation is static and does not change every day or so)
Rob
> The one thing I know that we need to request is elimination of symbol-rate
> restrictions, to be replaced with bandwidth restrictions.
I think you should not focus too much on symbol-rate restrictions. As has already
been written, using a high symbol-rate usually is impractical anyway. It is better
to use techniques like OFDM that combine a high bitrate with a low symbol-rate.
You only need to ensure that you can use the bandwidth that is technically required
for the experiment you want to run, within the limits of the band and the bandplan,
and without causing intentional interference to other users.
(i.e. you don't use the entire band. you don't cover the existing small-signal
and repeater allocations with your strong wideband signal, etc. spread spectrum
allows for some co-existence of wideband signals and other users, but it is not
what I am referrring to here)
Rob
> Ultimately, IPv4 just cannot handle the demands of the modern Internet,
> the emergence of IoT (that being a good or bad thing is another matter),
> etc. The world needs to move on to IPv6.
Actually the problem is less for "the modern Internet" because that has transformed
from a peer-to-peer network into a client-server network where most of the users are
only connecting to a couple of services, and the presence of NAT is less of a problem.
When IPv6 was designed, the designers still believed that every device should be able
to communicate with every other device. A peer-to-peer network. That was already
frowned upon at the time. Why would my refrigerator need to talk to yours?
But as the problem if malvolent users (usually called "hackers" in the press, although
that word originally has a different meaning) is becoming more and more prevalent,
firewalls have been deployed everywhere and such communication is not possible anyway.
Now, when ISPs deploy IPv6 for their customers, the routers they provide are by
default configured with a stateful firewall that allows only outgoing connections
and possibly has capability to "open" communication to some specific device/port.
This is roughly the same as an IPv4 router with NAT and port forwarding.
So, while some expansion of the address space is desirable due to the increasing
number of users, it certainly is not as critical as the IPv6 proponents claim.
(that also explains why the deployment of IPv6 has been such a fiasco)
Rob
Well we just heard a few days ago that some foreign hams don't have a
bandwidth restriction, other than it fits in the band. I haven't
heard of any ill effects from over there, but maybe someone from
abroad can chime in.
I can see it being a concern on HF, where the spectrum is more
limited, but I am pretty much with Brain for above 50 MHz. Further
more is takes a least a dozen years to make any headway with the FCC,
so I highly recommend futuristic thinking when writing comments.
Bruce Perens recommended basically do away with the bandwidth limits,
and let gentlemans agreements take rule. I think that seems logical.
Especially when the alternative is a 10-15 year re-revising the rule,
piece meal approach game like we have been playing, that really just
impedes innovation. But no one has to agree with me. You just have
to file comments to make me happy :-)
Further more, I see like less that 5% of the ham population being
actually capable of sending a 2 MHz wide signal, so the point is
pretty much moot (Everyone else has a Beofeng HT.)
>Now imagine someone sending a signal 2 mhz wide on 447 mhz not really cool for the rest of the >Ham community. That is why we need band with limitation
