Has anyone run into something like this?

| 13:53 Trying to handshake | CONNECT 16800/ARQ/V34/LAPM/V4
| 13:53 Trying to handshake | ATZ
|
| 13:53 Trying to handshake | OK
|
| 13:53 Trying to handshake | CONNECT 16800/ARQ/V34/LAPM/V4
|


Passwords are correct.. 1:300/3 can dial here and deliver no problem. Password
protected sessions constantly fail on session-level though if I dial him.

Bob writes to me:

I see you're getting a connect, but no session. As I noted, in dumb
terminal

there's stuff from the modem - I did see 'Prism BBS' there. But the

log/activity > window of Binkley shows nothing. When I dial out,
Binkley's log/activity window shows all the steps of the connect
and traffic passing. But not incoming.

I can connect with you, and all that
shows up in the activity/log window, but nobody can connect with me - and when
they try nothing shows up in the activity/log window..

The flags in binkley.evt are B M R - BBS, Mail >>> Receive.

Thanks!
Janis

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)

Hello Janis,

On Fri 2012-Apr-13 13:59, Janis Kracht (1:261/38) wrote to All:

Has anyone run into something like this?

No, but what I'm getting on him is:
# 13 Apr 18:38:24 BINK Connect 19200

* 13 Apr 18:38:59 BINK Remote didn't respond

Double spaced between lines so that word wrap would leave
them alone. That's what i get when polling him, we've same
passwords in place as we did have.

INteresting.

I was thinking he had his modem in auto answer instead of
letting bink do it. Wondering what he may have changed
about his setup from before.

I'm recalling when he had to move all the Fido stuff to
anotehr machine we had to do some wrestling with that
internal modem to get it to let the software handle
answering.

iT's a puzzler. Hopefully we can find some help for him.

Regards,
Richard
---
* Origin: (1:116/901)

Hi Richard,

Has anyone run into something like this?

No, but what I'm getting on him is:
# 13 Apr 18:38:24 BINK Connect 19200

* 13 Apr 18:38:59 BINK Remote didn't respond

Double spaced between lines so that word wrap would leave
them alone. That's what i get when polling him, we've same
passwords in place as we did have.

Incoming from Bob works great:

120413 16:35 Incoming call
120413 16:44 Incoming call
120413 16:44 CONNECT 19200/ARQ/V34/LAPM/V42BIS
120413 16:44 EMSI mail session
120413 16:44 Bob's Boneyard, 1:300/3.0
120413 16:44 SysOp: Bob Ackley
120413 16:44 From: Somewhere
120413 16:44 Using: BinkleyTerm 2.60/(UNREGISTERED)
120413 16:44 Flags:
120413 16:44 Phone: -Unpublished-
120413 16:44 Speed:
120413 16:44 Password protected mail session
120413 16:44 Received: 0027ffdd.fr3 (Zmodem, 5kB, 1474cps)
120413 16:44 Mail session completed
120413 16:44 --------------------------

From me to him though is the problem, as you mention:

120413 14:03 Calling Bob's BoneYard, 1-712-624-8471
120413 14:04 CONNECT 19200/ARQ/V34/LAPM/V42BIS
120413 14:05 Session handshake failed!
120413 14:07 Calling Bob's BoneYard, 1-712-624-8471
120413 14:07 CONNECT 19200/ARQ/V34/LAPM/V42BIS
120413 14:08 Session handshake failed!
120413 14:10 Calling Bob's BoneYard, 1-712-624-8471
120413 14:10 CONNECT 16800/ARQ/V34/LAPM/V42BIS
120413 14:11 Warning: Bad poll count exceeded for 1:300/3.0

It's been years since I ran binkley.. maybe it's a corrupted file in something like fastlst or whatever nodelist compiler he's got running.. you know, where the passwords are entered for the node, that kind of thing.

INteresting.

I was thinking he had his modem in auto answer instead of
letting bink do it. Wondering what he may have changed
about his setup from before.

Nothing that he recalls..

I'm recalling when he had to move all the Fido stuff to
anotehr machine we had to do some wrestling with that
internal modem to get it to let the software handle
answering.

This is an external Zoom external 56kb . I sent him the docs for that modem today.. it was online.

iT's a puzzler. Hopefully we can find some help for him.

Yep..


