Simple question on networking.
I've got a linux box, an old windows machine, and a machine
that dual boots windows/lunux. I'd like to connect them all 
for file and printer sharing, and so that I can telnet from 
one to the other, and view web pages on my apache server from
my windows machines.

Can I just do this with a inexpensive hub, or to I need a router?

I've not read up on doing this yet, but I understand that I'll need
to get samba working and tweek a few things on my windows machines.
It's a learning experience. Maybe I'll set up the linux box as a
firewall.

If you've done this, tell me about any issues that came up, or
any helpful tips that you have. Thanks!

27 responses total.

A hub will suffice.  (If you're using 10base2, you won't even need a hub.)
Make one of the Linux boxes your print server and run Samba on it.  This
works quite well -- just make sure whatever print filter you use has a "raw"
entry in the printcap, and point Windows at that, using the proper device
driver.  Samba should work well for your file sharing, too...it's easier
than trying to find an NFS client for Windows.  I suggest using SWAT to
configure it instead of trying to edit the config file by hand.

If you want to connect these machines to the outside, and you only have one
IP address, you'll need to put two ethernet cards in one of the Linux boxes
(or connect the modem to one of them, if you have a modem connection.) This
machine then effectively becomes your gateway. Run IP Masquerading on that
machine and it should work just fine for most things.  When you set up your
LAN, use IP addresses from one of the "reserved for private networks"
blocks, so you don't have address conflicts with the "real world." There are
two to choose from; 10.0.0.0 to 10.255.255.255, or 192.168.0.0 to
192.168.255.255.  These addresses are guaranteed not to be in use by anyone
directly connected to the Internet.

In my case, my gateway machine's "internal" IP is 192.168.1.1, and my other
machines go up from there.  I use a 255.255.255.0 netmask, since I don't
anticipate having more than 254 machines. ;)

Thanks, that will help. I'll connect the linux box to the 
internet with a modem and connect it to a hub. Then I'll
connect the other two machines to the hub.

I'll need to read up on samba, ip masquerading, and netmasks.
It'll probably take me a while, but it's a good project.

A good first step is to make sure "ping" works between the various
machines.  Once you have "ping" working, you'll know the low level stuff
works, and you can worry about higher level stuff like ftp & telnet.  If
"ping" doesn't work, you might find it useful to explore "arp" and
(below) "tcpdump".

Besides A (10/8) and C (192.168/16) there is also a class B private
network range, 172.16/12.

Something that you might want to think about running is "bind", probably
on the gateway machine.  You probably don't need to run a name server
but you might like to--this would allow you to specify local machines on
your network by name rather than IPaddr.

If you can get ping to work, but you are having trouble with more
complicated stuff, you might find it worthwhile to explore "tcpdump".
This will show you the actual network wire traffic, which can be very
educational.  This will be more useful if you are thinking of turning
into a network engineer than if you just want to get it done so you can
forget how it works.

I do plan on running a name server. My education is in
programming, but I like the system admin end of things
too, so I like the idea of learning the nuts and bolts.
I have a few good books. The main thing that I wanted
to know was if I could do it with just a hub, or if I
needed to invest more money, which I'd rather not do.;)
It'll just be a project to tinker with when I have 
free time over several months. Good experience, and fun.

Thanks for the tip on keeping it simple to start with.
Makes sense, and sometimes it's easy to get carried away.

Run a nameserver if you want the experience, but it's not necessary for a
network with only a few machines on it; you can always just edit the 'hosts'
file on each machine.  However, if you do set one up, you can speed up your
remote lookups somewhat by allowing it to cache them.  Bind is a little
complex and the configuration has some subtle "gotchas"; _UNIX System
Administration Handbook_ by Nemeth, Snyder, Seebass, and Hein has a fairly
good, if brief, treatment of it, but there are probably better references
people could suggest.

IP masquerading is pretty well covered by one of the Linux HOWTO documents. 
There's probably also a HOWTO for Samba, but I'm not sure.  My main
suggetion with Samba is to get printing working from Linux, using lpr,
first; then you can merely tell Samba to import the settings from your
printcap and things should work nicely.  I favor apsfilter as a print filter
for Linux or BSD, but many distributions come with one of their own, now.

I found a smb howto, 30 pages. 

