Really now. You forgot to backup the ramdisk to disk, or left out some important part. Configure it again and use the option 'save all but log' in the backup menu
> the problem is that the box seems to lose the link every so often > (like at least once a day) > the modem lights are on (DCD etc) and the ppp0 interface is there but nothing > gets thru.
I've had that problem before. I ended up throwing the modems in the corner and getting two new ones. You can try and notice this sooner with certain ppp options, check the man You can try and notice this sooner with certain ppp options, check the man page on some full linux box when available. See the options lcp-echo-failure and lcp-echo-interval . With these you should be able to decrease the "seld check" time of a ppp connection. Eg you could find out much sooner the link is down and restart it before the cilent notices. Note that this won't solve the problem, it will only reduce it.
See also -d and kdebug flags to log a truckload of info. You might also want to fiddle with modem settings. Make them more aggressive in dropping the line (because if the line drops, pppd will surely restart, instead of hanging dead in the water).
the non-FPU kernel means "this is a kernel with no FPU support, you need to have it in hardware" :) > But when I try loading it on my 386SX (a decidedly non-FPU system), it tries > to look for a FPU and fails, then "gives up".
Use the other image :)
If you are using syslinux or LILO you can try adding the following boot paramter: init=/bin/sh This will force the Linux kernel to boot sh instead of init. Use ae to edit the file /etc/passwd and remove everything between the first the colon's on the line starting with root: Alternatively, edit that file by unpacking and repacking the etc.lrp package
See: what's an .lrp file?
Because we've all been there. Especially the Vortex and Boomerang cards have given people a LOT of problems, esp when putting multiple of those in one machine. Get a nice NE2000 clone if your limiting factor is not ethernet in the first place.
Also see: networkcardisdead
Again, lots of options possible. Some of them are:
- The LRP didn't find your ethernet card. You didn't include the right module, the module needs specific paramters (ne MUST have irq= and io=), your modules configuration file doesn't mention your module - your card is using the wrong media (BNC instead of UTP or visa versa). Usually means the autosense failed. If on BNC, try adding cable before starting the machine. If using 3Com EtherLink's, disable PnP and force media to UTP or BNC instead of autosensing. do this with one of their EXE files from a bootdisk: ftp://ftp.3com.com/pub/NIC/ - Card broken? - IRQ conflict? /proc/interrupts doens't always tell the truth if there is a conflict. check with whatever DOS/configure disk shipped with your card. On never mainboards, try messing with the BIOS settings for pointing IRQ's to 'legacy' or 'ISA' cards if appropriate. Good IRQ's for cards are usually 5 (you don't have a soundcard in your LRP box right :) 9,10 and 11. If running out of IRQ's, and you don't use printer or serial, disable those in the BIOS to gain irq 3,4 and 7
There can be various reasons for this. Possibilities are: - Broken network card - Bad cabling or termination. Don't use TV coax for ethernet :P - Failed autosensing on the HUB. Try forcing full or half duplex - Cable is shorter then 1 meter - Mixed a regular UTP for a CrossCable UTP or visa versa (or the crossover switch on the HUB is set wrong)
You enabled a serial line for init, but forgot to include support for a serial port. If you have a special board (digiboard, etc) use the appropriate module. If you have a FourCom or standard serial port, add serial.o to your modules.lrp
See also: module generator
work out wtf was going on, I found this (searching DejaNews):
>To boot Linux on IBM Thinkpad laptops, the string >"floppy=thinkpad" has to be input to the kernel loader. >Looking at kernel source (1.2.1) I found the only >"documented" difference was the "inverted DCL bit". Is >there any other difference. Could someone point me to >any other sources of information.
Cool isn't it? Cable modem providing the entire household of Internet connectivity :) Btw. This is probably not allowed :)
You can. But be sure the dhcp package is based on the v2.x series of the ISC dhcp server package ( http://www.ics.org/).
If you want a quick answer from the mailinglist, try to describe you problem clearly. What does work, and what doesn't. Which parts of your network can you reach from where, and what parts are inaccessible? Also, add the output of the following commands in your email, since they contain valuable information to diagnose the problem:
ifconfig route -n ipfwadm -I -l -n ipfwadm -O -l -n ipfwadm -F -l -n
If you suspect hardware errors, try adding the following:
lsmod cat /proc/interrupts cat /proc/ioports
Are you using old serial controller chips (UART 16450?). Most pre-pentium PC's shipped with UART 16450's (or 16550's) that had a broken FIFO buffer. There are also some propriety chips that claim to be a 16550A that are really 16450's with a tiny buffer (I believe Compaq had those). If you want more then 14.400 speeds, make sure you are using 16550A's (The "A" matters). You can check this by watching the linux boot log on the console, with the setserial program, or by reading the chips in the computer.
This might be a nameserver problem. Did you configure a nameserver? DNS timeouts can take a long time.
You are probably using IP masquerading (NAT) and need to use some masquerading modules. You can see if the masquerading modules are loaded with 'lsmod'.
You forgot to either add the ppp.o module,, or the slhc.o module it depends on. Or you forgot to add serial support (eg: serial.o or digiboard.o(filename?)
If you use the module generator on www.linuxrouter.org, the first shouldn't happen. The second isn't an obvious dependancy, so the module generator doesn't "catch" this (yet)
The kernel has not been rdev'ed to use /dev/ram0 as the root device, and the boot loader has not been told to use it either.
For syslinux add 'root=/dev/ram0' to the append line of syslinux.cfg. For LILO, add 'root=/dev/ram0' to the lilo.conf file.
Your mileage will vary with other boot loaders.
If not using a bootloader (eg when using a dd'ed zImage) make sure to rdev it: rdev zImage /dev/ram0
Check your logfiles for any error messages.
You must define pools for ALL subnets your machine has defined. If you don't want DHCP on some subnet, define an empty subnet, eg:
subnet 10.0.1.0 netmask 255.255.255.0 { }
Also, for DHCP you need a "host" route to 255.255.255.255.
route add -host 255.255.255.255 eth0 (I don't know how this is done when wanting multiple dhcp pools, add more of these host routes? Does the new linux kernel or v2 dhcp daemon have a fix for this? Anyone?)
Dave, can we "ifdef dhcp package" this route?
Did you move your LRP router in the last few minutes? Switches and some routers remember where certain MAC addresses are to make sure not to route packets to network parts where they're not needed. (When is the last time you wheeled an UPS connected Solaris machine to another building ? :)
Flush the arp cache (on Cisco's for example) or reset/reboot the device.
You are refusing access to port 20 (firewall rules) and need non-passive FTP to work. Use the ip_masquerade_ftp module or open up access to port 20 (from FTP server to remote high ports >1024)
Lots of things can be wrong. ethernet card not detected (use shift-pgup to check for errors that scrolled off) or your network settings aren't correct. Double check IP, gateway, netmask, interface, and if possible ask your provider to double check the info you got. Also, if using firewall rules, disable them to see if those are the cause with: ipfwadm -I -f ; ipfwadm -O -f. It's a good idea to alwyas use -o with firewall deny rules so they will always end up in your log file.
See also: WhatsNetMaskReally
Ayyy, get a recent LRP or linux kernel. Bridging has been broken in a few older ones, and has also been leaking memory live a sieve. Last reports I heard were just of failures to get bridging to work, can anyone give me a success report?
Try using a new LRP with the ppp 2.3.5 or up version. It has inbuilt dial on demand. Anyone has more info on this? success reports?
This is more a Windows Browsing or Samba question. SMB isn't really a routable protocol and you need special things to show up in other networks. See the Samba HOWTO, get the O'Reilly Samba book, or dive into the Microsoft Knowledge base. Look into WINS options.
Some hints that can save you: - You do have TCP/IP on your clients (No NETBUIE(sp?) can't be routed) - Try ticking the box 'netbios in tcp encapsulation' in the TCP/IP properties box. - Change the samba server announce (if using samba ofcourse) to explicitely announce itself to the remote NT master browser (See smb.conf) - If you just need users to map a drive from a remote subnet, use "find" to find the computer (yes this works even if network neighbourhood doesn't) or choose Start->Run and type \\ComputerName\ to get a window to the host. Then map the drive, and if this works add it to the logon script for your users. - If you rely on the lmhosts-file in C:\windows, make sure DNS is enabled on the Win95 computer or it won't be used. (Duh Microsoft) - Search by name or by ip doesn't work on win95, but it works on NT??? Unless you add an entry in your lmhosts file with the suffix #PRE (Jamie? What is the exact entry?, just "#PRE" ?)
Remember every subnet needs its OWN "master browser". If you don't have one in your LRP connected network, consider using Samba for it. It can be a WINS server.
Paul: Could someone using two subnets with Windows servers in both, using masquerading as well, send me a confirmation this works? :)
Uhm, did this one get answered? :) I personally like "CRT" from www.vandyke.com as telnet client. I like SecureCRT (SSH+telnet+r-commands) even better, but I can't buy it from them because I'm outside the US. Evaluation copies of SecureCRT can be downloaded from vandyke or from ftp.replay.com for non Us people. (Yes this is legal, replay.com is located in the Netherlands, so your not exporting crypto. the only questionable thing is how it got on replay.com)
Cool isn't it? Cable modem providing the entire household of Internet connectivity :) Btw. This is probably not allowed :)
You can. But be sure the dhcp package is based on the v2.x series of the ISC dhcp server package (www.ics.org). (the ones on the LRP ftp site should work by the time you read this FAQ entry)
Did you define two ranges for the networks on eth0 and eth1 in dhcpd.conf, and then made one range empty? For example if you would want to run dhcpd on eth0 and give out 192.168.1.[100-200] and eth0 is 192.168.1.1 furhter let's assume your cable ISP is giving you something in the range of 10.0.1.x, then you'd have these routes: route add -net 10.0.1.0 netmask 255.255.255.0 eth1 route add -net 192.168.10 netmask 255.255.255.0 eth0
And your dhcpd.conf would look like:
subnet 10.0.1.0 netmask 255.255.255.0 { } subnet 192.168.10 netmask 255.255.255.0 { range 192.168.1.100 192.168.1.200; default-lease-time 86400; max-lease-time 86400; option subnet-mask 255.255.255.0; option broadcast-address 192.168.1.255; option routers 192.168.1.1; option domain-name-servers 192.168.1.1; option domain-name "fake.org"; }
Alternatively, you can try and block packets getting in from eth1 that are destined for a dhcpd server. but this might get very tricky, because your dhcp client still has to see one.
Another, perhaps easier solution, is to add the start of the dhcpd daemon in the if-up line for your eth1 interface, so that only after it gets it's dhcp client IP number, you start dhcpd. But when your lease expires, you'll need to kill the dhcp daemon in your if-down script again, because you need to renew your lease. I am not sure if the dhcp client actually calls the up and down scripts (eg it might renew the lease without taking the interface down at all)
Another way I just thought of (isnt it nice to think while typing) is to drop all forwarding for 0.0.0.0 packets. You never need those to travel along the ethernet interfaces anyway. try:
ipfwadm -F -i deny -P udp -S0.0.0.0/32 67 -D0.0.0.0/32 68
(Note: 0.0.0.0/32 is NOT a typo for 0.0.0.0/0)
Packagewise, you need to do the following: 1). get recent dhcp* package 2) Install dhcpcd.lpr & dhcpd.lpr on the boot disk then & edit the syslinux.cfg to inc the new pakages then reboot this will get the paks installed but not working 3) delete all the rc?/S??dhcpcd links from the package since they force dhcpcd up after network.sh) then 4) ln -s /etc/init.d/dhcpcd /etc/rcS.d/S40dhcpcd # to load the interface 5) start-stop-daemon --start --quiet --exec /sbin/dhcpcd -- -I $clientname eth$ # in /etc/init.d/dhcpcd (must use -I option to set host name with @home or else no ip address handed out or different IP each time 6) route add -host 255.255.255.255 dev eth? # insert this into /etc/init.d/dhcpcd ...route to the isp dhcp svr 7) edit the var/lib/lrpkg/dhcpcd.list & remove refs to the /etc/rc?/S??dhcpcd add the ref to /etc/rcS.d/S40dhcpcd 8) edit /etc/init.d/dhcpd set the interface 9) run lrcfg & back it all up except the logs I added this to network.sh, to get eth interfaces defined for the standard lpr network script & some other stuff in /etc/dhcpd.conf (if running dhcpd w/o named) so that dhcp will hand out dns of my isp to my client stations
RESOLVECONF="/etc/resolv.conf DHCPDCONF="/etc/dhcpd.conf" DHCPCDIR="/etc/dhcpc" if test -d $DHCPCDDIR then for file in `ls $DHCPCDIR/*` do case "$file" in *.conf) # resolve conf. echo "Updating entries in resolv.conf/dhcp.conf" cat "$file" | while read resolvevars args do #echo $resolvevars $args do #echo $resolvevars $args case "$resolvevars" in \nameserver*|"") # ln $file $RESOLVCONF echo $resolvevars $args >> $RESOLVCONF ) ;; \domain*|"") #echo ;; esac done ;; ) *hostinfo-eth?) # eth definitions. IF=${file#*-eth} for dhcpvars in `cat "$file"` do #echo $dhcpvars case "$dhcpvars" in \IPADDR*|"") IPADDR0=${dhcpvars#*=};; \NETMASK*|"") NETMASK0=${dhcpvars#*=};; \BROADCAST*|"") BROADCAST0=${dhcpvars#*=};; \ROUTER*|"") GATEWAY=${dhcpvars#*=};; esac done case $IF in "0") IF0=${file#*-} IPADDR0=$IPADDR; NETMASK0=$NETMASK BROADCAST0=$BROADCAST; NETWORK0=${BROADCAST%.*}.0 ) ;; "1") IF1=${file#*-} IPADDR1=$IPADDR; NETMASK1=$NETMASK BROADCAST1=$BROADCAST; NETWORK1=${BROADCAST%.*}.0 ) ;; esac ) ;; esac done fi
According to Cyclades, versions 2.1.1.4 through 2.1.1.7 of their boards all had problems that resulted in these symptoms. Basically, the first 4 ports on a machine would exhibit these problems. It doesn't happen to all external modems. Microcom ISPorte/Compaq series 4000 quad modems apparently had this problem, but K56flex didn't (But this could have been related to being on the first 4 ports?)
LRP has been reported to work very well even when the ramdisk has totally filled up. You might try to reduce the used diskspace of the ramdisk (and thus memory usage) by either logging less (turn of debug options), logging to a remote host (see RemoteLogging) or by running a cron job to purge logs once in a while (see /etc/cron*)
If you do crash your box, there might be a memory leak within the kernel code. this has happened to people using bridging code (ironically when nothing was being bridged for long times) on old versions of LRP/linux. You can also use Solar Designers' memleak detection patch to hunt down the problem, but it requires you to roll your own LRP kernel.
If using portslave, you can disable wtmp logging by addinhg a + i the inittab entry for portslave, eg:
T0:23:respawn:+/usr/sbin/portslave 0
pppd can reestablish a connection by itself with the "persist" option. To make sure that the chat doesn't fail, you can make a chatscript like:
while : do chat -v ABORT "NO CARRIER"\ ""\ ATZ OK\ "ATE0" CONNECT\ && exit 0 sleep 10 done
A worse hack is to restart pppd every 5 minutes from cron, because it will (loudly) conplain but not interfer with a working connection. (do this only as a last ditch/emergency solution)
also see the lcp options to tune the link
Add the most used lcp/ppp options with descriptions here.
Ipfwadm is used to set up, maintain, and inspect the IP firewall and accounting rules in the Linux kernel. These rules can be divided into 4 different categories: account- ing of IP packets, the IP input firewall, the IP output firewall, and the IP forwarding firewall. For each of these categories, a separate list of rules is maintained.
F is for forwarding. It tells the kernel if it is allowed to toss packets from one of its interfaces to other interfaces.
I is for the input firewall. It is a list of rules the kernel applies to all packets it receives from other machines.
O is for the output firewall. It is a list of rules the kernel applies to all packets it will send to other machines.
A is for accounting. It is used to gather statistics on usage per IP number/port
Examples:
ipfwadm -F -i masq -S192.168.1.0/24 -D0.0.0.0/0 -Wppp0
(Forward all traffic for the Internet over ppp0 and masquerade the IP
numbers using NAT)
ipfwadm -I -i deny -S0.0.0.0/0 -D 0.0.0.0/0 137 -P all
(deny all incoming packets that have destination port number 137, for all
protocols (udp and tcp). This is used to block windows sharing.
ipfwadm -O -i deny -S192.168.1.0/24 -D0.0.0.0/0 -o
(deny all packets with original 192.168.1.*, which are reserved for internal
use and should never be sent (nor received) from the "outside"). This is
usually a "catch-all" rule to prevent any private IP numbers to leak out when
they accidently bypass NAT due to some other configuration problem)
For more information on routing, firewalling and masquerading, please see various networ HOWTO's, Linux books, or magazines like LinuxJournal. Two links to papers paul@xtdnet.nl has written (one ofr LJ) are: http://www.linuxjournal.org/XXXX YAPBL (yes another paul's broken link ;)