Menu

#41 Routing table processing bug for non existing addres

1.0.8.x
open
nobody
None
2022-08-07
2022-05-02
No

There is a bug in the Routing behaviour, if a mail comes in or for that matter, is sent to an address that does NOT exist in the current node list, it does not get BOUNCED and in the case of a received net mail bounced back to sender.

This is documented in the manual in section, about the Net mail routing behaviour under Tracking and bouncing that states that it is not coded for but will be, sic!

This problem came about when a node sent in a ping request incorrectly addressed to 2:250/21 instead of 2:250/1 and this is assuming that mbse responds correctly to such ping requests.

Yes, it should have been rejected by the sender's system, but we all know that is NOT a given.

In my system other than my aka 2:250/1 I did also have my host addresses present such as 2:25/0, 2:250/0 and 2:263/0 which I have now removed although, I am not sure, that was the right thing to do.

The result of this bug is a never ending loop back between this system, the routing system at 2:0/0 and the sender and oh boy was it a loop - went on until spotted by me many hours later.

Discussion

  • Vincent (Bryan) Coen

    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -8,4 +8,4 @@
    
     In my system other than my aka 2:250/1 I did also have my host addresses present such as 2:25/0, 2:250/0 and 2:263/0 which I have now removed although, I am not sure, that was the right thing to do. 
    
    -The result of this bug is a never ending loop back between this system, the routing system at 2:0 and the sender and oh boy was it a loop.
    +The result of this bug is a never ending loop back between this system, the routing system at 2:0/0 and the sender and oh boy was it a loop - went on until spotted by me many hours later.
    
     
  • Sean Dennis

    Sean Dennis - 2022-05-02

    I saw the nastygram in ELIST. I'm wondering if this is related to an issue I had with my system screwing up AKAs in echoes. In Micronet (my othernet), I usually fly 618:618/0, /1 (main netqork mail hub), and /10 which is my nominal BBS AKA for all echoes except for admin echoes. Even though I set the echoes to use /10 and mail to go out using /1, the mail was coming from /10. So I had to eliminate the other AKAs and use /1 only. The problem resolved itself then.

     
    • Vincent (Bryan) Coen

      For netmails, I have a different NETMAIL echo for each AKA I will use, e.g., primary is for 2:250/1 Another is for 2:25/1 and lastly one for 2:25/21 when the same system used the later, but now all work for it, is now on a different system.

      This is used with Golded, and it seems to work.

      Switching the AKA to use with Golded does not work as it will always take the default for that Echo area regardless of the one I select, and the only other way is to have a golded.cfg for each one that is set up in a script before calling Golded. Very messy.

       
  • Vincent (Bryan) Coen

    Could well be - I have now had myself back with the additional AKA's but hopefully can remove them again. Noticing that some polls are not getting through, such as password issues.

    Yes, clutching at straws.

    That said I would have thought that mbse can handle using a point address, .but there again as the routing system is slightly broken, anything can be happening BUT check your settings in routing if any also check the setting you have for routing for down/up links and test them using
    mbfido test, assuming you can make sense of the o/p.

     

Log in to post a comment.