linux doesn't understand my  printers so I'll be trying 
to send my print jobs through my windows machines. 

I don't really have much of anything intillegent to say
until a actually get the hub in a few weeks. I'll just be
reading up on stuff till then. 

I don't know if anyone is still reading this conference,
but I've achieved some success. I've got the two linux
machines talking to each other.

I used a simple utility, /usr/sbin/netconfig (redhat 6.2).
My /etc/resolv.conf files look like:
search localdomain
nameserver 127.0.0.1
nameserver 192.168.0.1
and my /etc/hosts files look like:
127.0.0.1       localhost.localdomain   localhost
192.168.0.1     bedroom.localdomain     bedroom
and for the other machine:
127.0.0.1       localhost.localdomain   localhost
192.168.0.1     study.localdomain       study

I can telnet between the linux machines, and if I set up
my windows machine with an ip address I can telnet from
windows to linux. But the weird thing is; I can't ping
anything! When I ping one linux machine from the other
I get a signnificant percentage of packet loss. Not 100%.

I just got this set up yesterday after reading some howtos.
(err: the second line in the second above /etc/hosts file
should read: 192.168.0.2) Next up is trying to set up dhcp
on the lunux box.

Any ideas on why I can't ping?

Ping reflects actual packet loss, while telnet and ftp (and others) hide any
packet loss by resending as needed.

So you've probably got flaky wiring, but not flaky enough to prevent operation
with a "reliable" protocol.

Wow, this is truely strange. Somehow my /etc/resolv.conf file
has changed, and I can ping the other machine with no problem!

Now /etc/resolv.conf reads:
nameserver 198.108.1.42
nameserver 198.109.36.3

The only things that I've done are to establish a ppp connection
with the UM and to run staroffice to read the comp.os.lunux.networking
newsgroup.

I tried changing the resolv.conf file on the other linux box in the 
same way, but it didn't make any difference. I still can't ping in
that direction.

Any ideas on what changed my resolv.conf file? Ane why it's working?
(I realize this in no longer a hardware issue).

nslookup reports that 198.108.1.42 etc belongs to UM.
Apparantly when I ppp connect to UM, /etc/resolv.conf gets
overwritten. But it's readonly.

After I reboot my machines I can't telnet between them until
I've established a ppp connection to UM, even if the connection
is no longer open.

Does this have something to do with named?

Probably something in your PPP setup scripts is taking the dynamic DNS server
information from the PPP negotiation, and overwriting /etc/resolve.conf with
it, which sounds like an ugly hack, but I suppose a much easier way to handle
that than rewriting the resolver libraries.  The easiest thing to do would
probably be either to disable that (if you want to use your own DNS server
all the time), or make a copy of /etc/resolv.conf how you want it set up when
you're not dialed up, and stick something in the disconnect script to copy
that back to /etc/resolv.conf.  Or, you could change the script that's
overwriting resolv.conf to add a line telling your resolve to check
/etc/hosts before DNS.

To say that "ping reflects actual packet loss" is technically correct, but
in some cases misleading.  Ping sends out ICMP echo requests, and waits for
ICMP echo reply packets to come back.  If it sends out an echo request, and
doesn't receive a corresponding echo reply, it records that as a dropped
packet.  However, ICMP packets being dropped at a certain rate does not
necessarily tell you that TCP or UDP packets will be dropped at the same rate.
If no ICMP echo replies are coming back, but the connection otherwise seems
to be working, it's more likely that some device in the middle is blocking
ICMP echo, than that the connection is flaky.  Also, some devices treat ICMP
packets at a lower priority than other packets.  Cisco routers under high CPU
utilization, for example, will start dropping ICMP before they start dropping
other traffic, so there are situations where ICMP performance will be awful,
but other protocols will still be going across the network ok.  Likewise,
Ciscos (my main area of expertise, not the only devices that do this) have
mechanisms for rate limiting certain types of traffic, and many network
operators are attempting to minimize the impact of denial of service attacks
by rate limiting ICMP to somewhere near the normally expected level.  As a
general rule, if you're getting bad  ICMP performance, but some ICMP packets
are coming through, something is either down, broken, overloaded, or
misconfigured, but it's hard to know which without more data.

Also, make sure the sequence numbers actually skip counts.  I'm wondering if
the 'packet loss' you were seeing was actually just ping being slow because
it was trying to look up hostnames and your DNS configuration was broken.

