• Problem with Binkley

    From Bob Ackley@1:300/3 to All on Monday, October 18, 2010 16:31:26
    BT2 version 2.6 running on OS/2 version 4.0 (no fixpacks). Machine is a
    Compaq Deskpro.

    Binkley's outgoing window shows two packets awaiting delivery to 618:150/0
    and 618:150/1 (the same place for those interested). Binkley connects to 618:150/1 just fine and receives traffic regularly - but it won't pass the outgoing packets up the line. It used to work just fine and nothing has been changed. Traffic for 1:116/901 also shows in the pending outbound window
    when it's there, and it is sent every time that system connects.

    Binkley also shows a message 'No traffic for 618:150/0' in the log at at every connect, even though there IS a packet ready and waiting to go there.

    Is the problem on my end or on the other end?

    --- FleetStreet 1.19+
    * Origin: Bob's Boneyard, Emerson, Iowa (1:300/3)
  • From Richard Webb@1:116/901 to Bob Ackley on Tuesday, October 19, 2010 00:02:01
    HI Bob,

    On Mon 2038-Oct-18 16:31, Bob Ackley (1:300/3) wrote to All:

    BT2 version 2.6 running on OS/2 version 4.0 (no fixpacks). Machine
    is a Compaq Deskpro.

    Binkley's outgoing window shows two packets awaiting delivery to
    618:150/0 and 618:150/1 (the same place for those interested).
    Binkley connects to 618:150/1 just fine and receives traffic
    regularly - but it won't pass the outgoing packets up the line. It
    used to work just fine and nothing has been changed. Traffic for
    Hmmm, a couple of thoughts.

    USe the PickupAll verb in your binkley.cfg if not already.

    And here's one to take a close look at, make sure you have
    same session pwd defined for both akas of the 618:*/* node.


    1:116/901 also shows in the pending outbound window when it's there,
    and it is sent every time that system connects.

    Binkley also shows a message 'No traffic for 618:150/0' in the log
    at at every connect, even though there IS a packet ready and
    waiting to go there.

    THose two suggestions are my main thoughts, especially if
    you're doing emsi sessions, make sure your nodelist compiler stuffs same session pwd in the nodelist for both systems.

    Regards,
    Richard
    --- timEd 1.10.y2k+
    * Origin: (1:116/901)
  • From Sean Dennis@1:18/200 to Bob Ackley on Monday, October 18, 2010 22:36:14
    Hi, Bob-

    Binkley's outgoing window shows two packets awaiting delivery to
    618:150/0 and 618:150/1 (the same place for those interested).
    Binkley connects to 618:150/1 just fine and receives traffic
    regularly - but it won't pass the outgoing packets up the line.
    It used to work just fine and nothing has been changed. Traffic
    for 1:116/901 also shows in the pending outbound window when it's
    there, and it is sent every time that system connects.

    I'd second what Richard said about using the "PickUpAll" verb. But
    since I'm 618:618/1 and the head of the aforementioned network, is
    there any particular reason you're using the /0 address? They are not
    used in that network, at all, and all of your mail should be going
    directly to 150/1.

    Later,
    Sean

    ... Life is what happens to you while you are making other plans.
    --- Ezycom V2.15g2 01FA026A
    * Origin: Nocturnal State BBS/423.9267999/nsbbs.darktech.org (1:18/200)
  • From Bob Ackley@1:300/3 to Sean Dennis on Wednesday, October 20, 2010 07:22:30
    Replying to a message of Sean Dennis to Bob Ackley:

    Hi, Bob-

    Binkley's outgoing window shows two packets awaiting delivery to
    618:150/0 and 618:150/1 (the same place for those interested).
    Binkley connects to 618:150/1 just fine and receives traffic
    regularly - but it won't pass the outgoing packets up the line.
    It used to work just fine and nothing has been changed. Traffic
    for 1:116/901 also shows in the pending outbound window when it's
    there, and it is sent every time that system connects.

    I'd second what Richard said about using the "PickUpAll" verb. But
    since I'm 618:618/1 and the head of the aforementioned network, is
    there any particular reason you're using the /0 address? They are
    not used in that network, at all, and all of your mail should be
    going directly to 150/1.

    I added the PickUpAll command/option in the config file. Didn't help.

    Note that my system dials 150/1 (150/0 is the same number) and connects
    just fine. But it still logs a message that there's no traffic for 150/0. Note
    that I'd copied the 00960001.FLO file to 00960000.FLO, so the two FLO files (150/0 and 150/1) both pointed to the same set of packets - and during a successful connect the packets don't get sent. Traffic from 150/1 to me is flowing just fine. I did netmail Andrew about the problem (thru Fidonet) but he hasn't responded yet.

    --- FleetStreet 1.19+
    * Origin: Bob's Boneyard, Emerson, Iowa (1:300/3)
  • From Sean Dennis@1:18/200 to Bob Ackley on Thursday, October 21, 2010 09:26:46
    Hi, Bob-

    Note that my system dials 150/1 (150/0 is the same number) and
    connects just fine. But it still logs a message that there's no
    traffic for 150/0. Note that I'd copied the 00960001.FLO file to 00960000.FLO, so the two FLO files (150/0 and 150/1) both pointed
    to the same set of packets - and during a successful connect the
    packets don't get sent. Traffic from 150/1 to me is flowing just
    fine. I did netmail Andrew about the problem (thru Fidonet) but
    he hasn't responded yet.

    That sounds like you have Squish misconfigured either in the area
    declaration block in SQUISH.CFG or ROUTE.CFG is messed up.

    The reason why mail to 150/0 doesn't get sent is because Andrew
    doesn't "fly" 150/0; I've instructed all of my hubs to NOT fly that
    flag because my system doesn't use it. There's no need in such a
    small network to use the regional addresses.

    You really should double-check your Squish configuration. I'm 99%
    sure that's where the problem lies and not with Binkley.

    Later,
    Sean

    ... Well done is better than well said. - Benjamin Franklin
    --- Ezycom V2.15g2 01FA026A
    * Origin: Nocturnal State BBS/423.9267999/nsbbs.darktech.org (1:18/200)
  • From Bob Ackley@1:300/3 to Sean Dennis on Sunday, October 24, 2010 17:42:50
    Replying to a message of Sean Dennis to Bob Ackley:

    Hi, Bob-

    Note that my system dials 150/1 (150/0 is the same number) and
    connects just fine. But it still logs a message that there's no
    traffic for 150/0. Note that I'd copied the 00960001.FLO file to
    00960000.FLO, so the two FLO files (150/0 and 150/1) both pointed to
    the same set of packets - and during a successful connect the
    packets don't get sent. Traffic from 150/1 to me is flowing just
    fine. I did netmail Andrew about the problem (thru Fidonet) but he
    hasn't responded yet.

    That sounds like you have Squish misconfigured either in the area declaration block in SQUISH.CFG or ROUTE.CFG is messed up.

    I don't use Squish excpet to clean up database problems. I haven't changed Watergate's configuration for years.

    The reason why mail to 150/0 doesn't get sent is because Andrew
    doesn't "fly" 150/0; I've instructed all of my hubs to NOT fly that
    flag because my system doesn't use it. There's no need in such a
    small network to use the regional addresses.

    I wonder why Binkley was saying 'Nothing to send to 618:150/0'. it sounds
    to me like the other end said 'send traffic for 618:150/0' and Binkley reported there wasn't any. Some traffic has been moving, the backlogged packets are gone.

    You really should double-check your Squish configuration. I'm 99%
    sure that's where the problem lies and not with Binkley.

    Watergate's ROUTE.CFG simply says to route all 618:* traffic to 618:150/1. Watergate's user configuration has 618:150/1 subscribed to all the MIN_* echoes; 150/0 isn't subscribed to anything.

    Everything was working just fine until about six week or so ago. I didn't change anything here (I have in the past week or so). I added the PickUpAll
    to Binkley, and added a password for 618:150/0 in the password file for FASTLIST, then forced a recompile of my nodelist. Andrew's system was reporting a password mismatch - according to the log he sent me it looked
    like no password was being received, although the password has been in that file (for 618:150/1) since I joined Micronet.

    --- FleetStreet 1.19+
    * Origin: Bob's Boneyard, Emerson, Iowa (1:300/3)
  • From Andrew Leary@1:320/119 to Bob Ackley on Sunday, October 24, 2010 23:14:15
    Hello Bob!

    Sunday October 24 2010 17:42, Bob Ackley wrote to Sean Dennis:

    I wonder why Binkley was saying 'Nothing to send to 618:150/0'. it
    sounds to me like the other end said 'send traffic for 618:150/0' and Binkley reported there wasn't any. Some traffic has been moving, the backlogged packets are gone.

    I believe that the adding the domain to your micronet address in BINKLEY.CFG is
    what fixed it. Binkley is more forgiving about such things than Xenia is, apparently. I still haven't figured out why Binkley wasn't able to drop DTR to
    hang up, when every other piece of software on the machine has been able to do so with no problem. That includes Xenia/2, FrontDoor/2, ZapOCom, etc. It's got to be some oddity with the serial ports built into the Intel L440GX motherboard in the server that's running the BBS currently. I did find an old ISA dual 16550AFN serial port card; sometime I'll try installing that and disabling the onboard serial ports.

    You really should double-check your Squish configuration. I'm
    99% sure that's where the problem lies and not with Binkley.

    Watergate's ROUTE.CFG simply says to route all 618:* traffic to
    618:150/1. Watergate's user configuration has 618:150/1 subscribed to
    all the MIN_* echoes; 150/0 isn't subscribed to anything.

    Everything was working just fine until about six week or so ago. I
    didn't change anything here (I have in the past week or so). I added
    the PickUpAll to Binkley, and added a password for 618:150/0 in the password file for FASTLIST, then forced a recompile of my nodelist. Andrew's system was reporting a password mismatch - according to the
    log he sent me it looked like no password was being received, although
    the password has been in that file (for 618:150/1) since I joined Micronet.

    Six weeks ago is when I switched from BinkleyTerm-XE to Xenia/2, due to the DTR
    drop issue noted above. I may go back to Binkley if I can resolve that issue by swapping to the add on serial card/disabling the onboard ports.

    I think that the password issue was caused when you copied the .FLO file for 150/1 to 150/0, since you didn't have 150/0 setup with the password. Your system would try dialing 150/0 and not send the password, and then try 150/1 with the password. I believe the domain issue is why Xenia & Binkley didn't agree that the mail should be sent.

    In any case, we've got it working now.

    Andrew

    ---
    * Origin: Bits & Bytes BBS * V.Everything! * 860/535-4284 (1:320/119)
  • From Sean Dennis@1:18/200 to Bob Ackley on Sunday, October 24, 2010 23:11:04
    Hi, Bob-

    reporting a password mismatch - according to the log he sent me it looked like no password was being received, although the
    password has been in that
    file (for 618:150/1) since I joined Micronet.

    <mod hat on>
    I think it's time we moved this to where it belongs over in Micronet. I seriously doubt it's a Binkley problem-I'm suspecting your tosser is messing up
    somewhere. Binkley is not smart enough to cause that kind of problem. :)
    <mod hat off>

    Later,
    Sean


    --- Maximus/2 3.01
    * Origin: Paragon BBS - paragon.darktech.org (1:18/200)
  • From Sean Dennis@1:18/200 to Andrew Leary on Monday, October 25, 2010 00:12:46
    Hello, Andrew.

    Sunday October 24 2010 at 23:14, you wrote to Bob Ackley:

    I believe that the adding the domain to your micronet address in BINKLEY.CFG is what fixed it. Binkley is more forgiving about such

    In the Binkley docs, it's recommended that you NOT use the domain setup unless you absolutely have to use it. The only reason I run my system in 5D mode is because at one time, I was running two networks with the same zone number. I've
    just never bothered to remove that setup...

    In any case, we've got it working now.

    Glad to hear that you've got it fixed.

    Later,
    Sean

    ... Next to the dog, the wastebasket is a man's best friend.
    --- GoldED/2 3.0.1
    * Origin: Nocturnal State BBS - (423) 926-7999 - nsbbs.darktech.org (1:18/200)