## Increasing Revenue
## Joe Read <joe@freebsdzine.org>

Before I begin, I would just like to let people know a little bit 
about me.  I am a software quality technician (QA) for Intel Corp.
testing the unix NIC drivers being developed in the Network
Communications Group at Jones Farm in Oregon.  Recently, the
developers have written drivers conforming to the IPRB standard for
Solaris, DDI8-compliant drivers for UnixWare 7, and also a beta
_open_source_ kernel patch for Linux.  These releases will improve
upon the existing 3rd-party developer versions, and soon will include
the advanced feature set present in the server and management adapters
such as teaming, wake on lan, and VLAN support.  SCO3/5 and UnixWare
2.x/7.x (DDI7) versions of these drivers have already been developed
and released by Intel, and soon to be released will be the Solaris and
Linux versions.  I've also heard some unconfirmed rumors of FreeBSD
versions, but I've gotten no official word at present.

Before I started working at Intel, I was system administrator for a
local ISP called Triax Internet Services (along with Jim Mock, the 
editor of this e-zine).  During my reign as administrator, it was a
constant effort to come up with new ideas for services to offer our
customer database in order to keep their business and, well, keep our
business.  The president of the company was always thinking up things
that us technical types knew wouldn't work (technical types usually
have backgrounds in support and therefore know how customers react to
certain things), yet we tried them anyway.  Things like online
training courses or long distance calling cards were constantly
offered on our web page, yet they just weren't making us any money
since making things like that work requires practically taking out a
very expensive advertising campaign which is just plain impossible for
the smaller ISP's.  So, we had to come up with the better mousetrap to
alleviate the problem of a low marketing budget. The next few months
my articles will focus on these 'better mousetraps' that hopefully
will have the world beating a path to your door too.

Net@Home

The first idea I had, (I had this idea over a year ago), was a central
server-like appliance designed for the home user to proxy IP via a 
single dial-up connection for multiple home computers.  Since we had 
a lot of demand for something like this, (customers constantly asking
us to recommend a product like this), I figured it wouldn't be hard to
MAKE this device in-house.  Part of our business was a computer parts
distributor which meant we had plenty of old Pentium(R) 90 CPU's
laying around and more cases then motherboards for sale.  I proceeded
to put a single Pentium-90 FreeBSD server together (with only 32 megs
RAM and a 1 gig hard drive) with two NICs in it.  I put one of the
NICs on a private network (192.168.0.2), and the other NIC on a live
IP we had routed to our business office, then configured a client also
on the private network with the IP of this impromptu server as it's
gateway and proxy server.

With this setup, I tried a few things.  The first thing I tried was 
using Apache as the proxy server, which worked OK except at the time 
it was very limited in its proxy capabilities and didn't support ftp.
After that, I tried playing around with "Squid", but didn't really
have the time to dedicate as much attention as its complexities
required.  Next, and what I finally settled on as the optimum
solution, was natd.  Natd (network address translation daemon) is a
daemon which takes packets on the interface of a private network
(192.168.x.x) and translates the packet source IP to the address of
the second interface (with a valid internet IP), then vice-versa ONLY
for reply packets.  This provides each machine behind the 'proxy' 
server (for lack of a better term) with the ability to connect to ANY
port on ANY remote host, and yet keep the network secure as anyone
going to the public interface's IP address (which each client machine
uses for network transactions) stops at the 'proxy' server since you
can't publicly address a private network's IP.  With this security
'feature', and perhaps with a few ipfw rules, I figured the level of
overall system security would help with the marketing and salesability
of our new product.

Now that I have the product to provide the primary function of our 
server decided upon, I began thinking of the issue of configurability.
Even though I didn't use apache for the proxy, I decided to leave it
running on a certain port to (if nothing else) serve web pages written
as a manual once I had everything finished and documented.  This,
instead, proved to be the solution to customer configuration of the
device, as we couldn't train them on using commands like 'vi' or
'ifconfig' if we wanted to market the device as "easy to use".
Instead, I wrote up a few shell scripts to take input on the command
line to configure the public interface IP address and then create an
rc.conf file accordingly, then wrote up a very simple web page and cgi
script to get the IP address, netmask and gateway IP's from the user
and pass it to these shell scripts.

Once I had these scripts working, I figured that no home user is going
to have an ethernet connection to the Internet.  With some adjustments
to the web pages, and another set of scripts and web pages to 
configure the ppp daemon, I had the box completely set up for a dial-up
user.  With a little tweaking, I left the public NIC in the server
along with a modem so that high-bandwidth connections could be used
such as DSL or Cable.  Though we never actually ended up selling this
server to our customers, (we sold to another ISP before we could),
the prototype I made was used and still is being used successfully by
one of our past employees both for dial-up and then DSL when it became
available to him.  The conversion from dial-up to DSL was smooth (a
change in the web interface, and plugging the DSL modem into the
public interface NIC), and he's had nothing but compliments on it from
all the people he's shown and explained it to.

The total cost to the company for the parts was about $100 
(considering we got the parts wholesale as a parts distributor).  A 
company could easily get away with selling this device for around
$200-$250 (150% profit!) to a home user interested in online gaming,
the home office user, or even a user interested in learning
networking.  I also considered the pricing scheme after I finished the
prototype (even though I never was able to get it to market) and 
discovered that a small-business model could also be built that would
have a web server, mail server, and even a newsgroup server; each 
service enabled with a sizeable payment from the customer, and each
only needing a shell script to configure it and a cgi script to get
the information to pass to the shell script.  Considering the overhead
compared to the profit, this would be a worthwhile investment to any
ISP struggling with an under-sold high-bandwidth connection and a large
low-paying customer base.

[note: Also think of the support costs!  Anything goes wrong, find
their IP, telnet to it and fix it!]

- Joe

$Id: isp.txt,v 1.1 2000/02/16 08:07:53 jim Exp $