Thanks for all the great help, it's very informative.
I havn't pinned down the script that's overwriting
resolv.conf yet; I'm working on it.

Machine A (bedroom) was purchased from  Dell with Linux
already installed. This is the one that has the resolv.conf
problem. Machine B (study) I configured (win95/Linux), and
I don't use rp3 to establish ppp connections with it. I just
use minicom. Machine B's files are fine.

After I establish a ppp connection from  A to the UM, I can
ping B and everything works beautifully. Even after I disconnect
from UM. When  I ping A from B, the icmp_seq numbers are sequential,
and I get about an 80% packet loss. I'll need to learn more about
ping in order to give more complete info. I'll look into tcpdump
too. 

Telnet works fine. I'll try to figure out what Dell did.
Unfortunatly, now I've got to study for finals.

I assume the only thing between "bedroom" and "study" is an ethernet
hub.  The ethernet hub shouldn't be dropping or delaying any ICMP
packets, so what Steve said above doesn't apply.  Where what he says
applies is when you're talking about remote routers, which often do
prioritize ICMP packets, especially echos and replies, differently.  You
can thank the vandal community for that.

You should definitely try pinging by IP address (not DNS) first; this
should eliminate any weirdness caused by DNS.  If you're using thin-net,
and your network isn't properly terminated, you can get weird echos or
other stuff that might well cause partial packet loss.

Something else to look at: what does "netstat -r -n" say? It's not
sufficient to bring the ip interface up, you also have to make the other
machine routable in order to be able to send packets to it.

Stupid question: you *are* giving these two machines different
addresses, right?  I only see "192.168.0.1" above, and that's
definitely not right...

Yup, I'm pinging by ip addr. and each machine has a unique addr.
After playing around with it some more today, I'm starting to see
that things are just running slow, and I really wasn't expecting
that on such a small network. I think what was happening was that
there was a unexpected lag when I ping, so I was getting impatient
and hitting ctrl-c without giving it a chance. 

I was able to successfully ftp, but there was a long (15 second) lag
after I typed ftp 192.168.0.2 before anything happened. After the lag
everything worked fine. 

netstat -r -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
207.75.177.2    0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
192.168.0.1     0.0.0.0         255.255.255.255 UH        0 0          0 eth0
192.168.0.0     0.0.0.0         255.255.255.255 U         0 0          0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
0.0.0.0 207.75.177.2    0.0.0.0         UG        0 0          0 ppp0
This was "bedroom" (gotta think of better names one of these days)
207.75.177.2 == radius1.merit.edu

netstat -r -n from study reports:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.0.2     0.0.0.0         255.255.255.255 UH        0 0          0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
0.0.0.0 192.168.0.254   0.0.0.0         UG        0 0          0 eth0

So I can ping from 192.168.0.1 to 192.168.0.2 with no problem,
but the other way around I get about an 80% packet loss.

I just set this up using redhats /usr/sbin/netconfig, which is a very
simple utility. It asks for an IP address for the machine, then fills
in the following: 
Netmask:        255.255.255.0
Default gateway (IP):   192.168.0.254
Primary nameserver:     192.168.0.1
(this was for 192.168.0.1 "bedroom")

I still havn't figured out what Dell did that's causing 
my resolv.conf files to be overwritten.

When using the 'ping' command it's best to use the -c option and give it a
number of packets to send, if you want to rely on the stats.  If you do
'ping -c20 hostname' and wait for it to exit, the stats will be accurate; if
you leave out the -c and just hit Ctrl-C, you'll probably get one or two
dropped packets even if the connection is good.

Whether you lose any packets with ^C depends on the network lag and your
reaction time.  You should never get more than one dropped packet due to
^C unless you have lag > 1 second.  If you press ^C right after ping
reports a packet, and you've got a low latency network like ethernet,
you should be able to reliably not get any lost packets due to ^C.

You appear to have a strange netmask (255.255.255.255) on bedroom.  It's
probably wrong for "study" to have a default route, unless you actually
intend to have a 3rd machine addressed at 192.168.0.254.

