Hello Bob!

May 31 21:23 03, Bob Jones wrote to Bo Simonsen:

 BJ> Arrrgggghhhhh.....  We're starting to exceed the limitations of the 
 BJ> built in maximus full screen editor for replying to messages....  At 
 BJ> least dumping the message to a file and reading that file with the 
 BJ> maximus built in full screen editor still works....  So, the quoting 
 BJ> below will be slightly screwed up.

 BJ> :(

Hmm.. i wonder when MsgED runs over.. I've some good ideas for doing
multi-platform debugging. This bug, and squish should be able to take lines
longer than 512, in Areas.bbs.. (My boss complained about that, then we had
a talk about Squish/Maximus).

 >>> Ok, you've worked in somekind of companey where they used those 
 >>> unixes?

 BJ> Not a single company.  Multiple companies, colledge, etc. For the 
 BJ> most part, BSD flavored unix is BSD flavored Unix, and the other 
 BJ> flavor was System V (five) based....  

Hmm. Ok

 >>>  No, me neither, but i'm rather comfused about the case.

 BJ> I guess I'm not sure what you are refering to.  I never used EMSI (or 
 BJ> similar) hand shaking with BBS's that passed user name / password 
 BJ> info from the front end mailer to the BBS, so I'd have have to look 
 BJ> at that FTS standard to see how that's supposed to work.  

I've tested it with Terminate (or Telix?) once. 

 BJ> I think you 
 BJ> have spotted something trying to deal with that issue....  Where a 
 BJ> user's terminal program could be quiried for an auto-login type 
 BJ> sequence.....  I don't like to do things that way due to security 
 BJ> issues....

Yes, fx. bterm has somekind of autologin, but i don't know if it's only for
BBBS systems.

 BJ> ...
 >>> then max -k should be copied and rewritten a bit, so it asked about 
 >>> username/pwd, and it might work then.

 BJ> Warning: Using max -k could be dangerous to your BBS's system 
 BJ> security.....  The -k option was used for a local sysop login, and is 
 BJ> used to initialize the user database if one doesn't exist.  So, if 
 BJ> max cann't find the user database, and a user comes in with -k 
 BJ> (because they can on the local machine), then they could take over 
 BJ> full control of the BBS portion of the system....

I wrote _rewritten_ ! :) Well like a normal login, i just could start we a parameter.

 >>> That's right, but what the problem about communicating thru ttySX?

 BJ> What problem?  ttySX is the hardware rs-232 based serial ports.  

Well, we suppose we only have one user logon per modem.. What will the
problem be then to use /dev/ttySX, to communicate thru?

By point is why do we need a psedu terminal?

 >>> If i understand you well, we mostly agree.

 BJ> I think so, And while you have excellent command of the english 
 BJ> language, there may some suttle translation issues between us that 

Oh thanks.

 BJ> I'm not recognizing, leading to me inturpreting what you said 
 BJ> differently than what you were thinking.....  This is a general 
 BJ> problem with written communication, even when both speak the same 
 BJ> language natively....  

Yes. 

 BJ> And I may be out of sync with Linux on one or 
 BJ> more technical issues.  I assume a fair amount of background based on 
 BJ> BSD flavored Unixes, but Linux is a System V clone.....

Ok, maybe you should look a bit about handlingen modems in Linux (inbound calls)...

 >>> Oh i see, for example MBSE, have a mbtask manager there ensure that 
 >>> the processes whitch doesn't exist is beeing killed.

 BJ> Technically, the (running software)  processes still exist, but they 
 BJ> need to be killed because the physical connection has been broken or 
 BJ> disconnected.

.. and i don't suppose mr. mgetty would like to do that.

 >>> Linux is a sysv flavored clone.. But it's only about the initializing  
 >>> >> 
 >>> method?

 BJ> No.  There are some (at time subtle) differences between SysV and BSD 
 BJ> flavored Unix.  From memory, socket handling (at a low enough level) 
 BJ> *is* one of the areas where the differences surface.  

Hmm.. ok, i've not been reading the whole Modern Operating Systems (Adrew S
Tannenbaum).

 >>> I/O is quite the same in most unixes?

 BJ> For the most part, but not completely.  
...

Ok.

 >>> As it's now does maximus sends a ATH even over telnet.. if we are 
 >>> communicating between ttySX it should be possible.

 BJ> That is the software attempt at hangup.  Maximus also tries to 
 BJ> perform a hardware hangup of the modem (dropping dtr, or another 
 BJ> RS-232 control line, based on a bit map mask and IO call to a (MS/PC) 
 BJ> DOS interupt call that handles all RS-232 serial hard wire control 
 BJ> lines).  

