strange races in screen -D -m `tty`?

[Tomas Juknevicius]

Hello dear screen gurus ;-),

I'm fairly new to using the screen, but already starting to like it.
Recently I've been trying to solve one problem,
and encountered strange situation while using screen.

Here is my task: I have 2 machines; lets call them local & remote.
local is in the LAN which is NATed, remote is in the other LAN, which is

heavily firewalled. I want the user at remote have the bash at local.
The problem is remote can not ssh to local.
But local can ssh to remote.
(actualy this will be 2 step ssh:  local-->intermediate-->remote).

So, I want to do something like ssh but in reverse:
the person @ local ssh'es to remote and then person @ remote gets the
bash running on local.

I am doing this:

------------the case-------------
in a console at local type this:

1)  local> screen ssh remote
2) remote> exec screen -D -m `tty`

#at this step we get 2 ttys joined peer-to-peer

3) <ctrl>a :
4)in the screen prompt> exec ::: /bin/bash

#done, now the person at remote console can at any time do:
5)remote2> screen -ls
#we see our screen session, created in step 2),  in a list. Detatched,
as it should be
6) remote2> screen -r <screen session id>

#hurrah, now we have bash running @ local accessible to person @remote
#everything works - pwd, ls etc......
#a few small quirks - no echo & no color, but these do not matter at
# this time, i'll get to them later

----------end of the case-------------

Now my problem: the steps, outlined above work only SOMETIMES.
The other times I get only half of the connection - the characters
written at remote shell are sent to the local, but the characters
from the local are not sent to the remote.

This can be tested this way: if you omit the steps 3) 4) you should get
2 consoles connected peer-to-peer. Whatever is typed into one, gets
written into the other. But as I've said, this works only sometimes,
at other times I get only one way street remote-->local.

I have the suspicion, that there is some race condition at step #2,
which is
causing the problems. At this step screen is basically detaching from
the tty, and at the same time reattaching the same tty as the screen's
target.

I've also experimented with this command instead of the step 2):
#note the -d instead of -D
2a)remote>exec screen -d -m `tty`
But this results in the directly oposite case - now only characters
written  at local console get sent to remote, but not vice versa
(local-->remote). No dice.
But this behavior is at least repeatable - it works this way all the
time.

I've also experimented with these commands instead of the step 2):
2b)remote>exec screen -m `tty`
#note that now we need to hit 'a' second time, because we have the
screen-in-screen
2c)<ctrl>a a d
In this case I get simmilar results to my original case  (-D -m)


Any comments/suggestions? Whats going on here?
Is this a bug? Perhaps I use screen incorrectly?
How to workaround this?


for reference:
the machines are Debian,
uname -a
Linux kiras 2.6.9 #2 Mon Mar 21 17:17:31 EET 2005 i686 GNU/Linux
screen --version
Screen version 4.00.02 (FAU) 5-Dec-03


Sincerely
--
Tomas Juknevicius