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)

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)

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)

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)

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)

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)

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)

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)

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)