JNOS 2.0f2 - Snapshot of development system up to May 22, 2008 (LINUX ONLY) --------------------------------------------------------------------------- This *patch* adds full B2F support to JNOS 2.0f (official version). * ONLY apply this patch to JNOS 2.0f or 2.0f1, nothing earlier. AIRMAIL telnet (internet access) module can now be used to B2F forward with JNOS, including multiple attachments. There is a bug I am trying to fix where multiple attachments going out are bleeding into each other, so please avoid outgoing multiple attachments for now (sorry). Only one 'To:' field is allowed at this point, but you can 'CC:' to your hearts content. Attachments are saved to the HOME directory of the user getting the mail. The HOME directory for a user is taken from the /jnos/ftpusers file. Note : It is a terribly complicated thing to add support to the Read command so that one can view attachments in any convenient way. For now, all I do is save the attachment to the HOME directory, and add a line to the end of the regular mail saying what the file name is. You will have to access the file using FTP or some other method for now. Sorry if that's not convenient, but I want to give this alot more thought before I go any further ... I have tested this over and over, Airmail client can now telnet to JNOS and do this. The B2F will also work via the hfdd interface. I have tested this using my KAM and it seems to work fine. New commands and/or options added to JNOS 2.0f2 ----------------------------------------------- The 'mbox fbb' command now goes to 3, not 2 like in previous versions. The value 3 denotes B2F capability. After you apply this patch, JNOS 2.0f2 will now default to B2F forwarding, not the regular FBBCMP like before. Any stations that connect to JNOS will now see the '2' in the SID, ie : [JNOS-2.0fw-B2FHIM$] Warning : It *seems* that FBB 7.00 does NOT like the '2' in the SID, and it *seems* that the '2' messes up the forwarding - it *seems* to put in an additional 2 bytes in front of the forwarding data. I need to look at this some more, but that's why my initial observations suggest :( IF you regularly forward with FBB type stations, there are two solutions. You can default JNOS 2.0f2 to FBBCMP mode using 'mbox fbb 2', OR you can use the new 'noB2F list' feature I wrote to specifically address this situation. A new command, 'mbox nob2f ', where is optional. If you don't pass any callsign, JNOS 2.0f2 will display the current list, ie : Jnos> mbox nob2f no B2F for these callsigns : ve4bbs aa6hf Jnos> If you pass a callsign, then that callsign is added to the noB2F list. Jnos> mbox nob2f ve4ua Callsigns (that are in the noB2F list) that connect to JNOS 2.0f2 will never see a '2' in the SID given out by JNOS, and will just view us as a regular FBBCMP capable system (ie, no B2F). In other words, if you forward with any FBB type stations, make sure you put their callsigns in the noB2F list, and then things should work fine. How to install Patch -------------------- WARNING - patch can ONLY be installed on top of official 2.0f or 2.0f1 ! * place the 'J20f2.tar.gz' file into the JNOS2 source directory, then : gunzip J20f2.tar.gz tar xvf J20f2.tar make clean make Files contained in the tar file ------------------------------- 1277 2008-05-23 15:36:02 b2f.c 76137 2008-05-23 15:37:43 fbbfwd.c 55682 2008-05-23 15:35:29 forward.c 38999 2008-05-23 15:35:33 lzhuf.c 2195 2008-05-23 15:35:33 lzhuf.h 54269 2008-05-23 15:35:50 mailbox.c 15980 2008-05-23 16:12:19 mailbox.h 9137 2008-05-23 15:38:03 makefile 45566 2008-05-23 15:35:53 mboxcmd.c 50494 2008-05-23 16:14:40 mboxmail.c 11316 2008-05-23 15:36:04 version.c More detailed log ----------------- * fbbfwd.c New support for both incoming & outgoing FC proposals and B2F forwarding. New message type (m->stype) of 'E' to indicate the FC/B2F combo. New forward 'state' (MBX_REVB2F) to indicate we're in B2F receive mode. Modified fbbparse() function to properly handle an FC proposal. Very little information is given in the FC proposal, all headers for the transport are contained in the compressed data block we receive. We still fake this as an FA for processing purposes, but put dummy values in to get things going. Originally I was going to modify dofbbacceptnote() to handle any new headers brought in with the B2F/FC encapsulated mode (EM) used by the WinLink and Airmail software, but decided to write a new function to deal with it instead. The message id (arg2) in the FC proposal is still important, since the FBB mechanism counts on it for duplicate checks. New doB2Facceptnote () function decided upon to handle receiving of any incoming B2F compressed forwarding, instead of hacking up the existing dofbbacceptnote () function. Cleaner approach. Added a 'b2f' parameter to the recv_yapp() function, so that it knows about the 2 byte CRC in front of the regular FBB compressed payload. BUG fix - thanks to AA6HF (Jack) and his forwarding partners, discovered a bug that was messing up the 'tofrom' field of bulletins - was apparently also messing up the proper handling of R: line entries. Fixed a bad typo in the AIRMAILGW (email gateway) code I added some time ago. The typo was preventing the 'tofrom' field from being properly setup, messing up headers in the message. New B2Fsendmsg() function - B2F alternative to the FBB fbbsendmsg() call. The F6FBB documentation states that 'Y' can be used in place of '+', 'N' can be used in place of '-', and 'L' can be used in place of '=', when processing the FS response from a remote host. I have modified the fbbdofs() function to allow for those additional cases. The Winlink group is using Y, N, and L in their traffic, so we better do our best to accomodate for that. Throughout the forwarding code, we check for '+', '-', or '=' values, so I have added code to also check for the counterparts, ie 'Y', 'N', and 'L'. send_yapp() function now has an additional parameter to signal B2F mode. Added code to *convert* multiple incoming FC proposals to FA format for internal handling. Previous patch (f1) only did it for the first message, but was crapping out for multiple proposals. Attachments are now saved in the HOME directory for the user that is receiving the mail. During development I was using /tmp for everything, but figured the HOME directory was more appropriate. The HOME directory is taken from the 'ftpusers' file. * forward.c Send B2F in our SID only if the remote system supports it. Uses the new B2F mailbox SID string (version.c). Added code to the makecl() function to build an FC proposal if asked for, ie: New field 'm->sid2' & MBX_B2F). It appears that all I have to do is build something like 'FC EM - - 0' to make this work. The regular size and compressed size parameters *seem* to be ignored here, so I use '-' characters to do that. The 0 is an unused field to begin with. This is all good, cause if it was required to use them, I would have to do some significant redesign of the forwarding code. * lzhuf.c Removed the very old (never used) LZHTEST development code. The function calls did not even match the latest function prototypes, so compile would always fail. Added 'b2f' parameter to the Decode() function. B2F puts a CRC in front of the regular FBB compressed data, so skip the 2 bytes for now. Of course I will need to actually make sure the CRC is matched - TODO LIST ! Added a 'b2f' parameter to the recv_yapp() function, so that it knows about the 2 byte CRC in front of the regular FBB compressed payload. Added additional parameter to encode() function to signal B2F mode. Airmail and Winlink use the Xmodem variation of CRC-CCITT for the 2 byte checksum put in front of the regular F6FBB forwarding data. This is not the same variation used within the original F6FBB checksum code itself, so I had to put in a new table (crc16tab) and new macro (UPDCRC16) to cover this. Further changes to encode() function. If B2F is defined, we have to change the write mode of the fopen() so that we can rewrite to the file later when updating the 2 byte checksum that preceeds the usual F6FBB forwarding data. If B2F is flagged, we have to write 2 empty bytes first, before we deal with the regular F6FBB forwarding stream. Then after the F6FBB data is dealt with, we have to seek back to the first 2 bytes of the output file, and update them with the new and up2date 2 byte checksum, using the new table/macro above. send_yapp() function now has an additional parameter to signal B2F mode, make sure to change the call to encode() which now has a new parameter. some debugging stuff to make sure recvbuf() is returning the number of bytes we expect from it. I may remove it (what2read and recvcnt) when I finish this. recvbuf() is definitely returning what we expect. * lzhuf.h Updated function prototypes - encode(), decode(), recv_yapp() for B2F flag. * mailbox.c Removed a bunch of long unused '#ifdef notdef' code. Figured out incoming AirMail telnet client. The '.' character that preceeds the login user name will help me set CRONLY so that the mbx_parse works properly. CRONLY is needed or else the first byte of each command gets lost. As a result and in conjunction with other mods ... April, 2008 - successfully used Airmail Telnet Module to B2F forward email (and multiple attachments) to JNOS ! Added NEW j2sysevent() notification for bbs CONN, and DISC events. Added '3' value to 'Mfbb' so that JNOS will now show B2F in the SID for incoming connects. Use the 'mbox fbb 3' command. This uses the new B2F mailbox SID string (version.c). if the default forwarding protocol is set to B2F, ie: 'mbox fbb 3', which is now the default value for JNOS after you apply this patch, we add the number '2' to the SID that we present to any incoming connects. However, it *seems* that putting in the '2' messes up compressed forwarding when FBB 7.00 connects to us. FBB *seems* to insert an additional 2 bytes in front of the regular forwarding data. What I have done to counter this, is create a 'noB2F' list. If the incoming station that connects to us is in the 'noB2F' list, then we will just give that station the regular FBBCMP side, not the B2F one. The check for noB2F * mailbox.h Added '#define MBX_REVB2F 18' to indicate B2F reverse forward mode. Added 3rd option, FBB batched (B2F compressed) to Mfbb global var. Added 'sid2' member to mbx structure definition, since 'sid' does not have enough room. Need 'sid2' for B2F and future considerations. Added extern reference to the new B2F mailbox SID string (version.c). * makefile Added -DB2F -DMB_XFBB_KLUDGE to the PATCHES line, added b2f.o object file. * mboxcmd.c If B2F is defined at compile time, the FBB forward level (mbox fbb) will now default to 3 (B2F), instead of the previous value of 2 (FBBCMP) ... Modified dombfbb() - maxvalue is now 3, not 2 (if B2F is compiled in). Added new 'mbox nob2f' command, for the 'noB2F' list mentioned earlier. Required me to create another new function, doaddnoB2F(), which calls a couple of new functions that I wrote - j2noB2F() and j2AddnoB2F(), contained in the new source file, b2f.c. * mboxmail.c Removed a bunch of long unused '#ifdef notdef' code. Modified dosid() to set m->sid and new m->sid2 with new MBX_B2F flag if the incoming SID contains a '2' identifier. * version.c Bumped up the version to 2.0f2 (primarily B2F and airmail development). Added a new SID string, char MBoxIdB2F[], for B2F forwarding. * NEW FILE - b2f.c Two functions, j2noB2F() to display the current list (if called with NULL callsign), or to return value 1 if the passed callsign is in the list, and j2AddnoB2F() to add the passed callsign to the existing 'noB2F' list. You can't delete from the list at this time, only add to it. The list will disappear only when JNOS terminates or exits ... ----- 73 de Maiko Langelaar / VE4KLM http://www.langelaar.net/jnos2