Hello all,

I haven't managed to come up with a clean solution for this scenario for a customer.

The customer wants to host his MS DOS Point of Sale System on a Server and have his store client computers (some Windows, some MS DOS) dial up to that server computer, and run the POS Software via dial up.

The first solution I came up with works but its quite crazy. 8 DOS VMWare Virtual Machines sitting in listen mode in PCAnywhere, once client connects (DOS or Windows) it puts at C: prompt, they type app.bat which runs a bat file that maps to the samba share on this Linux Server PC and runs the POS.EXE file.

This works fine - but it could be a nightmare to troubleshoot - also if the distro Kernel changes, VMWare will get unhappy. So I was trying to find a cleaner solve. I'm using Slackware 12.0.

Any ideas how I could clean this solution up a bit - Ideally I'd just like this BOX to accept dial up (from dos or windows clients) and the samba share gets mounted as a drive letter on the connecting DOS or Windows client and they run from there.

Thanks in advance,
Steve

You are most likely going to have to install some software on the DOS/Windows clients to allow them to map the network drives and run a network logon script.

Here is a list of some possible network client packages for DOS.

Networking software for DOS and Windows 3.x

Thx - muchly for your responce. I think I've got that part covered - honestly my challenge is the dial in server - I saw some old stuff on mgetty but I'm not sure if that's the way to do it if you have an 8 port modem PCI card... I got the card operating fine - drivers etc... It's the dial in server and then once the modem connection is made, how the server shares the network to the dial up users... That's where i'm a bit grey.

Basically you create a PPP (Point-to-Point Protocol) dial in server that can service the 8 ports. Use DHCP (Dynamic Host Configuration Protocol) to assign each dial in client an IP address.

When a client wants to access a shared folder, it either has a drive permanently mapped to the share, or a login script that maps the drive. The SMB (Server Message Block) protocol is used through TCP/IP port 445 or 139.

In order for a client to access a share on a server, the client has to know the server's IP address. One way to do that is use the IP address in place of the server name. Another way is through some kind of name resultion protocol.

You can provide a DNS (Domain Name System) server to allow the clients to find your server's IP address from the name (or define the name and IP address in the "hosts" file on the clients)

You may be able to get NetBIOS name service working if you can provide that service in SAMBA. NetBIOS name service uses broadcasts on UDP port 137. When a server sees a broadcast request with its name, the server responds to the client. In order for that to work, the client has to be configured to route NetBIOS UDP broadcasts to the modem (PPP). NetBIOS name service, DNS or the hosts file are all ways for a client to get a server's IP address from the server name. I'm not sure which of those will work with a DOS client.

Here are the various ports involved in SMB and NetBIOS.

UDP 137 - NetBIOS name resolution (broadcast and reply)
UDP 138 - NetBIOS datagram service (broadcast or direct)
TCP 139 - NetBIOS session (connection)
TCP 445 - SMB session

NOTE: SMB can use port 139 (NetBIOS session) if 445 is not available.

Port 138 is used mostly by the computer browser that maintains a list of the server computers on the network. The computer browser normally doesn't work through a dial up connection.

Here is how the dial in process works.

The modem answers the phone and the client logs in to the serial terminal port. The PPP protocol attaches to the serial terminal port. The client uses DHCP to request an IP address. The DHCP server responds with the IP address, default gateway and DNS server addresses.

When the client attempts to access a share on the server, first it tries to resolve the server name to an IP address. That's done by the "hosts" file on the client, DNS on the server, or NetBIOS name service provided by the server.

Once the client has the server's IP address then the client establishes an SMB session using port 445 or through NetBIOS using port 139. SMB protocol is used to access the shared files.

Since the PPP connection carries IP protocol, any of the normal UDP or TCP service ports can be accessed on the server. The client can use telnet or other services.

Thx Erik_FL,

You've made a few things more clear to me. I appreciate you taking the time to share your knowledge.
All of that info on ports is going to be helpful when I lock it down as I'll want to be able to SSH in if there is a problem to fix it.

I should be able to implement that - I'll let you know how it goes.

Thx again,
Steve

