This PPP section is intended for the use of a MANUAL PPP connection for both:
Dial-On-Demand style PPP connections are documented in TrinityOS in the Section 23 - DialD section. Though recent versions of PPPd versions support Dial-On-Demand functionality, it hasn't been as flexible as Diald but this is no longer the case. The newest versions of PPPd support full filtering of interesting/non-interesting packets to keep the line down or up. Because of this, I would recommend to simply just use PPPd instead of Diald. Though I need to expand this section, here are a few pro/con sections:
Anyway, regardless of your PPP use, you have a PPP enabled kernel running. This is fully described in Section 12
-----
Notes for people thinkink of using Multi-Link PPP (ML/PPP) for multiple connections to the same remote site:
As of 01/22/00, the ML/PPP code is moving quite well. Some are patches to PPPd while others are not. Most patches are only for 2.2.x kernels and have issues. Here is an email I receive about one user's view:
-- From Charles @ chas@pcscs.com >This link: http://mp.mansol.net.au/ > is not available as of the time of this mailing. > > It does, however, have functional mods for kernels 2.2.13 and 2.2.14. I > have worked with the 2.2.13 kernel and have been pleased with the > functionality, but I would say that the code is not ready for production > machines as there are still latency issues as well as overhead issues with > 3 or more links in a bundle- at least from my observations. With 3 lines, > the latency was jumping from 150ms to 750ms. With 2 lines, the latency > was smoother with ranges of 150ms to 300ms, but rarely perfect. > > There are also > fault tolerance issues with automated link resets and bundling. If one > maintains the individual links manually, however, this is a functional > solution, but by no means an installation which you can walk away from for > long periods of time and guarantee fault tolerance. Novell's NIAS is still > the best I have seen in these regards as it meets the demands if high load > in both large and small packet fills. > > For Linux, Chris Pascoe's code is by far the most evolved code I have seen. > He shows great promise of mature code in a relatively short period of time. > He has also shown integration with the ppp daemon and ppp kernel > architecture to be an effective way for doing asynchronous analog and > synchronous adapter-based MLPPP. There are rumors and controversy with > regards to modifying Linux PPP's architecture altogether to streamline > features of MLPPP, asynchronous analog and synchronous PPP links for better > uniformity. In my opinion, however, Chris' technique is going to be more > compatible for hardware functionality than an architectural PPP rebuild > that reduces feature modularity in its design. > > As far as the final production stuff: > If you want performance, you are going to need features such as data and/or > VJ header compression for PPP packets. I haven't seen Linux code support that > yet. I also haven't seen Linux code handle link bundling perfectly yet. > Links seem to add well and some links can even go down, but there are still > issues with the 1st link going down causing the whole bundle to need to be > reset via killall pppd. These refinements, I'm sure, will be last on the > "TO DO" list and will probably be quite some time before they are properly > implemented, nevertheless, Linux does in fact now support MLPPP. >>I also haven't seen Linux code handle link bundling perfectly yet. >>Links seem to add well and some links can even go down, but there are >>still issues with the 1st link going down causing the whole bundle to need to >>be reset via killall pppd. These refinements, I'm sure, will be last on >>the "TO DO" list and will probably be quite some time before they are >>properly implemented, nevertheless, Linux does in fact now support MLPPP. -----
Anyway, for you Normal PPP users, here is the TrinityOS setup.
/etc/ppp/chat.your-ppp-isp
-- ABORT BUSY ABORT 'NO CARRIER' "" ATZ OK ATM0S11=40 OK ATDT5551212 CONNECT "" --
Fix its permissions: chmod 600 /etc/ppp/chat.your-ppp-isp
-- /etc/ppp/pap-secrets * your-ppp-login your-ppp-password --
Fix its permissions: chmod 600 /etc/ppp/pap-secrets
/etc/ppp/options
-- # MTU settings will greatly effect your performance, please read up # on calculating MTU settings from my PPP web page. # <url url="http://www.ecst.csuchico.edu/~dranch/PPP/ppp-performance.html#mtu"> # # This setup is optimized for file transfers and NOT for interactive # traffic like telnet, talk, etc # # 14.4k modem users: 296 # 28.8/33.6k modem users: 470 # IP Masq users (regardless of speed): 1500 # Masq users: If you get a lot of "MASQ: failed TCP/UDP checksum for # xxx.xxx.xxx.xxx" errors, turn off VJ header compression # by do the following: # # -vj #pppd v2.3.x PAP config require-pap #Get a dynamic IP address. If you have a static IP addres, put # the static IP address in the LEFT hand address space 0.0.0.0:0.0.0.0 asyncmap 0 lock #Use Hardware flow control crtscts #BSDComp is a more modern compression method than "deflate" bsdcomp 15,15 lcp-restart 1 ipcp-restart 1 defaultroute #Enable these for debugging #debug #kdebug 1 user your-ppp-login --
Fix its permissions: chmod 600 /etc/ppp/options
/usr/local/sbin/startppp
-- #!/bin/sh # # Version: 07/03/00 # # Part of the copyrighted and trademarked TrinityOS document. # <url url="http://www.ecst.csuchico.edu/~dranch"> # # Written and Maintained by David A. Ranch # dranch at trinnet dot net # # NOTE: This configuration assumes that your modem is on COM2 # echo Killing any stray PPPD processes killall pppd killall chat echo Beginning PPP negotiation.. #Replace /dev/ttyS1 with your modem's COMM port. Remember, always start #counting with "0". Also, make SURE that the paths for pppd/chat are #in /usr/sbin. If not, change this command line to use the correct path #Old pppd v2.2.x format #New pppd v2.3.x format /usr/sbin/pppd /dev/ttyS1 38400 crtscts -d lock defaultroute connect '/usr/sbin/chat -v -t 45 -f /etc/ppp/chat.your-ppp-isp' & --
Fix its permissions: chmod 700 /usr/local/sbin/startppp
/usr/lib/ppp/stopppp
-- #!/bin/sh # # Version: 07/03/00 # # Part of the copyrighted and trademarked TrinityOS document. # <url url="http://www.ecst.csuchico.edu/~dranch"> # # Written and Maintained by David A. Ranch # dranch at trinnet dot net # # NOTE: This configuration assumes that your modem is on COM2 # echo Shutting down PPP # #Replace /dev/ttyS1 with your modem's COMM port.. remember, always start #counting with "0". Also.. make SURE that the paths for pppd/chat are #in /usr/sbin. If not, change this command line to use the correct path /usr/lib/ppp/pppd /dev/ttyS1 disconnect echo Killing any stray PPPD processes killall chat killall pppd --
Fix its permissions: chmod 700 /usr/local/sbin/stopppp
If you are using the strong firewall rule sets (IPCHAINS/IPFWADM), you will need to re-run your firewall rule set everytime you get your dynamic IP address. To do this:
- Edit or create the file called /etc/ppp/ip-up and in it put:
--
#!/bin/sh
/etc/rc.d/rc.firewall
#OPTIONAL: Its nice to be able to update your system
# clock when on-line. To do this, add these
# lines, un # them out, and then follow the
# instructions in TrinityOS <ref id="sect-26" name="Section 26">
#
# /usr/local/bin/getdate
--
- now fix the permissions on it:
chmod 700 /etc/ppp/ip-up
That's IT!
Backup PPP links: If you are like me, you either have a locked up ADSL or Cablemodem connection to the Internet. Well, from time to time, your connection will go down for various reasons and you'll be SOL for Internet access.
What can you do? Setup a backup PPP link! Currently, the config shown below will need to be invoked MANUALLY. It is my plan that once I received my ISDN line, I will develop an AUTOMATIC dial-backup configuration based upon a series of connectivity criteria that will be put into the Diald section of TrinityOS.
NOTE: This rule set is OLD and isn't nearly are secure as the new IPCHAINS rule set found in sect-10 . I hope to either port a version of the strong IPCHAINS rule set here soon or make the master rule set adapt to changing environments.
NOTE: When your primary link goes down, your old /etc/rc.firewall rule set will NOT let you out (changed external IP address). So, you need to enter in the following files to bring-up and bring-down a temporary firewall.
/etc/ppp/ip-up
-- #!/bin/sh echo "Starting /etc/ppp/ip-up" # ----------------------------------------------------------------------------------- # NOTE: This short firewall script is for IPFWADM (2.0.x kernels) to only allow # SSH, DNS, and NTP in or out of the PPP0 connection. If you need additional # connectivity, go ahead and add them in. # #Specification of the LOOPBACK interface loopback="127.0.0.1" #Specification of the INTERNAL NIC intif="eth1" #The IP address on your INTERNAL nic intip="192.168.0.1" #IP network address of the INTERNAL net intnet="192.168.0.0" #IP address of an internal host that should have IPPORTFW forward traffic to portfwip="192.168.0.20" #Specification of the EXTERNAL NIC # # PPP Users: If you are using the Dynamic PPP "extif" script from above, # make sure to comment the below line out so it doesn't override it. # # If you want to use the PPPd variables, change this to read: # extif="$1" # extif="ppp0" #The IP address you get from the Internet # # PPP users: If you are getting dynamic address, either use the "extip" script # from the header above or if you want to use the PPPd variables, # change this to read: # extip="$3" # extip="100.200.0.212" # The IP broadcast address of the external net # # PPP users: If you are getting dynamic address, use the PPPd variables. # Change "extbroad" to read (this make an assuption but it should # be a safe assumption): # extbroad=`echo $4 | cut -d '.' -f 1-3`.255 # extbroad="100.200.0.255" #IP address of the default gateway on the EXTERNAL NIC # # PPP users: If you are getting dynamic address, use the PPPd variables. # Change "dgw" to read: # dgw=$4 # dgw="100.200.0.1" #IP Mask for ALL IP addresses universe="0.0.0.0" #IP Mask for BROADCAST broadcast="255.255.255.255" #Specification of HIGH IP ports # NOTE: Notice that this STARTS at 1024 and NOT at 1023 which it should. # for some reason SSH sometimes initiates connections at 1023 which # is a TCP violation but shit happens. # # Brief update: This is due to SSH not being executed with "-P" # unprivports="1024:65535" #Specification of backup DNS server secondarydns="102.200.0.25" #Specifically allowed external host - secure1.host.com securehost="200.211.0.40" # ----------------------------------------------------------------------------------- echo "Change default route to PPP" /sbin/route add default gw $dgw echo "Enabling IP Forwarding.." echo "1" > /proc/sys/net/ipv4/ip_forward echo "Changing IP MASQ Timeouts.." # 2 hrs timeout for TCP session timeouts # 10 sec timeout for traffic after the TCP/IP "FIN" packet is received # 60 sec timeout for UDP traffic (MASQ'ed ICQ users must enable a 30sec # firewall timeout in ICQ itself) /sbin/ipfwadm -M -s 7200 10 60 #Flush all old rule sets echo "Flushing old poicies" /sbin/ipfwadm -I -f /sbin/ipfwadm -O -f /sbin/ipfwadm -F -f #Change default policies echo "Setting default policies to REJECT" /sbin/ipfwadm -I -p reject /sbin/ipfwadm -O -p reject /sbin/ipfwadm -F -p reject echo "Allow SSH DNS through the PPP0 interface" /sbin/ipfwadm -I -i accept -W $extif -P tcp -S $universe/0 -D $extip/32 ssh domain ntp /sbin/ipfwadm -I -i accept -W $extif -P udp -S $universe/0 -D $extip/32 domain echo "Allow ICMP through the PPP0 interface" /sbin/ipfwadm -I -i accept -W $extif -P icmp -S $universe/0 -D $extip/32 echo "Allowing SSH, DOMAIN, and ICMP out" /sbin/ipfwadm -O -i accept -W $extif -P tcp -S $extip/32 $unprivports -D $universe/0 ssh domain ntp /sbin/ipfwadm -O -i accept -W $extif -P udp -S $extip/32 $unprivports -D $universe/0 domain /sbin/ipfwadm -O -i accept -W $extif -P icmp -S $extip/32 -D $universe/0 echo "Masquerade from local net on local interface to anywhere." /sbin/ipfwadm -F -a masquerade -W $extif -S $intnet/24 -D $universe/0 echo "Logging all failed connections" /sbin/ipfwadm -I -a reject -S $universe/0 -D $universe/0 -o /sbin/ipfwadm -O -a reject -S $universe/0 -D $universe/0 -o /sbin/ipfwadm -F -a reject -S $universe/0 -D $universe/0 -o echo "Temporary PPP0 firewall and MASQ Done. --
/etc/ppp/ip-down
--
#!/bin/sh
# Re-run the master firewall rule set to reset the firewall back to the primary
# interface.
/etc/rc.d/rc.firewall
# /sbin/route add default gw 24.1.83.1
LOGDEVICE=$6
REALDEVICE=$1
[ -x /etc/ppp/ip-down.local ] && /etc/ppp/ip-down.local $*
/etc/sysconfig/network-scripts/ifdown-post ifcfg-${LOGDEVICE}
exit 0
--
Jun 6 21:12:18 server chat[499]: Can't get terminal parameters: Input/output error Jun 6 21:12:18 server pppd[498]: Connect script failed
Redhat: /etc/rc.d/init.d/pcmcia start
--
from: Donald Spoon" <marsala@txdirect.net>
The Microsoft web-site, and Stroud's Consummate Winlist web-site would
literally take MINUTES to load! I had others that exhibited similar
behavior, mainly in the *.mil domain, but most sites would load
fairly quickly as expected. I played around with the MTU / MRU settings and
found an "optimum" set-up for me that helped a great deal, but the
"selective" delay in loading certain web sites remained. One day I noticed
that when I had brought the PPP link up MANUALLY the
affected web-sites loaded normally!!
I did one more review of your notes and applied the
suggestions for re-setting lcp-restart = 1, and ipcp-restart = 1 (from
defaults of 3 in the /etc/ppp/options file!. This change alone did the
trick for me!
--