Take care,
Janis

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)

Hello Janis,

On Fri 2012-Apr-13 21:44, Janis Kracht (1:261/38) wrote to Richard Webb:

Incoming from Bob works great:

<snip>

From me to him though is the problem, as you mention:

YEp, think we're both seeing the same thing, our software
just logs it differently.

<snip again>

I'm recalling when he had to move all the Fido stuff to
anotehr machine we had to do some wrestling with that
internal modem to get it to let the software handle
answering.

This is an external Zoom external 56kb . I sent him the docs for
that modem today.. it was online.

Cool! That'll probably help him because I think this is a
modem issue more than a binkley issue. ASk him if he's
changed any of his event flags though, because if he's put
an s in any event as a flag then he'll call out, but if the
modem was still in auto answer it would of course answer,
but I'm doubting he's changed them. But just for grins I'd
check that.

I'll bet you he'll find it in the init string he decides on
for that zoom.

Will be out of pocket most of today. Will try to connect
with him this evening.

iT's a puzzler. Hopefully we can find some help for him.

Yep..

Know you saw my note on that the other day. sInce I'm
non-cm I'd prefer to deliver, otherwise I'll probably steer
him to you or my friend Mark for a feed. I think this one
is soluble though, especially now with the modem docs in his hand.


Regards,
Richard
---
* Origin: (1:116/901)

MvanLe> I can reproduce one-sided-only handshake problems between
MvanLe> FrontDoor and Binkleyterm (where FrontDoor->BinkleyTerm is MvanLe> problematic but BinkleyTerm->FrontDoor is successful).

[trim]

MvanLe> This is between two Virtual Modems on the same computer.

what OS? and is this also in a Virtual Machine?

Windows XP. No, this is happening on a physical machine. The problem is workable by simply minimising all open windows. This problem was just an observation after many hours of frustration (and reluctance to give up on FrontDoor).

MvanLe> There is no problem when BinkleyTerm initiates a call to
MvanLe> FrontDoor. The handshake is fast and smooth to observe and MvanLe> completes successfully.

MvanLe> I have found that this problem is determined by which window MvanLe> is in the foreground while the handshake is in progress. CPU MvanLe> is 100% if FrontDoor is in the foreground while a handshake MvanLe> with BinkleyTerm is in progress, and I suspect that this
MvanLe> causes a delay with sending data during the handshake to
MvanLe> BinkleyTerm.

this is possible... it is one of the reasons why i ask
what OS and if this is in a VM... you haven't stated
what version of FD you're testing with... if you did
then i missed it... sorry...

Even on a VM the CPU would still be hit by real-mode DOS apps. I haven't found any good workaround for these problems. It's the nature of DOS apps.

[EDIT]
i went back and looked at your post again... i see that
the log snippet does show FD v2.02 being used... that
version is extremely ancient and i can easily see it
having the problem you describe... i don't even have
that one in my historical archives (/me frowns about
that) but i do have the DOS and OS/2 versions of FD
v2.26 and i've the patches to update FD v2.30 to v2.31
then to 2.32 and finally to 2.33... i'd try your tests
again with a newer version of FD ;)

FD 2.02 was released in 1991. That is why it is cool to use. It is also freeware (the only freeware version of FD). The most popular was FrontDoor 2.12.

I don't think the version of FD matters. The problem will still exist because I
can see the CPU at 100% when navigating the FD 2.12/2.26 menus in an open (non-full screen) window. The solution would be a 32-bit version of FD but I don't think there are any.

/me goes off to figure out why those missing files are
missing and to replace them...
[/EDIT]

Do you have your system in Escrow ? - Just in case you die of a heart attack or
aneurism or something, then somebody can takeover your BBS (and files).

MvanLe> FrontDoor is 16-bit DOS and probably not giving enough
MvanLe> timeslices. I am using BinkleyTerm 16-bit DOS but I suspect MvanLe> that even the 16-bit DOS version of BinkleyTerm handles
MvanLe> timeslices better than FrontDoor.

back in the day, programs did need to give up
timeslices but that shouldn't be all that necessary any
more... i see some problems when a program is in a
tight polling loop, though... but this also depends on
the program... my 16bit stuff still contains slicing
code but my newer stuff doesn't and doesn't seem to
need it...

