IOA-IPAD

Version 2.0 DETAILED New Features List

---

Note that this list is presented raw and in full detail. Some of the smaller new features are not included in this list in an effort to not overwhelm you with too much trivia.

COMMON INTERNET FILE SERVER

---

• The IPAD now has a CIFS (Common Internet File Server) which will allow the IPAD's visible volume(s) (local or networked) to look like a Windows file server to other Windows (and CIFS compatible) workstations.
  
  The CIFS server is enabled with the following IPAD.CTL commands:

SERVER CIFS

CIFS AUTH=<fid> [NAME=<name>] [SCOPE=<scope>] [WORKGROUP=<wkgroup>] [COMMENT=<cmnt>] [PERMIT=nn.nn.nn.nn[/bb]]

• AUTH=<fid> Indicates the control file that holds the authorization information which defines those IPAD directories which can be shared as a CIFS file tree with other machines. See below for the format of this file.
• NAME=<name> Defines the server name by which the IPAD will be known in the CIFS network. By default this name will be the rightmost portion (up to the first dot) of the IPAD's HOST NAME= name.
• SCOPE=<scope> Establishes a scope within which this CIFS server is to operate. Most CIFS or Windows LAN Manager networks operate with no scope but you can use scopes to divide access in a large LAN.
• WORKGROUP = <wkgroup> Defines the workgroup the IPAD's CIFS system is part of. If this parameter is absent, the workgroup is name WORKGROUP.
• COMMENT = <cmnt> This defines the comment that will show in the Windows properties display of the IPAD's name. By default is the IPAD's version number (e.g. IPAD 2.0).
• PERMIT = nn.nn.nn.nn[/bb] Restricts access to the CIFS server to systems which originate from specified IP addresses or networks. nn.nn.nn.nn is the IP address which is allowed, the optional /bb defines the netmask in bits. Up to 20 PERMIT statements are allowed (you may use multiple CIFS commands to enter them if you wish).

Example: Only allow access to CIFS server from Class C network 192.168.143.0. For systems outside this network, the CIFS server will simply not exist.

Note: All parameters have logical defaults, and most will never need to be used. The only one you will need to use in most cases is CIFS AUTH=<fid> to establish a share list.

Example IPAD.CTL command:

Note: The IPAD will behave as a WINS server if you wish. A special file named WINS will be looked for in the IPAD's home directory to allow you to pre-load cross-segment servers into the WINS server if you wish. The format of this file is compatible with the Microsoft LMHOSTS file and has the following format:

1. Any line beginning with a semicolon(;) or # character is a comment.

2. Other lines are CIFS server definitions as follows:

where:

Example WINS entries:

DEFINING SHARED DIRECTORIES

The IPAD CIFS sharing is defined in the auth file you specify on the CIFS AUTH= command in IPAD.CTL. The IPAD is more flexible in defining share than Windows NT, and you can mix SHARE level authorization with USER level authorization as well as have public shares and USER shares with an added password. The format of the share control file is:

• <user> <pswd> <dir> NAME=<shname> [COMMENT=<comment>] [READ_ONLY=YES]

• user = Name user has logged on to their client Windows machine as. If this field is an * then any user name qualifies.
• pswd = Password which must be supplied to access this share. If this field is an * no password is required.

This allows four types of share as follows:

• user * - Any client which has logged on as user at the Windows level can see and use this file share.
• * pwsd - All clients will see this share, but must know the password to access it.
• user pswd - Any client which has logged on a user at the Windows level can see this share, but must know the password to access it.
• * * - Public Share. Anyone can see and use it with no authorization required.
  
• shname = The name this share will be known as when viewed by the client. This name is limited to 13 characters and may include blanks (although share names with blanks can be tricky for DOS clients).
• comment = 1 to 40 character comment which displays in the detail level when this computer is opened and the shares listed.
• READ_ONLY=YES (or RO=YES) means that this share is read-only and the LAN user cannot write to it.

In this example:

- A client logged in as admin would see four shares:

• cdrive
• IPAD
• PGMS
• PUBLIC

If the user clicked PGMS to open it, the password mypass1 would be required to proceed to see and use the files.

- A client logged in as lab would see three shares:

• cdrive
• IPAD
• PUBLIC

No passwords would be required for access to any share.

- A client logged in as jkb would see two shares:

• cdrive
• PUBLIC

No passwords would be required for access to any share.

- All other clients would see only one share:

• PUBLIC

Notes on the CIFS Server

1. Once configured, the IPAD's file system should show up in the Network Neighborhood of your windows machines automatically. Note: The browser system used by LAN Manager takes some time, so it may be a minute or two before it shows up. You can get access immediately by using the find computer option and entering the IPAD's CIFS name. In Windows95 find computer is accessed on the pull-down menu obtained by right clicking the Network Neighborhood.

2. From the DOS prompt in Windows95, or from a DOS machine using the Workgroups for DOS LAN client you mount shares with the NET USE command. Example: The IPAD is known as machine LAB and you wish to mount the share named cdrive. The command from the DOS prompt on the client computer is:

3. Because the IPAD only supports 8.3 file names, you cannot use long file names on the IPAD mounted drives, even if the machine you mounted it to supports them.

4. You may treat the IPAD's local drive (once you attach the share) the same as you would any other file server. It's performance is comparable to a Windows/NT server on the same hardware. However, remember you are adding a load to your IPAD if you do heavy file activity through CIFS (there's no magic here).

5. The IPAD's CIFS has been tested using Microsoft's Front Page to directly edit a web site hosted on the IPAD's local drive.

Even More Notes on CIFS

I've seen a lot of confusion over how CIFS needs to be configured on Windows machines. Here are some tips:

1. You only need the following networking components installed:

1. Client for Microsoft Networks
2. File and printer sharing for Microsoft Networks
3. TCP/IP -> Your Ethernet Adapter

You do NOT need NetBEUI, IPX, etc. They aren't used in CIFS transactions with the IPAD, and aren't needed in Windows-to-Windows CIFS transactions either if they aren't present. Windows uses NetBEUI if you install it, but if you don't it will switch to using TCP/IP automatically.

2. Only machines that are defined to have the same WORKGROUP will see each other's files. Machines with different workgroup names are in different file system domains and won't share files.

3. The CIFS browser system uses the broadcast IP address on each Ethernet or Token Ring interface to advertise itself and find other file servers. If you do too much sub-netting and don't define the netmask on an interface, you can create a situation where the interface's broadcast address (as seen in stat int) doesn't route to that interface! This will confuse CIFS mightily and cause things not to be visible where you expect. The solution here is to put IP_ADDRESS and NETMASK on the interfaces to properly define you real network structure.

4. You can use the console command _cifs show xxx to look at the CIFS browser tables to see if the IPAD and your systems are communicating.

_cifs show servers Displays the browser tables by IP address sub-net and shows what servers have been discovered and whether the IPAD is the master browser or just a server on each sub-net.

_cifs show subnets Shows what IP subnets the CIFS browser thinks exist on the IPAD and what NETBIOS names have been registered on each one.

_cifs show connections Shows data about each current CIFS connection to the IPAD.

_cifs show share Shows data about the IPAD's SHARE.EXE file sharing system. This doesn't pertain just to CIFS but to all files the IPAD has open for any reason. It can be used if you think file sharing isn't happening as it should for some reason.

The stat files display also shows any files open by the new CIFS file server.

TRANSPARENT PROXY AND PRIVATE NETWORKS

Added Transparent PROXY firewalling, and Phil Becker's own custom blend of:

• Network Address Translation
• Port Address Translation
• Stateful Inspection Firewalling

to create the ability to have an RFC1597 phantom private sub-net that is transparently proxied off of the primary HOST IP address.

IPAD.CTL Syntax to create such a sub-net is:

The IP_address=nn.nn.nn.nn indicates the IPAD's host address on the PROXY subnet, and the netmask (indicated with either /bits or the NETMASK= option) defines the size of the sub-net. If no netmask is given, the subnet is a full Class C in size.

The resultant sub-net becomes the PROXY sub-net and all addresses on it will map to the IPAD's host IP address and local ports rather than be routed normally. Note that this sub-net is intrinsically firewalled in that no incoming packet from any interface with a destination address for this sub-net is accessible from the outside world.

Because they live behind the firewall, no computer which is using one of the private sub-net addresses may normally have a server on it, as no incoming access to it is possible. However, for each TCP/UDP port a single server may be specified and a hole in the firewall opened to it through the use of the IPAD.CTL command:

Where nn.nn.nn.nn is the IP address on the private subnet where the server is located and port is the port the server will listen for incoming connections on.

Finally, because the PROXY sub-net doesn't really exist, any routes to it will not be advertised by RIP.

The PROXY sub-net is proxied from any interface on the IPAD, so it may be used on multiple Ethernet interfaces and dial-up lines as long as proper ROUTE commands indicate where what parts reside. If you have sub-nets of the private PROXY net on different interfaces, they may reach each other through the IPAD in a normal fashion, as they all are behind the firewall together.

You may mix proxy sub-net addresses and real IP addresses on any interface through the use of ROUTE commands, and you can choose to define an interface as having an address on the PROXY network if you wish as well.

You MAY NOT MAKE THE IPAD HOST IP_ADDRESS BE AN ADDRESS ON THE PROXY SUB-NET. The HOST primary address MUST be the real IP address that all PROXY sub-net addresses are mapped to when they contact the outside world.

Example: Make the Class C network 198.161.0.0 be the proxy sub-net and designate the IPAD as 198.161.0.1 on that network. Make the sub-net exist for computers hooked to interface EN0 and dial-up DYNAMIC addresses only. Put up a real-audio server on the computer with private address 192.168.0.27

Note: To the outside world, the real-audio server will have the IP address and DNS name of the IPAD HOST IP address.

Note: To avoid confusion, the PROXY command will accept the command

as a synonym for:

It was felt these were so close together that confusion would result, and it is unambiguous to accept either command and feed the ARP PROXY parser so all options work with either.

New console command stat proxy shows the proxy subnet circuit table as it forms and dies with usage, along with subnet structure and stats.

The IPAD now has a Zero configuration DHCP server to allocate proxy subnet IP addresses and configuration. It works as follows:

If you have a PROXY IP_ADDRESS command to define a sub-net, the DHCP server starts automatically. It will take control of the upper half of the PROXY addressing space for DCHP assignment. So if you have the command:

the DHCP will assign addresses 192.168.1.127 through 192.168.1.255 and leave the lower addresses for you to manually allocate as you wish.

There is a new stat dhcp command to display the dynamic IP address range(s) controlled by DHCP showing free and allocated IP addresses along with current and expired leases for them (if any) as well as the number and type of DHCP transactions.

Using DHCP

Once you configure a PROXY subnet using the IPAD.CTL PROXY IP_ADDRESS= command, DHCP becomes available to allow automatic Zero-admin setup of workstations on the proxy subnet. To do this with a Windows '95 workstation do the following:

• 1. Right Click Network Neighborhood and select the Properties option.
• 2. IF this is a fresh configuration, you need to add the following components to the empty box by clicking ADD and selecting each one:
  • Client for Microsoft Networks
  • File and printer sharing for Microsoft Networks
  • TCP/IP -> Your Ethernet Adapter

You may optionally wish to add:

• Dial-up Adapter
• TCP/IP -> Dial-up Adapter

To allow dial-out use as well.

Note: You may have other components here, but this is the minimum required for full auto-config TCP/IP access.

• 3. Highlight the component TCP/IP -> Your Ethernet Adapter and then click the properties button. A multi-tabbed screen will appear with the IP Address tab active.
• 4. On the IP Address tab, click the button marked Obtain an IP address automatically.
• 5. Click OK and reboot the computer.

You will find that an IP address, gateway, netmask, DNS server, and WINS server has been fully configured and you are ready to run on the Internet! That is what DHCP is all about, Zero-config on workstations on the LAN.

Technical Notes on DHCP

While DHCP assumes at the start that it controls the upper half of the IP addresses on the PROXY sub-net, it verifies each one before assigning it. So if you put up a static computer on a high-group IP address, DHCP still won't create a conflict by re-assigning it. But it is better if you use the lower half for all static assignments.

Also, if you use PROXY sub-net addresses for DYNAMIC or specific user dial-in, you should assign those addresses from the lower half of the proxy sub-net to avoid conflict with the DHCP managed address range. Again the IPAD will usually protect you, but it's best to use the lower address range for static assignments, and leave the upper half for DHCP to manage.

DHCP leases IP addresses for a fixed time, after which the client must check in and renew the lease. This is how it regains an IP address for re-use if you take a computer away. However, DHCP remembers which IP was given to which computer for as long as it can (and that will usually be weeks or months) and it that same computer re-appears it will lease it back the same IP address it had before if at all possible. This version's Zero-config DHCP manager will always issue 24 hour leases. I think that's a good compromise assuming the IPAD is always up on the LAN.

Note: If you find the file LEASES.CTL in the IPAD directory, feel free to look but DO NOT TOUCH! This is the IPAD's memory of leases between system restarts. Manual editing of this file can be dangerous!

Finally, there is a program in Windows '95 which will let you play with the DCHP process and watch it work. It is called WinIPcfg and you can go to the Start button, select run and type winipcfg in the box to run it. It comes up in a short screen mode, click More info button as your first move.

Now you can release and renew the configuration and watch it happen, and see the info DHCP supplies. Have fun!

IPAD firewall supports UDP which returns from a different port than we sent it to. I call this an unbalanced UDP circuit. Example:

I suspect this happens on UNIX systems where the UDP server spawns a task from the listener and doesn't do the system level work to inherit the socket for sending. In any case, the XING Streamworks server does this, despite the nice Firewall discussion on their web site saying how to filter it indicating it doesn't.

Protocols tested to work through the Transparent Proxy Firewall:

(List updated elsewhere on this web site.)

The Web Browser based manager! The major benefit from this feature is that you may now change all IPAD configuration in real-time. Note: You must use Netscape Navigator version 3.0 or greater or Internet Explorer version 3.0 or greater for proper operation! No claim is made for correct operation with every browser and operating system combination. Our tests were done on Windows 3.1x/95/NT[3.5x/4.x] with Netscape 3.x and IE 3.x.

Web Manager Activation

The web manager is enabled using the WWW_MANAGER configuration statement in IPAD.CTL as follows:

As you can see, this uses the exact same syntax as the WWW_LITE server with the requirement that AUTHORIZATION must be specified.

Example:

NOTE: It is recommended that you DO NOT advertise the manager's IP address in your DNS files. Since you will be the only person who should be accessing the manager, it's best to simply bookmark it with your web browser.

ORIENTATION

The web manager is designed for optimal viewing using a browser in 800x600 mode with at least 256 colors. The minimum supported screen is 640x400 resolution. When you first enter the web manager. you will be greeted with a four framed windows. They are:

IPAD Logo	Result/help Messages
Menu	Form/Messages.

• IPAD Logo - Always shows the IPAD and model number you're running.
• Result - Displays all help text and result messages.
• Menu - Cascading menu. See below.
• Form/Messages - Where configuration forms appear.

WEB MANAGER MENU

The top menu is divided into six categories:

• Servers - E-mail, Web, DNS, CIFS, FTP, Telnet, and Miscellaneous.
• System - Primary/Secondary IP addresses, telnet/web managers, local
• console, time/date, SNMP, system logs.
• Dialup - Interfaces, RADIUS, billing log.
• Routing - Route table, proxy subnet, filters, ARP, and RIP.
• Interfaces - Sync PPP, Frame Relay, Ethernet, Token Ring, Dialout.
• Save - Save and reset

FOLDERS

When you reach a configuration item, it is in a manila folder motif. Each tab represents a different configuration folder. Each folder may show you more depending on your selection (e.g., expert mode). You can always go back to the top level of the folder by clicking on its tab. For example, if you no longer wish to look at the expert configuration for web servers, clicking the WWW tab will return you to the typical folder view.

Some folders are divided further, such as DNS.

To exit a folder, simply click on another menu entry at the left or click on the X in the upper right corner of the folder.

FUNCTIONALITY

The minimum goal is to completely do away any need to edit the IPAD.CTL file by hand (the only exception to this is the MULTIPORT statement).

The second goal is to eliminate the need for third-party utilities (e.g., text editors) to configure DNS, and WWW form configuration. At this time web based e-mail and ftp/dialup user editing is not implemented.

SAVING THE IPAD.CTL FILE

The web manager saves its current configuration into a new version of the IPAD.CTL file using the existing file as a template. The old IPAD.CTL file will be renamed and up to 10 different backups will be saved using the names IPAD.CT0 - IPAD.CT9.

The WWW_LITE and WWW_MANAGER configuration statements can now take an optional PORT keyword, specifying the port that it should run on.

The following example shows the web manager enabled on port 5000

To access the web manager, you must add the port to the URL in your web browser such as:

Note: If you change the web manager's port, you will also need to change the port in the URL for the next access. The browser won't know that the port has changed.

The IPAD now supports near-completion of all Polyform options on the WWW FORMS= handling. Specifically, you can now email the results of a form to a specific user, and also mail a canned acknowledgment back to the submitter of the form. Also, the template capability of formatting the saved (or now emailed) output is implemented. The options are as follows:

The Template output style portion of the Polyform compatible FORMS handling in the WWW server is now active. This adds a new option to the OutputStyle= .INI parameter and also a new .INI parameter as follows:

• OutputStyle=Template
• OutputTemplate=<filespec>
• Where <filespec> is a fully qualified file name (e.g. c:\ipad\template.txt) which indicates where the template text is.

The template option operates by copying the template file to the output (which is either the Archive= file or the To= email destination or both). The template file may have insertion parameters based on the variables the FORM has returned. An insertion parameter is delimited by the carat (^) character on each end and is the name of the variable.

Example Template:

The file label.txt contains:

This template would write a mailing label as its output (with the title Mailing Label: and the divider bars as shown). The fields indicated by parameters would be replaced with the values that were returned by the form submitted.

The Template option allows you nearly unlimited formatting capability for either the Archive file, or for the email message you send to the designated person with the forms data (see below).

The email portion of the Polyform compatible FORMS handling in the WWW server is now active. This adds four new active parameters to the .INI file entry for a form as follows:

• <dest> = destination to send FORM data email message to
• <source> = email address to show message from (default if not given is webmaster@hostname where hostname is the name on the IPAD.CTL HOST NAME= command.
• <subject> = the subject line of the email message. (default if not given is Form Message).
• <body> = An optional text file which will be the body of an email message sent to the user of the form.
• <sendfrom> = name to show the canned message <body> is sent from (default if not given is webmaster@hostname as above.

Note: This allows two email messages to be sent on a forms submission as follows:

1) The data from the form is sent as:

• From: <Sender=>
• To: <To=>
• Subject: <Subject=>
• ... Formatted form data based on <OutputStyle=>

2) The canned response to form submitter is sent as:

• From: <From=>
• To: <email variable>
• Subject: <Subject=>
• ... data from file <SendMessage=>

The field <email variable> is string typed by the user into the form itself. This must go to a special variable named email defined in HTML in your form as:

The user response is screened for having been entered (i.e., not blank) and also for containing an @ and at least one . characters or the message won't be sent.

Note: You can both send email message(s) AND append forms data to and archive file. If the Archive= parameter is absent or empty, then no file data is written. If the To= parameter is absent or empty, then no email message is sent. If both are present, both an email message and an archive file entry will be generated.

Note: For compatibility with older versions of Polyform .INI files, the From= variable may occur once in a block called [Config]. It is only looked for there if it doesn't appear in the specific form's block in the WWW server's FORMS= .INI file.

Example: Mail the results of each form submission to pbecker@example.com and say they came from sales@example.com. Also add them to the archive file c:\formdata\csi.txt. Send a Thank you letter to the submitter.

Contents of WWW .INI file for this form:

Actions from form submission:

1) Form data is appended to the file c:\formdata\csi.txt in the Text format:

2) Email will be sent with the form data in Text format:

• To: pbecker@example.com
• From: sales@example.com
• Subject: Application for CSI
• ... Data user entered on form ...

3) If the client filled out the field in the form with the special variable name email then a second email message will be sent as follows:

• To: <email variable response>
• From: csi@example.com
• Subject: Application for CSI
• ... Contents of file c:\text\csithank.txt ...