| |
HB2PMS > JNOS 02.04.21 15:00l 319 Lines 12225 Bytes #999 (0) @ WW
BID : 8414HB2PMS
Read: GAST DAE595
Subj: Jnos v2.0m.5G
Path: DBO595<DBX320<DBX233<VB1BOX<NL3VKL<NL3PRC<HB1BBS<HB1BBS
Sent: 210402/1403 @:HB1BBS.ZL.NLD.EU Sally 7.2.048 $:8414HB2PMS
Message from: HB2PMS@HB1BBS
differences between 2.0m.5G and 2.0m.4 - April 1, 2021
------------------------------------------------------
1) Basic DNS malformed packet protection, better error checks and logging,
bumped up stack size of DNS procs, this fix alone will add significant
stability to people reporting JNOS crashing (from DNS attacks).
2) Got a few reports of longer hex values showing up when running the
console
commands like 'ax25 status', 'tcp status', 'netrom status', however when
it
was required to 'kick' or 'reset' by hex value, JNOS would report the
call
back as not valid, preventing people from being able to do such things.
The fix was fairly easy, replacing htoi() calls with htol() instead.
3) Robust Packet Interface (KISS over TCP/IP) to WinRPR Software Modem
4) VARA IP Bridge Interface (TCP/IP) to EA5HVK VARA Software Modem
As documented, you need to extract the source from varadev.tar. This
is because the current vara code hardcodes some things in PPP source
which I have not finalized at release time. Applying the VARA source
will break any serial PPP configurations you may have running.
Chances are nobody is using PPP with JNOS anymore, but I need to be sure
:]
5) This update sees the addition of DUPE protection for concurrent
forwarding
sessions from multiple remote hosts, where messages having the same BID
are
coming in from multiple sources, seconds of each other, even within
minutes
of each other in some cases. It should be noted that up till now, JNOS
has
always been vunerable to this, resulting in posting of duplicate
messages,
which in turn get forwarded to other systems, which is just not good.
The solution up till now has been to stagger forwards with remote
partners,
such that only one partner is forwarding at any particular time. With
this
new feature, we can loosen things up a bit more, and not worry about it.
Excess messages get deferred (not refused), since we might need them
later.
6) The BID for messages from 'our host' is now in BASE36 format, giving us
a much bigger range of several million numbers, instead of the original
range of 99999 and then start over again.
If you use an email client (like thunderbird) to send messages to your
JNOS system, you'll notice this version no longer uses a portion of the
long message-id present in the email header to generate the BID, rather
it will just create another BASE36 BID from JNOS sequence number pool.
I figure it is perfectly fine to do this now, since BASE36 extends the
range of the BID to several million. The original message-id is still
preserved in the message header anyways, so nothing is lost here.
7) Protection from getting 2 UA frames after we send a SABM frame,
resulting
in a terribly vicious loop, like a DOS attack, rare scenario
encountered,
some time ago, where the remote software (based on linux ax25 stack)
went
nuts on some of us. Possible ax25 libs were updated, but the software on
the other end not compiled in a long time and running old libs ? We will
never know to be honest, but the situation was very real, yup.
8) Very basic implementation of Multi Factor Authentication (MFA) - why not
?
(note this is very much a prototype, and needs to evolve over time)
9) Important changes to the JNOS httpvnc (web based user BBS) service
Now using POST instead of GET in the form submission, so you won't be
seeing any user credentials and commands in the URL anywmore, it's all
hidden in the message body now. The original version had user callsign
and password exposed in the URL which was just bad, but my knowledge of
HTTP programming was quite limited at the time I wrote the original
prototype, so really it is a huge security improvment.
NOTE : Data is still cleartext over your network since this is HTTP ...
This version also quickly shuts down those annoying and bandwidth
consuming
favicon http requests that firefox likes to send out in huge volumes,
yeah.
Added a CTRL-A checkbox so a user can abort any SEND (SP, SR, SB)
commands.
Made adjustments to timeout values in the code, removed some pwait()
calls
which didn't seem necessary anymore, and now setting the 'Server:' field
in
the HTTP response header to reflect the more recent JNOS version 2.0m
...
Cleaned up debugging and general logging to the JNOS logfile.
10) Important changes to the SID Capture feature.
The original prototype was written more to help me debug stuff at the
time,
but I figured it might come in handy for others, but the last
enhancements
actually were not really great. In the interest of getting more
information
about the hosts connecting to us, the focus on the connecting callsign
was
lost, the information displayed was confusing, you had no idea who the
call
was in many cases, and it turns out in the end that I introduced bugs
into
the code, so the information at times was even wrong here and there.
This new version has a much better user friendly layout, being more in
line
with what I originally wanted to do way back then. Now you get the
callsign,
the time of connect, the full SID sent to us, and connection details, as
in
was this a netrom connect, a radio port, a wormhole, telnet connect, etc
?
For example, on the JNOS console of my development system :
jnos> mbox sid > /tmp/sid8.txt
Then from the linux prompt, I can retrieve the content as follows :
root@slackware:/jnos/src/dev_2.0m.4# more /tmp/sid8.txt
[FBB-7.0.10-AB1FHMRX
gb7cip 20:06:02 GB7CIP @ GB7CIP
[JNOS-2.0.6.URO.C-B1FHIM
ve3cgh 11:37:17 ve3cgh.ampr.org
[TNOS-3.00-FHIMW
ve2har 18:57:57 VE2HAR-8 @ VE2HAR-9
[FBB-7.05G-AB1FHM
ve2pkt 17:47:34 VE2PKT @ VE2PKT
[OPENBCM-1.08-5-G2F4A-AB1D1FHMRW
i0ojj 20:15:10 host-79-52-228-200.retail.telecomitalia.it
[JNOS-2.0M-B1FHIM
ve3tok 20:24:55 port.ve3mch.ampr.org
[JNOS-2.0M.5C-B1FHIM
n2nov 20:25:21 N2NOV-4 on port newyork
ve3cgr 17:58:20 jnos.ve3cgr.ampr.org
aa6hf 20:24:03 AA6HF-8 on port cal
i0ojj 20:13:19 i0ojj.ampr.org
[BPQ-6.0.20.10-B1FIHJM
va3tok 20:14:05 linux.ve3mch.ampr.org
[JNOS-2.0M.5B-B1FHIM
n2nov 18:09:25 1d N2NOV-4 on port newyork
[FBB-7.07-AB1FHM
ve3tok 20:11:25 linux.ve3mch.ampr.org
[WL2K-5.0-B2FWIHJM
wl2k 03:39:54 1d winlink-lb-628697408.us-east-
1.elb.amazonaws.com
11) Security - make sure you configure users in ftpusers with BBS
permissions
only for stations you have authorized incoming forwarding with. This
will
protect against rogue or ignorant incoming connects from any stations
who
could then proceed to send a SID, possibly followed by illegal 3rd
party
forwarding or forwarding of malicious messages.
for BBS permissions OR 0x02000 - so 0x0407f in ftpusers becomes 0x0607f
Up till now, JNOS has always allowed this, but now JNOS will send a
terse
message to the 'offending' station first, instead of the SID,
disrupting
the message flow - it might require some refinement, let me know
please.
These events are also logged to the JNOS logfile.
IF this feature causes you grief, then disable it in config.h with :
#define J2_DONT_ENFORCE_BBS_USER
12) Added EHLO support to SMTP server. I discovered this by accident when
my
android email app refused to talk to my JNOS, so tcpdump showed me
exactly
the problem, easy enough to add the command. Quite honestly, I thought
it
was there already, oops :|
13) Instead of hardcoding NETROM parameters, I know several folks have had
it
done, please consider using the following NEW commands in autoexec.nos
:
netrom obsoinit <value> default is 6, for NEDA use 5
netrom obsominbc <value> default is 5, for NEDA use 3
Same with acktime, use the EXISTING command instead of hardcoding it :
netrom acktime <value> default is 3000, for NEDA (?)
14) Couple of 'stability' mods to netrom code.
15) Better error logging during saving of the BID to the history file.
16) Removed first column (gateway ip address) from the 'genencaptxt' file.
(now it matches the exact same format as a real encap.txt)
17) If you are running two systems with the same Call Sign
Please consider staggering your sequence numbers, since the sequence
number
pool is now into the several million range, not constrained to the old 1
to
99999 and back. For example, in my /jnos/spool/mqueue/sequence.seq, I
reset
the value to 16801420, which starts my base36 bid at ANNNN, way ahead.
If anyone sees a flaw in this, please talk to me :]
Not so sure one should be running multi BBS with same callsigns, but ...
18) Some tweaks to APRS code, for instance making sure to remove trailing
0xc0
characters from the end of APRS data coming in via a WinRPR interface,
and
also breaking out callsign list management routines - which are no
longer
specific to the APRS aspect of JNOS, also used for IP access and
Winlink
call lists, so they got moved to the new j2KLMlists.[ch] source files.
19) Fixed some more compiler and linker warnings, some dependant on how one
modified their config.h file - originally these never would have showed
for the more standard configurations (if there is such a thing). I also
added some TNODE 'mods' from Brian (N1URO).
20) Important for ARM processors, the makefile now FORCES signed char, the
reason being the linux version of JNOS always assumed signed char, but
this is a big problem for ARM and Raspberry PI based hardware, which
actually assumes unsigned char intead - more efficient apparently.
So BEFORE this got enforced, PI users were complaining about all sorts
of strange behavior with JNOS and/or outright continuous crashing ...
21) How to update your JNOS 2.0m.4 system (or just compile fresh)
WARNING : only apply this update on 2.0m.4 systems, nothing earlier !
Run rsync on your source tree like you usually would, for example :
cd <your JNOS source>
rsync -av www.langelaar.net::jnos2 .
Note the following new possibilities for your config.h file :
#define WINRPR /* kiss over tcp/ip interface to WinRPR */
#define J2MFA /* prototoype multi factor authentication */
#define TNODE /* Brian's TNODE mods */
#define J2_DONT_ENFORCE_BBS_USER /* use only if it gives you grief
*/
#define EA5HVK_VARA /* ip bridge tcp/ip interface for VARA */
Hopefully I have not missed anything (sorry), then compile as usual :
make clean
./configure
make
22) No more patch files, all moved into a patches subdirectory again ...
(the README files in some of them might come in handy, who knows)
73 Henk.
(Message sent with Sally 7.2.048)
======================================================================
_ _ ____ __ ____ ____ _____
| | | | _ \/_ | _ \| _ \ / ____| SYS: Henk (hb1nos@hb1bbs.com)
| |__| | |_) || | |_) | |_) | (___ QTH: Ouwerkerk - JO11XO
| __ | _ < | | _ <| _ < \___ \ BBS: HB1BBS.ZLD.NLD.EU
| | | | |_) || | |_) | |_) |____) | QRV: 27.235 MHz (FM 1200bps)
|_| |_|____/ |_|____/|____/|_____/ WEB: www.hb1bbs.com
======================================================================
AXUDP : HB1BBS.NET UDP 93
APRS : APRS.HB1BBS.COM (51.37.48N : 003.59.01E)
TELNET: HB1BBS.NET 23
** Netrom/Node HB7NOD::HB7NOS (Jnos)
** Netrom/Node HB8NOD::HB8NOS (Bpq32)
** Netrom/Node HB9NOD::HB9NOS (LinBpq)
======================================================================
** This message is generated with Sally 7.2.044
----------------------------------------------------------------------
** Timed vrijdag 02 april 2021 14:02 West-Europa (zomertijd)
** BBS HB2PMS@HB1BBS
Lese vorherige Mail | Lese naechste Mail
| |