First I wanted to mention I am glad to read Bjorn's message about
adding some content to the network.
Keeping in contact is key. Be that a coordinator or any host on the
amprnet. Seems every few months on here we are discussing how someone
is sending out random packets, and a straight forward way to get a
hold of people would be helpful.
Some time back it was brought up to have a whois server or something
like that. I bet I can guess the status of that.
As for everyone having an ampr.org email address, perhaps a forwarding
service like the arrl.net addresses? Then there is the possible spam
problem, and the fact that someone would need to set up such a
service.
Overall a lot of good ideas are brought up on this list, so few ever
happen. The only solution I am offering is everyone should help
spread the word and try and get more people involved with moving this
network forward. I wish I had better coding skills.
One of the core problems at least in my country where the ampr/44net
space is not well utilized is the lack of higher speed equipment to
build a network. You really have to be part of a well organized club
with site connections to do anything microwave on any big scale from
what I have seen.
>Are hams allowed to use spread spectrum modes in USA?
Yes. Speaking of rules...
I once asked about data data rates and bandwidth rules for ham radio
in other countries. I am interested in learning about spread spectrum
rules, and encryption rules for the hobby in other areas for anyone
who cares to share.
Steve KB9MWR
Dean,
Thanks for sharing. Range will be the big thing at least for me, so
if you get around to testing that, I hope you'll share your results.
Though I am really leaning toward the 400 MHz modules.
If there continues to be hold up on the MMDVM boards, then I'll likely
order some LoRa modules for my winter project instead.
Since we really need some other data radio options in the hobby, I
wanted to mention LoRa.
It's a chirped spread spectrum technology used for low power WAN
applications, with air transfer rates: 300bps-31.2Kbps. There are 433
MHz modules, as well as 900 MHz and 2.4 GHz.
As a staring place, WA2KWR has some code here:
https://github.com/fcolumbu/LoRa_Projects/wiki
Steve, KB9MWR
> Since we really need some other data radio options in the hobby, I
> wanted to mention LoRa.
> It's a chirped spread spectrum technology used for low power WAN
> applications, with air transfer rates: 300bps-31.2Kbps. There are 433
> MHz modules, as well as 900 MHz and 2.4 GHz.
Indeed it is interesting, I have looked at it as well when a local telecom
company recently announced it has deployed a country-covering network.
(by mounting LoRa equipment at all cell towers and locations)
They use 900 MHz, which is not a ham band here. But 433 could be useful.
It is unfortunate that the datarate is too low for many applications.
It could be interesting for APRS-like mobile datacomm or other telemetry,
which is also what the commercial network is for.
Rob
Greetings.
Lately my small amateur server been severely flooded with similar
activities:
Nov 21 22:54:01 linux postfix/smtp/smtpd[26048]: connect from
unknown[200.7.249.218]
Nov 21 22:54:02 linux postfix/smtp/smtpd[26048]: disconnect from
unknown[200.7.249.218]
Nov 21 22:55:01 linux postfix/smtp/smtpd[26048]: connect from
unknown[83.70.149.33]
Nov 21 22:55:04 linux postfix/smtp/smtpd[26048]: disconnect from
unknown[83.70.149.33]
Nov 21 22:56:59 linux postfix/smtp/smtpd[26066]: connect from
mail.devaney.net[96.91.214.49]
Nov 21 22:57:00 linux postfix/smtp/smtpd[26066]: disconnect from
mail.devaney.net[96.91.214.49]
Nov 21 23:00:11 linux postfix/smtp/smtpd[26161]: connect from
unknown[83.70.149.33]
Nov 21 23:00:11 linux postfix/smtp/smtpd[26161]: disconnect from
unknown[83.70.149.33]
Nov 21 23:02:27 linux postfix/smtp/smtpd[26203]: connect from
unknown[186.33.182.12]
Nov 21 23:02:28 linux postfix/smtp/smtpd[26203]: disconnect from
unknown[186.33.182.12]
Nov 21 23:02:31 linux postfix/smtp/smtpd[26203]: connect from
unknown[unknown]
Nov 21 23:02:31 linux postfix/smtp/smtpd[26203]: disconnect from
unknown[unknown]
Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: connect from
unknown[50.126.82.18]
Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: lost connection after HELO
from unknown[50.126.82.18]
Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: disconnect from
unknown[50.126.82.18]
System logs were building up very fast!
Created new entries for fail2ban porogram and got rid of this in a few
minutes time!
In jail.local file added:
[postfix-auth]
enabled = true
filter = postfix.auth
action = iptables-multiport[name=postfix,
port="http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve", protocol=tcp]
logpath = /var/log/mail.log
In filter.d folder added new filter postfix.auth.conf with regex:
#
failregex = ^%(__prefix_line)slost connection after (AUTH|UNKNOWN|EHLO) from
(.*)\[<HOST>\].*
^%(__prefix_line)sconnect from unknown\[<HOST>\].*
^%(__prefix_line)swarning: hostname.*
ignoreregex =
#
>From now on NO MORE such crap!!!
Best regards.
Tom - SP2L
Speaking of documentation...
Every once and a while I get an email from someone, and it's not clear
to them how the IP space is useful, "since everyone on the internet
already has a publicly routeable address."
Maybe that can be made clearer some where? Just a suggestion.
> Ah, I stand corrected; I've updated the entry. The section on 44.128/16 was
> pointing to an obsolete article that incorrectly gave the impression that
> that subnet was unroutable like an RFC1918 network, whereas it's really just
> reserved for testing.
> Unfortunately, there's an article on www.eastnetpacket.net that incorrectly
> states that it *IS* an RFC1918-style network and people outside the AMPRNet
> are quoting it as justification for using the network AS an unrouted network.
Well, that amprnets.txt file of course has existed and has been maintained on
hamradio.ucsd.edu for many many years. I have 3 old copies and all of them mention
that it may be assumed that any packets with 44.128 addresses are bogons, so
this text has probably been there for at least a decade if not much more.
Currently this file does not exist anymore at hamradio.ucsd.edu, I presume its
function has been taken over by the "networks" menu item at portal.ampr.org.
However, that listing does not mention 44.128.0.0/16 at all. When it is desired
to change the definition of this subnet, it may be better to provide an explicit
new definition, instead of trying to remove the old definition from internet
without providing a new one.
I think that is not going to work well, given the way information is stored,
copied and archived on the web.
Also note that this information on portal.ampr.org is only available to registered
users, so it would be wise to put some information on a publicly available site
as well (maybe a description of the subnetting of net 44 at the top level without
all that country-specific info). That could be on the www.ampr.org site.
Rob
There are some rather troublesome inaccuracies in the Wikipedia
article on the AMPRNet. Does anyone on this list have edit privileges
on this page so those could be corrected?
- Brian
Quick question: why is 44.127/16 listed as "No Country" on the portal? How
are the subnet allocations different from allocations that belong under a
specific country?
Thanks,
Assi
