- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Remote control of DOS-Box
- Thread starter wiwa64
- Start date
Hey guys,
so I made a few tests under FreeDOS. In default the application works ok, but has issues on using telnet or any other port/socket when used (I have a Realtek 8139 TCP packet driver running and DHCP). It works in general but despite good terminal configuration ir glitches a lot. It also cuts off different commands, seems to be limited to a certain size of the commands. Like opening telnet to a BBS wasn't possible, it cut off the end of the name. (example was: telnet fatcatsbbs.com... it got until telnet fatcats).
The application also lacks of any authorization method, but I think that can be resolved somehow... (configuring rmenu options or applying firewall rules on a router)
Right now I just made a quick test, I will detail more when configured more...
Regards:
norbert79
so I made a few tests under FreeDOS. In default the application works ok, but has issues on using telnet or any other port/socket when used (I have a Realtek 8139 TCP packet driver running and DHCP). It works in general but despite good terminal configuration ir glitches a lot. It also cuts off different commands, seems to be limited to a certain size of the commands. Like opening telnet to a BBS wasn't possible, it cut off the end of the name. (example was: telnet fatcatsbbs.com... it got until telnet fatcats).
The application also lacks of any authorization method, but I think that can be resolved somehow... (configuring rmenu options or applying firewall rules on a router)
Right now I just made a quick test, I will detail more when configured more...
Regards:
norbert79
No, you misunderstood me: I just tried using the same port, which RMenu was running it. No go. Like if you have RMenu running, you can't access anything, which runs on port 23. That was the goal: accessing a server through RMenu on telnet protocol. Scenario: Linux based device, connecting to RMenu hosting, accessing it through telnet. RMenu is accessed, called true command line. Executing "telnet fatcatsbbs.com", not only it won't work since the command ends at "telnet fatcats" but when going to the real device and extending the command to "telnet fatcatsbbs.com" it still won't allow the telnet to connect to the desired host through telnet. It says: Socket busy.
I hope this explains it a bit better...
I hope this explains it a bit better...
It's even worse than that. From within RMENU you cannot run any program, that uses the IP protocol itself. This is due to the combination of the WATTCP library linked to the program with the packet driver which allows only one program to register for a given protocol at a time.
The probably easiest way to do the kind of "telnet hopping" you apparently want to do would be to install a second network card and a second packet driver.
Yes, I was merely testing if I can use my home Debian box to access the DOS hardware; as RMenu doesn't support any authorization, it would be dangerous allowing full access to telnet through the router. And since DOS is ANSI compatible, or just for the heck of it, yes, I wanted to test, if I could even do Telnet or SSH further. I am just playing with possibilities, testing functions, services to find out what the DOS device would be capable of.
I see... Well, it's a bit pity, but maybe I have another Realtek card somewhere... A second Ethernet card wouldn't be that much of a problem. Pity, I thought I could solve it, like with a Linux device. Nevertheless: What is causing the issue with cutting of an end of a command? I am thinking about like the issue with the "telnet fatcat" problem... This is a problem, since despite DOS commands might be shorter, I could still bump into one, which would be a bit longer...
Well, DOS is not UNIX! While programs like RMENU (and others) try their best to "look like" a real TELNET server, their possibilities to mimic such systems are limited.
I still dont fully understand the problem you had as i don't exactly know what you were trying. Assuming you just wanted to play around with the (unmodified) demonstration configuration that comes with the package and assuming that you chose item "6" of the menu which this configuration displays, then your problem could simply have been, that you were a bit to unpatient. The operating mode behind that menu item is indeed somewhat slow so you should avoid typing ahead of the character echo. Try to obey that rule and see what happens.
I am fully aware of all these, I am working with PC's since 1995 and started with MS-DOS 3 (first computer was a Commodore +4), so I have been around for a while around DOS as well. And, no, I wasn't inpatient, I am fully aware of echo, latency and all related topics.
RMenu basically cuts off the end of a command, if the command hits a certain character limit. No idea how this might be related, but it seems to be in connection in which directory are you in. I will try to record an attempt later today.
And yes, I know it's only a mimic in telnet, since only the port is the same, but not following strictly the telnet protocol. Yes, I have read through the documentation too, read all the points. That's why I started asking...
Regards:
norbert79
Evening!
Ok, I did some testing again, here is a short demo of what happens:
RMenu is up, running well. Selected default menu, used option 6, real DOS console.
This is what happens:
So far everything OK. Let's select number 6:
So let's try to dial an SSH server using SSH2DOS.
And there we go. The end of the command just cut off. This is the bug I was talking about. It's probably related to the @ sign...
Regards:
norbert79
Ok, I did some testing again, here is a short demo of what happens:
RMenu is up, running well. Selected default menu, used option 6, real DOS console.
This is what happens:
Code:
norbi@XXXXXX:~$ telnet Hal-9000
Trying XXX.XXX.XXX.XXX...
Connected to Hal-9000.XXXXXX.
Escape character is '^]'.
C:\>rmenu
RMENU V1.7 listening as XXX.XXX.XXX.XXX on port 23
Please enter selection, use '?' to show menu>So far everything OK. Let's select number 6:
Code:
C:\>rmenu
RMENU V1.7 listening as XXX.XXX.XXX.XXX on port 23
FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]
C:\>
C:\>clsSo let's try to dial an SSH server using SSH2DOS.
Code:
C:\>ssh2dos norbert79@sshhosting.net [I]{At this point I press the [B]Enter[/B] button}[/I]
[I]{screen clears}[/I]
C:\>ssh2dos norbertAnd there we go. The end of the command just cut off. This is the bug I was talking about. It's probably related to the @ sign...
Regards:
norbert79
That looks indeed strange. 
When i try the same, i get this:
Of course my system complains about the unknown command "ssh2dos" because i haven't installed that program on this computer, but there is nothing cut-off. And the only apparent difference i can see so far is that i used MS-DOS while you tryed to run it under FreeDos. But i don't think that this should make a fifference :confused4:
When i try the same, i get this:Of course my system complains about the unknown command "ssh2dos" because i haven't installed that program on this computer, but there is nothing cut-off. And the only apparent difference i can see so far is that i used MS-DOS while you tryed to run it under FreeDos. But i don't think that this should make a fifference :confused4:
After thinking a bit longer about the strange behaviour i have a guess about the cause.
RMENU uses the WATTCP library as TCP/IP stack. This library in-turn uses a/the packet driver for the actual data transfer. As far as i know there is no way to tell WATTCP which driver to use in case there is more than one. It simply grabs the first one it can find, starting at interrupt number 0X60 and continuing the search up to interrupt 0X7F. If SSH2DOS uses the same library, which is very likely, then you are again in bad luck, as this program will try to do the very same.
You might possibly get away with the following trick: Load the first packet driver, explicitly assigning it an interrupt vector higher than 0X60 (e.g. 0X61). Then start RMENU. Then, from within RMENU, start the second packet driver. Many packet drivers will assume interrupt 0X60 by default, if yours doesn't explicitly assign that number (or any other one that is equal or above 0X60 but below the one you assigned to the first driver) If you then start another program (like e.g. SSH2DOS) also using the WATTCP libraray, that second instance should find the second dirver as it has the lower interrupt. Perhaps this works.
An alternative could be to use Mike Brutmans TELNET client in place of SSH2DOS. WATTCP and mTCP should happily coexist and mTCP can (and has to) be assigned a packet driver interrupt explicitly.
As i have no personal experience with ssh2dos i have some more questions first:
- Is that "{screen clears}' part of the normal behaviour of ssh2dos?"
- Is that uncomplete "ssh2dos norbert" part of the normal prompt of that program?
- would you see that too if you ran it directly, not via RMENU?
RMENU uses the WATTCP library as TCP/IP stack. This library in-turn uses a/the packet driver for the actual data transfer. As far as i know there is no way to tell WATTCP which driver to use in case there is more than one. It simply grabs the first one it can find, starting at interrupt number 0X60 and continuing the search up to interrupt 0X7F. If SSH2DOS uses the same library, which is very likely, then you are again in bad luck, as this program will try to do the very same.
You might possibly get away with the following trick: Load the first packet driver, explicitly assigning it an interrupt vector higher than 0X60 (e.g. 0X61). Then start RMENU. Then, from within RMENU, start the second packet driver. Many packet drivers will assume interrupt 0X60 by default, if yours doesn't explicitly assign that number (or any other one that is equal or above 0X60 but below the one you assigned to the first driver) If you then start another program (like e.g. SSH2DOS) also using the WATTCP libraray, that second instance should find the second dirver as it has the lower interrupt. Perhaps this works.
An alternative could be to use Mike Brutmans TELNET client in place of SSH2DOS. WATTCP and mTCP should happily coexist and mTCP can (and has to) be assigned a packet driver interrupt explicitly.
Jürgen,
First, Rmenu is a great piece of software. I like the trick of running as a normal C program and shelling; it takes a little more memory but it gets rid of a lot of the problems associated with TSRs. I have thought about doing network drive letter access using that trick also to avoid TSR programming. (Or at least as a first step toward a TSR version.)
How does RMENU "stuff" keystrokes into the keyboard buffer? The mTCP Telnet client uses the BIOS functions to poll and read the keyboard. For the programs that are known not to work with RMENU, how are they reading the keyboard? (Are they hooking the hardware interrupt directly, thus bypassing the BIOS ? That would be extreme, but I've seen it done.)
Mike
First, Rmenu is a great piece of software. I like the trick of running as a normal C program and shelling; it takes a little more memory but it gets rid of a lot of the problems associated with TSRs. I have thought about doing network drive letter access using that trick also to avoid TSR programming. (Or at least as a first step toward a TSR version.)
How does RMENU "stuff" keystrokes into the keyboard buffer? The mTCP Telnet client uses the BIOS functions to poll and read the keyboard. For the programs that are known not to work with RMENU, how are they reading the keyboard? (Are they hooking the hardware interrupt directly, thus bypassing the BIOS ? That would be extreme, but I've seen it done.)
Mike
There is a BIOS function for that. It's interrupt 16h (Keyboard service) subfunction 05 (Push character and scan code to Bufer). It may however not be present in very old BIOSes.
Alternatively you could try to manipulate the keyboard ring-buffer directly. That buffer is located from offset 1E to offset 3D of the BIOS data area which in-turn is located in segment 0040h. The put and get pointers are found at offsets 1A anf 1C. But this method is rather tricky and should be well tested if used.
I haven't explored how those programs that do not run with RMENU access the keyboard (the most prominent one being MS EDIT) but i assume they implement their own keyboard handler and access the (hardware-)interrupt or the keyboard controler directly.
Alternatively you could try to manipulate the keyboard ring-buffer directly. That buffer is located from offset 1E to offset 3D of the BIOS data area which in-turn is located in segment 0040h. The put and get pointers are found at offsets 1A anf 1C. But this method is rather tricky and should be well tested if used.
I haven't explored how those programs that do not run with RMENU access the keyboard (the most prominent one being MS EDIT) but i assume they implement their own keyboard handler and access the (hardware-)interrupt or the keyboard controler directly.
Mike Chambers
Veteran Member
- Joined
- Sep 2, 2006
- Messages
- 2,621
there are a fair number of programs that will not work by just hooking int 16h or shoving the new keypress directly into the ring buffer. when i wrote remoter, i had the same issues with MS-EDIT, QBASIC, Turbo C++, etc. not responding to keypresses.
what i did was copy the int 9h keyboard interrupt handler code from the generic XT BIOS at phatcode.net directly into my program, and it is run whenever the client send a keypress/unpress packet. i do this instead of insert a value directly into the ring buffer because the value the client sends is identical to real scancodes from the physical keyboard, so i needed all the conversion tables from a real BIOS.
i changed the beginning of the code so that it reads the keyboard scancode from the UDP packet the client sent rather than the keyboard controller. then i issue an actual "INT 9" instruction so that programs like those that detect when there's a new keypress by having int 9 hooked know that it's time to check.
when my TSR starts though, i set the the interrupt vector for int 9 to my own function here:
old_int9_ptr and old_int9_seg are set to the original BIOS handler's location. i set int9_flag to 1 right before i issue the int 9h for keypresses and then set it back to 0 when it's done so that the original BIOS doesn't run if it's not a real local physical keypress. that would put garbage in the ring buffer.
this method works 100% of the time (well, as long as the server TSR is started before anything else has a chance to hook int 9h. i.e., don't start it inside a Turbo C++ DOS shell or something like that)
i haven't run into one program that doesn't work as if the remote client is using the physical keyboard. i suppose if some program's key routines tried to directly read scancodes from port 60h (the keyboard controller) it wouldn't work, but i haven't found one yet. i would be surprised to see that method used by anything other than some games. i was able to play at least ultima 6 and ms. pacman remotely though.
what i did was copy the int 9h keyboard interrupt handler code from the generic XT BIOS at phatcode.net directly into my program, and it is run whenever the client send a keypress/unpress packet. i do this instead of insert a value directly into the ring buffer because the value the client sends is identical to real scancodes from the physical keyboard, so i needed all the conversion tables from a real BIOS.
i changed the beginning of the code so that it reads the keyboard scancode from the UDP packet the client sent rather than the keyboard controller. then i issue an actual "INT 9" instruction so that programs like those that detect when there's a new keypress by having int 9 hooked know that it's time to check.
when my TSR starts though, i set the the interrupt vector for int 9 to my own function here:
Code:
fake_int9:
cmp cs:[int9_flag], 1
je skip_int9
db 0EAh ;far jump to seg:off
old_int9_ptr dw 0
old_int9_seg dw 0
skip_int9:
iretold_int9_ptr and old_int9_seg are set to the original BIOS handler's location. i set int9_flag to 1 right before i issue the int 9h for keypresses and then set it back to 0 when it's done so that the original BIOS doesn't run if it's not a real local physical keypress. that would put garbage in the ring buffer.
this method works 100% of the time (well, as long as the server TSR is started before anything else has a chance to hook int 9h. i.e., don't start it inside a Turbo C++ DOS shell or something like that)
i haven't run into one program that doesn't work as if the remote client is using the physical keyboard. i suppose if some program's key routines tried to directly read scancodes from port 60h (the keyboard controller) it wouldn't work, but i haven't found one yet. i would be surprised to see that method used by anything other than some games. i was able to play at least ultima 6 and ms. pacman remotely though.
Last edited:
Hello everyone!
Sorry for the late reply.
- No, I have only experienced that with RMenu only.
- No, that happens only through RMenu only as well.
I can add my environment settings though, if you wish, there are some portions, which might cause the problem, you might spot some.
At this point I haven't used any second Ethernet card, because that would need additional cabling, for which I don't have the possibility yet. So the configuration was still the same: Bare 486 (5x86 - 133 Mhz CPU, 40 MB RAM, Realtek 8139 Ethernet card running Realtek packet driver, 1 Ethernet cable, DHCP through FreeDOS, working perfectly, no WATTCP afaik).
Well, that would be an issue, since I want to use real SSH, so that's why I use SSH2DOS. For SSH2DOS please go to this page: http://sourceforge.net/projects/sshdos/
Regards:
norbert79
Sorry for the late reply.
- No, I have only experienced that with RMenu only.
- No, that happens only through RMenu only as well.
I can add my environment settings though, if you wish, there are some portions, which might cause the problem, you might spot some.
At this point I haven't used any second Ethernet card, because that would need additional cabling, for which I don't have the possibility yet. So the configuration was still the same: Bare 486 (5x86 - 133 Mhz CPU, 40 MB RAM, Realtek 8139 Ethernet card running Realtek packet driver, 1 Ethernet cable, DHCP through FreeDOS, working perfectly, no WATTCP afaik).
Well, that would be an issue, since I want to use real SSH, so that's why I use SSH2DOS. For SSH2DOS please go to this page: http://sourceforge.net/projects/sshdos/
Regards:
norbert79
In that case it is even more likely that it's the SSH2DOS taking over the line and kicking RMENU out of the boat. And of course you have WATTCP! It's directly linked into RMENU and probably into SSH2DOS as well. And even if not, they both try to use the same packet driver at the same time, but packet drivers aren't multitasking, like DOS as a whole.