REPLY: 33.fdn_argus@3:633/509 220e227f   
   MSGID: 1:3634/12.73 5da8f593   
   PID: GED+LNX 1.1.5-b20180707   
   CHRS: CP437 2   
   TZUTC: -0400   
   TID: hpt/lnx 1.9.0-cur 17-02-17   
      
    On 2019 Oct 18 09:34:06, you wrote to me:   
      
    ML>> paul, has a connection with this system worked in the past or is this   
    ML>> the first attempt at connecting between your systems?   
      
    DG> So it has in the past. (I'm the connection Paul is refering to).   
      
   yup :)   
      
    DG> This is Argus -> Argus - whats recently changed is the tosser - and   
    DG> thus the format of the ?LO files. (The packets are still going to the   
    DG> same path they were previously).   
      
   the FLO files' format should not have changed... my binkd and sbbs' binkit   
   both work just fine with sbbsecho's ?lo files...   
      
   the path HAS to be in the ?LO files so the mailer knows where to look for the   
   file...   
      
   you might consider to tcpdump a transaction from sbbs -> binkd and one from   
   sbbs -> argus and seeing if the path in the ?LO file is actually transmitted...   
      
    DG> I dont recall what the format was previously (it was Ezycom), but now   
    DG> that SBBS is tossing the mail, the interpretation of the ?LO files is   
    DG> incorrect by Argus.   
      
   perhaps you have or can grab the argus source code and take a look?   
      
    DG> (My) Argus is quite happily sending to an upstream SBBS, but fails   
    DG> when sending to an upstream Argus.   
      
   what does the argus ?LO files look like? you should tcpdump capture that,   
   too...   
      
    DG> SBBS is configured to toss mail in the outbound C:/mailer/outbound   
    DG> (I've also tried C:\mailer\outbound - but the format of the ?LO file   
    DG> is ^C:/mailer/outbound...)   
      
   because the direction of the slash doesn't matter to modern software... IIRC,   
   argus/radius/taurus don't care... i've run them all in the past when i had a   
   working winwhatever setup... somewhere around here i also have the source code   
   to each of them... it is delphi and i don't do delphi so i need to port it to   
   freepascal/lazarus which, when i tried, needed some more work on the   
   conversion translator... that was at least 5+ years ago when the rough idea   
   was to port them to linux as well as to freepascal/lazarus...   
      
    DG> Argus is configured for the outbound has \mailer\outbound (and its   
    DG> installed on C:)   
      
   that's fine...   
      
    DG> If I drop the "C:" from the SBBS config - argus interprets the   
    DG> outgoing packet as C:\mailer\outbound/mailer/outbound.015/xxxx.pkt   
    DG> (and thus is invalid and doesnt send). (The format of the ?LO is   
    DG> ^/mailer/outbound.015/xxxx.pkt)   
      
   yeah... that's a slight bug, IMHO... but we know how it wants things so we do   
   it that way...   
      
    DG> If I leave the "C:" in the SBBS config - argus happily attempts to   
    DG> transfer the files (it knows about it, reports the size, etc) - and   
    DG> sends happily to another SBBS - but to another Argus, the remote   
    DG> refuses. (In this case the remote is Paul). (And in this case the   
    DG> format of the ?LO file is ^C:/mailer/outbound.015/xxx.pkt)   
      
   yeah... the problem is that that local path should not be being transferred...   
   the remote side has no need to know anything about your local paths...   
      
    DG> My work around is to get SBBS to toss the mail into an outbox, and   
    DG> have that outbox configured in Argus.   
      
   that'll work, too... painful but works...   
      
    DG> I'm not sure who is "at fault"? I would suggest Argus - it shouldnt be   
    DG> sending to the remote the name of the file as /mailer/outbound.015/xxx.pkt   
    DG> right? it should just say here is packet xxx.pkt and the remote saves it   
    DG> with whatever name it wants, in whatever path it is configured?   
      
   right... so something (argus) is not stripping out the path from the   
   transmitted information...   
      
   did you see my other post about using a different protocol than hydra? the   
   fault could be in there... tell your argus to use something other than hydra   
   and see what happens...   
      
   FWIW: argus was the first in the "ART" family... then came radius... it is a   
   drop-in replacement and fixes numerous bugs while adding a few features...   
   taurus is the latest one... it is a drop-in replacement for argus and   
   radius... it also fixes bugs and brings even more features...   
      
   you don't say what version of argus you are running but a newer one might have   
   a fix for this bug... perhaps it would be an idea to try radius and/or taurus,   
   too...   
      
   )\/(ark   
      
   Once men turned their thinking over to machines in the hope that this would   
   set them free. But that only permitted other men with machines to enslave them.   
   ... Habs. Doan Touch! Too hut! - Neekha   
   ---   
    * Origin:  (1:3634/12.73)   
   SEEN-BY: 1/19 120 123 14/6 15/0 2 16/0 18/0 19/36 34/999 90/1 104/57   
   SEEN-BY: 106/201 116/18 116 120/302 123/0 25 50 130 131 140 150 755   
   SEEN-BY: 132/174 135/300 153/7715 203/0 218/700 221/0 1 6 360 222/2   
   SEEN-BY: 227/114 229/354 426 452 728 1014 230/0 150 152 240/5832 249/206   
   SEEN-BY: 249/317 250/1 261/38 100 1466 266/512 267/155 275/100 280/464   
   SEEN-BY: 280/5003 282/1031 1056 291/1 111 292/854 300/4 317/3 320/119   
   SEEN-BY: 320/219 322/0 757 340/400 342/13 200 396/45 423/120 633/280   
   SEEN-BY: 640/1321 1384 712/848 770/1 801/161 189 2320/105 2452/250   
   SEEN-BY: 3634/0 12 15 27 50 119 5020/1042   
   PATH: 3634/12 261/38 320/219 221/1 280/464 229/426