Hi! Wilfred,

A funny thing happened yesterday. I finally tested FMail's "ping" function, from my other point...

09 Jan 18 09:03:21 FMAIL Processing 87479A7C.PKT from 3:640/384 to 3:640/1384
09 Jan 18 09:03:21 FMAIL Pkt info: FastEcho 1.46, Type 2+, 415,
2018-01-09 08:51:06, Pwd, Sec
09 Jan 18 09:03:21 FMAIL Processed PING request message from
3:640/384.125 to 3:640/1384
09 Jan 18 09:03:21 FMAIL Deleted: /opt/ftn/fido/inbound/87479A7C.PKT

That worked beautifully. OTOH, the pack manager's handling of FMAil's response
caught me by surprise, with...

09 Jan 18 09:03:21 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 - Pack -C
09 Jan 18 09:03:21 FMAIL Warning: Node 3:640/384.125 is not defined in
the node manager
09 Jan 18 09:03:21 FMAIL Message #1 : 3:640/1384 -> 3:640/384.125
09 Jan 18 09:03:21 FMAIL Create /opt/ftn/fido/outbound/02800180.pnt/0000007d.flo
09 Jan 18 09:03:21 FMAIL Sending new mail from 3:640/1384 to
3:640/384.125
09 Jan 18 09:03:21 FMAIL Netmail: 1, Personal: 0, Hudson: 0, JAMbase:
0
09 Jan 18 09:03:21 FMAIL Msgbase net: 0, echo: 0, dup: 0, bad: 0
09 Jan 18 09:03:21 FMAIL Pack Active: 0.0062 sec.

Since I didn't have a 'node' setting in binkD for the point, it meant the mail packet just got hung up (the default binkD ~binkp.net addressing wouldn't work as it's a point, and therefore not available from the WAN side).

To my way of thinking it shouldn't have happened. The pack manager's routing is defined as...

