Subj : Re: Routing Problem
To   : Dale Shipp
From : Mvan Le
Date : Sat Jan 05 2008 09:47 pm

-=> 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 <nodelist file>" 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 <node> <nodes ...> (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 <name> <main-outbound> <default-zone>
 # or
 #     domain <new-name> alias-for <name>
 #

 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 <addr1> ...
 #

 address 3:712/104@fidonet

 ...
 ...
 ...

 #
 # Define a link:
 #       node [[z:]n/]n[.p][@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
* Origin: <Xaragmata>< - Adelaide, Australia +61-8-8351-7637 (3:800/432)

You are viewing proxied material from cvs.synchro.net. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.