Nп/п : 7 из 25
От : Vincent Coen 2:250/1 15 фев 25 15:29:36
К : Andrew Leary 15 фев 25 18:51:01
Тема : Possible bug using mbfido no
----------------------------------------------------------------------------------
@MSGID: 2:250/1@fidonet 67b0b476
@REPLY: 1:320/219@fidonet 67b03205
@CHRS: UTF-8 2
@TZUTC: 0000
@TID: MBSE-FIDO 1.1.0 (Linux-x86_64)
Hello Andrew!
15 Feb 25 01:13, you wrote to me:
> Hello Vincent!
> 14 Feb 25 17:35, you wrote to all:
VC>> Just did a notify using mbfido no 2:263/1
VC>> Node reports that the netmails come from 2:263/0
VC>> Now my AKAs are as set up :
VC>> 1 2:250/1@fidonet 11
VC>> 2 2:25/21@fidonet 12
VC>> 3 2:250/0@fidonet 13
VC>> 4 2:25/0@fidonet 14
VC>> 5 2:263/0@fidonet 15
VC>> This is because I am the Host for region 2:25 and therefore 2:250
VC>> and
VC>> 2:263
VC>> My primary node is 2:250/1 and 2:25/21 is used for the Elist
VC>> software. As region 25 is the UK including Northern Ireland but
VC>> Southern Ireland is an independent country it has its own net as
VC>> 2:263 and there are 2 nodes present .1 and .5. and I am the host
VC>> at 2:263/0 as that has to be defined in the nodelist.
VC>> I have had a look at the source code at mbfido / notify.c and I
VC>> cannot see where it obtains system AKA from but at a guess it is
VC>> the last one so how do I tell mbfido no to use the first entry
VC>> (2:250/1) ?
VC>> I did a mbfido no 2:250/1 but that did not produce anything,
VC>> then did a mbfido no 2:25/21 then unpacked the archive being sent
VC>> to that address as the system reported all AKA`s are locked -
VC>> reasonably as it was trying to send to itself. So moved over the
VC>> pkt and let mbse deal with it into my netmail inbox area for
VC>> 250/1 (I have 2 more one for 25/21 and one for 25/0 & 25/21 and
VC>> no I have no idea who two different akas are being used as :
VC>> NETMAIL is set Fido Aka 2:250/1 all traffic to/from me at 250/1.
VC>> NETMAIL2 is set Fido Aka 2:25/0 for Z2 netmail traffic. NETMAIL3
VC>> is set Fido Aka 2:25/21 for the Elist AKA 25/21.
VC>> The only conclusion I can draw is that the problem netmail sent
VC>> from MBFIDO NO uses the Last AKA but I cannot define what one is
VC>> used so the question is how do I fix it without breaking the
VC>> other two Netmail msg areas.
VC>> Hope I have made this clear but if you have a query regarding all
VC>> this, fire away.
VC>> Vincent
> MBSE defaults to using the closest AKA to the destination. For
> 2:263/1, that would be 2:263/0. There currently isn`t a way to
> override which AKA is used. I am considering adding support for this,
> but it`ll take a while to get that done and debugged.
> I do recommend that you setup a NetMail area for every AKA your system
> has. This insures that MBFIDO has a place to put incoming netmail for
> any of your system`s AKA addresses.
My problem is with the AKA being used that may get a reply by a node to the
posted notify message. The one instance I had this week is node was confused
what address to use for sending a areafix, filemgr request too as my system
normally expects all to go to 250//1 - at least as far as I know, but I could
be wrong :)
I would be a lot easier if I can specify what AKA is used for all such notify
messages as an override, may be as a added param to mbfido ne which would help
make any change easier to do for yourself, etc. Failing that, then the first
one on the list of AKA`s but that might not suit everyone as it would `assume`
that every one uses first AKA in the list as their primary one.
Vincent
--- Mageia Linux v9 X64/Mbse v1.1.0/GoldED+/LNX 1.1.5-b20240309
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)
SEEN-BY: 1/120 18/0 25/0 21 50/109 123/0 25 180
755 3001 3002 135/115
SEEN-BY: 153/7715 154/10 220/6 221/1 6 222/2
240/1120 1254 1634 4075 8001
SEEN-BY: 240/8002 8005 8050 250/0 1 2 3 4 5 7
8 11 13 14 15 263/0 275/1000
SEEN-BY: 275/1000 280/464 5003 291/111 301/1 113
313/41 335/364 341/66 371/0
SEEN-BY: 712/1321 1321 3634/0 12 12 27 57 58 60
119 5000/111 5020/715 846 848
SEEN-BY: 5020/1042 4441 12000 5030/49 1081 5058/104
5061/133 5075/128
SEEN-BY: 5083/444
@PATH: 250/1 3634/12 240/1120 301/1 5020/1042
4441