Following are some questions and answers that are commonly asked.
Yes you can, take a look at TERM. TERM allows you you to run network connections over a normal terminal session. It requires some modifications to the network applications to work with it, but binaries and sources are available for the most common ones already. take a look at the TERM-HOWTO for lots more information.
You do not have your name resolver configured properly. Reread the
section on /etc/resolv.conf. You must have at least a nameserver
entry configured.
RFC1597 has specifically reserved some IP addresses for private networks. You should use these as they prevent anything nasty happening if you accidentally get connected to the Internet. The addresses reserved are:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
Note, reserved network addresses are of classes A, B and C, so you are not restricted in your network design or size. Since you won't be connecting to the Internet it doesn't matter if you use the same address as some other group or network, just so long as the addresses you use are unique within your network.
You have three options. They are as follows:
IP-Masquerade software. This is probably
the simplest way, as it is fairly straightforward to do and doesn't require
special clients on your machines. This software very cleverly performs
address translations that make the machines on your network look like they
are the machine supporting your dial-up connection. There are some limitations
to how well this will work, but it is much lighter-weight than running a
full firewall gateway.Alan's archive is mirrored on:
ftp.Uni-Mainz.DE
/pub/Linux/packages/Net2Debugged
and/or:
ftp.infomagic.com
/pub/mirrors/linux/sunacm
The network code and kernel now have synchronised version numbers, so try:
uname -a
or:
cat /proc/version
The /etc/issue is the message that is given to normal
getty users when they login. Some telnetd programs use a different
file /etc/issue.net instead. So if you find that changing your
issue file doesn't work, try changing the other.
This usually means that your Ethernet cable is unplugged, or that the setup parameters for your card (I/O address, IRQ, etc.) are not set correctly. Check the messages at boot time and make sure that your card is recognized with the correct Ethernet address. If it is, check that there is no conflict with any other hardware in your machine, eg you might have a soundblaster sharing the same IRQ or i/o control port.
You probably have your Ethernet card configured incorrectly. Double check the settings in /usr/src/linux/drivers/net/CONFIG. If this checks out ok, you may in fact have a cabling problem, check the cables are plugged in securely.
You are using a version of route that is older than your kernel. You should upgrade to a newer version of route. Refer to the "The network configuration tool suite" section of this document for information on where to obtain the tool set.
This message means that yours, or some other, machine doesn't know how to route to the host that you are attempting to ping or connect to. If it occurs for all hosts that you try, then it is probable that you don't have your default route set up properly, reread the `routing' section.
This is probably due to a routing problem. Reread the `routing' section in this document. If this looks ok, then make sure that the host you are attempting to connect to has a route to you. If you are a dialin user then this is a common cause of problems, ensure that your server is either running a routing program like gated or routed, or that it is `proxy arping' for you, otherwise you will be able to get datagrams to the remote host, but it won't know how to return datagrams to you.
You should read the IPX-HOWTO as it has information on Linux software that will allow you to do this without having to worry about using NFS.
Certain vendors (Sun primarily) shipped many machines running NFS without UDP checksums. Great on ethernet, suicide otherwise. UDP checksums can be enabled on most file servers. Linux has it enabled by default from pl13 onwards - but both ends need to have it enabled...
The Linux NFS server defaults to read only. RTFM the `exports' and nfsd manual pages. With non Linux servers you may also need to alter /etc/exports
dip doesn't really need to know the address of your SLIP
server for SLIP to function. The remote option was added as
a convenience so that dip could automate the ifconfig
and route commands for you. If you don't know and cannot find out
the address of your SLIP server then Peter D. Junger
[email protected] has suggested that he simply used his own
address wherever a dip script called for a remote address. This is a small
kludge but it works ok, as the server's address never actually appears in
the SLIP headers anyway.
dip needs to be setuid root to do some of the things it needs to do, such as modifying the routing table. Uri Blumenthal recommends the following:
/etc/group
file and place each person who you want to allow dial out operation in it.# chown root.dip /usr/bin/dip # chmod u=rx,g=x,o= /usr/bin/dip # chmod u+s /usr/bin/dip
Dial-In users will be restricted in what they can do by what is contained in
the /etc/diphosts file.
DIP: tty: set_disc(1): Invalid argument', why?This usually suggests that your kernel has not been compiled with
SLIP support in it. Check that /proc/net/dev contains
devices called sl0, sl1 etc. It could also mean that
your version of dip is very old. You should upgrade to a newer version.
wrong data byte #17...', why?This generally means that you have your modem configured for XON/XOFF flow control. SLIP must have an eight bit clean line, so you cannot use XON/XOFF flow control. Hardware handshaking works better anyway, use it.
This is most likely caused by a disagreement on the use of header compression between your server and your machine. Double check that both ends either are, or are not, using compression. They must match.
If you use dip to dial out on the SLIP line, just `dip -k' should do the trick. If not, try to kill the dip process that is running. When dip dies it should hang up the call. To give it the best chance to clean up after itself, try killing the process in the following sequence: `kill <pid>', `kill -hup <pid>' and finally, if the dip process still refuses to die, try `kill -9 <pid>'. The same philosophy should be applied to all unix processes that you are attempting to kill.
The older network tools incorrectly report number of packets compressed as the number of packets overrun. This has been corrected and shouldn't occur of you are running the new version kernel and tools. If it still is it probably indicates that your machine isn't keeping up with the rate of data incoming. If you are not using 16550AFN UARTs then you should upgrade to them. 16450, or 8250 generate an interrupt for every character they receive and are therefore very reliant on the processor to be able to find time to stop what it is doing an collect the character from them to ensure none get lost. The 16550AFN has a 16 character FIFO and they only generate interrupts when the FIFO is nearly full, or when they have had character waiting, this means that less interrupts get generated for the same amount of data and that less time is spent servicing your serial port. If you want to use multiple serial ports you should mandatorily upgrade to 16550AFN UARTs anyway.
Yes. If you have, for example, three machines which you would like to interconnect, then you most certainly could use two SLIP interfaces on one machine and connect each of the other machines to it. Simply configure the second interface as you did the first. NOTE that the second interface will require a different IP address to the first. You may need to play with the routing a bit to get it to do what you want, but it should work.
The kernel SLIP comes with a default of a maximum of 4 SLIP devices
configured, this is set in the /usr/src/linux/drivers/net/slip.h file.
To increase it, say to 16, change the #define SL_NRUNIT to
16, in place of the 4 that will be there. You also need to
edit /usr/src/linux/drivers/net/Space.c and add sections for sl4,
sl5 etc. You can copy the existing driver definition as a template to
make it easier. You will need to recompile the kernel for the change to take
effect.
You should refer to the PPP-HOWTO for a list of PPP questions and answers compiled by Al Longyear.