It appears the scope of the project has changed - the clients are winXP... Anyhow. I went the route of using mgetty to answer the call and then like you said make certain services available.

However I am battling to get Mgetty/PPP working... It seems that mgetty is running fine on all ports ttyG0_00 to ttyG0_07... modem responds to inits etc. I setup as per a doc on howtoforge for dial in server.
If I:
tail -f /var/log/mgetty.ttyG0_00

I get:
02/27 10:37:26 _00 wfr: waiting for ``RING''
02/27 10:37:26 _00 send: ATA[0d]
02/27 10:37:26 _00 waiting for ``CONNECT'' ** found **
02/27 10:37:43 _00 send:
02/27 10:37:43 _00 waiting for ``_'' ** found **
02/27 10:38:24 ##### failed dev=ttyG0_00, pid=9582, got signal 1, exiting

Originally I got something about mgetty FATAL cannot get TIO ... then I did some googling and found other docs on setting up mgetty/pppd so now its a mishmash of all of those ... the error message has changed, but nonetheless the symptom is the same... when the connecting win2k client dials up, it appears to negotiate a connection but hangs during username and password verification... If I bring up a terminal window upon connection, or if i use hyperterminal, i can actually login to the box like a telnet and poke around...

Slackware 12
Digi 8 port RAS modem card
mgettty interim release 1.1.35
pppd

Ideas anyone?

thx muchly,
Steve

It looks like the pppd process is aborting due to a SIGHUP signal. That implies that the Windows client disconnected the modem link.

The problem could be due to the authentication method that you selected for pppd and/or Windows. I don't know a whole lot about that, so I'm afraid I can't be more specific. Make sure that you don't select the option in Windows to "log on to network" or "log on to domain". Those try to use Windows authentication that probably isn't supported by Linux.

Thx Erik,

I've tried that stuff. Honestly I wish this project never came to my desk. Alas the client is adament about dial up... sigh. I may look at just using Windows2003 server to do all this - its just going to cost him a whole lot more.

Erik,

Here is something strange - I can negotiate a connection when I set the Win2k dial up connectoin to use Slip - Unix instead of PPP Windows. That seems quite odd. Thoughts?

Thx

http://www.blisstonia.com/eolson/notes/smboverssh.php

Try this link or similar. I think wha tyou need is Samba over SSH with port forwarding. You setup a loopback adapter on a client and forward it to samba port as if it is your local host.

Works a treat over ADSL but over dial-up maybe very slow.

Seriously he should consider the cost of waiting at POS as direct loss of his business revenue. He should take payments off-line and import transaction at intervals later!

Thanks yuri_d... So this customer is ok with it working over dsl/cable as long as dial up can work if dsl/cable is dead. Here's what I found. Comparing Samba over SSH to Microsoft Terminal Services running the dos apps I noticed the following.

Although the delays in key presses in Terminal Services vs Samba via SSH are about the same, its a different store when it comes to crunching data - reports an loading of transaction history.

Terminal Services is far quicker when crunchy reports and loading transaction data etc. Which I suppose makes sense because its running the app in a dos window on the server, whereas the samba via ssh is running exe and data over ssh...

My q's at this point are:
Is there a way to tune samba to improve this setup drastically?

Is there another way to do this on linux and get good performance? (i've tried dosemu over ssh but it doesn't recognize the F1 to F12 keys needed in the software) I suppose Virtual Machines are an option..

It's looking like maybe for this situtation its better to go with Windows Server 2003 and Terminal Services - if indeed the LPT ports and USB ports can be directed to the connecting client somehow to trigger his cashdrawer and receipt printers... This is 1 area where samba over ssh worked like a treat as you say - all that happened nicely.

Thanks again for your invaluable input - any thoughts on the above?

Steve

Steve,
I do not think you can completely win over the latency.
SSH produces a lot of trafic due to encryption and may be not the fastest protocol, but it is secure (if used with a private key) and reliable. VPN equipment may work faster.
Teminal services. Printers should work if drivers installed on W2K3 side
Terminal server will also require additional licenses from
M$. I actually had to install a W2K3 here to host a retail system and it is a steep learning curve, good fun though :-)