The problem is that a lot of 16-bit DOS apps don't timeslice at all, causing the NTVDM to struggle badly. In the end the best way to beat laggy DOS apps is to buy an i7.


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

MvanLe> This is between two Virtual Modems on the same computer.

what OS? and is this also in a Virtual Machine?

MvanL> Windows XP. No, this is happening on a physical machine.

ahhh... ok... what virtual modem software?

MvanL> The problem is workable by simply minimising all open windows.
MvanL> This problem was just an observation after many hours of
MvanL> frustration (and reluctance to give up on FrontDoor).

i can understand that... i still run FD on my POTS and telnet/vmodem system ;)

[trim]

this is possible... it is one of the reasons why i ask
what OS and if this is in a VM... you haven't stated
what version of FD you're testing with... if you did
then i missed it... sorry...

MvanL> Even on a VM the CPU would still be hit by real-mode DOS apps. I
MvanL> haven't found any good workaround for these problems. It's the
MvanL> nature of DOS apps.

possibly... have you tried TAME to tame them down and force timeslices to be released more often? especially in tight loops...

[EDIT]
i went back and looked at your post again... i see that
the log snippet does show FD v2.02 being used... that
version is extremely ancient and i can easily see it
having the problem you describe... i don't even have
that one in my historical archives (/me frowns about
that) but i do have the DOS and OS/2 versions of FD
v2.26 and i've the patches to update FD v2.30 to v2.31
then to 2.32 and finally to 2.33... i'd try your tests
again with a newer version of FD ;)

MvanL> FD 2.02 was released in 1991. That is why it is cool to use. It is
MvanL> also freeware (the only freeware version of FD). The most popular
MvanL> was FrontDoor 2.12.

yes, i definitely remember :)

MvanL> I don't think the version of FD matters.

yes, it does matter... newer versions when thru some heavy rewrites... partially for timeslicing problems and partially for comms problems on multitasking systems... but new and more efficient code was also desired and so
the work was done...

MvanL> The problem will still exist because I can see the CPU at 100%
MvanL> when navigating the FD 2.12/2.26 menus in an open (non-full
MvanL> screen) window.

still not new enough... i don't know if that one took any rewrites in those areas or not... i wasn't invited to join the FD Beta Team until May '95... all the real good stuff came after that... especially one huge and major rewrite...

MvanL> The solution would be a 32-bit version of FD but I don't think
MvanL> there are any.

i'm not sure, TBH, but i definitely do not see the problems you are reporting on my OS/2 setup... not with the DOS flavor nor the native OS/2 flavor... besides, bitness doesn't really have anything to do with tight code loops eating 100% CPU... i have a native 32bit windows app that chews up several dozen txt files and merges them together keeping the most recent duplicate entries, flushing expired old entries and sorting everything as needed before emitting the final output file... it chews 100% CPU for the little bit of time it takes to run... it does in 15 seconds what the app it replaces takes 30 to 45 minutes to do... that old app has the 64k memory allocation limitation... the final output of my 32bit program is 36000+ lines whereas the final output of the old app is only 6000 lines... this all due to memory constraints but i diverged... sorry...

anyway, in my 32bit app, i've not done anything to handle timeslicing... i'm using everyday, well used, tested and vetted library routines... i haven't even
inquired of the compiler and library folks if i can give up slices like i do in
my 16bit DOS apps... most of those (16bit DOS apps) run bursty to about 10% CPU
usage but if i remove the timeslicing, they complete their task in seconds compared with a minute or two to when slicing to stay friendly with other apps... so back to the native 32bit code stuff... it gobbles the CPU but is done and complete in seconds... that with some several hundred MEG of RAM allocated during execution... where the CPU usage comes from in this particular
app i'm not sure but the point of this was that bitness doesn't have anything to do with timeslicing... but now i've gotta go make those inquiries and find out if i can reduce the CPU usage during my apps execution...

/me goes off to figure out why those missing files are
missing and to replace them...
[/EDIT]

MvanL> Do you have your system in Escrow ? - Just in case you die of a
MvanL> heart attack or aneurism or something, then somebody can takeover
MvanL> your BBS (and files).

hahaha... no... i'm sure that someone could figure it out, though... however, when i have to go in to make changes and i haven't done so in a while, even i have to study its flow and locate exactly where to make the changes... especially since things can run on either the DOS or OS/2 side, at any time, and either side can fire up a task to run on the other side at any time...

MvanLe> FrontDoor is 16-bit DOS and probably not giving enough
MvanLe> timeslices. I am using BinkleyTerm 16-bit DOS but I suspect MvanLe> that even the 16-bit DOS version of BinkleyTerm handles
MvanLe> timeslices better than FrontDoor.

back in the day, programs did need to give up timeslices but that shouldn't be all that necessary any more... i see some problems
when a program is in a tight polling loop, though... but this also depends on the program... my 16bit stuff still contains slicing
code but my newer stuff doesn't and doesn't seem to need it...

MvanL> The problem is that a lot of 16-bit DOS apps don't timeslice at
MvanL> all, causing the NTVDM to struggle badly. In the end the best
MvanL> way to beat laggy DOS apps is to buy an i7.

hahaha! yeah but they're still laggy... they just lag faster and are done lagging before the humans notice it ;)

but seriously, the system i speak of above is only a PIII 800mhz with only 384Meg of RAM... while it is faster than the PII 300mhz 112Meg RAM it just replaced, neither has been laggy or slow for the work they do and the new one still does the same work as before... new OS on the boot drive but everything else on the other drives is still the same as it ever was...

but i still think you might find some benefit from TAME... maybe... possibly...

)\/(ark


* Origin: (1:3634/12)

Hello Janis!

13 Apr 2012 13:59, Janis Kracht wrote to All:

Has anyone run into something like this?

| 13:53 Trying to handshake | CONNECT 16800/ARQ/V34/LAPM/V4

that was the days here :)

Passwords are correct.. 1:300/3 can dial here and deliver no problem. Password protected sessions constantly fail on session-level though if
I dial him.

try connect on 2400 baud ?

Bob writes to me:

I see you're getting a connect, but no session. As I noted, in dumb
terminal

there's stuff from the modem - I did see 'Prism BBS' there. But the

log/activity > window of Binkley shows nothing. When I dial out,
Binkley's log/activity window shows all the steps of the connect
and traffic passing. But not incoming.

I can connect with you, and all that
shows up in the activity/log window, but nobody can connect with me - and
when they try nothing shows up in the activity/log window..

The flags in binkley.evt are B M R - BBS, Mail >>> Receive.

is the modem setup with 7 wire ?, or just 3 ?

is hardware dte ok ?

i had lots of fun with dte on 930260 with my zyxel ta 128, and isdn :)

with the old amiga 2000 and cpu just as slow as 7.14 mhz :)


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/3.5.7-gentoo (i686))
* Origin: duggi.junc.org where qico is waiting (2:230/0)

Hi Benny!

is the modem setup with 7 wire ?, or just 3 ?

is hardware dte ok ?

i had lots of fun with dte on 930260 with my zyxel ta 128, and isdn :)

Well this fellow has disconnected from fidonet when his problems couldn't be solved.

with the old amiga 2000 and cpu just as slow as 7.14 mhz :)

Bob Atkins not my amiga downlink, I'm not sure what he was running, but it could have been DOS or one of the versions of Windows, I don't remember now..

Richard Webb probably could answer your questions better than I could since Richard talked with Bob a lot regarding his problems back then.

Take care,
Janis

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)

120413 14:03 Calling Bob's BoneYard, 1-712-624-8471
120413 14:04 CONNECT 19200/ARQ/V34/LAPM/V42BIS
120413 14:05 Session handshake failed!
120413 14:07 Calling Bob's BoneYard, 1-712-624-8471
120413 14:07 CONNECT 19200/ARQ/V34/LAPM/V42BIS
120413 14:08 Session handshake failed!
120413 14:10 Calling Bob's BoneYard, 1-712-624-8471
120413 14:10 CONNECT 16800/ARQ/V34/LAPM/V42BIS
120413 14:11 Warning: Bad poll count exceeded for 1:300/3.0

It's been years since I ran binkley.. maybe it's a
corrupted file in something like fastlst or whatever
nodelist compiler he's got running.. you know, where
the passwords are entered for the node, that kind of
thing.

That looks like a modem problem to me. It looks like there is noise during the EMSI/YooHoo handshake. The corruption is happening during the handshake. There's nothing wrong with the nodelist or session password.

