Just a sample of the Echomail archive
[ << oldest | < older | list | newer > | newest >> ]
|  Message 1707  |
|  Wilfred van Velzen to Paul Quinn  |
|  Re: FMail-lnx32-2.1.0.18-Beta20170905 ne  |
|  10 Jan 18 09:42:17  |
 
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":
PQ> That worked beautifully. OTOH, the pack manager's handling of FMAil's
PQ> 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.
PQ> Since I didn't have a 'node' setting in binkD for the point, it meant the
PQ> mail packet just got hung up (the default binkD ~binkp.net addressing
PQ> wouldn't work as it's a point, and therefore not available from the WAN
PQ> side).
PQ> To my way of thinking it shouldn't have happened. The pack manager's
PQ> routing is defined as...
PQ> 9. 3:640/* via 3:640/384
PQ> 10. 1:* 2:* 3:* 4:* 5:* 6:* via 3:640/384
PQ> (The other 8 entries deal with other zones & regions.)
PQ> So, I'm wondering what I might need to add to the routing table in the
PQ> event of further "ping" queries, especially from other 'unknown' nodes?
PQ> 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 [
|
[ << oldest | < older | list | newer > | newest >> ]