Hi there
Im starting to check the option to install a Wireless lan on 430 MHZ using the Xagyl card ...
Has anyone experienced such wireless networks ?
Most important to me is the Range and non line of sight operation (especially in mobile)
Have anyone done it and can say something on the subject ?
https://www.xagyl.com/download/XC420M_Datasheet.pdf
XC420M DATASHEET - XAGYL<https://www.xagyl.com/download/XC420M_Datasheet.pdf>
www.xagyl.comWWW.XAGYL.COM RADIO SYSTEM INFORMATION Tx/Rx Specification 20MHz Channel Width 432.5MHz and 437.5MHz only DATA RATE MODULATION TX POWER RX SENSITIVITY
Thanks Gorward
Ronen - 4Z4ZQ
There were concerns that having the data stored in the clear on my site would preset security issues.
The file is now encrypted with 7zip which encrypts filenames also with the pass phrase being 44Index0cAM6wJRCI
http://174.71.72.143:8885/files/44archiveMidMar18.7z
Hello everyone,
I'm pleased such a community exists. I requested an allocation about three weeks ago and am excited about getting connected!
The last couple of weekends I put two sdr receivers and a couple of websites up on the public internet for a quick migration to the 44 network when a gateway is received and configured correctly.
In preparation for things to come, I've looked at the 44net archives, absorbing what I could. In trying to find info about using PFSense and other subjects, I realized how tedious it was to manually open each archive to search every time an answer or guidance was needed - so an index was made. I wrote a script to sort the subjects, etc. Also, each month was dl'd, expanded, and all put into one folder for ease of searching. Now I can search the index or grep all the files with one command. Maybe this exists elsewhere - I couldn't find it. If anyone is interested, here's the index and expanded files through mid-March contained in one folder:
http://174.71.72.143:8885/files/44archiveMidMar18.tar.xz
Thank you and 73,
Dean
K4DIN
> I recommend disabling the access to unneeded management services and to
> the remaining ones, restricting the access to them from the networks
> used by the administrators.
Of course. And we had that already in place on the routers inside our own part
of the network (which was deployed to facilitate our co-channel diversity repeater network).
However, above I was discussing the settings on our internet gateway. I cannot control
what all the individual amateurs, with varying networking skills, do on their routers at home,
but by filtering inbound connects to port 8291 I can protect them from the current problem.
There now are 430.000 addresses in the scan I did last night. only net-44 addresses:
44.140.129.12
44-25-128-124.ip.hamwan.net[44.25.128.124]
44.34.131.144
But of course, when people start filtering outbound 8291 connections, it is not a complete picture.
Rob
> it is not wise to block port 8291, because the exploitable service is
> on http port 80 tcp.
The worm uses port 8291 to identify possible victims (when it can connect to port 8291 it assumes
there is a MikroTik router on that address), then attacks it on port 80 and some other ports that
people may likely have set as an alternative for HTTP access to the router (8080 etc).
So blocking port 8291 effectively blocks the worm in its current version, while not destroying the
useful port 80. Of course experience with earlier events like this shows that such a worm typically
evolves and may skip the port 8291 scan later, rendering this block ineffective.
For now, I have blocked access to port 8291 from addresses outside AMPRnet on our gateway.
Of course this restriction will be lifted when/if this worm stops operation.
It appears to be controlled via a peer-to-peer network and it looks like it is a version of an
existing worm that has been active on network cameras/recorders, routers from other manufacturers,
etc, all running embedded Linux.
Rob
> All these should be good now, I've check the upgrade and it's on the newest
> code. Please let me know if you see anything else.
I'll run another scan (actually: a trace) tonight.
It has to run for about 8-10 hours to catch everything, it appears.
I just trace for SYN to port 8291 and get the source addresses. Unfortunately it cannot be done using a simple
tshark -i eth0 -f "tcp dst port 8291"
because tshark collects session state information and its memory use balloons under
the millions of session open attempts it sees.
So I use:
while true
do
tshark -i eth0 -f "tcp dst port 8291" -c 20000 | fgrep '[SYN]' | sed -e 's/ ->.*//' -e 's/.* //' >>/tmp/syn8291
done
Of course it would also be possible to limit it to AMPRnet:
tshark -i eth0 -f "tcp dst port 8291 and src net 44.0.0.0/8"
Rob
> A central syslog and firewalled 8291 ports with logging would be a better solution imho :)
> Grep seems less of a strain than tshark and would be quicker I imagine
If you would want to do this permanently, yes. But this is only something I would run maybe
for 3-4 days and then be bored.
First night I did the tshark logging without the postprocessing (so file gets the 1-line-per-packet
trace info) and it collected 500MB in a single night. Maybe you don't want that all in the syslog...
Now I keep only the source addresses,
Rob