Yes allright.

 BJ> We need similar capbility in the Unix / Linux port, but 
 BJ> getty may be the solution.  I think it can be (in a BSD flavored 
 BJ> unix) done via IOCtl calls.....  

I wonder if mgetty exist in BSD systems too? How would these people else
could get a fidonet call :)

 >>> Maybe it should be +++ATH+++..

 BJ> No!  This should be a configuration item.  Some BBS's change the +++ 
 BJ> sequence to a differnet character.  And the +++ sequence also 
 BJ> involves timing of a delay between certain characters.....

But you're scure about the modem get's the initstring.

 >>> That's right..

 BJ> After thinking about it, I have another solution to offer....  One 
 BJ> that leaves maximus started as a TCP/IP server /dameon.  Instead of 
 BJ> having (m)getty handling the modem, Max acts as a wait for caller for 
 BJ> the RS-232 based nodes, and could be implemented with the startup of 
 BJ> the TCP/IP demon.  The existing Maximus for OS/2, DOS and Win32 has 
 BJ> that as an option.  Unfortunately, this does not solve the Fidonet 
 BJ> front end mailer needs, and is why I don't use that option with 
 BJ> max.....

... the poor fidonet people :) 

 >>> The POTS/ISDN handlingen is what i care about.. 

 BJ> Well, if we get POTS/ISDN handling via modems hooked up to serial 
 BJ> ports handled by (m)getty, we also get TCP/IP capability via 
 BJ> (m)getty....

 BJ> Ok.  Enough on that issue.....  We're in basic agreement.

Yes.

 >>> Excatly.. my i really doesn't see a good reason to use IPC.

 BJ> It's needed for in Maximus for (a) Chat function, (b) Who is on 
 BJ> function, and I believe one or two other items.  The Chat function is 
 BJ> not needed because one could instead use the Unix talk command / 
 BJ> program.  The who-is-on function potentially could be obtained from a 
 BJ> 'ps' output, if we put the needed info on the line.....

Acknowledged. Just forget i talked about IPC :)

 >>> It's controled by writing/reading files afaik. But it's too somekind 
 >>> of IPC, 
 >>> the way i thought about was send()/recv().

 BJ> I've got to look up send()/recv() functions to refresh my memory, but 
 BJ> we are in basic agreement, all of this runs via some sort of disk 
 BJ> file space / structure to accomplish inter-process communications.  

Yes. send() and recieve() is very easy to fuckup with (sorry my language).

 BJ> I believe, YES.  I believe the husky tool set has now been compiled 
 BJ> for both OS/2 and Win32 platforms.  I believe I've seen both OS/2 and 
 BJ> Win32 binaries for all the Husky tools come done one of my filebone 
 BJ> feeds.  So, I *think* I have the binaries (and possibly source) on my 
 BJ> BBS....

Jesper Sørensen compiles some binaries for OS/2 by boss gets (never
versions than 0.9.7).

 >>> My BOSS runs hpt/OS2

 BJ> I haven't configured fidoconfig for either Linux or OS/2, so I 
 BJ> haven't tried to run the husky tools in either environment yet.  I 
 BJ> have contemplated it, but figured the current system wasn't broke in 
 BJ> this area (under OS/2).....  

Ok, we need to write a Areafix program to Squish, so it would work out
under Linux, i really don't think that the auther of Sqafix would give us
the sources.. Did anyone ask him?

 >>> And i did some corrections in msgapi too..

 BJ> Interesting.  What needed correcting in the msgapi?  Was this the 
 BJ> Maximus msgapi, or the versions of the api previously ported to Linux 
 BJ> / Unix systsems for use by such things as the husky project?

Maximus's msgapi, it didn't wrote the XMSG structure correctly (subject,
from, to, ftsc_data and so on). So i borrowed some code from the smapi.

 BS>>>     * Maximus should be called from mgetty, after it 
 BS>>> detects it's a human call.

 BJ>> Be it hardwired terminal, modem, or a (telnet or TCP/IP) pseudo 
 BJ>> terminal connection.....

 >>> Hmm?

 BJ> I think you start to see one way that I view running Maximus under 
 BJ> Linux, where all nodes will be configured the same way -- under 
 BJ> (m)getty, and I get both modem, local and TCP/IP all in one shot..... 
 BJ>  Or did you have a specific question about this?

Ahh now i understand :) 

Regards,
Bo

--- Msged/LNX 6.1.2