You might want to do a "netstat -s" on each machine, before & after
sending packets.  It's possible your ping packets on "bedroom" were
actually going off to merit (due to the bad netmask & default route).
Merit should have thrown those packets away, but if they're using
192.168 for their own purposes, it's possible they might respond to ping
packets - and likely that they'd be very "lossy" on responding.  If this
is what is happening, then you won't see any change in icmp stats on
"study".  You'll also see big delays on the ping packets that do get
through to merit, since they'll be going over ppp.  Delays between two
ethernet connected machines should definitely be under 10 ms, and most
likely under 2 ms (the exact time depends on the speed of the two
machines and the network cards).  RTT delays via ppp are likely to be
more like 70-250 ms., depending on line quality and whatever else is
happening on that line.

Something else to look at is "arp".  Arp is the protocol used by
ethernet machines to map mac addresses into IP addresses.  Normally, the
arp cache will start out empty on both machines - after sending a packet
from one machine to the other, both machines should know the other's mac
& IP address.  There's also a way to flush the arp cache and add or
delete entries, though this is only rarely used.

Ahh!
I've got it. Sheesh, I feel kind of stupid. I guess it just took
a while for what these configuration files actually do to sink in.

I changed study's primary nameserver to study instead of bedroom
and then  realized that study's /etc/hosts didn't have an entry
for bedroom. So I put that in and now I can ping! 

Well I've got that figured out, thanks all for your help.
Now I've just got to rig up a fix for that resolv.conf overwriting
problem and I'll be set. Whew.

resolv.conf is probably being overwritten by pppd.  Look for options to
disable that behavior.

Ah this is beautiful. I've got the windows machines talking to each other
with netbeui and a tcp/ip connection with the linux box. :-)

I checked out some documentation on  pppd and I think I may have found
out whats overwriting resolv.conf.

Here's the culprit:

[nkj@bedroom ppp]$ cat /etc/ppp/ip-up.local
#!/bin/sh

PATH=/bin:/sbin:/usr/bin:/usr/sbin

INTERFACE=`echo $1 | sed 's/[0-9]$//'`
if [ "$INTERFACE" = "ippp" ]; then
    cp -f /etc/resolv.conf /etc/resolv.conf_isdnbak >& /dev/null
fi           

And here's a little excerpt from the pppd man pages:

       nodefaultroute
              Disable the defaultroute option.  The system admin-
              istrator  who wishes to prevent users from creating
              default routes with pppd can do so by placing  this
              option in the /etc/ppp/options file.

Time to tinker...

Hey, I know this thread has been dead for awhile but I'm learning networking
right now and I'm wondering.  What all can networking do?  I had a null-modem
link between two windows boxes once and I couldn't even get onto the otehr
hard-drive.  I want to hookup an old Mac Performa 400 to a win98se box.  Is
that even possible? (highly doubts it)  I just want a network where I can
access the otehr HDDs like at my school.  So I can use Winamp on this box but
get MP3's from an HDD on a different box.   Is that possible?  Thanks for any
responses.

A "null modem" cable would be a serial thing.  Yes, it's possible to do
networking over a serial cable.  You will most likely want to
investigate "ppp".  It will not be very afst, and you probably don't
want to use this for filesystem access for MP3's.  What you probably
want instead are ethernet cards.  That will get you the speed you want.

There are a variety of networking choices that will run on top of that,
but if you want to fileshare between a mac & a windows box, this may be
ugly: the mac comes with a peer to peer file sharing option, but it only
works with other macs (or via netatalk on linux, *bsd., etc.) Various
versions of windows also support peer to peer file sharing, but I'm not
quite sure what "win98se" has.  Most likely it supports smb, but macs
don't talk smb, at least not out of the box (but again, linux & *bsd
have a solution--samba.)

Another option might be to instead run a web server on one machine or
the other (I think both have support for this today) -- if winamp can
resolve and play "http:" style urls directly.

Isn't there an SMB client for Macs?

You might be able to run samba on 10.2.  I don't know if there's a smb
client for older macs, although there at least used to be a novell
netware client.

Wow thanks for the responses.  I never thought that such an incoherent post
would get good answers.  Kicky-tech!  Yeah...The onl ymac I have is a perforam
400, so...I don't think it's 80 MB hdd would be world putting Mp3s on or
hooking up to a network for that purpose.   I just wanted to learn more about
networking.  Sort of as a project... Getting windows and a mac and a *nix
system to communicate happily... :P

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss