my zone 39:xx links are:
39:ALL , set local aka to 39:943/0 and Route To 39:90/0
Hi Ragnarok,
On 2021-10-03 23:06:20, you wrote to DOVE-Net.Synchronet_Discussion:
Ra> my zone 39:xx links are:
Ra> 39:ALL , set local aka to 39:943/0 and Route To 39:90/0
I don't know how synchronet works, so maybe this is "automatic", but I think there should be an exception for this route:
39:943/ALL shouldn't be routed to 39:90/0 ! Because you would get those messages back immediately, and a loop is born...
I don't know how synchronet works, so maybe this is "automatic", but IHi Wilfred! i don't route 39:943/all to 39:90/0
think there should be an exception for this route:
39:943/ALL shouldn't be routed to 39:90/0 ! Because you would get those
messages back immediately, and a loop is born...
now, for the z39 i have:
39:90/0 my boss -> your node :)
39:ALL route to 39:90/0
39:943/100 (my downlink node for testing)
I don't know how synchronet works, so maybe this is "automatic", but I
think there should be an exception for this route:
39:943/ALL shouldn't be routed to 39:90/0 ! Because you would get those
messages back immediately, and a loop is born...
Hi Wilfred! i don't route 39:943/all to 39:90/0
You shouldn't but it seems you do!?
now, for the z39 i have:
39:90/0 my boss -> your node :)
39:ALL route to 39:90/0
39:943/100 (my downlink node for testing)
There is no "39:943/all no route"...?
Hi all i working on makenl to create a nodelist updates for 39:943
the tool generate a simple netmail to send the generated file this is
the fmsgdump output:
root@scarlet:/sbbs/fido/makenl/msgout# fmsgdump -ctrl -body 1.msg
fmsgdump rev 3.6 - Dump FidoNet Stored Messages
Opening 1.msg
Subj: /sbbs/fido/makenl/out/net.943
Attr: 0x0191 (PRIVATE, FILE, KILLSENT, LOCAL)
To : Coordinator (39:943/100.0)
From: MakeNL 3.5.1 (39:943/0.0)
Time: 03 Oct 21 01:41:01
-start of message text-
@MSGID: 39:943/0 615908bc
-end of message text-
I move that file to netmail directory on sbbs for sbbsecho procesing.
I notice that the sbbsecho log weird address (4:943) instead of 39:943,
so this was ruoted via 4:* (zone was rewrite)
2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
to Coordinator (4:943/100), attr: 0191, subject: /sbbs/fido/makenl/out/net.943
I notice that the sbbsecho log weird address (4:943) instead of 39:943,
so this was ruoted via 4:* (zone was rewrite)
2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
to Coordinator (4:943/100), attr: 0191, subject:
/sbbs/fido/makenl/out/net.943
Looks like Fuzzy Zone operation is enabled.
Fuzzy Zone Operation when set to Yes, if SBBSecho receives an inbound
netmail with NO international zone information, it will compare the
net/node of the destination to the net/node information in your AKAs
and assume the (source and destination) zone of a matching AKA.
This setting defaults to No.
Re: makenl sbbsecho and netmail and routing issue
By: Ragnarok to DOVE-Net.Synchronet_Discussion on Sun Oct 03 2021 11:06 pm
> Hi all i working on makenl to create a nodelist updates for 39:943
>
> the tool generate a simple netmail to send the generated file this is
> the fmsgdump output:
>
> root@scarlet:/sbbs/fido/makenl/msgout# fmsgdump -ctrl -body 1.msg
> fmsgdump rev 3.6 - Dump FidoNet Stored Messages
>
> Opening 1.msg
> Subj: /sbbs/fido/makenl/out/net.943
> Attr: 0x0191 (PRIVATE, FILE, KILLSENT, LOCAL)
> To : Coordinator (39:943/100.0)
> From: MakeNL 3.5.1 (39:943/0.0)
> Time: 03 Oct 21 01:41:01
>
> -start of message text-
> @MSGID: 39:943/0 615908bc
> -end of message text-
>
> I move that file to netmail directory on sbbs for sbbsecho procesing.
>
> I notice that the sbbsecho log weird address (4:943) instead of 39:943,
> so this was ruoted via 4:* (zone was rewrite)
>
> 2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
> to Coordinator (4:943/100), attr: 0191, subject:
> /sbbs/fido/makenl/out/net.943
Looks like Fuzzy Zone operation is enabled.
Fuzzy Zone Operation when set to Yes, if SBBSecho receives an inbound
netmail with NO international zone information, it will compare the
net/node of the destination to the net/node information in your AKAs
and assume the (source and destination) zone of a matching AKA.
This setting defaults to No.
Hi Digital,
On 2021-10-04 19:06:36, you wrote to Ragnarok:
>> I notice that the sbbsecho log weird address (4:943) instead of 39:943,
>> so this was ruoted via 4:* (zone was rewrite)
>>
>> 2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
>> to Coordinator (4:943/100), attr: 0191, subject:
>> /sbbs/fido/makenl/out/net.943
DM> Looks like Fuzzy Zone operation is enabled.
DM> Fuzzy Zone Operation when set to Yes, if SBBSecho receives an inbound
DM> netmail with NO international zone information, it will compare the
DM> net/node of the destination to the net/node information in your AKAs
DM> and assume the (source and destination) zone of a matching AKA.
DM> This setting defaults to No.
I checked a stored message that makenl generates. It has the complete 4D address of the source and destination in the header (and also the source address in the MSGID kludge). A tosser should put those in the INTL kludge of the packed message in the .pkt file it generates. The Fuzzy Zone setting shouldn't overrule the information in an INTL kludge if present. So where does this go wrong?
I checked a stored message that makenl generates. It has the complete
4D address of the source and destination in the header (and also the
source address in the MSGID kludge). A tosser should put those in the
INTL kludge of the packed message in the .pkt file it generates. The
Fuzzy Zone setting shouldn't overrule the information in an INTL kludge
if present. So where does this go wrong?
this is the example file:
http://downloads.bbs.docksud.com.ar/tmp/1.msg
Hi Digital,
On 2021-10-04 19:06:36, you wrote to Ragnarok:
>> I notice that the sbbsecho log weird address (4:943) instead of 39:943,
>> so this was ruoted via 4:* (zone was rewrite)
>>
>> 2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
>> to Coordinator (4:943/100), attr: 0191, subject:
>> /sbbs/fido/makenl/out/net.943
DM> Looks like Fuzzy Zone operation is enabled.
DM> Fuzzy Zone Operation when set to Yes, if SBBSecho receives an inbound
DM> netmail with NO international zone information, it will compare the
DM> net/node of the destination to the net/node information in your AKAs
DM> and assume the (source and destination) zone of a matching AKA.
DM> This setting defaults to No.
I checked a stored message that makenl generates. It has the complete 4D address of the source and destination in the header (and also the source address in the MSGID kludge). A tosser should put those in the INTL kludge of the packed message in the .pkt file it generates. The Fuzzy Zone setting shouldn't overrule the information in an INTL kludge if present. So where does this go wrong?
Hi Digital,
On 2021-10-04 19:06:36, you wrote to Ragnarok:
I notice that the sbbsecho log weird address (4:943) instead of 39:943,
so this was ruoted via 4:* (zone was rewrite)
2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
to Coordinator (4:943/100), attr: 0191, subject:
/sbbs/fido/makenl/out/net.943
Looks like Fuzzy Zone operation is enabled.
Fuzzy Zone Operation when set to Yes, if SBBSecho receives an inbound
netmail with NO international zone information, it will compare the
net/node of the destination to the net/node information in your AKAs
and assume the (source and destination) zone of a matching AKA.
This setting defaults to No.
I checked a stored message that makenl generates. It has the complete 4D address of the source and destination in the header (and also the source address in the MSGID kludge). A tosser should put those in the INTL kludge of the packed message in the .pkt file it generates. The Fuzzy Zone setting shouldn't overrule the information in an INTL kludge if present. So where does this go wrong?
Looks like Fuzzy Zone operation is enabled.
I disable the Fuzzy zone option but have same result
2021-10-05 09:59:21 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
to Coordinator (4:943/100), attr: 0191, subject: /sbbs/fido/makenl/out/net.943
2021-10-05 09:59:21 Routing NetMail (1.msg) to 4:90/1
I checked a stored message that makenl generates. It has the complete
4D address of the source and destination in the header (and also the
source address in the MSGID kludge). A tosser should put those in the
INTL kludge of the packed message in the .pkt file it generates. The
Fuzzy Zone setting shouldn't overrule the information in an INTL kludge
if present. So where does this go wrong?
The Fuzzy Zone setting instructs SBBSecho to ignore the zone information in
the netmail message header. If the netmail itself had an INTL kludge, it would use the zone information from that, but makenl isn't adding it. So, with Fuzzy Zone behavior, SBBSecho will "guess" the zone information based on the destination net/node/point. It's an arcane feature for old pre-historic "stored messages" and probably should just be removed.
Re: Re: makenl sbbsecho and netmail and routing issue
By: Wilfred van Velzen to Digital Man on Tue Oct 05 2021 09:45 am
> Hi Digital,
>
> On 2021-10-04 19:06:36, you wrote to Ragnarok:
>
> >> I notice that the sbbsecho log weird address (4:943) instead of 39:943,
> >> so this was ruoted via 4:* (zone was rewrite)
> >>
> >> 2021-10-03 22:42:03 Packing NetMail (1.msg) from MakeNL 3.5.1 (4:943/0)
> >> to Coordinator (4:943/100), attr: 0191, subject:
> >> /sbbs/fido/makenl/out/net.943
>
> DM> Looks like Fuzzy Zone operation is enabled.
>
> DM> Fuzzy Zone Operation when set to Yes, if SBBSecho receives an inbound
> DM> netmail with NO international zone information, it will compare
> DM> the
> DM> net/node of the destination to the net/node information in your
> DM> AKAs
> DM> and assume the (source and destination) zone of a matching AKA.
> DM> This setting defaults to No.
>
> I checked a stored message that makenl generates. It has the complete 4D
> address of the source and destination in the header (and also the source
> address in the MSGID kludge). A tosser should put those in the INTL kludge
> of the packed message in the .pkt file it generates. The Fuzzy Zone setting
> shouldn't overrule the information in an INTL kludge if present. So where
> does this go wrong?
The Fuzzy Zone setting instructs SBBSecho to ignore the zone information in the netmail message header. If the netmail itself had an INTL kludge, it would use the zone information from that, but makenl isn't adding it. So, with Fuzzy Zone behavior, SBBSecho will "guess" the zone information based on the destination net/node/point. It's an arcane feature for old pre-historic "stored messages" and probably should just be removed.
Indeed, you probably almost never need it. Maybe with really old software that generates *.msg files. But should you want to use that software?
This was the correct solution, I had deactivated fuzzy zone, but it
still did not work until I changed the INTL parameter in the makenl config
Re: Re: makenl sbbsecho and netmail and routing issue
By: Ragnarok to Digital Man on Tue Oct 05 2021 10:03 pm
> This was the correct solution, I had deactivated fuzzy zone, but it
> still did not work until I changed the INTL parameter in the makenl config
If that is truly the case, then there's a bug - and I would be surprised (since that's some pretty damn old code there). Are you positive? Do you mind retesting, that is, disabling the INTL parameter in your makenl config, double checking your sbbsecho.ini that "Fuzzy Zone" operation is in fact not enabled, and reproducing the problem again?
El 6/10/21 a las 00:24, Digital Man escribi¢:
Re: Re: makenl sbbsecho and netmail and routing issue
By: Ragnarok to Digital Man on Tue Oct 05 2021 10:03 pm
> This was the correct solution, I had deactivated fuzzy zone, but it
> still did not work until I changed the INTL parameter in the makenl config
If that is truly the case, then there's a bug - and I would be surprised (since that's some pretty damn old code there). Are you positive? Do you mind retesting, that is, disabling the INTL parameter in your makenl config, double checking your sbbsecho.ini that "Fuzzy Zone" operation is in fact not enabled, and reproducing the problem again?
Yes I can confirm with fuzzy zone is disabled and whitout INTL parameter
on makenl.ctl, it does not work
Re: Re: makenl sbbsecho and netmail and routing issue
By: Ragnarok to Digital Man on Wed Oct 06 2021 10:13 am
> El 6/10/21 a las 00:24, Digital Man escribi�:
> > Re: Re: makenl sbbsecho and netmail and routing issue
> > By: Ragnarok to Digital Man on Tue Oct 05 2021 10:03 pm
>
> > > This was the correct solution, I had deactivated fuzzy zone, but it
> > > still did not work until I changed the INTL parameter in the makenl
> > config
>
> > If that is truly the case, then there's a bug - and I would be surprised
> > (since that's some pretty damn old code there). Are you positive? Do you
> > mind retesting, that is, disabling the INTL parameter in your makenl
> > config, double checking your sbbsecho.ini that "Fuzzy Zone" operation is
> > in fact not enabled, and reproducing the problem again?
>
> Yes I can confirm with fuzzy zone is disabled and whitout INTL parameter
> on makenl.ctl, it does not work
Okay, thanks for confirming. I see what's going on now: "Fuzzy Zone" operation is for *importing* netmail, which is not what you're having a problem with. Your problem was with *packing* netmail, where the "Fuzzy Zone" feature is not used and instead the zone information from the header of the netmail message is simply discarded. I'll fix that and appreciate you re-testing when you get a chance and letting us know how that worked.
Sysop: | Chris Crash |
---|---|
Location: | Huntington Beach, CA. |
Users: | 579 |
Nodes: | 8 (0 / 8) |
Uptime: | 00:46:40 |
Calls: | 10,740 |
Files: | 5 |
Messages: | 444,492 |