-=> Quoting Dale Shipp to Mvan Le <=-

 -=> On 12-31-07  02:19,  Mvan Le <=-
 -=> spoke to Dale Shipp about Re: Routing Problem <=-
 
 ML> Ok. Based on the information above, 
 
 ML> 01130064.flo 
 
 ML> means you're trying to send a "Normal" flavoured packet to 
 ML> 3:275/100 (the "01130064" part of 01130064.flo is 3275100 
 ML> in hex, and the ".flo" part of 01130064.flo in Binkley-
 ML> style outbound filenames means Normal routed mail).

Hmm. People are asleep in this echo ... I'm slacking off myself. I thought
somebody would've fixed your problem by now because it seems pretty obvious
to me.

 DS> Took me a while to figure out how you got that.   0x113 = 275 and
 DS> 0x064 = 100.  Not sure where the 3 came from.  The node the netmail

Woops. Sorry. You're right. The zone is determined by the primary address
defined in Squish.cfg and/or the domain in your BinkP compatible mailer.
Files for other zones go into h:\argus\out.[23456789] etc (if your default
domain is "1").  

 DS> was addressed to was 1:275/100.  That netmail was still sitting
 DS> there tonight.  I had to readdress it using the Argus interface to
 DS> make it get routed to 1:123/500 -- which is how my ROUTE.CFG file
 DS> says should happen to almost all netmail.  The fact that it does not
 DS> get addressed to 1:123/500 is the problem.
 
 ML> Argus should automatically send your net netmail packets 
 ML> (ie. the filename listed within the .clo file).

 DS> Before I made Argus readdress it, I also tried to change the flavor
 DS> to crash.  That caused Argus to attempt a poll to
 DS> f100.n275.z1.fidonet.org.   I'm uncertain how that could have worked
 DS> since 1:275/100 is PVT and that DNS does not exist.

This is normal (default) BinkP behaviour for unlisted nodes, and only works
for static IPs. You got to register your (or the target) net/node's static
IP address with fidonet.org DNS for this behaviour to work. 

Otherwise you will need to manually define a node & IP entry for
1:275/100 (et al) in Argus configuration so that if it finds a file named
01130064.*o it will know where to send it. 

Or disable unlisted node dialing in Argus.  

Instructions on how to obtain a BinkP nodelist are posted in the BinkD
echo. (I don't know how to incorporate that nodelist into Argus (In BinkD
you just use the "Include " directive)).
 
 ML> Hence we would focus troubleshooting efforts on your BBS 
 ML> and Squish, in which case post the contents of your 
 ML> route.cfg file.

 DS> My route.cfg file has a lot of standard comments in it.   Here is
 DS> what remains after they are removed:

 DS> Send Normal World
 DS> Route           normal   1:123/500 1:All 2:All 
 DS> 3:All 4:All 5:All 6:ALL
 DS> Send            Crash   1:140/1
 DS> Send     Crash   1:261/1
 DS> Send            Crash   1:261/38
 DS> Send            normal   1:123/500

 DS> I have tried altering the order, and changing the flavor to 1:123/500
 DS> to crash instead of normal the two times it appears.   No effect on
 DS> behavior -- mail still gets stuck without being routed.

Order is important. 

Try this,

  =================
  Send Normal World
  #End Route.Cfg
  =================

Ie. "Send Normal World" is the only command you need. You don't
need all the other Send commands unless you want to specifically alter the
flavour of the packet for those   (in this
case netmail message), for example when you're a NC or hub and want to
alter passthru messages. 

For crash *netmail* messages that originate from your system, you don't
need Send Crash in Route.cfg.

The reason why your crash netmail aren't sent immediately as expected is
because Argus isn't configured to send to those nodes properly (eg.
indicative from your f100.n275.z1.fidonet.org problem) and that you're
altering the CRASH flag before saving the message -- Leave the CRASH flag
alone. 

The reason why Argus will only send to 1:123/500 is because it knows about
1:123/500 :) ...

When you create a Crash netmail message in IE (Intermail Editor (which I
know nothing about)), I hope it behaves correctly by assuming it will
create a packet in your outbound directory after Squish Squash is run. 

For example, if a crash netmail created is addressed to 1:275/100 the
following steps should occur, 

  1. Squish Squash
  2. The following file containing your message is created
"H:\Argus\Out\01130064.cut"
  3. If Argus has 1:275/100 configured in its nodelist, it will dial the IP
and establish a session

Nb. A *.?ut file means the Binkley-style packet is uncompressed, and a
*.?lo file means it's a header file that contains further instructions
inside.

The way you currently have Route.Cfg set up, ie. 

  ==============================================
  Send Normal World
  Route           normal   1:123/500 1:All 2:All 
  3:All 4:All 5:All 6:ALL
  Send            Crash   1:140/1
  Send     Crash   1:261/1
  Send            Crash   1:261/38
  Send            normal   1:123/500
  ==============================================

All your mail is getting re-addressed to 1:123/500, so the other Send
commands have no effect.

Anyway, your problem is to do with Argus. You need to define the
destination node & IP addresses in Argus. If it doesn't know about the
destination, your packet will just get stuck in the outbound directory. And
check that the crash netmail message is created in your outbound directory
with *.cut extension.

As a comparison, here is my Binkd.cfg file:

  ====================================================================
  # Your FTN domains:
  #     domain   
  # or
  #     domain  alias-for 
  #

  domain fidonet     M:\\mailing\\mailer\\bt\\out\\ftn 3
  domain fido        alias-for fidonet
  domain fidonet.org alias-for fidonet
  domain fidonet.net alias-for fidonet

  # 
  # Your addresses, 4D or 5D:
  #       address  ...
  #
  
  address 3:712/104{at}fidonet

  ...
  ...
  ...

  #
  # Define a link:
  #       node [[z:]n/]n[.p][{at}domain] [-nr|-nd] [-md] [-ip|-sip] 
  #       [{hosts|-} [{pwd|-} [flavour [{obox|-} [{ibox|-}]]]]]
  #

  include nodelist.inc

  node 3:712/0 -md sysgod.org mypassword

  node 1:343/41 tophat.darktech.org

  #
  # Default node flags. Binkd will call unlisted node if "defnode" 
  # defined.
  #
  # The line below sets up default node settings for -nr (not 
  # reliable link) and instructs BinkD to do 1:2/3.4 --> 
  # p4.f3.n2.z1.fidonet.net translation.
  #
  #defnode -nr *
  ====================================================================

Based on the "defined links" section above, you can see that I
only intend on sending crash mail to 3:712/0 and 1:343/41. I define these
entries after the "include" so that my specs override the ones
from nodelist.inc (because I don't trust it). I also don't bother with
unlisted nodes.

--- Maximus 3.01