Maybe you can fix the problem by just sending a normal "CONNECT 19200" without the extended modem status string (or get Bob's modem/system to understand extended strings).

I can reproduce one-sided-only handshake problems between FrontDoor and Binkleyterm (where FrontDoor->BinkleyTerm is problematic but BinkleyTerm->FrontDoor is successful).

FrontDoor initiating call: ======================================================================= ---------- Sat 01 Sep 12, FD 2.02
+ 22:53:19 Event 0-@
- 22:53:19 Preparing outbound mail
22:53:19 No messages to send in this event
+ 22:54:20 Calling ypan.dyndns.org, 3:712/104, 12700000000100024
= 22:54:24 CONNECT 38400
? 22:55:04 No response from remote system
22:55:04 Terminating call =======================================================================

BinkleyTerm receiving call: =======================================================================
+ 01 Sep 22:53:30 BINK begin, BinkleyTerm Version 2.60 -uSoft8.0
: 01 Sep 22:53:30 BINK Starting Event 9
# 01 Sep 22:54:22 BINK Ring
# 01 Sep 22:54:23 BINK Connect 38400
* 01 Sep 22:54:33 BINK Seconds: 13 Tariff: 0 Fee: 0 System: Unknown =======================================================================

This is between two Virtual Modems on the same computer.

There is no problem when BinkleyTerm initiates a call to FrontDoor. The handshake is fast and smooth to observe and completes successfully.

I have found that this problem is determined by which window is in the foreground while the handshake is in progress. CPU is 100% if FrontDoor is in the foreground while a handshake with BinkleyTerm is in progress, and I suspect

that this causes a delay with sending data during the handshake to BinkleyTerm.

FrontDoor is 16-bit DOS and probably not giving enough timeslices. I am using BinkleyTerm 16-bit DOS but I suspect that even the 16-bit DOS version of BinkleyTerm handles timeslices better than FrontDoor.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)
--- SBBSecho 2.27-Win32
* Origin: http://realitycheckbbs.org | tomorrow's retro tech (1:218/700)

MvanLe> I can reproduce one-sided-only handshake problems between
MvanLe> FrontDoor and Binkleyterm (where FrontDoor->BinkleyTerm is
MvanLe> problematic but BinkleyTerm->FrontDoor is successful).

[trim]

MvanLe> This is between two Virtual Modems on the same computer.

what OS? and is this also in a Virtual Machine?

MvanLe> There is no problem when BinkleyTerm initiates a call to
MvanLe> FrontDoor. The handshake is fast and smooth to observe and
MvanLe> completes successfully.

MvanLe> I have found that this problem is determined by which window
MvanLe> is in the foreground while the handshake is in progress. CPU
MvanLe> is 100% if FrontDoor is in the foreground while a handshake
MvanLe> with BinkleyTerm is in progress, and I suspect that this
MvanLe> causes a delay with sending data during the handshake to
MvanLe> BinkleyTerm.

this is possible... it is one of the reasons why i ask what OS and if this is in a VM... you haven't stated what version of FD you're testing with... if you did then i missed it... sorry...

[EDIT]
i went back and looked at your post again... i see that the log snippet does show FD v2.02 being used... that version is extremely ancient and i can easily see it having the problem you describe... i don't even have that one in my historical archives (/me frowns about that) but i do have the DOS and OS/2 versions of FD v2.26 and i've the patches to update FD v2.30 to v2.31 then to 2.32 and finally to 2.33... i'd try your tests again with a newer version of FD

;)

/me goes off to figure out why those missing files are missing and to replace them...
[/EDIT]

MvanLe> FrontDoor is 16-bit DOS and probably not giving enough
MvanLe> timeslices. I am using BinkleyTerm 16-bit DOS but I suspect
MvanLe> that even the 16-bit DOS version of BinkleyTerm handles
MvanLe> timeslices better than FrontDoor.

back in the day, programs did need to give up timeslices but that shouldn't be all that necessary any more... i see some problems when a program is in a tight

polling loop, though... but this also depends on the program... my 16bit stuff still contains slicing code but my newer stuff doesn't and doesn't seem to need

it...

)\/(ark


* Origin: (1:3634/12)
--- SBBSecho 2.27-Win32
* Origin: http://realitycheckbbs.org | tomorrow's retro tech (1:218/700)