Post by Jim Brain on Mar 11, 2004 15:27:20 GMT -5
As previously noted on c.s.c, I am putting the finishing touches on a daemon that will bridge 1 or more serial ttys and and IP port. Here are the highlights:
Ok, with this in mind, my initial code was not adequate. However, with a quick google of fork()/pipe() and such, I have re-factored my code to handle all of these issues.
Now, the code consists or a scheduler/IP listener task that forks children to do the actual work (same as before, but with pipes to communicate between). The children are "modem core tasks". These tasks emulate a modem core (AT comments and passing data from serial <-> IP). The modem core forks a small process to watch serial port status pins (DTR (shows up as DSR on Linux size) and others. This offers a number of advantages:
Specifics:
What I need:
As my first Linux app in 10 years, I am pleasantly surprised by how far I have gotten thus far.
Code is mostly POSIX, except for a few IOCTLs. Code should compile on Win32 via cygwin, so I will do that after I get it working on Linux.
If this is ultimately successful, I will try to either find or implement a virtual tty driver (so that VICE can bind to a port, and this can bind to the other end). But, first things first.
Jim
Ok, with this in mind, my initial code was not adequate. However, with a quick google of fork()/pipe() and such, I have re-factored my code to handle all of these issues.
Now, the code consists or a scheduler/IP listener task that forks children to do the actual work (same as before, but with pipes to communicate between). The children are "modem core tasks". These tasks emulate a modem core (AT comments and passing data from serial <-> IP). The modem core forks a small process to watch serial port status pins (DTR (shows up as DSR on Linux size) and others. This offers a number of advantages:
- same code can be used for incoming and outgoing calls. In fact, same running app can fulfill both functions (you could call out, then turn around and receive a call.)
- since the master can fork multiple children, 1 IP port can be bound to multiple serial ports. If so, incoming connections will be send to first available open connection.
Specifics:
- when an incoming connection is detected, master notifies open child. Child accepts connection, then prints "RING" to serial port.
- If modem has previously set ats0=n (n != 0, which implies do not answer phone, I think), serial and IP are connected. (If answer is turned off, master will not send incoming requests to this task) Modem is then switched out of command mode.
- If modem drops DTR, status line task will notify modem core, which will drp IP connection and go back to command mode
- If serial does "+++" and and then "ATH", any active IP is dropped and core switches to command mode
- If master has no open ports to send incoming connnections to, it accepts the connection itself, prints a msg, and disconnects
- if serial wants an outgoing connection, task notifies master it is busy, an outgoing conn is created.
- if outgoing conn fails, a BUSY is sent to modem (maybe NO ANSWER, let me know which is more appropriate)
- if connection is established, core is switched out of command mode. CONNECT (speed) is printed on screen. speed is speed of the serial port.
What I need:
- people to send me their modem init and dial commands (email to me with subject of "AT commands"). I want to test my parser.
- Cameron et al. with UDS-10 units or Leif with his win32 app. Can you tell me how your hardware/software deals with rejected connections to IP ports, etc.?
- Comments or suggestions for things I have missed.
As my first Linux app in 10 years, I am pleasantly surprised by how far I have gotten thus far.
Code is mostly POSIX, except for a few IOCTLs. Code should compile on Win32 via cygwin, so I will do that after I get it working on Linux.
If this is ultimately successful, I will try to either find or implement a virtual tty driver (so that VICE can bind to a port, and this can bind to the other end). But, first things first.
Jim