the BBS Xchange
the BBS Xchange

  • SBBSEcho Problems / Linux

    From Sampsa@VERT/B4BBS to All on Wed Jun 11 01:17:00 2014
    I'm using SBBSecho v2.27-Linux (rev 1.252) on Ubuntu 14.04 LTS and am getting a strange routing
    error.

    Basically, all mail to my direct uplink (2:250/7) work fine, but when I try to send a netmail to my
    hub (2:250/1), instead of routing it through /7 like I want it to, it instead creates a packet
    directly for /1 and put it's in my binkd outbound directory.

    My /sbbs/ctrl/sbbsecho.cfg file looks as follows:

    ---SNIP---
    NOTIFY 1
    SECURE_ECHOMAIL
    KILL_EMPTY
    FUZZY_ZONE
    FLO_MAILER
    SYSOP_ALIAS SYSOP
    LOG 0FFFFFFF
    LOG_LEVEL 6
    INBOUND /fido/inbound/
    SECURE_INBOUND /fido/inbsecure/
    OUTBOUND /fido/outbound/
    PKTPWD ALL PASS
    PACKER ZIP 0 504B
    PACK /usr/bin/zip %f %s
    UNPACK /usr/bin/unzip -j %f -d %s
    END
    USEPACKER NONE ALL
    USEPACKER NONE 2:250/7
    AREAFIX ALL PASS
    ROUTE_TO 2:250/7 ALL 2:250/1 1:ALL
    ROUTE_TO 2:250/7 2:ALL 3:ALL 4:ALL
    --- SNIP ---

    (Sorry about the extra ROUTE_TO statements, was trying basically ANYTHING to get this to work.)


    ... MultiMail, the new multi-platform, multi-format offline reader!
    --- MultiMail/Darwin v0.49
    ■ Synchronet ■ B4BBS = London, England - b4bbs.sampsa.com:2323 (telnet) or 2222 (ssh)
  • From Access Denied@VERT/PHARCYDE to Sampsa on Tue Jun 10 22:48:18 2014
    Hello Sampsa,

    On 11 Jun 14 01:17, Sampsa wrote to All:

    I'm using SBBSecho v2.27-Linux (rev 1.252) on Ubuntu 14.04 LTS and am getting a strange routing error.

    My /sbbs/ctrl/sbbsecho.cfg file looks as follows:

    ---SNIP---
    NOTIFY 1
    SECURE_ECHOMAIL
    KILL_EMPTY
    FUZZY_ZONE
    FLO_MAILER
    SYSOP_ALIAS SYSOP
    LOG 0FFFFFFF
    LOG_LEVEL 6
    INBOUND /fido/inbound/
    SECURE_INBOUND /fido/inbsecure/
    OUTBOUND /fido/outbound/
    PKTPWD ALL PASS
    PACKER ZIP 0 504B
    PACK /usr/bin/zip %f %s
    UNPACK /usr/bin/unzip -j %f -d %s
    END
    USEPACKER NONE ALL
    USEPACKER NONE 2:250/7
    AREAFIX ALL PASS
    ROUTE_TO 2:250/7 ALL 2:250/1 1:ALL
    ROUTE_TO 2:250/7 2:ALL 3:ALL 4:ALL
    --- SNIP ---

    (Sorry about the extra ROUTE_TO statements, was trying basically
    ANYTHING to get this to work.)

    If you're trying to setup a direct route to 2:250/7, try:

    ROUTE_TO 2:250/7 2:250/7

    That will route anything for that node number, to that node number.

    Then if you're trying to route everything else to your main hub:

    ROUTE_TO 2:250/1 1:ALL 2:ALL 3:ALL 4:ALL

    Basically, all mail to my direct uplink (2:250/7) work fine, but when
    I try to send a netmail to my hub (2:250/1), instead of routing it
    through /7 like I want it to, it instead creates a packet directly for
    /1 and put it's in my binkd outbound directory.

    Okay, if you want to route netmail through /7, why even have /1 in your configuration? You could simply do:

    ROUTE_TO 2:250/7 1:ALL 2:ALL 3:ALL 4:ALL

    And it will route everything through /7. Then /7 should be setup to route to /1
    separately. Or am I misunderstanding you here?

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: Dark Sorrow | darksorrow.us (723:1/701)
    ■ Synchronet ■ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
  • From Bill McGarrity@VERT/TEQUILAM to Access Denied on Wed Jun 11 11:10:00 2014
    Access Denied wrote to Sampsa <=-

    Hiya Nick...

    On 11 Jun 14 01:17, Sampsa wrote to All:

    I'm using SBBSecho v2.27-Linux (rev 1.252) on Ubuntu 14.04 LTS and am getting a strange routing error.

    My /sbbs/ctrl/sbbsecho.cfg file looks as follows:

    ---SNIP---
    NOTIFY 1
    SECURE_ECHOMAIL
    KILL_EMPTY
    FUZZY_ZONE
    FLO_MAILER
    SYSOP_ALIAS SYSOP
    LOG 0FFFFFFF
    LOG_LEVEL 6
    INBOUND /fido/inbound/
    SECURE_INBOUND /fido/inbsecure/
    OUTBOUND /fido/outbound/
    PKTPWD ALL PASS
    PACKER ZIP 0 504B
    PACK /usr/bin/zip %f %s
    UNPACK /usr/bin/unzip -j %f -d %s
    END
    USEPACKER NONE ALL
    USEPACKER NONE 2:250/7
    AREAFIX ALL PASS
    ROUTE_TO 2:250/7 ALL 2:250/1 1:ALL
    ROUTE_TO 2:250/7 2:ALL 3:ALL 4:ALL
    --- SNIP ---

    (Sorry about the extra ROUTE_TO statements, was trying basically
    ANYTHING to get this to work.)

    If you're trying to setup a direct route to 2:250/7, try:

    ROUTE_TO 2:250/7 2:250/7

    That will route anything for that node number, to that node number.

    Then if you're trying to route everything else to your main hub:

    ROUTE_TO 2:250/1 1:ALL 2:ALL 3:ALL 4:ALL

    Basically, all mail to my direct uplink (2:250/7) work fine, but when
    I try to send a netmail to my hub (2:250/1), instead of routing it
    through /7 like I want it to, it instead creates a packet directly for
    /1 and put it's in my binkd outbound directory.

    Okay, if you want to route netmail through /7, why even have /1 in your configuration? You could simply do:

    ROUTE_TO 2:250/7 1:ALL 2:ALL 3:ALL 4:ALL

    And it will route everything through /7. Then /7 should be setup to
    route to /1 separately. Or am I misunderstanding you here?

    I really don't think this has anything to do with sbbsecho as it seems more of a mailer issue with routing. Wonder what mailer is he using?


    Bill

    Telnet: bbs.tequilamockingbirdonline.net
    Web: bbs.tequilamockingbirdonline.net
    IRC: irc.tequilamockingbirdonline.net Ports: 6661-6670 SSL: +6697
    Radio: radio.tequilamockingbirdonline.net:8010/live


    ... Motorcycles are everywhere... Look Twice, Save a Life!
    --- MultiMail/Win32 v0.50
    ■ Synchronet ■ TequilaMockingbird Online - TELNET: tequilamockingbirdonline.net
  • From Access Denied@VERT/PHARCYDE to Bill McGarrity on Wed Jun 11 18:43:18 2014
    Hello Bill,

    On 11 Jun 14 11:10, Bill McGarrity wrote to Access Denied:

    I really don't think this has anything to do with sbbsecho as it seems more of a mailer issue with routing. Wonder what mailer is he using?

    Mailers don't know anything about routing. That is done by the tosser. From his
    original post, the ROUTE_TO statements were a mess. I only gave a couple different options he could use instead of what he had. Plus, if you noticed in his original post, he was using ALL instead of #:ALL as well (where # is a zone
    number). So that could have been causing problems too.

    Regards,
    Nick

    --- GoldED+/LNX 1.1.5-b20130910
    * Origin: Dark Sorrow | darksorrow.us (723:1/701)
    ■ Synchronet ■ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)