Bugs to Fix (Answered bugs are fixed and are useful documentation)
------------------------------------------------------------------
2. Once in dialout mode should we stop recognizing all telnet escape 
   sequences. We could end up doing vague things if these escapes turn 
   up during binary file transfers.
   Some notes:
   1. Telnet escapes are sent as the IAC (255) character followed by the
      telnet command character or sequence.
   2. IAC followed by IAC will be interpreted as a single character (255).
   3. So binary file transfers in dialout (and recognising telnet escapes)
      will work so long as the telnet client that supports file transfer
      quotes the character 255 with the character 255 (IAC). Does it?
      Check out Procomm Plus 3.0.
   -- Procomm's telnet file transfer module handles IAC properly. During
      binary or ascii file transfers, it quotes IAC with IAC. So we can 
      still support telnet sequences during dialout.
   -- We too quote buffers received on the serial side for tx to the telnet
      client.
3. Get rid of the DTR dialling business from the modem state machine.
   -- Left in, just in case it is required. Currently, DTR dialling is not
      invoked.
5. The username/password/access checking code.
7. Windows based WAN chat modification to skip initial dial-out screens.
   (Need we support dial-out using a Windows app that we provide?).
9. Flow control, connection started by, connection stopped by, choice of
   modem, modem parameters configuration, etc. needs to be done.
   -- Ignoring connection started by, connection stopped by
   -- Choice of modem will not be allowed here. Consequently, we will not
      also have modem parameters config. So any modem init, etc is not
      automatic and will have to be manually performed by the dialout feature
      user. Decided to have this setup from roucon. So we will be using
      modem strings as dictated by ROUCON. How will this be used?
   -- No choice of flow control - we will always do hardware flow control.
14. There seems to be some TCP problem. Sometimes telnet connections are not
    established at all. You need to retry many times before you can get a
    connection. Methinks that once the limit of the TCP receive window is
    reached, then hassles crop up slowly but surely. Needs a definite dekko.
    -- Skipped for now. Seems to work properly with Trumpet's TCP stack.
       Only NCSA TELBIN has some hassles.
    -- (A few weeks later) Fixed couple of TCP design problems and a bug.

Suggestions
-----------
1. Perform a login sort of operation as soon as telnet is invoked.
   Currently we present a menu and depending on choice, subsequenlty
   you are queried for username and password. Use a well-defined
   name such as "supervisor" or "administrator" who only can see stats
   and any other username can dialout too.

Notes
-----
0. We have introduced 1024 byte buffer per telnet session possible.
1. If anything is done that will abort or remove the password prompting
   and acceptance, make sure that the flag indicating verification at that
   point is turned off.
2. Dialout idle timeout is set at 1/2 hour. This currently cannot be 
   modified. The idle timeout is currently set to max whenever there is
   be serial activity (either tx or rx).
3. In all places, exiting the client can be done by one of the following
   means
	- typing the string "exit"
	- using the telnet interrupt key combination
	- terminating the telnet client
   So in the code handling in these three places, make sure that you 
   restore session variables to default and remove special settings.
4. In all menus, you can go to the previous level of menu by pressing
   ESC or making a menu choice. In such cases, make sure that you remove
   special settings enforced by the previous or current level of menu.
5. In all menus, the telnet abort output command redisplays the menu. 
6. The special handling refered to above is 
	- when accepting passwords, echo is turned off
	- after choice of WAN port is made, it is reserved immediately
	  (marked as BUSY). If in later menu's the client is exited,
	  the WAN port should be de-reserved so that others can use it.
7. In between actually using a port and choosing it, there is a brief
   period when port is reserved and should not be used by others. To take
   care of this, each client info class structure has a field by name of
   'port_reserved' set to TRUE during this period.
8. Once in dialout mode, session termination can occur in once of many
   ways
	- Using telnet exit 
		You get a close connection in this case
	- Using telnet interrupt process
		You may get a close connection, but before that you get the
		telnet interrupt process characters
	- Using telnet abort output
		You get a telnet abort output sequence, but connection is
		not closed.
	- Session timing out
		You initiate the session closing.
   In each of the above cases, you need to hangup properly.
10. Procomm Plus for Windows Version 3.0 supports telnet with file transfers
   using serial protocols from within this telnet.
11. What ports can dialout occur on?
	Decision made: WAN ports not currently in use by routing/RAS will
	be used for dialout. Disabled ports remain disabled unavailable for
	either routing or dialout.
	Maybe: Additional support so that some ports can be marked as
	meant for dialout to provide atleast a certain percentage of
	ports for dialout. OR maybe this is not required. Admin can see to
  	it that some port is not marked as DoD and the same port is not
	connected to any other router via modem, etc.
	Points:
	1. Direct connect issues
	2. Dialout only on async
	3. WANCHAT vs WANDRV
	4. How do you determine "currently in use" and by whom?
	   Direct connect is permanently "in use".

	- All disabled ports -- actually does not make sense. You've 
	  disabled a port indicating no use, not different use. Maybe
	  you could have one additional config telling 
	  disabled/routing/dialout. Needs UI change. No PnP.
	  The proper way perhaps of looking at this is that the box
	  will be a server, administered probably only once in its lifetime.
	  During that time, the admin guy can specify "so many ports for
	  routing/ras", "so many ports for dialout", "so many ports not to
	  be used -- we do not have that many modems". Then he can attach
	  modems that go out to other modems attached to routers, or
	  attach modems that go out to other modems attached to BBS's or
	  terminal servers. The essential thing is that the admin guy in
	  advance has to configure certain things.
	  So install has to change to ask for this info.
	- All enabled ports that are currently not in use. Two hassles
		- Conflicts - need to introduce code so that if one guy is 
		  using, the other guy does not try to use it (guy implies
		  routing/ras/dialout). So you need extra code in dialout 
		  and in the router sections to take care of this.
		- How do you tell in-use - simple, modem state should be
		  OFFLINE. 
			- Does modem state apply to all kinds of devices.
			- What about direct connect. Here possiblly you are
			  online constantly. Since router comes up first,
			  the direct connect link will always be considered
			  busy and in use by the router, so dialout cannot
			  be performed on a direct connect.
			- What about dial-on-demand, where modem could
			  possibly be offline though the link has been
			  reserved for use by the router perhaps
		- Problem of the buffer descriptors and style of init as
		  dialout uses the WANCHAT code while routing uses the
		  WANDRV code.
			- We can't integrate the two because while one
			  uses malloc'ed buffers, the other uses 
			  device_driver_malloc'ed buffers. Or am I imagining
			  things.
12. A possible source of delay (possibly for the entire router) is the
    quoting business that we do in send_chat_pkt_to_specific_telnet_client()
    in dialout.c. We need to quote, but if by any other means...

Scenarios of Usage
------------------

	Layout
	------
	
	         LAN A
	 ==*===============*==
	   |		   |
	+-----+		+-----+	    Serial     +-----+	
	| WS  |		|  R  |----<><><><>----| BBS |
	+-----+		+-----+		       +-----+

	WS  - Workstation
	R   - Router
	BBS - Bulletin Board System

1. Upload from WS to BBS:
	WS will use TCP to send packets to router. In router, code is such
	that in timer, socket read calls are made and for each socket read
	a packet may be sent out on the serial side. So serial send is at 
	the frequency of socket read calls. Currently, no check is made to 
        see if the serial send succeeded (it may fail due to lack of tx
	serial buffers). It is assumed that serial sending is faster than
	the frequency at which socket read calls are made. This is okay
	when keystrokes are being processed. What about file transfers?

	Actually, if our assumption is not true, we can perhaps introduce
	a flow control mechanism.

	Our assumption is not okay. For baud below 38400, file transfers
	are faster than serial speed, so packets are dropped due to lack
	of buffer space.
		
 Fixed - Flow control mechanism as following was introduced. If a serial
	send failed, the buffer is preserved and no future socket reads 
	are made until this buffer has been sent. If future socket reads
	are not made, the TCP rx window will fill up and TCP will throttle 
	send from the telnet client side. So there is automatic flow control.

2. Download by WS from BBS:
	Packets from the BBS will arrive onto the serial buffers. For
	every foreground serial read done, a buffer is rx-ed by the
	telnet server. The telnet server tries to do an immediate
	socket send. If socket send fails, the buffer is preserved and
	future serial rx-es are added to the buffer upto a certain limit.

	Like in the upload case above, serial rx-es at speeds < 38400 will
	be slow enough that TCP will not get throttled. But at bauds >= 38400
	rx-es on the serial will be so fast as to fill up the TCP send
	window. So we need a flow control mechanism on the serial side.
	
Ideas
-----

Algorithm to determine if a WAN port is available for dialout
-------------------------------------------------------------

If dialout structures say that WAN(i) is in use for dialout,
	tell port 'i' is in use for dialout.
If WAN(i) is disabled, 
	tell port 'i' is disabled.
If WAN(i) is direct-connect or WAN(i) is dial-on-demand or WAN(i) is said 
to be SYNC, 
	tell port 'i' is not the right type.

(* So ultimately we are left with an ASYNC non-dial-on-demand port. For
   such a port, the router will on start up run the modem state machine.
   If successful connection occurs, the modem will go on-line. i.e. CD
   will be present. During all other times, CD will not be present.
*)

If CD is present on WAN(i),
	tell port 'i' is in use for RAS or Routing

Else tell port 'i' is free.


Notes Re: Algorithm above
-------------------------
1. Check if SYNC ports need the jumper change or if it is only if you want
   V.35 support.
2. Check if it can be determined if dial-on-demand port is currently in 
   in active use.
3. We at present happily modify the WAN struct info. Shouldn't be doing so.
4. Re: CD -- assumption is not valid for SYNC and other kinds of setup.
   Valid only for ASYNC modem connections. Also when we show the menu,
   the CD may not be present. But by the time the user chooses an item,
   the CD may come on. So later we need to check when we actually do dialout
   on the line. Also we need to send some Carriage Returns so that dialling
   may be aborted, etc.
5. Currently the WAN structures do not tell if a port is used as 
   dial-on-demand. Need to look into PPP structs. Then the question of
   bundling ports comes up as in MLPPP. Maybe we can modify PPP to set
   the info back into the WAN structs? Can we, can we, ha ha. For now
   problem ignored -- let the user configure carefully....or can he?

Steps once a port is chosen for dialout and config params are selected
----------------------------------------------------------------------

If CD is present,
   inform user that someone else has grabbed the port and return to
   the state showing available WAN ports.

If CD is not present,
   If dialling end, send some CR's to abort dialling if dialling was in
   progress
   If answering end, ....

Set in our structures that this port is in use by dialout.
Stop the modem state machine of the router (how?)
Do our init for the wan port (note that this will re-program the SCC
and alloc it's own set of buffers)
Go ahead...


Notes Re: Steps Above
---------------------
1. What if answering end -- modem could possibly go online by the time we
   are fully setup for dialout. Do be bring down CD in that case to abort
   the old connection?


Steps once a dialout connection is terminated
---------------------------------------------
1. Do our de-init of the SCC and freeing of buffers, etc.
2. Re-init the router WAN programming so that the modem state machine
   starts off normally on the router end and in a proper modem state.
   Probably call wan_control() with open_port request.
   BUT this may occur after some delay when we hangup.
3. On actually hanging up, update our structures to say that this port
   is not in use by dialout.


Notes Re: Steps Above
---------------------
1. In the time taken for these steps, what if someone requests to see the
   ports for choosing for dialout --- what do we show these ports as?




WEBSERVER
---------
1. PAP and CHAP are to be fixed (Changes in PAP and CHAP through WEB is putting
      some unknown strings)
2. Once we connected to HTTP server it never deinitialize cfgmgr
3. validation for IPX network number is to be done
4. Validation for ppp parameters are to be done