9. 3:640/* via 3:640/384
10. 1:* 2:* 3:* 4:* 5:* 6:* via 3:640/384

(The other 8 entries deal with other zones & regions.)

So, I'm wondering what I might need to add to the routing table in the event of
further "ping" queries, especially from other 'unknown' nodes? Did the "Pack -C" statement have any bearing?

Do you have time to help, please?

Cheers,
Paul.

... Bad command. Bad, bad command! Sit! Stay! Staaay...
--- GoldED+/LNX 1.1.5-b20110213
* Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)

Hi Paul,

On 10 Jan 18 12:25, Paul Quinn wrote to Wilfred van Velzen:
about: "FMail-lnx32-2.1.0.18-Beta20170905 netmail Pack":

That worked beautifully. OTOH, the pack manager's handling of FMAil's response caught me by surprise, with...

09 Jan 18 09:03:21 FMAIL FMail-lnx32-2.1.0.18-Beta20170905 - Pack -C
09 Jan 18 09:03:21 FMAIL Warning: Node 3:640/384.125 is not defined in
the node manager
09 Jan 18 09:03:21 FMAIL Message #1 : 3:640/1384 -> 3:640/384.125
09 Jan 18 09:03:21 FMAIL Create
/opt/ftn/fido/outbound/02800180.pnt/0000007d.flo
09 Jan 18 09:03:21 FMAIL Sending new mail from 3:640/1384 to
3:640/384.125
09 Jan 18 09:03:21 FMAIL Netmail: 1, Personal: 0, Hudson: 0, JAMbase:
0
09 Jan 18 09:03:21 FMAIL Msgbase net: 0, echo: 0, dup: 0, bad: 0
09 Jan 18 09:03:21 FMAIL Pack Active: 0.0062 sec.

Since I didn't have a 'node' setting in binkD for the point, it meant the mail packet just got hung up (the default binkD ~binkp.net addressing wouldn't work as it's a point, and therefore not available from the WAN side).

To my way of thinking it shouldn't have happened. The pack manager's routing is defined as...

9. 3:640/* via 3:640/384
10. 1:* 2:* 3:* 4:* 5:* 6:* via 3:640/384

(The other 8 entries deal with other zones & regions.)

So, I'm wondering what I might need to add to the routing table in the event of further "ping" queries, especially from other 'unknown' nodes? Did the "Pack -C" statement have any bearing?

It might be due to the -C indeed. Although PING replies shouldn't have the Crash flag (I think), so shouldn't be touched by 'Pack -C'. But doing 'Pack -C'
the right way is a bit odd:

The syntax of FMail Pack:

FMail Pack [ <node>...
[EXCEPT <node>...]
[VIA <node>|HOST]
[/A] [/C] [/H] [/I] [/L] [/O]
]

So if you specify -C you _must_ specify the <node>, otherwise the behaviour is undefined.

What I do in my pack script is something like:

$BIN/fmail pack 2>&1 | tee -a $LOG
...
$BIN/fmail pack '*' '-c' 2>&1 | tee -a $LOG

So pack routed netmail first, and then handle the unsend crash mail that is left in my netmail folder.

Wilfred.

--- FMail-W32 2.0.1.4
* Origin: point@work (2:280/464.112)

Hi! Wilfred,

On 10 Jan 18 09:42, you wrote to me:

What I do in my pack script is something like:
$BIN/fmail pack 2>&1 | tee -a $LOG
...
$BIN/fmail pack '*' '-c' 2>&1 | tee -a $LOG

Fascinating.

So pack routed netmail first, and then handle the unsend crash mail
that is left in my netmail folder.

Ah, yes. I have another idea in mind, and already on hand, that will employ a similar process. Thank you, kindly.

Cheers,
Paul.

... No smoke or sparks! ...Hmmm... Must be a software problem then...
--- GoldED+/LNX 1.1.5-b20110213
* Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)

Hi Paul,

On 2018-01-10 20:25:15, you wrote to me:

What I do in my pack script is something like:
$BIN/fmail pack 2>&1 | tee -a $LOG
...
$BIN/fmail pack '*' '-c' 2>&1 | tee -a $LOG

Fascinating.

Btw: That logging stuff at the end of the lines is because of my "debugging" FMail. Regular users could just dump it to /dev/null or let it just print on the terminal it runs in. The regular fmail.log should contain enough information for them. ;)

So pack routed netmail first, and then handle the unsend crash mail
that is left in my netmail folder.

Ah, yes. I have another idea in mind, and already on hand, that will employ a similar process. Thank you, kindly.

Let us know how it works out!

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Wilfred,

On 10 Jan 18 13:15, you wrote to me:

Fascinating.

Btw: That logging stuff at the end of the lines is because of my "debugging" FMail. Regular users could just dump it to /dev/null or
let it just print on the terminal it runs in. The regular fmail.log
should contain enough information for them. ;)

No worries, mate. I would have just dropped the extra and gone with whatever FMail wanted to throw to the logfile in any case.

So pack routed netmail first, and then handle the unsend crash
mail that is left in my netmail folder.

Ah, yes. I have another idea in mind, and already on hand, that
will employ a similar process. Thank you, kindly.

Let us know how it works out!

Absolutely. I give it another go on my netbook tomorrow AM, my time. It's how
I start my days: breakfast in bed, reading Fido mail. :-D

Cheers,
Paul.

... I admit I wrote in COBOL once, but I never compiled.
--- GoldED+/LNX 1.1.5-b20110213
* Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)

Hi! Wilfred,

On 01/10/2018 10:23 PM, Paul Quinn -> Wilfred van Velzen wrote:

So pack routed netmail first, and then handle the unsend crash
mail that is left in my netmail folder.

Ah, yes. I have another idea in mind, and already on hand, that
will employ a similar process. Thank you, kindly.

Let us know how it works out!

I cheated. My plan B has been an 'understudy' for FMail pack for the longest time; I used CF-Route. Its config for the pertinent routing is simply...

TOPDOWN
[ ... ]
ROUTE-TO 3:640/384 1:* 2:* 3:* 4:*

As with FMail's pack manager, other statements take care of other zones & regions. The logfile looked like this...

------------------------------------------------------
CFR-UNX 0.95a started at Jan 11,2018 (Thu) 00:07:06

From: FMail PING bot (3:640/1384.0)
To: Paul Quinn (3:640/384.125)
Subj: Pong: Hi! How are ya?
Date: 11-01-2018 00:07:06 - 0 days ago - Body size: 1013
Attr: Pvt Loc
Via: 3:640/384.0 as NORMAL (OUT).
File: /opt/ftn/fido/outbound/02800180.OUT ------------------------------------------------------

It was all over & dusted before corn flakes. ;-P

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Paul's Puppy 4.2.1 multiuser vBox - M'boro, Qld, OZ (3:640/384.125)