-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathREADME
342 lines (227 loc) · 14.8 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
Final patch, this is 2.0m.5F, next official version, cleaned everything up !
This patch converts the official 2.0m.4 to the new official 2.0m.5F :]
version.c - changed from 5E to 5F
mboxmail.c - base36 code now permanent
(removed HARGROVE_VE4KLM_FOX_USE_BASE36)
forward.c - multiple wl2k calls and base36 code now permanent
(removed HARGROVE_VE4KLM_FOX_USE_BASE36, renamed MULTIPLE_WL2K_CALLS)
fbbfwd.c - base36 code now permanent
(removed HARGROVE_VE4KLM_FOX_USE_BASE36)
wlauth.c - multiple wl2k calls now permanent
(removed MULTIPLE_WL2K_CALLS)
j2KLMlists.[ch] - multiple wl2k calls now permanent
(renamed MULTIPLE_WL2K_CALLS)
aprssrv.c - removed code that had been long commented out
makefile - bumped up to 03Dec2020_v1.8 from 30Aug2020_v1.7
(removed directives from PATCHES that really didn't belong there)
configure - bumped up to 03Dec2020_v1.8 from 30Aug2020_v1.7
(must match what is defined in the makefile)
config.h.default - added a couple of directives previously in makefile
(also trying to clean up the file, sections by version # perhaps)
Couple of #define directives you can add to your config.h if you wish :
#define WINRPR /* kiss over tcp/ip for SCS WinRPR modem software */
#define J2MFA /* prototype of Multi Factor Authentication */
Note : JNOS 2.0m.5F is JNOS 2.0m.5E 'cleaned up'. I just want to get a new
official version out there, it's been a while and I'm sure everyone
is tired of all these patches (including myself actually) ...
05Dec2020 - corrections made after initial patch release
compiler warnings (from N2NOV) corrected IF following defined in config.h :
RSPF, TCPGATE, MBOX_DYNIPROUTE, AX25_XDIGI, EDITOR
mailbox.c, tcpgate.c, rarp.c, ax25xdigi.c editor.c
rspfcmd.c, rspfhdr.c
rspf.c - particularly concerned me, trying to understand the reason
behind 'pointer casting of source' on some of the function calls ?
(compiler warnings fixed, hopefully RSPF has not been broke)
13Dec2020 - more corrections and 2 additions
mailbox.c - if a user has is not registered (REGISTER command) and they
try to telnet into a MFA enabled JNOS, it will crash, I wasn't checking
for a NULLCHAR on m->IPemail - fixed. The JNOS log will say user is not
registered for MFA use and disconnect them. Also changed sysop warning.
aprs.c - remove trailing 0xc0 from aprs data if we are getting it from
the new WinRPR interface, yes, it's a kludge, but I don't want to mess
with the winrpr.c source right now, need to give this some thought.
lapb.c - firestorm protection, read comments in the code for details.
(protection against strange behavior from apps using linux AX25 stack)
21Dec2020 - couple of patches, they keep coming in, don't they :|
mailbox.c - don't disconnect an unregistered MFA user, chances are they
are not even in ftpusers file, so univperm is low enough for them to do
little to no damage - it also gives them an opportunity to REGISTER :)
Also forgot to kick the SMTP queue, failure to do so results in the user
having to wait a very long time before they get their auth code emailed.
24Dec2020 - give sysops a way to disable enforcement of bbs user during fwd
sessions, had one report already, it makes life difficult for them, so added
the #ifndef J2_DONT_ENFORCE_BBS_USER compiler directive to mboxmail.c, then
you can '#define J2_DONT_ENFORCE_BBS_USER' in your config.h if you want :)
(also added to config.h.default, but as #undef, thanks Red :)
Originally Updated December 4, 2020
------
Another patch, this is 2.0m.5E, all about Multi Factor Authentication (MFA)
1) mailbox.c - added MFA support functions, this is where it happens.
2) mboxcmd.c - added 2 new 'mbox' commands -> MFAexclude and MFAfixed.
3) j2KLMlists.[ch] - added MFAexclude list and supporting functions.
4) j2strings.[ch] - added MFAexclude strings.
5) makefile - added '-DJ2FMA' to enable the MFA feature.
Note : IF you decide to #undef WINLINK_SECURE_LOGIN in your config.h, you
need to edit makefile and remove '-DMULTIPLE_WL2K_CALLS' from it or
else you will get an unresolved link error, have not fixed it yet.
6) usage/MFAexclude.txt - copy this to your /jnos/usage area
DOCUMENTATION : https://www.langelaar.net/jnos2/documents/working.txt
(actually an edit of some new documentation I started last summer)
just search for the term MFA ...
7) corrections made after initial patch release
29Nov2020, Maiko, The 'mbox MFAfixed' can NOT be any length, due to the way
the original non-BBS prompting code was written (it's related), so for now
the maximum length is 10 characters. It's also enforced in the command now.
Also note, incoming telnet mbox 'open' is now 'open (MFA)' in the JNOS log,
with exclusions logged as 'auth excluded' and failures as 'auth rejected'.
26Nov2020, Maiko, another oops, MFA prompting shouldn't be happening
for non telnet connects - if you are connecting ax25 over a port. It
turns out I wrongly interpreted the use of the &anony flag. I should
be using the value of m->family instead, patch file is updated now.
26Nov2020, Maiko, added code to reduce the amount of connect failed entries
in the main JNOS log if the WinRPR software is offline for extended times.
(so the tar.gz will contain an additional source file - winrpr.c)
Updated November 24, 2020
------
Fourth patch, this one is 2.0m.5D, sorry it's not the final one yet :)
1) makefile - added WINRPR define (for now) and the NEW winrpr object file.
2) mboxmail.c - some major work on the SID capture stuff, much better now.
3) config.c and winrpr.c - new WinRPR (KISS over TCP/IP) interface code.
4) bbs10000.[ch] - long time coming updates to HTTP VNC service !!!
5) ipcmd.c - remove the first 'gateway ip' column from genencaptxt file.
6) OOPS - forgot to copy patched misc.c, netuser.c, socket.h, and telnet.c
for Brian's TNODE modifications - supposedly available version 2.0m.5
14Nov2020, Maiko, found a mistake in telnet.c - work around put in place.
Updated November 12, 2020
------
Third patch, this one is 2.0m.5C, these are additions to 2.0m.5B changes.
(see the first two patches further further below)
* WHY are these being released as patches ? because I would like a fair of
time to pass to make sure they are all 'working' as planned before they
get permanently added to the official release - Sorry :|
1) nr4subr.c - try and better validate a NETROM CB (Control Block) when a
NETROM disconnect is received, because we might be trying to free memory
for something that may have disappeared already.
2) Bumped up Nr_maxroutes to 10, seeing Nr_maxroutes exceeded in the logs.
3) mboxmail.c - IMPORTANT - if a station that is NOT configured as a BBS in
your ftpusers, sends a SID, JNOS will NOW send back terse message saying
the user is not configured for BBS operation, disrupting the flow !
This is my alternative to some modifications Brian (N1URO) came up with,
the concern being to protect against rogue or ignorant incoming connects,
which could result in possible malicious forwarding or illegal forwarding
of 3rd party messages. Any events are also logged to the JNOS logfile.
WARNING : IF you choose to apply this update, make sure ALL the remote
systems you expect INCOMING forwards from have 0x02000 OR'd into their
permissions - so for example, 0x0407f will become 0x0607f instead.
I also cleaned up log calls in the capture_sid() function, thinking they
should not be smack in the middle of link list processing, like what was
encountered in the DUPE control code. I also removed some old code that
was permanently commented out, no point leaving it there anymore.
4) fbbfwd.c - updates to the DUPE control code introduced in 2.0m.5B.
When duplicate messages are coming in simulaneously, we pick one of them,
and then ignore the rest by refusing them. The problem with refusing them
however is if anything bad happens during the processing of the message we
picked, then we've taken away the ability for JNOS to receive the message
again from our remote systems. I've changed it now to use defer instead.
Also, if anything bad happens during processing, we need to make sure to
remove the BID from the DUPE control list, or else JNOS will NEVER accept
the message again, since the only other time it's removed is inside SMTP
code after the message has been successfully delivered by JNOS.
5) Added EHLO support to smtpserv.c (thought it was there already, oops)
Discovered this by accident, when my android phone kept complaining that
the SMTP to my JNOS was not working, a quick trace showed the EHLO cmd.
Updated November 1, 2020
------
Last updated October 25, 2020 just after 8:10 pm (Winnipeg Time) DST
*** This is BETA, test the crap out of it, watch for DUPES ***
ONLY APPLY THIS to the latest 2.0m.4 (from rsync repository), sorry ...
please report ANY issues ASAP, thank you !
This is the second patch, which sees the addition of DUPE protection for
concurrent forwarding sessions from more then one remote host, where the
same message with same BID is coming in from multiple sources, seconds of
each other, even within a minute or so of each other. JNOS is vunerable
to this, resulting in duplicate bulletins. This patch fixes the issue.
The first patch was 2.0m.5, this one is 2.0m.5B !
What this patch adds to the first patch
---------------------------------------
1) As noted above, addition of DUPE protection, explanation below :
When JNOS gets an incoming proposal and accepts a message with FS +, there
is a period of time (depending how quick forwarding is with remote system),
where if another message with the same BID shows up from another remote BBS
or even in the same batch as the 1rst incoming proposal, JNOS will actually
accept these messages with FS + as well ! That is because the BID does not
get stored in the history file until the message being forwarded has been
fully delivered by JNOS - that can take even several minutes believe it or
not. So during this 'gap' we are vunerable to incoming DUPES, yes, true !
So up till now, I have recommended some time ago to stagger forwards as
best as possible so that your system only forwards with one remote host
at a time, no concurrent forwarding with multiple remote systems. There
is still a rare chance for dupes, but this strategy greatly reduces it.
This new code now tracks ALL concurrent forwarding sessions, and watches
for messages having identifical BIDS, only allowing the first message it
sees to be accepted with FS + and processed by JNOS, the rest are ignored
and JNOS responds to those with FS - instead. It seems to work quite well
based on testing I was able to do with several systems definitely sending
me dupes at the time (ironically now when I need to test, they've decided
to follow the stagger recommendation, so harder to test now, how funny is
that), anyways ...
I'm still debating whether I should actually defer DUPE messages instead of
refusing them (using FS= instead of FS-) since if something goes wrong with
the delivery of the first message it sees, we loose the chance for another
message to come in and try again, so we'll see how that plays out first.
2) Better error logging in case there are errors saving BID to history file.
How to update your JNOS 2.0m.4 system
-------------------------------------
run rsync on your source tree like you usually would, for example :
cd <your JNOS source>
rsync -av www.langelaar.net::jnos2 .
after the rsync is complete, you should notice a new file called :
update_jnos.2.0m.5B.tar.gz
extract the files using :
tar xvzf update_jnos.2.0m.5B.tar.gz
if you need TNODE stuff, then add #define TNODE to config.h
then do the usual make clean ; ./configure ; make
What you got in the previous 2.0m.5 patch
-----------------------------------------
1) If I sent a message from my JNOS to someone else, the BID is of
the format NNNNN_VE4KLM, where NNNNN runs between 1 and 99999.
If an email client is used, NNNNN gets set from the last 5 characters
of the usually lengthy message-id from the email client, for example :
will result in 581ae_VE4KLM, which as of late has been an issue, note it
is not capitalized, and several instances of this have recently generated
duplicate messages from various JNOS systems out there.
Why ? I suspect the uppercase/lowercase mods I did in 2018, started back
in 2015 are possibly responsible for this, so it is imperative to get as
many cases of JNOS 2.0 up to speed as possible once BETA tests are done.
(in other words I may have bit myself in the ass back then, not sure)
With this update, NNNNN is now a base36 number for both of the above cases,
since the pool of sequence numbers now goes into the several million range,
so for the case of email clients, it now draws from the JNOS sequence pool,
hopefully that makes sense to everyone.
If a message is NOT from our host, a crc and the callsign of where the
message came from is used to generate the BID, I was hoping to replace
the use of crc with the same base36 number, but some strange results
occurred in my tests, so I've held off with that.
Any time I release an update like this, I'm nervouse, so please keep your
eyes open for issues.
2) Instead of hardcoding NETROM parameters, I know several folks have had it
done, please consider useing 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
I saw acktime hardcoded as well in some cases, use an existing command :
netrom acktime <value> default is 3000, for NDEA use 64
(you may want to confirm, 0100 octal)
3) If you want to use Brian's (N1URO) mods for TNODE, then define TNODE in
your config. h or in your makefile before you compile your code.
4) There is other stuff I wanted to add, but this BID thing is important,
and I want to get it out of the way, there will be more BID stuff at a
later date, we're not done with this yet ...
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 ...