1. 14 Apr, 2021 1 commit
  2. 04 Apr, 2021 1 commit
    • Rob Swindell's avatar
      A poll() failure with EINTR does not mean a socket is closed. · fcf58640
      Rob Swindell authored
      This won't impact Synchronet as it has a separate signal handling
      thread, but we still need to behave properly for processes that
      don't.  I'm also saying that ENOMEM does not indicate a disconnection,
      though it may be better to pretend it was disconnected...
      fcf58640
  3. 15 Feb, 2021 2 commits
  4. 16 Aug, 2020 1 commit
  5. 10 Aug, 2020 1 commit
  6. 29 Aug, 2019 1 commit
  7. 20 Aug, 2019 2 commits
  8. 07 Aug, 2019 1 commit
  9. 02 Aug, 2019 1 commit
    • rswindell's avatar
      There appears to be an issue with QWKnet messages being crossed-up where · b81a0c95
      rswindell authored
      a message is posted to a different conference than the original sub-board with
      completely different header information. I suspect this has something to do
      HEADERS.DAT creation or import - not sure. So I added a "Conference"
      headers.dat field for *messages* (it already existed for votes) and use that
      value to confirm that the message header at the associated offset value in the
      QWK packet has the same conference number as the section in the headers.dat
      file. This is really just a sanity check and will only catch messages that were
      mistakening cross-posted (to a different conference) - *but* it log errors and
      save the bad QWK or REP file for me to examine more closely and see what's
      going on - and the message won't be imported (just "lost", which is also bad).
      
      So added more QWK import success/error checking and logging (especially for QWK
      packets since REP importing already had a lot of stats covered).
      
      Another check would be to store the original message number in the headers.dat
      file as well and use that to confirm that the headers.dat section is the
      correct match for the QWK message at that offset. I did not implement this
      check, yet. The conference number check seems like it'll catch most of the bad
      msgs and lead me to the root-cause.
      b81a0c95
  10. 10 Apr, 2019 1 commit
  11. 17 Feb, 2019 2 commits
  12. 08 Feb, 2019 2 commits
    • rswindell's avatar
      Remove unused variable: fp · 37a24e3a
      rswindell authored
      37a24e3a
    • rswindell's avatar
      Add/use new function findstr_list() which opens and returns a string list · 32051b32
      rswindell authored
      suitable for passing to findstr_in_list().
      SBBSecho peformance improvement: don't open/read the twitlist.cfg file for
      *each* imported message: just read it once during initialization (using the new
      findstr_list() function of course).
      Reversed course on the findstr()/trashcan() matching logic: significant leading
      white-space was not backwards compatible (and was the cause of recent lost
      messages in DOVE-Net) - so I decided to go a different route and support
      C-style character escape sequences (e.g. \r, \n, \t, \x##, etc.) in findstr
      comparison strings, so the new way to represent a leading space character
      in a filter file (e.g. twitlist.cfg, name.can) would be: "\ ". So to match (e.g.
      filter/disallow) all strings with a leading space: "\ *". "\x20 *" would also
      work (0x20 is ASCII for "space").
      Now, again, leading white-space in filter files (e.g. text/*.can, twitlist.cfg)
      is ignored. <sigh>
      32051b32
  13. 18 Jan, 2019 1 commit
    • rswindell's avatar
      Log a warning instead of an error when unpacking a QWK REP packet which · 48f95164
      rswindell authored
      contains a message hdr with a block length less than 2. Some versions of
      Mystic apparently generate these REP packets and the errors are annoying
      and there's really nothing the sysop can do about it but report back to
      the user (or QWKnet node) that their packets contained some invalid
      message headers.
      48f95164
  14. 17 Dec, 2018 1 commit
  15. 03 Aug, 2018 1 commit
  16. 25 Jul, 2018 1 commit
  17. 18 Apr, 2018 1 commit
  18. 16 Apr, 2018 1 commit
    • rswindell's avatar
      2 unrelated changes: · 61dd1bf0
      rswindell authored
      1: Wrap SSH cryptDestroySession() calls in a wrapper that tracks the number of
          open sessions and logs errors upon failure (and remaining session count).
          This is how I found the SSH session leak in sbbs_t::hangup().
          Also found multiple cals to SSH_END() which were invalid (no session to
          destroy) and removed them.
      2: If errors are detected when unpacking a REP packet, save the .rep file
          (in data/file/<filename.rep>.<timestamp>.bad) for later inspection.
          Also added some VOTING.DAT debug output (to be removed later).
          Trying to the get to the bottom of the
          "smb_addvote thread_back field missing" errors.
      61dd1bf0
  19. 10 Mar, 2018 1 commit
  20. 20 Nov, 2016 2 commits
    • rswindell's avatar
      VOTING.DAT Backwards-compatibility enhancement: · 8dd3b13e
      rswindell authored
      If a VOTING.DAT file is received which did not contain offset/location
      sections, the vote/polls/etc. wouldn't be imported. Now, when each QWK 'V'
      msg hdr block is imported, the corresponding section is removed from the
      VOTING.DAT and after all QWK importing, the VOTING.DAT is then parsed
      for remaining items/sections and if there are any, imported at that time (in
      order in the file, not in the old poll/vote/closure order).
      8dd3b13e
    • rswindell's avatar
      Solved the networked-voting "ordering problem". QWK/REP packets that contained · 3258eca3
      rswindell authored
      normal messages along with voting data (polls, ballots, etc.) would always be
      imported in this order: msgs, polls, ballots/votes, and then poll-closures.
      This could result in a confusing order of messages in the local msg base where
      there were messages in reply to a poll before the poll appears and other
      oddities. Anyway, this is now resolved by placing a msg "header block" for each
      vote-data item in the MESSAGES.DAT file. Since there is no body/text blocks,
      it should be ignored under normal circumstances, but these header blocks are
      only created if VOTING.DAT is enabled anyway.
      And now, the VOTING.DAT contains an extra line (empty .ini section) with the
      HEADERS.DAT offset associated with the chronology of the item. The format
      is still backwards compatible with the earlier builds that included VOTING.DAT
      support.
      
      Also, fixed the vote/poll/closure Message-IDs containing a msg number of 0
      (while not technically a problem, it wasn't the intention) with the use of the
      new function: get_new_msg_number().
      3258eca3
  21. 19 Nov, 2016 1 commit
  22. 18 Nov, 2016 1 commit
  23. 15 Nov, 2016 1 commit
  24. 10 Nov, 2016 1 commit
    • rswindell's avatar
      Message voting via QWKnet is now fully implemented: · 74902cee
      rswindell authored
      - Users can be restricted from voting with the 'V' restriction
      - Sub-boards can be disalbled for voting in SCFG
      - VOTING.DAT can be include/excluded from QWK packets via user cfg
        (when a VOTING.DAT is received in a REP, the user cfg flag is auto-set)
      - Adds several new text.dat lines (if not present in yours, uses the default)
      
      What's not yet implemented:
      - Notification of votes on your posted messages
      - Method to view/audit all votes
      - Polling
      - Any special handling to auto-exclude votes from msg-related JavaScripts
      74902cee
  25. 06 Dec, 2015 1 commit
    • rswindell's avatar
      QWK import/export now correctly handles the unexpected case of RECIPIENTNETTYPE · 3f587dd7
      rswindell authored
      and RECIPIENTNETADDR fields in messages posted to sub-boards. Apparently
      GoldEd+ does this and it triggered a chain of bugs (mostly cosmetic), but bugs
      that bugged me, so I'm squashing them. Now messages being export to QWK will
      not include the RECIPIENTNETTYPE/ADDR information unless it's netmail.
      Ditto for importing. Also, the net_type is more accurately determined (i.e. if
      there's no '@' in the address, as there not be any expected for QWK and Fido
      net addresses).
      3f587dd7
  26. 08 Jan, 2014 1 commit
  27. 25 Aug, 2011 1 commit
  28. 21 Jul, 2011 1 commit
    • rswindell's avatar
      Complete QWKE support (using MultiMail for testing): · c9f6aaa5
      rswindell authored
      Create and include in packet TOREADER.EXT if QWKEsupport is enabled
      (MultiMail keys of this file for QWKE support, so without, no QWKE features are
      enabled in MultiMail).
      Parse TODOOR.EXT if included in REP packets (for adding/dropping subs or
      setting/resetting pointers).
      Parse To:, From:, and Subject: QWKE kludge lines and use if/when appropriate
      (e.g. to defeat QWK 25-char header field limits).
      Create To:, From:, and Subject: QWKE kludge lines in QWK/REP packets when
      QWKE support is enabled and those fields exceed QWK limits (25 chars).
      Also, legacy SyncQNET kludge lines (@VIA, @TZ, etc.) may now exist in the
      top of the message body in any order.
      Note: current versions of MultiMail do not support "To" fields > 25 chars, even
      in QWKE mode (though I have a patch pending) and do not (yet) support
      Synchronet HEADERS.DAT file (rendering QWKE kludges unnecessary).
      These are major changes in the QWK/REP creation/parsing code, so testing
      (especially with QWKE-compliant offline readers) and bug reports are welcome!
      c9f6aaa5
  29. 12 Mar, 2010 1 commit
  30. 06 Mar, 2010 1 commit
  31. 09 Nov, 2009 1 commit
  32. 28 Oct, 2009 1 commit
  33. 27 Oct, 2009 1 commit
  34. 17 Aug, 2009 1 commit
  35. 20 Mar, 2009 1 commit