> 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
Hi Brian,
I don't see the rip broadcasts from ucsd to my gateway at 69.165.175.62
since a couple days. I'm still in the encap.txt and I still see the
regular packets routed by ucsd.edu addressed to my subnets coming in.
Something wrong at that end?
Bob (Boudewijn) VE3TOK
--
There is nothing permanent except change
Heraclitus
> I've tried a few other things with no avail at this point.
Put a monitoring device at the outside port, or start a data capture in the router itself when EdgeOS can
do that, and then check what is arriving when you do the outside ping.
When you see packets coming from 169.228.66.251 addressed to your external IP with protocol field 4 you
at least know the external causes are covered. You can then concentrate on the setup of your router.
When no such packets appear, the problem is in your gateway setup at portal.ampr.org or your DNS entry.
As I don't see your callsign or AMPRnet IP anywhere in your message I can't do much research...
Rob
The host 'hamradio.ucsd.edu' will be offline some of Monday to
upgrade its operating system. Services such as this mailing
list and the DNS robot will be unavailable during that time.
- Brian
