From c28a628740d261ab8fc279435cce7a42a2b46386 Mon Sep 17 00:00:00 2001 From: Mark Ovens Date: Tue, 26 Sep 2000 19:22:40 +0000 Subject: [PATCH] Re-formatted the mark-up in chapters 9, 10, & 11 to conform to the FDP. Translation Teams can ignore this, these are a whitespace changes only --- en_US.ISO8859-1/books/faq/book.sgml | 3350 +++++++++++++++----------- en_US.ISO_8859-1/books/faq/book.sgml | 3350 +++++++++++++++----------- 2 files changed, 3898 insertions(+), 2802 deletions(-) diff --git a/en_US.ISO8859-1/books/faq/book.sgml b/en_US.ISO8859-1/books/faq/book.sgml index 2dd9a30208..7956369953 100644 --- a/en_US.ISO8859-1/books/faq/book.sgml +++ b/en_US.ISO8859-1/books/faq/book.sgml @@ -15,7 +15,7 @@ - $FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.103 2000/09/26 12:40:11 marko Exp $ + $FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.104 2000/09/26 16:26:15 marko Exp $ This is the FAQ for FreeBSD versions 2.X, 3.X, and 4.X. @@ -7316,255 +7316,352 @@ Key F15 A A Menu Workplace Nop - -Networking - - - -Where can I get information on diskless booting? - -Diskless booting means that the FreeBSD box is booted over a -network, and reads the necessary files from a server instead of -its hard disk. For full details, please read -the Handbook entry on diskless booting - - - - - Can a FreeBSD box be used as a dedicated network router? - - -Internet standards and good engineering practice prohibit us from -providing packet forwarding by default in FreeBSD. You can -however enable this feature by changing the following variable to -YES in rc.conf: - -gateway_enable=YES # Set to YES if this host will be a gateway - -This option will put the sysctl variable -net.inet.ip.forwarding to 1. - -In most cases, you will also need to run a routing process to -tell other systems on your network about your router; FreeBSD -comes with the standard BSD routing daemon -routed, or for more complex situations you may want to try -GaTeD (available from http://www.gated.org/ ) which -supports FreeBSD as of 3_5Alpha7. - -It is our duty to warn you that, even when FreeBSD is configured -in this way, it does not completely comply with the Internet -standard requirements for routers; however, it comes close enough -for ordinary usage. - - - - -Can I connect my Win95 box to the Internet via FreeBSD? - -Typically, people who ask this question have two PC's at home, one -with FreeBSD and one with Win95; the idea is to use the FreeBSD -box to connect to the Internet and then be able to access the -Internet from the Windows95 box through the FreeBSD box. This -is really just a special case of the previous question. - ... and the answer is yes! In FreeBSD 3.x, user-mode ppp contains a - option. If you run ppp with -the , set gateway_enable to -YES in /etc/rc.conf, and -configure your Windows machine correctly, this should work -fine. - -More detailed information about setting this up can be found in -the Pedantic PPP -Primer by Steve Sims. - -If you are using kernel-mode ppp, or have an Ethernet connection -to the Internet, you will have to use natd. Please -look at the natd section of this FAQ. - - - - - Why does recompiling the latest BIND from ISC fail? - - -There is a conflict between the cdefs.h file in the -distribution and the one shipped with FreeBSD. Just remove -compat/include/sys/cdefs.h. - - - - -Does FreeBSD support SLIP and PPP? - -Yes. See the man pages for -slattach, sliplogin, -pppd and -ppp. -pppd and ppp provide support for both incoming and outgoing -connections. Sliplogin deals exclusively with incoming connections and -slattach deals exclusively with outgoing connections. - -These programs are described in the following sections of the -handbook: - - - - - -Handbook entry on SLIP (server side) - - - - -Handbook entry on SLIP (client side) - - - - -Handbook entry on PPP (kernel version) - - - - -Handbook entry on PPP (user-mode version) - - - - - -If you only have access to the Internet through a shell -account, you may want to have a look at the slirp -package. It can provide you with (limited) access to services -such as ftp and http direct from your local machine. - - - - - Does FreeBSD support NAT or Masquerading - - -If you have a local subnet (one or more local machines), but have -been allocated only a single IP number from your Internet provider -(or even if you receive a dynamic IP number), you may want to look at -the natd -program. natd allows you to connect an entire subnet to the -internet using only a single IP number. - -The ppp program has similar functionality built in via -the switch. The alias library -is used in both cases. - - - - - -I can't create a /dev/ed0 device! - -In the Berkeley networking framework, network interfaces are only -directly accessible by kernel code. Please see the -/etc/rc.network file and the manual pages for the various -network programs mentioned there for more information. If this -leaves you totally confused, then you should pick up a book -describing network administration on another BSD-related -operating system; with few significant exceptions, administering -networking on FreeBSD is basically the same as on SunOS 4.0 or -Ultrix. - - - - -How can I setup Ethernet aliases? - -Add netmask 0xffffffff to your ifconfig -command-line like the following: - -&prompt.root; ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff - - - - -How do I get my 3C503 to use the other network port? - -If you want to use the other ports, you'll have to specify an -additional parameter on the -ifconfig command line. The -default port is link0. To use the AUI port instead of -the BNC one, use link2. These flags should be specified -using the ifconfig_* variables in /etc/rc.conf. - - - - -I'm having problems with NFS to/from FreeBSD. - -Certain PC network cards are better than others (to put it -mildly) and can sometimes cause problems with network intensive -applications like NFS. - -See the Handbook entry on NFS -for more information on this topic. - - - - -Why can't I NFS-mount from a Linux box? - -Some versions of the Linux NFS code only accept mount requests -from a privileged port; try - -&prompt.root; mount -o -P linuxbox:/blah /mnt - - - - -Why can't I NFS-mount from a Sun box? - -Sun workstations running SunOS 4.X only accept mount requests -from a privileged port; try - -&prompt.root; mount -o -P sunbox:/blah /mnt - - - - -I'm having problems talking PPP to NeXTStep machines. - -Try disabling the TCP extensions in /etc/rc.conf by -changing the following variable to NO: - -tcp_extensions=NO - -Xylogic's Annex boxes are also broken in this regard and you must -use the above change to connect thru them. - - - - -How do I enable IP multicast support? - -Multicast host operations are fully supported in FreeBSD 2.0 and -later by default. If you want your box to run as a multicast router, -you will need to recompile your kernel with the MROUTING -option and run mrouted. FreeBSD 2.2 and later will start -mrouted at boot time if the flag mrouted_enable is set -to "YES" in /etc/rc.conf. - -MBONE tools are available in their own ports category, mbone. If -you are looking for the conference tools vic and -vat, -look there! - -For more information, see the -Mbone Information Web. - - - - -Which network cards are based on the DEC PCI chipset? - -Here is a list compiled by Glen Foster, with some more modern additions: + + Networking + + + + + Where can I get information on + diskless booting? + + + + Diskless booting means that the FreeBSD + box is booted over a network, and reads the necessary files + from a server instead of its hard disk. For full details, + please read the + Handbook entry on diskless booting + + + + + + + Can a FreeBSD box be used as a dedicated network + router? + + + + Internet standards and good engineering practice prohibit + us from providing packet forwarding by default in FreeBSD. You + can however enable this feature by changing the following + variable to YES in + rc.conf: + + gateway_enable=YES # Set to YES if this host will be a gateway + + This option will put the + sysctl variable + net.inet.ip.forwarding + to 1. + + In most cases, you will also need to run a routing process + to tell other systems on your network about your router; + FreeBSD comes with the standard BSD routing daemon routed, + or for more complex situations you may want to try + GaTeD (available from http://www.gated.org/ ) + which supports FreeBSD as of 3_5Alpha7. + + It is our duty to warn you that, even when FreeBSD is + configured in this way, it does not completely comply with + the Internet standard requirements for routers; however, + it comes close enough for ordinary usage. + + + + + + + Can I connect my Win95 box to the Internet via + FreeBSD? + + + + Typically, people who ask this question have two PC's + at home, one with FreeBSD and one with Win95; the idea is to + use the FreeBSD box to connect to the Internet and then be able + to access the Internet from the Windows95 box through the + FreeBSD box. This is really just a special case of the previous + question. ... and the answer is yes! In FreeBSD + 3.x, user-mode ppp contains a option. If + you run ppp with the , + set gateway_enable to + YES in /etc/rc.conf, + and configure your Windows machine correctly, this should work + fine. + + More detailed information about setting this up can be + found in the + Pedantic PPP Primer by Steve Sims. + + If you are using kernel-mode ppp, or have an Ethernet + connection to the Internet, you will have to use + natd. Please look at the + natd section of this FAQ. + + + + + + + Why does recompiling the latest BIND from ISC fail? + + + + There is a conflict between the + cdefs.h file in the distribution and the + one shipped with FreeBSD. Just remove + compat/include/sys/cdefs.h. + + + + + + + Does FreeBSD support SLIP and PPP? + + + + Yes. See the man pages for + slattach, + sliplogin, pppd and + ppp. + pppd and ppp provide + support for both incoming and outgoing connections. + Sliplogin deals exclusively with incoming connections + and + slattach deals exclusively with outgoing + connections. + + These programs are described in the following sections of + the handbook: + + + + + Handbook entry + on SLIP (server side) + + + + + Handbook entry + on SLIP (client side) + + + + Handbook entry on + PPP (kernel version) + + + + + Handbook entry on PPP (user-mode version) + + + + If you only have access to the Internet through a + shell account, you may want to have a look at + the + slirp package. It can provide you with (limited) + access to services such as ftp and http direct from your local + machine. + + + + + + + Does FreeBSD support NAT or Masquerading + + + + If you have a local subnet (one or more local machines), + but have been allocated only a single IP number from your + Internet provider (or even if you receive a dynamic IP number), + you may want to look at the natd + program. natd allows you to connect an + entire subnet to the internet using only a single IP + number. + + The + ppp program has similar functionality built in via + the switch. The + alias library is used in both cases. + + + + + + + I can't create a /dev/ed0 + device! + + + + + In the Berkeley networking framework, network interfaces + are only directly accessible by kernel code. Please see the + /etc/rc.network file and the manual pages + for the various network programs mentioned there for more + information. If this leaves you totally confused, then you + should pick up a book describing network administration on + another BSD-related operating system; with few significant + exceptions, administering networking on FreeBSD is basically + the same as on SunOS 4.0 or Ultrix. + + + + + + + How can I setup Ethernet aliases? + + + Add netmask 0xffffffff to your + ifconfig command-line like the following: + + &prompt.root; ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff + + + + + + + How do I get my 3C503 to use the other network + port? + + + + If you want to use the other ports, you'll have to specify + an additional parameter on the + ifconfig command line. The default port is + link0. To use the AUI port instead of the + BNC one, use link2. These flags should be + specified using the ifconfig_* variables in + /etc/rc.conf. + + + + + + + I'm having problems with NFS to/from FreeBSD. + + + + Certain PC network cards are better than others (to put + it mildly) and can sometimes cause problems with network + intensive applications like NFS. + + See + the Handbook entry on NFS for more information on + this topic. + + + + + + + Why can't I NFS-mount from a Linux box? + + + + Some versions of the Linux NFS code only accept mount + requests from a privileged port; try + + &prompt.root; mount -o -P linuxbox:/blah /mnt + + + + + + + Why can't I NFS-mount from a Sun box? + + + + Sun workstations running SunOS 4.X only accept mount + requests from a privileged port; try + + &prompt.root; mount -o -P sunbox:/blah /mnt + + + + + + + I'm having problems talking PPP to NeXTStep + machines. + + + + + Try disabling the TCP extensions in + /etc/rc.conf by changing the following variable to + NO: + + tcp_extensions=NO + + Xylogic's Annex boxes are also broken in this regard and + you must use the above change to connect thru them. + + + + + + + How do I enable IP multicast support? + + + + Multicast host operations are fully supported in FreeBSD + 2.0 and later by default. If you want your box to run as a + multicast router, you will need to recompile your kernel with + the MROUTING option and run + mrouted. FreeBSD 2.2 and later will start + mrouted at boot time if the flag + mrouted_enable is set to + "YES" in + /etc/rc.conf. + + MBONE tools are available in their own ports category, + mbone. If you are looking for the conference tools + vic and vat, + look there! + + For more information, see the + Mbone Information Web. + + + + + + + Which network cards are based on the DEC PCI + chipset? + + + Here is a list compiled by Glen Foster, + with some more modern additions: Vendor Model ---------------------------------------------- @@ -7584,789 +7681,1005 @@ SMC EtherPower (Model 8432) TopWare TE-3500P Znyx (2.2.x) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348 (3.x) ZX345Q, ZX346Q, ZX348Q, ZX412Q, ZX414, ZX442, - ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd) + ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd) + - + + - -Why do I have to use the FQDN for hosts on my site? + + + Why do I have to use the FQDN for hosts on my + site? + -You will probably find that the host is actually in a different -domain; for example, if you are in foo.bar.edu and you wish to reach -a host called mumble in the bar.edu domain, you will have to -refer to it by the fully-qualified domain name, mumble.bar.edu, -instead of just mumble. + + You will probably find that the host is actually in a + different domain; for example, if you are in foo.bar.edu and + you wish to reach a host called mumble in the + bar.edu domain, you will + have to refer to it by the fully-qualified domain name, mumble.bar.edu, instead of just + mumble. -Traditionally, this was allowed by BSD BIND resolvers. However -the current version of bind that ships -with FreeBSD no longer provides default abbreviations for non-fully -qualified domain names other than the domain you are in. -So an unqualified host mumble must either be found -as mumble.foo.bar.edu, or it will be searched for -in the root domain. + Traditionally, this was allowed by BSD BIND resolvers. + However the current version of bind + that ships with FreeBSD no longer provides default + abbreviations for non-fully qualified domain names other than + the domain you are in. So an unqualified host + mumble must either be found as mumble.foo.bar.edu, or it will be searched + for in the root domain. -This is different from the previous behavior, where the -search continued across mumble.bar.edu, and -mumble.edu. Have a look at RFC 1535 for why this -was considered bad practice, or even a security hole. + This is different from the previous behavior, where the + search continued across + mumble.bar.edu, and + mumble.edu. Have a look at + RFC 1535 for why this was considered bad practice, or even a + security hole. -As a good workaround, you can place the line + As a good workaround, you can place the line -search foo.bar.edu bar.edu + search foo.bar.edu bar.edu -instead of the previous + instead of the previous -domain foo.bar.edu + domain foo.bar.edu -into your /etc/resolv.conf file. However, make sure that the search order -does not go beyond the boundary between local and public -administration, as RFC 1535 calls it. + into your + /etc/resolv.conf file. However, make sure that the + search order does not go beyond the boundary between + local and public administration, as RFC 1535 calls + it. - + + - -Permission denied for all networking operations. + + + Permission denied for all networking + operations. + -If you have compiled your kernel with the IPFIREWALL -option, you need to be aware that the default policy as of -2.1.7R (this actually changed during 2.1-STABLE development) -is to deny all packets that are not explicitly allowed. + + If you have compiled your kernel with the + IPFIREWALL option, you need to be aware + that the default policy as of 2.1.7R (this actually changed + during 2.1-STABLE development) is to deny all packets that are + not explicitly allowed. -If you had unintentionally misconfigured your system for -firewalling, you can restore network operability by typing -the following while logged in as root: + If you had unintentionally misconfigured your system for + firewalling, you can restore network operability by typing + the following while logged in as root: -&prompt.root; ipfw add 65534 allow all from any to any + &prompt.root; ipfw add 65534 allow all from any to any -You can also set firewall_type="open" in /etc/rc.conf. + You can also set firewall_type="open" + in /etc/rc.conf. -For further information on configuring a FreeBSD firewall, -see the Handbook section. + For further information on configuring a FreeBSD firewall, + see the + Handbook section. - + + - -How much overhead does IPFW incur? + + + How much overhead does IPFW incur? + -The answer to this depends mostly on your rule set and processor -speed. For most applications dealing with ethernet and small -rule sets, the answer is, negligible. For those of you that need -actual measurements to satisfy your curiosity, read on. + + The answer to this depends mostly on your rule set and + processor speed. For most applications dealing with ethernet + and small rule sets, the answer is, negligible. For those of + you that need actual measurements to satisfy your curiosity, + read on. -The following measurements were made using 2.2.5-STABLE on -a 486-66. IPFW was modified to measure the time spent within -the ip_fw_chk routine, displaying the results to the console -every 1000 packets. + The following measurements were made using 2.2.5-STABLE + on a 486-66. IPFW was modified to measure the time spent + within the ip_fw_chk routine, displaying + the results to the console every 1000 packets. -Two rule sets, each with 1000 rules were tested. The first set -was designed to demonstrate a worst case scenario by repeating the -rule: + Two rule sets, each with 1000 rules were tested. The + first set was designed to demonstrate a worst case scenario + by repeating the rule: -&prompt.root; ipfw add deny tcp from any to any 55555 + &prompt.root; ipfw add deny tcp from any to any 55555 -This demonstrates worst case by causing most of IPFW's packet -check routine to be executed before finally deciding that the -packet does not match the rule (by virtue of the port number). -Following the 999th iteration of this rule was an allow ip -from any to any. + This demonstrates worst case by causing most of IPFW's + packet check routine to be executed before finally deciding + that the packet does not match the rule (by virtue of the port + number). Following the 999th iteration of this rule was an + allow ip from any to any. -The second set of rules were designed to abort the rule -check quickly: + The second set of rules were designed to abort the rule + check quickly: -&prompt.root; ipfw add deny ip from 1.2.3.4 to 1.2.3.4 + &prompt.root; ipfw add deny ip from 1.2.3.4 to 1.2.3.4 -The nonmatching source IP address for the above rule causes -these rules to be skipped very quickly. As before, the 1000th -rule was an allow ip from any to any. + The nonmatching source IP address for the above rule causes + these rules to be skipped very quickly. As before, the 1000th + rule was an allow ip from any to any. -The per-packet processing overhead in the former case was -approximately 2.703ms/packet, or roughly 2.7 microseconds per -rule. Thus the theoretical packet processing limit with these -rules is around 370 packets per second. Assuming 10Mbps ethernet -and a ~1500 byte packet size, we would only be able to achieve a -55.5% bandwidth utilization. + The per-packet processing overhead in the former case was + approximately 2.703ms/packet, or roughly 2.7 microseconds per + rule. Thus the theoretical packet processing limit with these + rules is around 370 packets per second. Assuming 10Mbps + ethernet and a ~1500 byte packet size, we would only be able to + achieve a 55.5% bandwidth utilization. -For the latter case each packet was processed in -approximately 1.172ms, or roughly 1.2 microseconds per rule. -The theoretical packet processing limit here would be about -853 packets per second, which could consume 10Mbps ethernet -bandwidth. + For the latter case each packet was processed in + approximately 1.172ms, or roughly 1.2 microseconds per rule. + The theoretical packet processing limit here would be about + 853 packets per second, which could consume 10Mbps ethernet + bandwidth. -The excessive number of rules tested and the nature of those -rules do not provide a real-world scenario -- they were used only -to generate the timing information presented here. Here are a -few things to keep in mind when building an efficient rule set: + The excessive number of rules tested and the nature of + those rules do not provide a real-world scenario -- they were + used only to generate the timing information presented here. + Here are a few things to keep in mind when building an + efficient rule set: - - + + + + Place an established rule early + on to handle the majority of TCP traffic. Don't put any + allow tcp statements before this + rule. + - -Place an established rule early on to handle the -majority of TCP traffic. Don't put any allow tcp -statements before this rule. - - + + Place heavily triggered rules earlier in the rule + set than those rarely used (without + changing the permissiveness of the firewall, + of course). You can see which rules are used most often + by examining the packet counting statistics with + ipfw -a l. + + - -Place heavily triggered rules earlier in the rule -set than those rarely used (without changing the -permissiveness of the firewall, of course). You can see -which rules are used most often by examining the packet counting -statistics with ipfw -a l. - - + + - - + + + How can I redirect service requests from one machine to + another? + - + + You can redirect FTP (and other service) request with + the socket package, available in the ports + tree in category sysutils. Simply replace the + service's commandline to call socket instead, like so: - -How can I redirect service requests from one machine to another? - + ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp -You can redirect FTP (and other service) request with the socket -package, available in the ports tree in category sysutils. -Simply replace the service's commandline to call socket instead, like so: + where ftp.foo.com and + ftp are the host and port to + redirect to, respectively. -ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp + + -where ftp.foo.com and ftp are the host and port to redirect to, -respectively. + + + Where can I get a bandwidth management tool? + - + + There are two bandwidth management tools available for + FreeBSD. + ALTQ is available for free; Bandwidth Manager from + Emerging Technologies + is a commercial product. - -Where can I get a bandwidth management tool? + + -There are two bandwidth management tools available for FreeBSD. -ALTQ is available for free; Bandwidth Manager from -Emerging Technologies is -a commercial product. + + + Why do I get /dev/bpf0: device not + configured? + - + + The Berkeley Packet Filter (bpf) + driver needs to be enabled before running programs that + utilize it. Add this to your kernel config file and build + a new kernel: - -Why do I get /dev/bpf0: device not configured? + pseudo-device bpfilter # Berkeley Packet Filter -The Berkeley Packet Filter (bpf) driver -needs to be enabled before running programs that utilize it. -Add this to your kernel config file and build a new kernel: + Secondly, after rebooting you will have to create the + device node. This can be accomplished by a change to the + /dev directory, followed by the execution + of: -pseudo-device bpfilter # Berkeley Packet Filter + &prompt.root; sh MAKEDEV bpf0 -Secondly, after rebooting you will have to create the device -node. This can be accomplished by a change to the /dev -directory, followed by the execution of: + Please see the + handbook's entry on device nodes for more information + on creating devices. -&prompt.root; sh MAKEDEV bpf0 + + -Please see the handbook's entry on device nodes for more information -on creating devices. + + + How do I mount a disk from a Windows machine that's on my + network, like smbmount in Linux? + - + + Use the + sharity light package in the ports collection. - - - How do I mount a disk from a Windows machine that's on my - network, like smbmount in Linux? - - - Use the sharity - light package in the ports collection. - - - - + + + + - -PPP - - - I can't make ppp work. What am I doing wrong ? - + + PPP -You should first read the ppp man page and -the ppp section of the handbook. Enable logging with the command + + + + I can't make ppp work. What am I doing wrong ? + -set log Phase Chat Connect Carrier lcp ipcp ccp command + + You should first read the + ppp man page and the + ppp section of the handbook. Enable logging with + the command -This command may be typed at the ppp command prompt or -it may be entered in the /etc/ppp/ppp.conf configuration file -(the start of the default section is the best place to put it). -Make sure that /etc/syslog.conf contains the lines + set log Phase Chat Connect Carrier lcp ipcp ccp command -!ppp + This command may be typed at the + ppp command prompt or it may be + entered in the /etc/ppp/ppp.conf + configuration file (the start of the + default section is the best + place to put it). Make sure that + /etc/syslog.conf contains the lines + + !ppp *.* /var/log/ppp.log -and that the file /var/log/ppp.log exists. You can -now find out a lot about what's going on from the log file. -Don't worry if it doesn't all make sense. If you need to -get help from someone, it may make sense to them. + and that the file /var/log/ppp.log + exists. You can now find out a lot about what's going on + from the log file. Don't worry if it doesn't all make sense. + If you need to get help from someone, it may make sense to + them. -If your version of ppp doesn't understand the set log -command, you should download the -latest version. -It will build on FreeBSD version 2.1.5 and higher. - - + If your version of ppp doesn't understand the + set log command, you should download the + + latest version. It will build on FreeBSD version + 2.1.5 and higher. + + - -Ppp just hangs when I run it + + + Ppp just hangs when I run it + -This is usually because your hostname won't resolve. The best -way to fix this is to make sure that /etc/hosts is -consoluted by your resolver first by editing /etc/host.conf -and putting the hosts line first. Then, simply put an -entry in /etc/hosts for your local machine. If you have -no local network, change your localhost line: + + This is usually because your hostname won't resolve. + The best way to fix this is to make sure that + /etc/hosts is consoluted by your + resolver first by editing /etc/host.conf + and putting the hosts line first. Then, + simply put an entry in /etc/hosts for + your local machine. If you have no local network, change your + localhost line: -127.0.0.1 foo.bar.com foo localhost + 127.0.0.1 foo.bar.com foo localhost -Otherwise, simply add another entry for your host. Consult the -relevant man pages for more details. + Otherwise, simply add another entry for your host. + Consult the relevant man pages for more details. -You should be able to successfully ping -c1 `hostname` -when you're done. + You should be able to successfully + ping -c1 `hostname` when you're done. - + + - -Ppp won't dial in -auto mode + + + Ppp won't dial in -auto mode + -First, check that you've got a default route. By running -netstat -rn, -you should see two entries like this: + + First, check that you've got a default route. By running + + netstat -rn, you should see two entries like this: -Destination Gateway Flags Refs Use Netif Expire + Destination Gateway Flags Refs Use Netif Expire default 10.0.0.2 UGSc 0 0 tun0 10.0.0.2 10.0.0.1 UH 0 0 tun0 -This is assuming that you've used the addresses from the -handbook, the man page or from the ppp.conf.sample file. -If you haven't got a default route, it may be because you're -running an old version of ppp that doesn't understand the -word HISADDR in the ppp.conf file. If your version of -ppp is from before FreeBSD 2.2.5, change the + This is assuming that you've used the addresses from the + handbook, the man page or from the ppp.conf.sample file. + If you haven't got a default route, it may be because you're + running an old version of ppp + that doesn't understand the word HISADDR + in the ppp.conf file. If your version of + ppp is from before FreeBSD + 2.2.5, change the -add 0 0 HISADDR + add 0 0 HISADDR -line to one saying + line to one saying -add 0 0 10.0.0.2 + add 0 0 10.0.0.2 -Another reason for the default route line being missing is that -you have mistakenly set up a default router in your -/etc/rc.conf file (this file was called -/etc/sysconfig prior to release 2.2.2), and you have -omitted the line saying + Another reason for the default route line being missing + is that you have mistakenly set up a default router in your + + /etc/rc.conf file (this file was called + /etc/sysconfig prior to release 2.2.2), + and you have omitted the line saying -delete ALL + delete ALL -from ppp.conf. If this is the case, go back to the -Final system configuration section of the handbook. + from ppp.conf. If this is the case, + go back to the + Final system configuration section of the + handbook. - + + - -What does No route to host mean + + + What does No route to host mean + -This error is usually due to a missing + + This error is usually due to a missing -MYADDR: + MYADDR: delete ALL add 0 0 HISADDR -section in your /etc/ppp/ppp.linkup file. This is -only necessary if you have a dynamic IP address or don't know the -address of your gateway. If you're using interactive mode, you can -type the following after entering packet mode (packet mode is -indicated by the capitalized PPP in the prompt): + section in your /etc/ppp/ppp.linkup + file. This is only necessary if you have a dynamic IP address + or don't know the address of your gateway. If you're using + interactive mode, you can type the following after entering + packet mode (packet mode is + indicated by the capitalized PPP in the + prompt): -delete ALL + delete ALL add 0 0 HISADDR -Refer to the PPP and Dynamic IP addresses section of the handbook -for further details. + Refer to the + PPP and Dynamic IP addresses section of the handbook + for further details. - + + - -My connection drops after about 3 minutes + + + My connection drops after about 3 minutes + -The default ppp timeout is 3 minutes. This can be adjusted -with the line + + The default ppp timeout is 3 minutes. This can be + adjusted with the line -set timeout NNN + set timeout NNN -where NNN is the number of seconds of inactivity before the -connection is closed. If NNN is zero, the connection is -never closed due to a timeout. It is possible to put this command in -the ppp.conf file, or to type it at the prompt in -interactive mode. It is also possible to adjust it on the fly while -the line is active by connecting to ppps server socket using -telnet -or pppctl. Refer to the -ppp man -page for further details. + where NNN is the number of + seconds of inactivity before the connection is closed. If + NNN is zero, the connection is never + closed due to a timeout. It is possible to put this command in + the ppp.conf file, or to type it at the + prompt in interactive mode. It is also possible to adjust it on + the fly while the line is active by connecting to ppps server socket using telnet + or pppctl. + Refer to the ppp man + page for further details. - + + - -My connection drops under heavy load + + + My connection drops under heavy load + -If you have Link Quality Reporting (LQR) configured, it is -possible that too many LQR packets are lost between your -machine and the peer. Ppp deduces that the line must therefore -be bad, and disconnects. Prior to FreeBSD version 2.2.5, -LQR was enabled by default. It is now disabled by default. -LQR can be disabled with the line + + If you have Link Quality Reporting (LQR) configured, + it is possible that too many LQR packets are lost between + your machine and the peer. Ppp deduces that the line must + therefore be bad, and disconnects. Prior to FreeBSD version + 2.2.5, LQR was enabled by default. It is now disabled by + default. LQR can be disabled with the line -disable lqr + disable lqr - + + - -My connection drops after a random amount of time + + + My connection drops after a random amount of time + -Sometimes, on a noisy phone line or even on a line with -call waiting enabled, your modem may hang up because it -thinks (incorrectly) that it lost carrier. + + Sometimes, on a noisy phone line or even on a line with + call waiting enabled, your modem may hang up because it + thinks (incorrectly) that it lost carrier. -There's a setting on most modems for determining how tolerant -it should be to temporary losses of carrier. On a USR -Sportster for example, this is measured by the S10 register in -tenths of a second. To make your modem more forgiving, you could -add the following send-expect sequence to your dial string: + There's a setting on most modems for determining how + tolerant it should be to temporary losses of carrier. On a + USR Sportster for example, this is measured by the S10 + register in tenths of a second. To make your modem more + forgiving, you could add the following send-expect sequence + to your dial string: -set dial "...... ATS10=10 OK ......" + set dial "...... ATS10=10 OK ......" -Refer to your modem manual for details. + Refer to your modem manual for details. - + + - -My connection hangs after a random amount of time + + + My connection hangs after a random amount of time + -Many people experience hung connections with no apparent -explaination. The first thing to establish is which side of the -link is hung. + Many people experience hung connections with no apparent + explaination. The first thing to establish is which side of + the link is hung. -If you are using an external modem, you can simply try using -ping to see if the TD light is flashing when you -transmit data. If it flashes (and the RD light doesn't), the -problem is with the remote end. If TD doesn't flash, the problem -is local. With an internal modem, you'll need to use the set -server command in your ppp.conf file. When the hang occurs, -connect to ppp using pppctl. If your network connection suddenly -revives (ppp was revived due to the activity on the diagnostic socket) -or if you can't connect (assuming the set socket command -succeeded at startup time), the problem is local. If you can connect -and things are still hung, enable local async logging with set log -local async and use ping from another window or terminal to make -use of the link. The async logging will show you the data being -transmitted and received on the link. If data is going out and not -coming back, the problem is remote. + If you are using an external modem, you can simply try + using ping to see if the + TD light is flashing when you transmit data. + If it flashes (and the RD light doesn't), + the problem is with the remote end. If TD + doesn't flash, the problem is local. With an internal modem, + you'll need to use the set server command in + your ppp.conf file. When the hang occurs, + connect to ppp using pppctl. If your network connection + suddenly revives (ppp was revived due to the activity on the + diagnostic socket) or if you can't connect (assuming the + set socket command succeeded at startup + time), the problem is local. If you can connect and things are + still hung, enable local async logging with set log + local async and use ping from + another window or terminal to make use of the link. The async + logging will show you the data being transmitted and received + on the link. If data is going out and not coming back, the + problem is remote. -Having established whether the problem is local or remote, -you now have two possibilities: - - + Having established whether the problem is local or remote, + you now have two possibilities: + + - -The remote end isn't responding + + + The remote end isn't responding + -There's very little you can do about this. Most ISPs will -refuse to help if you're not running a Microsoft OS. You can -enable lqr in your ppp.conf file, allowing ppp to -detect the remote failure and hang up, but this detection is -relatively slow and therefore not that useful. You may want -to avoid telling your ISP that you're running user-ppp.... + + There's very little you can do about this. Most ISPs + will refuse to help if you're not running a Microsoft OS. + You can enable lqr in your + ppp.conf file, allowing ppp to detect + the remote failure and hang up, but this detection is + relatively slow and therefore not that useful. You may want to + avoid telling your ISP that you're running user-ppp.... -First, try disabling all local compression by adding the -following to your configuration: + First, try disabling all local compression by adding the + following to your configuration: -disable pred1 deflate deflate24 protocomp acfcomp shortseq vj + disable pred1 deflate deflate24 protocomp acfcomp shortseq vj deny pred1 deflate deflate24 protocomp acfcomp shortseq vj -Then reconnect to ensure that this makes no difference. -If things improve or if the problem is solved completely, -determine which setting makes the difference through trial -and error. This will provide good amunition when you contact -your ISP (although it may make it apparent that you're not -running a Microsoft product). + Then reconnect to ensure that this makes no difference. + If things improve or if the problem is solved completely, + determine which setting makes the difference through trial + and error. This will provide good amunition when you contact + your ISP (although it may make it apparent that you're not + running a Microsoft product). -Before contacting your ISP, enable async logging locally -and wait until the connection hangs again. This may use up -quite a bit of disk space. The last data read from the port -may be of interest. It is usually ascii data, and may even -describe the problem (Memory fault, core dumped ?). + Before contacting your ISP, enable async logging locally + and wait until the connection hangs again. This may use up + quite a bit of disk space. The last data read from the port + may be of interest. It is usually ascii data, and may even + describe the problem + (Memory fault, core dumped ?). -If your ISP is helpful, they should be able to enable logging -on their end, then when the next link drop occurs, they may be -able to tell you why their side is having a problem. Feel free -to send the details to &a.brian;, or even to ask your ISP to -contact me directly. + If your ISP is helpful, they should be able to enable + logging on their end, then when the next link drop occurs, + they may be able to tell you why their side is having a + problem. Feel free to send the details to &a.brian;, or + even to ask your ISP to contact me directly. - + + - -Ppp is hung + + + Ppp is hung + -Your best bet here is to rebuild ppp by adding CFLAGS+=-g -and STRIP= to the end of the Makefile, then doing a -make clean && make && make install. When -ppp hangs, find the ppp process id with ps ajxww | fgrep ppp -and run gdb ppp PID. From the gdb prompt, you can then use -bt to get a stack trace. + + Your best bet here is to rebuild ppp by adding + CFLAGS+=-g and STRIP= + to the end of the Makefile, then doing a + make clean && make && make + install. When ppp hangs, find the ppp process id + with ps ajxww | fgrep ppp and run + gdb ppp PID. + From the gdb prompt, you can then use bt + to get a stack trace. -Send the results to brian@Awfulhak.org. + Send the results to brian@Awfulhak.org. - + + - -Nothing happens after the Login OK! message + + + Nothing happens after the Login OK! message + -Prior to FreeBSD version 2.2.5, once the link was established, -ppp would wait for the peer to initiate the Line Control -Protocol (LCP). Many ISPs will not initiate negotiations and -expect the client to do so. To force ppp to initiate -the LCP, use the following line: + + Prior to FreeBSD version 2.2.5, once the link was + established, ppp + would wait for the peer to initiate the Line Control Protocol + (LCP). Many ISPs will not initiate negotiations and expect + the client to do so. To force + ppp to initiate the LCP, use the + following line: -set openmode active + set openmode active -Note: It usually does no harm if both sides initiate -negotiation, so openmode is now active by default. However, -the next section explains when it does do some harm. + Note: It usually does no + harm if both sides initiate negotiation, so openmode is now + active by default. However, the next section explains when + it does do some harm. - + + - -I keep seeing errors about magic being the same + + + I keep seeing errors about magic being the same + -Occasionally, just after connecting, you may see messages in -the log that say magic is the same. Sometimes, these -messages are harmless, and sometimes one side or the other -exits. Most ppp implementations cannot survive this problem, and -even if the link seems to come up, you'll see repeated configure -requests and configure acknowledgements in the log file until -ppp eventually gives up and closes the connection. + + Occasionally, just after connecting, you may see messages + in the log that say magic is the same. + Sometimes, these messages are harmless, and sometimes one side + or the other exits. Most ppp implementations cannot survive + this problem, and even if the link seems to come up, you'll see + repeated configure requests and configure acknowledgements in + the log file until ppp eventually gives up and closes the + connection. -This normally happens on server machines with slow disks that -are spawning a getty on the port, and executing ppp from a -login script or program after login. I've also heard reports -of it happening consistently when using slirp. The reason is -that in the time taken between getty exiting and ppp starting, the -client-side ppp starts sending Line Control Protocol (LCP) -packets. Because ECHO is still switched on for the port on -the server, the client ppp sees these packets reflect back. + This normally happens on server machines with slow disks + that are spawning a getty on the port, and executing ppp from + a login script or program after login. I've also heard reports + of it happening consistently when using slirp. The reason is + that in the time taken between getty exiting and ppp starting, + the client-side ppp starts sending Line Control Protocol (LCP) + packets. Because ECHO is still switched on for the port on + the server, the client ppp sees these packets + reflect back. -One part of the LCP negotiation is to establish a magic number -for each side of the link so that reflections can be detected. -The protocol says that when the peer tries to negotiate -the same magic number, a NAK should be sent and a new magic -number should be chosen. During the period that the server -port has ECHO turned on, the client ppp sends LCP packets, -sees the same magic in the reflected packet and NAKs it. It -also sees the NAK reflect (which also means ppp must change -its magic). This produces a potentially enormous number of -magic number changes, all of which are happily piling into -the server's tty buffer. As soon as ppp starts on the server, -it's flooded with magic number changes and almost immediately -decides it's tried enough to negotiate LCP and gives up. -Meanwhile, the client, who no longer sees the reflections, -becomes happy just in time to see a hangup from the server. + One part of the LCP negotiation is to establish a magic + number for each side of the link so that + reflections can be detected. The protocol says + that when the peer tries to negotiate the same magic number, a + NAK should be sent and a new magic number should be chosen. + During the period that the server port has ECHO turned on, the + client ppp sends LCP packets, sees the same magic in the + reflected packet and NAKs it. It also sees the NAK reflect + (which also means ppp must change its magic). This produces a + potentially enormous number of magic number changes, all of + which are happily piling into the server's tty buffer. As soon + as ppp starts on the server, it's flooded with magic number + changes and almost immediately decides it's tried enough to + negotiate LCP and gives up. Meanwhile, the client, who no + longer sees the reflections, becomes happy just in time to see + a hangup from the server. -This can be avoided by allowing the peer to start negotiating -with the following line in your ppp.conf file: + This can be avoided by allowing the peer to start + negotiating with the following line in your ppp.conf + file: -set openmode passive + set openmode passive -This tells ppp to wait for the server to initiate LCP -negotiations. Some servers however may never initiate negotiations. -If this is the case, you can do something like: + This tells ppp to wait for the server to initiate LCP + negotiations. Some servers however may never initiate + negotiations. If this is the case, you can do something + like: -set openmode active 3 + set openmode active 3 -This tells ppp to be passive for 3 seconds, and then to start -sending LCP requests. If the peer starts sending requests during -this period, ppp will immediately respond rather than waiting for -the full 3 second period. + This tells ppp to be passive for 3 seconds, and then to + start sending LCP requests. If the peer starts sending + requests during this period, ppp will immediately respond + rather than waiting for the full 3 second period. - + + - - LCP negotiations continue 'till the connection is closed - + + + LCP negotiations continue 'till the connection is + closed + -There is currently an implementation mis-feature in ppp -where it doesn't associate LCP, CCP & IPCP responses with -their original requests. As a result, if one ppp -implementation is more than 6 seconds slower than the other side, -the other side will send two additional LCP configuration requests. -This is fatal. + + There is currently an implementation mis-feature in + ppp where it doesn't associate + LCP, CCP & IPCP responses with their original requests. As + a result, if one ppp + implementation is more than 6 seconds slower than the other + side, the other side will send two additional LCP configuration + requests. This is fatal. -Consider two implementations, A and B. A starts -sending LCP requests immediately after connecting and B takes -7 seconds to start. When B starts, A has sent 3 LCP -REQs. We're assuming the line has ECHO switched off, otherwise -we'd see magic number problems as described in the previous section. -B sends a REQ, then an ACK to the first of A's REQs. -This results in A entering the OPENED state and sending -and ACK (the first) back to B. In the meantime, B sends -back two more ACKs in response to the two additional REQs sent by -A before B started up. B then receives the first -ACK from A and enters the OPENED state. A receives -the second ACK from B and goes back to the REQ-SENT state, -sending another (forth) REQ as per the RFC. It then receives the -third ACK and enters the OPENED state. In the meantime, -B receives the forth REQ from A, resulting in it reverting -to the ACK-SENT state and sending another (second) REQ and -(forth) ACK as per the RFC. A gets the REQ, goes into -REQ-SENT and sends another REQ. It immediately receives the -following ACK and enters OPENED. + Consider two implementations, + A and B. A starts + sending LCP requests immediately after connecting and B takes 7 seconds to start. When B starts, A + has sent 3 LCP REQs. We're assuming the line has ECHO switched + off, otherwise we'd see magic number problems as described in + the previous section. B sends a + REQ, then an ACK to the first of A's REQs. This results in A entering the OPENED + state and sending and ACK (the first) back to B. In the meantime, B sends back two more ACKs in response to + the two additional REQs sent by A + before B started up. B then receives the first ACK from + A and enters the + OPENED state. A receives the second ACK from B and goes back to the REQ-SENT state, sending another (forth) REQ + as per the RFC. It then receives the third ACK and enters the + OPENED state. In the meantime, B receives the forth REQ from A, resulting in it reverting to the + ACK-SENT state and sending + another (second) REQ and (forth) ACK as per the RFC. A gets the REQ, goes into REQ-SENT and sends another REQ. It + immediately receives the following ACK and enters + OPENED. -This goes on 'till one side figures out that they're getting -nowhere and gives up. + This goes on 'till one side figures out that they're + getting nowhere and gives up. -The best way to avoid this is to configure one side to be -passive - that is, make one side wait for the other to start -negotiating. This can be done with the + The best way to avoid this is to configure one side to be + passive - that is, make one side + wait for the other to start negotiating. This can be done + with the -set openmode passive + set openmode passive -command. Care should be taken with this option. You should also -use the + command. Care should be taken with this option. You + should also use the -set stopped N + set stopped N -command to limit the amount of time that ppp waits for the peer -to begin negotiations. Alternatively, the + command to limit the amount of time that + ppp waits for the peer to begin + negotiations. Alternatively, the -set openmode active N + set openmode active N -command (where N is the number of seconds to wait before -starting negotiations) can be used. Check the manual page for -details. + command (where N is the + number of seconds to wait before starting negotiations) can be + used. Check the manual page for details. - + + - -Ppp locks up shortly after connecting + + + Ppp locks up shortly after connecting + -Prior to version 2.2.5 of FreeBSD, it was possible that your -link was disabled shortly after connection due to ppp -mis-handling Predictor1 compression negotiation. This would -only happen if both sides tried to negotiate different -Compression Control Protocols (CCP). This problem is now -corrected, but if you're still running an old version of -ppp, the problem can be circumvented with the line + + Prior to version 2.2.5 of FreeBSD, it was possible that + your link was disabled shortly after connection due to + ppp mis-handling Predictor1 + compression negotiation. This would only happen if both sides + tried to negotiate different Compression Control Protocols + (CCP). This problem is now corrected, but if you're still + running an old version of ppp, + the problem can be circumvented with the line -disable pred1 + disable pred1 - + + - -Ppp locks up when I shell out to test it + + + Ppp locks up when I shell out to test it + -When you execute the shell or ! command, -ppp -executes a shell (or if you've passed any arguements, ppp -will execute those arguements). Ppp will wait for the command -to complete before continuing. If you attempt to use the -ppp link while running the command, the link will appear to have -frozen. This is because ppp is waiting for the command -to complete. + + When you execute the shell or + ! command, ppp executes a + shell (or if you've passed any arguements, + ppp will execute those arguements). Ppp will + wait for the command to complete before continuing. If you + attempt to use the ppp link while running the command, the link + will appear to have frozen. This is because + ppp is waiting for the command to + complete. -If you wish to execute commands like this, use the -!bg command instead. This will execute the given command -in the background, and ppp can continue to service the link. + If you wish to execute commands like this, use the + !bg command instead. This will execute + the given command in the background, and ppp can continue to + service the link. - + + - -Ppp over a null-modem cable never exits + + + Ppp over a null-modem cable never exits + -There is no way for ppp to automatically determine that -a direct connection has been dropped. This is due to the -lines that are used in a null-modem serial cable. When using -this sort of connection, LQR should always be enabled with -the line + + There is no way for ppp to + automatically determine that a direct connection has been + dropped. This is due to the lines that are used in a + null-modem serial cable. When using this sort of connection, + LQR should always be enabled with the line -enable lqr + enable lqr -LQR is accepted by default if negotiated by the peer. + LQR is accepted by default if negotiated by the peer. - + + - -Why does ppp dial for no reason in -auto mode + + + Why does ppp dial for no reason in -auto mode + -If ppp is dialing unexpectedly, you must determine the -cause, and set up Dial filters (dfilters) to prevent such dialing. + If ppp is dialing + unexpectedly, you must determine the cause, and set up Dial + filters (dfilters) to prevent such dialing. -To determine the cause, use the following line: + To determine the cause, use the following line: -set log +tcp/ip + set log +tcp/ip -This will log all traffic through the connection. The next -time the line comes up unexpectedly, you will see the reason -logged with a convenient timestamp next to it. + This will log all traffic through the connection. The + next time the line comes up unexpectedly, you will see the + reason logged with a convenient timestamp next to it. -You can now disable dialing under these circumstances. Usually, -this sort of problem arises due to DNS lookups. To prevent -DNS lookups from establishing a connection (this will not -prevent ppp from passing the packets through an established -connection), use the following: + You can now disable dialing under these circumstances. + Usually, this sort of problem arises due to DNS lookups. To + prevent DNS lookups from establishing a connection (this will + not prevent + ppp from passing the packets + through an established connection), use the following: -set dfilter 1 deny udp src eq 53 + set dfilter 1 deny udp src eq 53 set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0 -This is not always suitable, as it will effectively break your -demand-dial capabilities - most programs will need a DNS lookup -before doing any other network related things. + This is not always suitable, as it will effectively break + your demand-dial capabilities - most programs will need a DNS + lookup before doing any other network related things. -In the DNS case, you should try to determine what is actually -trying to resolve a host name. A lot of the time, -sendmail is the culprit. You should make sure that you tell -sendmail not to do any DNS lookups in its configuration file. See -the section on Mail Configuration for -details on how to create your own configuration file and what should -go into it. You may also want to add the following line to your -.mc file: + In the DNS case, you should try to determine what is + actually trying to resolve a host name. A lot of the time, + + sendmail is the culprit. You should make sure that + you tell sendmail not to do any DNS lookups in its + configuration file. See the section on + Mail Configuration for details + on how to create your own configuration file and what should + go into it. You may also want to add the following line to + your .mc file: -define(`confDELIVERY_MODE', `d')dnl + define(`confDELIVERY_MODE', `d')dnl -This will make sendmail queue everything until the queue is -run (usually, sendmail is invoked with , telling it -to run the queue every 30 minutes) or until a sendmail -q -is done (perhaps from your ppp.linkup file). + This will make sendmail queue everything until the queue + is run (usually, sendmail is invoked with + , telling it to run the queue every + 30 minutes) or until a sendmail -q is done + (perhaps from your ppp.linkup file). - + + - -What do these CCP errors mean + + + What do these CCP errors mean + -I keep seeing the following errors in my log file: + + I keep seeing the following errors in my log file: -CCP: CcpSendConfigReq + CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) -This is because ppp is trying to negotiate Predictor1 -compression, and the peer does not want to negotiate any -compression at all. The messages are harmless, but if you -wish to remove them, you can disable Predictor1 compression -locally too: + This is because ppp is trying to negotiate Predictor1 + compression, and the peer does not want to negotiate any + compression at all. The messages are harmless, but if you + wish to remove them, you can disable Predictor1 compression + locally too: -disable pred1 + disable pred1 - + + - -Ppp locks up during file transfers with IO errors + + + Ppp locks up during file transfers with IO errors + -Under FreeBSD 2.2.2 and before, there was a bug in the tun -driver that prevents incoming packets of a size larger than -the tun interface's MTU size. Receipt of a packet greater than -the MTU size results in an IO error being logged via syslogd. + + Under FreeBSD 2.2.2 and before, there was a bug in the + tun driver that prevents incoming packets of a size larger + than the tun interface's MTU size. Receipt of a packet + greater than the MTU size results in an IO error being logged + via syslogd. -The ppp specification says that an MRU of 1500 should -always be accepted as a minimum, despite any LCP -negotiations, therefore it is possible that should you decrease -the MTU to less than 1500, your ISP will transmit packets of -1500 regardless, and you will tickle this non-feature - locking -up your link. + The ppp specification says that an MRU of 1500 should + always be accepted as a minimum, + despite any LCP negotiations, therefore it is possible that + should you decrease the MTU to less than 1500, your ISP will + transmit packets of 1500 regardless, and you will tickle this + non-feature - locking up your link. -The problem can be circumvented by never setting an MTU of -less than 1500 under FreeBSD 2.2.2 or before. + The problem can be circumvented by never setting an MTU of + less than 1500 under FreeBSD 2.2.2 or before. - + + - -Why doesn't ppp log my connection speed? + + + Why doesn't ppp log my connection speed? + -In order to log all lines of your modem conversation, -you must enable the following: + -set log +connect + In order to log all lines of your modem + conversation, you must enable the + following: -This will make -ppp -log everything up until the last requested expect string. + set log +connect -If you wish to see your connect speed and are using PAP or CHAP -(and therefore don't have anything to chat after the CONNECT -in the dial script - no set login script), you must make sure that -you instruct ppp to expect the whole CONNECT line, something like -this: + This will make ppp log + everything up until the last requested expect + string. -set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \ + If you wish to see your connect speed and are using PAP + or CHAP (and therefore don't have anything to + chat after the CONNECT in the dial script - no + set login script), you must make sure that + you instruct ppp to expect the whole CONNECT + line, something like this: + + set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \ \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" -Here, we get our CONNECT, send nothing, then expect a line-feed, -forcing ppp to read the whole CONNECT response. + Here, we get our CONNECT, send nothing, then expect a + line-feed, forcing ppp to read + the whole CONNECT response. - + + - -Ppp ignores the \ character in my chat script + + + Ppp ignores the \ character in my + chat script + -Ppp parses each line in your config files so that it can -interpret strings such as set phone "123 456 789" correctly -(and realize that the number is actually only one argument. -In order to specify a " character, you must escape it using -a backslash (\). + Ppp parses each line in your config files so that it can + interpret strings such as + set phone "123 456 789" correctly (and + realize that the number is actually only + one argument. In order to specify + a " character, you must escape it using a + backslash (\). -When the chat interpreter parses each argument, it re-interprets -the argument in order to find any special escape sequences such -as \P or \T (see the man page). As a result of this -double-parsing, you must remember to use the correct number of -escapes. + When the chat interpreter parses each argument, it + re-interprets the argument in order to find any special + escape sequences such as \P or + \T (see the man page). As a result of this + double-parsing, you must remember to use the correct number of + escapes. -If you wish to actually send a \ character to (say) your -modem, you'd need something like: + If you wish to actually send a \ + character to (say) your modem, you'd need something + like: -set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" + set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" -resulting in the following sequence: + resulting in the following sequence: -ATZ + ATZ OK AT\X OK -or + or -set phone 1234567 + set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" -resulting in the following sequence: + resulting in the following sequence: -ATZ + ATZ OK ATDT1234567 - + + - -Ppp gets a seg-fault, but I see no ppp.core file + + + Ppp gets a seg-fault, but I see no + ppp.core file + -Ppp (or any other program for that matter) should never -dump core. Because ppp runs with an effective user id of 0, -the operating system will not write ppps core image to disk -before terminating it. If, however ppp is actually -termating due to a segmentation violation or some other -signal that normally causes core to be dumped, and you're -sure you're using the latest version (see the start of this -section), then you should do the following: + + Ppp (or any other program for that matter) should never + dump core. Because ppp runs with an effective user id of 0, + the operating system will not write ppps core image to disk + before terminating it. If, however ppp + is actually termating due to a + segmentation violation or some other signal that normally + causes core to be dumped, and + you're sure you're using the latest version (see the start of + this section), then you should do the following: -&prompt.user; tar xfz ppp-*.src.tar.gz + &prompt.user; tar xfz ppp-*.src.tar.gz &prompt.user; cd ppp*/ppp &prompt.user; echo STRIP= >>Makefile &prompt.user; echo CFLAGS+=-g >>Makefile @@ -8375,16 +8688,16 @@ section), then you should do the following: &prompt.root; make install &prompt.root; chmod 555 /usr/sbin/ppp -You will now have a debuggable version of ppp installed. You -will have to be root to run ppp as all of its privileges have -been revoked. When you start ppp, take a careful note of what -your current directory was at the time. + You will now have a debuggable version of ppp installed. + You will have to be root to run ppp as all of its privileges + have been revoked. When you start ppp, take a careful note + of what your current directory was at the time. -Now, if and when ppp receives the segmentation violation, it -will dump a core file called ppp.core. You should then do the -following: + Now, if and when ppp receives the segmentation violation, + it will dump a core file called ppp.core. You should then do + the following: -&prompt.user; su + &prompt.user; su &prompt.root; gdb /usr/sbin/ppp ppp.core (gdb) bt ..... @@ -8395,812 +8708,1047 @@ following: (gdb) l ..... -All of this information should be given alongside your -question, making it possible to diagnose the problem. + All of this information should be given alongside your + question, making it possible to diagnose the problem. -If you're familiar with gdb, you may wish to find out some -other bits and pieces such as what actually caused the dump and -the addresses & values of the relevant variables. + If you're familiar with gdb, you may wish to find out some + other bits and pieces such as what actually caused the dump and + the addresses & values of the relevant variables. - + + - - The process that forces a dial in auto mode never connects - + + + The process that forces a dial in auto mode never + connects + -This was a known problem with ppp set up to negotiate -a dynamic local IP number with the peer in auto mode. It is -fixed in the latest version - search the man page for iface. + + This was a known problem with + ppp set up to negotiate a + dynamic local IP number with the peer in auto mode. It is + fixed in the latest version - search the man page for + iface. -The problem was that when that initial program calls -connect(2), the IP number of the tun interface is -assigned to the socket endpoint. The kernel creates the first -outgoing packet and writes it to the tun device. Ppp then -reads the packet and establishes a connection. If, as a result -of ppps dynamic IP assignment, the interface address is changed, -the original socket endpoint will be invalid. Any subsequent -packets sent to the peer will usually be dropped. Even if -they aren't, any responses will not route back to the originating -machine as the IP number is no longer owned by that machine. + The problem was that when that initial program calls + + connect(2), the IP number of the tun interface is + assigned to the socket endpoint. The kernel creates the first + outgoing packet and writes it to the tun device. Ppp then reads the packet and establishes a + connection. If, as a result of ppps dynamic IP assignment, the interface + address is changed, the original socket endpoint will be + invalid. Any subsequent packets sent to the peer will usually + be dropped. Even if they aren't, any responses will not route + back to the originating machine as the IP number is no longer + owned by that machine. -There are several theoretical ways to approach this problem. -It would be nicest if the peer would re-assign the same IP number -if possible :-) The current version of ppp does this, -but most other implementations don't. + There are several theoretical ways to approach this + problem. It would be nicest if the peer would re-assign the + same IP number if possible :-) + The current version of ppp does + this, but most other implementations don't. -The easiest method from our side would be to never change the -tun interface IP number, but instead to change all outgoing packets -so that the source IP number is changed from the interface IP to -the negotiated IP on the fly. This is essentially what the -iface-alias option in the latest version of ppp is -doing (with the help of libalias(3) -and ppp's switch) - it's maintaining all previous -interface addresses and NATing them to the last negotiated address. + The easiest method from our side would be to never change + the tun interface IP number, but instead to change all outgoing + packets so that the source IP number is changed from the + interface IP to the negotiated IP on the fly. This is + essentially what the iface-alias option in + the latest version of ppp is + doing (with the help of + libalias(3) and ppp's switch) - + it's maintaining all previous interface addresses and NATing + them to the last negotiated address. -Another alternative (and probably the most reliable) would be -to implement a system call that changes all bound sockets from one -IP to another. Ppp would use this call to modify the -sockets of all existing programs when a new IP number is -negotiated. The same system call could be used by dhcp clients -when they are forced to re-bind() their sockets. + Another alternative (and probably the most reliable) would + be to implement a system call that changes all bound sockets + from one IP to another. Ppp would + use this call to modify the sockets of all existing programs + when a new IP number is negotiated. The same system call could + be used by dhcp clients when they are forced to re-bind() their + sockets. -Yet another possibility is to allow an interface to be brought -up without an IP number. Outgoing packets would be given -an IP number of 255.255.255.255 up until the first SIOCAIFADDR -ioctl is done. This would result in fully binding the socket. It -would be up to ppp to change the source IP number, but only if -it's set to 255.255.255.255, and only the IP number and IP checksum -would need to change. This, however is a bit of a hack as -the kernel would be sending bad packets to an improperly -configured interface, on the assumption that some other mechanism -is capable of fixing things retrospectively. + Yet another possibility is to allow an interface to be + brought up without an IP number. Outgoing packets would be + given an IP number of 255.255.255.255 up until the first + SIOCAIFADDR ioctl is done. This would result in fully binding + the socket. It would be up to ppp + to change the source IP number, but only if it's set to + 255.255.255.255, and only the IP number and IP checksum would + need to change. This, however is a bit of a hack as the kernel + would be sending bad packets to an improperly configured + interface, on the assumption that some other mechanism is + capable of fixing things retrospectively. - + + - -Why don't most games work with the -nat switch + + + Why don't most games work with the -nat switch + -The reason games and the like don't work when libalias is -in use is that the machine on the outside will try to open a -connection or send (unsolicited) UDP packets to the machine -on the inside. The NAT software doesn't know that -it should send these packets to the interior machine. + + The reason games and the like don't work when libalias + is in use is that the machine on the outside will try to open a + connection or send (unsolicited) UDP packets to the machine on + the inside. The NAT software doesn't know that it should send + these packets to the interior machine. -To make things work, make sure that the only thing running -is the software that you're having problems with, then either -run tcpdump on the tun interface of the gateway or enable ppp -tcp/ip logging (set log +tcp/ip) on the gateway. + To make things work, make sure that the only thing + running is the software that you're having problems with, then + either run tcpdump on the tun interface of the gateway or + enable ppp tcp/ip logging (set log +tcp/ip) + on the gateway. -When you start the offending software, you should see packets -passing through the gateway machine. When something comes back -from the outside, it'll be dropped (that's the problem). Note -the port number of these packets then shut down the offending -software. Do this a few times to see if the port numbers are -consistent. If they are, then the following line in the relevant -section of /etc/ppp/ppp.conf will make the software functional: + When you start the offending software, you should see + packets passing through the gateway machine. When something + comes back from the outside, it'll be dropped (that's the + problem). Note the port number of these packets then shut down + the offending software. Do this a few times to see if the port + numbers are consistent. If they are, then the following line in + the relevant section of /etc/ppp/ppp.conf will make the + software functional: -nat port proto internalmachine:port port + nat port proto internalmachine:port port -where proto is either tcp or udp, -internalmachine is the machine that you want the packets -to be sent to and port is the destination port number of -the packets. + where proto is either + tcp or udp, + internalmachine is the machine that + you want the packets to be sent to and + port is the destination port number + of the packets. -You won't be able to use the software on other machines -without changing the above command, and running the software -on two internal machines at the same time is out of the question -- after all, the outside world is seeing your entire internal -network as being just a single machine. + You won't be able to use the software on other machines + without changing the above command, and running the software + on two internal machines at the same time is out of the question + - after all, the outside world is seeing your entire internal + network as being just a single machine. -If the port numbers aren't consistent, there are three more -options: + If the port numbers aren't consistent, there are three + more options: -1) Submit support in libalias. Examples of special -cases can be found in /usr/src/lib/libalias/alias_*.c (alias_ftp.c -is a good prototype). This usually involves reading certain -recognised outgoing packets, identifying the instruction that -tells the outside machine to initiate a connection back to the -internal machine on a specific (random) port and setting up a -route in the alias table so that the subsequent packets -know where to go. + 1) Submit support in + libalias. Examples of special cases can be found + in /usr/src/lib/libalias/alias_*.c + (alias_ftp.c is a good prototype). This + usually involves reading certain recognised outgoing packets, + identifying the instruction that tells the outside machine to + initiate a connection back to the internal machine on a + specific (random) port and setting up a route in + the alias table so that the subsequent packets know where to + go. -This is the most difficult solution, but it is the best and -will make the software work with multiple machines. + This is the most difficult solution, but it is the best + and will make the software work with multiple machines. -2) Use a proxy. The application may support socks5 -for example, or (as in the cvsup case) may have a passive -option that avoids ever requesting that the peer open connections -back to the local machine. + 2) Use a proxy. The + application may support socks5 for example, or (as in the + cvsup case) may have a passive + option that avoids ever requesting that the peer open + connections back to the local machine. -3) Redirect everything to the internal machine using -nat addr. This is the sledge-hammer approach. - - + 3) Redirect everything to + the internal machine using nat addr. This + is the sledge-hammer approach. + + - -Has anybody made a list of useful port numbers ? + + + Has anybody made a list of useful port numbers ? + -Not yet, but this is intended to grow into such a list (if -any interest is shown). In each example, internal should -be replaced with the IP number of the machine playing the game. + Not yet, but this is intended to grow into such a list + (if any interest is shown). In each example, + internal should be replaced with + the IP number of the machine playing the game. - + + + Asheron's Call - -Asheron's Call - + nat port udp + internal + :65000 65000 -nat port udp internal:65000 65000 + Manually change the port number within the game to + 65000. If you've got a number of machines that you wish + to play on assign a unique port number for each (i.e. + 65001, 65002, etc) and add a nat port + line for each one. + -Manually change the port number within the game to 65000. -If you've got a number of machines that you wish to play on assign -a unique port number for each (i.e. 65001, 65002, etc) and add a -nat port line for each one. - + + Half Life - -Half Life - + nat port udp + internal:27005 + 27015 + -nat port udp internal:27005 27015 - + + PCAnywhere 8.0 - -PCAnywhere 8.0 - + nat port udp + internal:5632 + 5632 -nat port udp internal:5632 5632 + nat port tcp + internal:5631 + 5631 + -nat port tcp internal:5631 5631 - + + Quake - -Quake - + nat port udp + internal:6112 + 6112 -nat port udp internal:6112 6112 + Alternatively, you may want to take a look at + www.battle.net for Quake proxy support. + -Alternatively, you may want to take a look at -www.battle.net for Quake proxy support. - + + Quake 2 - -Quake 2 - + nat port udp + internal:27901 + 27910 + -nat port udp internal:27901 27910 - + + Red Alert - -Red Alert - + nat port udp + internal:8675 + 8675 -nat port udp internal:8675 8675 + nat port udp + internal:5009 + 5009 + + -nat port udp internal:5009 5009 - + + - + + + What are FCS errors ? + - + + FCS stands for Frame + Check + Sequence. Each ppp packet + has a checksum attached to ensure that the data being + received is the data being sent. If the FCS of an incoming + packet is incorrect, the packet is dropped and the HDLC FCS + count is increased. The HDLC error values can be displayed + using the show hdlc command. - -What are FCS errors ? + If your link is bad (or if your serial driver is dropping + packets), you will see the occasional FCS error. This is not + usually worth worrying about although it does slow down the + compression protocols substantially. If you have an external + modem, make sure your cable is properly shielded from + interference - this may eradicate the problem. -FCS stands for Frame Check Sequence. Each -ppp packet has a checksum attached to ensure that the data -being received is the data being sent. If the FCS of an -incoming packet is incorrect, the packet is dropped and the -HDLC FCS count is increased. The HDLC error values can be -displayed using the show hdlc command. + If your link freezes as soon as you've connected and you + see a large number of FCS errors, this may be because your link + is not 8 bit clean. Make sure your modem is not using software + flow control (XON/XOFF). If your datalink + must use software flow control, use the + command set accmap 0x000a0000 to tell + ppp to escape the ^Q and + ^S characters. -If your link is bad (or if your serial driver is dropping -packets), you will see the occasional FCS error. This is not -usually worth worrying about although it does slow down the -compression protocols substantially. If you have an external -modem, make sure your cable is properly shielded from -interference - this may eradicate the problem. + Another reason for seeing too many FCS errors may be that + the remote end has stopped talking PPP. You + may want to enable async logging at this + point to determine if the incoming data is actually a login or + shell prompt. If you have a shell prompt at the remote end, + it's possible to terminate ppp without dropping the line by + using the close lcp command (a following + term command will reconnect you to the shell + on the remote machine. -If your link freezes as soon as you've connected and you see -a large number of FCS errors, this may be because your link is -not 8 bit clean. Make sure your modem is not using software -flow control (XON/XOFF). If your datalink must use -software flow control, use the command -set accmap 0x000a0000 to tell ppp to escape -the ^Q and ^S characters. + If nothing in your log file indicates why the link might + have been terminated, you should ask the remote administrator + (your ISP?) why the session was terminated. -Another reason for seeing too many FCS errors may be that -the remote end has stopped talking PPP. You may want to -enable async logging at this point to determine if the -incoming data is actually a login or shell prompt. If you -have a shell prompt at the remote end, it's possible to -terminate ppp without dropping the line by using the -close lcp command (a following term command -will reconnect you to the shell on the remote machine. + + -If nothing in your log file indicates why the link might -have been terminated, you should ask the remote administrator -(your ISP?) why the session was terminated. + + + Why do MacOS and Windows 98 connections freeze when + running PPPoE on the gateway + - + + Thanks to Michael Wozniak + mwozniak@netcom.ca for figuring this out and + Dan Flemming danflemming@mac.com for the Mac + solution: - + This is due to what's called a Black Hole + router. MacOS and Windows 98 (and maybe other Microsoft OSs) + send TCP packets with a requested segment size too big to fit + into a PPPoE frame (MTU is 1500 by default for ethernet) + and have the don't + fragment bit set (default of TCP) and the Telco router + is not sending ICMP must fragment back to the + www site you are trying to load. When the www server is sending + you frames that don't fit into the PPPoE pipe the Telco router + drops them on the floor and your page doesn't load (some + pages/graphics do as they are smaller than a MSS.) This seems + to be the default of most Telco PPPoE configurations (if only + they knew how to program a router... sigh...) - - Why do MacOS and Windows 98 connections freeze when running PPPoE on the gateway - + One fix is to use regedit on your 95/98 boxes to add the + following registry entry... - - - - Thanks to Michael Wozniak mwozniak@netcom.ca for figuring - this out and Dan Flemming danflemming@mac.com for the Mac - solution: - - - - This is due to what's called a Black Hole router. MacOS and Windows 98 (and - maybe other Microsoft OSs) send TCP packets with a requested - segment size too big to fit into a PPPoE frame (MTU is 1500 by default - for ethernet) and have the don't fragment - bit set (default of TCP) and the Telco router is not sending ICMP must - fragment back to the www site you are trying to load. When the www - server is sending you frames that don't fit into the PPPoE pipe the Telco - router drops them on the floor and your page doesn't load (some - pages/graphics do as they are smaller than a MSS.) This seems to be the - default of most Telco PPPoE configurations (if only they knew how to - program a router... sigh...) - - - - One fix is to use regedit on your 95/98 boxes to add the following - registry entry... - - - + HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU - - It should be a string with a value 1450 (more accurately it - should be 1464 to fit TCP packets into a PPPoE frame - perfectly but the 1450 gives you a margin of error for - other IP protocols you may encounter). - + It should be a string with a value 1450 + (more accurately it should be 1464 to fit TCP + packets into a PPPoE frame perfectly but the + 1450 gives you a margin of error for other IP + protocols you may encounter). - - Refer to MS KB # Q158474 - Windows TCPIP Registry Entries - and Q120642 - TCPIP & NBT Configuration Parameters for Windows NT - for more information on changing Windoze MTU to work with a - FreeBSD/NAT/PPPoE router. - + Refer to MS KB # Q158474 - Windows TCPIP Registry + Entries and Q120642 - TCPIP & NBT Configuration + Parameters for Windows NT for more information on + changing Windoze MTU to work with a FreeBSD/NAT/PPPoE + router. - - Unfortunately, MacOS does not provide an interface for changing TCP/IP - settings. However, there is commercial software available, such as - OTAdvancedTuner (OT for OpenTransport, the MacOS TCP/IP stack) by - Sustainable Softworks, - that will allow users to customize TCP/IP settings. MacOS NAT users - should select ip_interface_MTU from the drop-down - menu, enter 1450 instead of 1500 - in the box, click the box next to Save as Auto - Configure, and click Make Active. - + Unfortunately, MacOS does not provide an interface for + changing TCP/IP settings. However, there is commercial software + available, such as OTAdvancedTuner (OT for OpenTransport, the + MacOS TCP/IP stack) by Sustainable Softworks, + that will allow users to customize TCP/IP settings. MacOS NAT + users should select ip_interface_MTU from + the drop-down menu, enter 1450 instead of + 1500 in the box, click the box next to + Save as Auto Configure, and click + Make Active. - - + + - -None of this helps - I'm desperate ! + + + None of this helps - I'm desperate ! + -If all else fails, send as much information as you can, -including your config files, how you're starting ppp, -the relevant parts of your log file and the output of the -netstat -rn command (before and after connecting) to the -freebsd-questions@FreeBSD.org mailing list or the -comp.unix.bsd.freebsd.misc news group, and someone -should point you in the right direction. + + If all else fails, send as much information as you can, + including your config files, how you're starting + ppp, the relevant parts of your + log file and the output of the + netstat -rn command (before and after connecting) to + the freebsd-questions@FreeBSD.org mailing list + or the + comp.unix.bsd.freebsd.misc news group, and someone + should point you in the right direction. - - - + + + + - -Serial Communications + + Serial Communications -This section answers common questions about serial communications -with FreeBSD. PPP and SLIP are covered in the section. + This section answers common questions about serial + communications with FreeBSD. PPP and SLIP are covered in the + section. - -How do I tell if FreeBSD found my serial ports? + + + + How do I tell if FreeBSD found my serial ports? + -As the FreeBSD kernel boots, it will probe for the serial ports -in your system for which the kernel was configured. You can -either watch your system closely for the messages it prints or -run the command + + As the FreeBSD kernel boots, it will probe for the serial + ports in your system for which the kernel was configured. + You can either watch your system closely for the messages it + prints or run the command -&prompt.user; dmesg | grep sio + &prompt.user; dmesg | grep sio -after your system's up and running. + after your system's up and running. -Here's some example output from the above command: + Here's some example output from the above command: -sio0 at 0x3f8-0x3ff irq 4 on isa + sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A -This shows two serial ports. The first is on irq 4, is using -port address 0x3f8, and has a 16550A-type UART chip. The -second uses the same kind of chip but is on irq 3 and is at port -address 0x2f8. Internal modem cards are treated just like -serial ports---except that they always have a modem attached -to the port. + This shows two serial ports. The first is on irq 4, is + using port address 0x3f8, and has a + 16550A-type UART chip. The second uses the same kind of chip + but is on irq 3 and is at port address 0x2f8. + Internal modem cards are treated just like serial ports---except + that they always have a modem attached to the + port. -The GENERIC kernel includes support for two serial ports -using the same irq and port address settings in the above -example. If these settings aren't right for your system, or if -you've added modem cards or have more serial ports than your -kernel is configured for, just reconfigure your kernel. See -section about building a kernel for -more details. + The GENERIC kernel includes support + for two serial ports using the same irq and port address + settings in the above example. If these settings aren't + right for your system, or if you've added modem cards or have + more serial ports than your kernel is configured for, just + reconfigure your kernel. See section + about building a kernel for + more details. - + + - -How do I tell if FreeBSD found my modem cards? + + + How do I tell if FreeBSD found my modem cards? + -Refer to the answer to the previous question. + + Refer to the answer to the previous question. - + + - -I just upgraded to 2.0.5 and my tty0X are missing! + + + I just upgraded to 2.0.5 and my + tty0X are missing! + -Don't worry, they have been merged with the ttydX devices. -You'll have to change any old configuration files you have, though. + + Don't worry, they have been merged with the + ttydX devices. You'll have to change + any old configuration files you have, though. - + + - -How do I access the serial ports on FreeBSD? + + + How do I access the serial ports on FreeBSD? + -The third serial port, sio2 (known as -COM3 in DOS), is on /dev/cuaa2 for dial-out devices, and on -/dev/ttyd2 for dial-in devices. What's the difference -between these two classes of devices? + + The third serial port, sio2 + (known as COM3 in DOS), is on /dev/cuaa2 + for dial-out devices, and on /dev/ttyd2 + for dial-in devices. What's the difference between these two + classes of devices? -You use ttydX for dial-ins. When opening /dev/ttydX -in blocking mode, a process will wait for the corresponding -cuaaX device to become inactive, and then wait -for the carrier detect line to go active. When you open the -cuaaX device, it makes sure the serial port isn't already in -use by the ttydX device. If the port's available, it -steals it from the ttydX device. Also, -the cuaXX -device doesn't care about carrier detect. With this scheme and -an auto-answer modem, you can have remote users log in and you -can still dialout with the same modem and the system will take -care of all the conflicts. + You use ttydX for dial-ins. When + opening /dev/ttydX in blocking mode, a + process will wait for the corresponding + cuaaX device to become inactive, and then + wait for the carrier detect line to go active. When you open + the cuaaX device, it makes sure the serial + port isn't already in use by the ttydX + device. If the port's available, it steals it + from the ttydX device. Also, the + cuaXX device doesn't care about carrier + detect. With this scheme and an auto-answer modem, you can have + remote users log in and you can still dialout with the same + modem and the system will take care of all the + conflicts. - + + - -How do I enable support for a multiport serial card? + + + How do I enable support for a multiport serial + card? + -Again, the section on kernel configuration provides information -about configuring your kernel. For a multiport serial card, -place an sio line for each serial port on the card in the -kernel configuration file. But place the irq and vector -specifiers on only one of the entries. All of the ports on the -card should share one irq. For consistency, use the last serial -port to specify the irq. Also, specify the COM_MULTIPORT -option. + + Again, the section on kernel configuration provides + information about configuring your kernel. For a multiport + serial card, place an sio line + for each serial port on the card in the kernel configuration + file. But place the irq and vector specifiers on only one of + the entries. All of the ports on the card should share one irq. + For consistency, use the last serial port to specify the irq. + Also, specify the COM_MULTIPORT + option. -The following example is for an AST 4-port serial card on irq 7: + The following example is for an AST 4-port serial card on + irq 7: -options "COM_MULTIPORT" + options "COM_MULTIPORT" device sio4 at isa? port 0x2a0 tty flags 0x781 device sio5 at isa? port 0x2a8 tty flags 0x781 device sio6 at isa? port 0x2b0 tty flags 0x781 device sio7 at isa? port 0x2b8 tty flags 0x781 irq 7 vector siointr -The flags indicate that the master port has minor number 7 -(0x700), diagnostics enabled during probe (0x080), and -all the ports share an irq (0x001). + The flags indicate that the master port has minor number 7 + (0x700), diagnostics enabled during probe + (0x080), and all the ports share an irq + (0x001). - + + - -Can FreeBSD handle multiport serial cards sharing irqs? + + + Can FreeBSD handle multiport serial cards sharing + irqs? + -Not yet. You'll have to use a different irq for each card. + + Not yet. You'll have to use a different irq for each + card. - + + - -Can I set the default serial parameters for a port? + + + Can I set the default serial parameters for a + port? + -The ttydX (or cuaaX) device is the regular device -you'll want to open for your applications. When a process opens -the device, it'll have a default set of terminal I/O settings. -You can see these settings with the command + + The ttydX (or + cuaaX) device is the regular device + you'll want to open for your applications. When a process + opens the device, it'll have a default set of terminal I/O + settings. You can see these settings with the command -&prompt.root; stty -a -f /dev/ttyd1 + &prompt.root; stty -a -f /dev/ttyd1 -When you change the settings to this device, the settings are in -effect until the device is closed. When it's reopened, it goes -back to the default set. To make changes to the default set, you -can open and adjust the settings of the initial state device. -For example, to turn on CLOCAL mode, 8 bits, and -XON/XOFF flow control by default for ttyd5, do: + When you change the settings to this device, the settings + are in effect until the device is closed. When it's reopened, + it goes back to the default set. To make changes to the + default set, you can open and adjust the settings of the + initial state device. For example, to turn on + CLOCAL mode, 8 bits, and + XON/XOFF flow control by default for + ttyd5, do: -&prompt.root; stty -f /dev/ttyid5 clocal cs8 ixon ixoff + &prompt.root; stty -f /dev/ttyid5 clocal cs8 ixon ixoff -A good place to do this is in /etc/rc.serial. Now, an -application will have these settings by default when it opens -ttyd5. It can still change these settings to its liking, -though. + A good place to do this is in + /etc/rc.serial. Now, an application will + have these settings by default when it opens + ttyd5. It can still change these settings + to its liking, though. -You can also prevent certain settings from being changed by an -application by making adjustments to the lock state device. -For example, to lock the speed of ttyd5 to 57600 bps, do + You can also prevent certain settings from being changed + by an application by making adjustments to the + lock state device. For example, to lock the + speed of ttyd5 to 57600 bps, do -&prompt.root; stty -f /dev/ttyld5 57600 + &prompt.root; stty -f /dev/ttyld5 57600 -Now, an application that opens ttyd5 and tries to change the -speed of the port will be stuck with 57600 bps. + Now, an application that opens ttyd5 + and tries to change the speed of the port will be stuck with + 57600 bps. -Naturally, you should make the initial state and lock state -devices writable only by root. The -MAKEDEV -script does NOT do this when it creates the -device entries. + Naturally, you should make the initial state and lock state + devices writable only by root. The MAKEDEV + script does NOT do this when it creates the + device entries. - + + - -How can I enable dialup logins on my modem? + + + How can I enable dialup logins on my modem? + -So you want to become an Internet service provider, eh? First, -you'll need one or more modems that can auto-answer. Your modem -will need to assert carrier-detect when it detects a carrier and -not assert it all the time. It will need to hang up the phone -and reset itself when the data terminal ready (DTR) line -goes from on to off. It should probably use RTS/CTS -flow control or no local flow control at all. Finally, it must -use a constant speed between the computer and itself, but (to be -nice to your callers) it should negotiate a speed between itself -and the remote modem. + + So you want to become an Internet service provider, eh? + First, you'll need one or more modems that can auto-answer. + Your modem will need to assert carrier-detect when it detects a + carrier and not assert it all the time. It will need to hang up + the phone and reset itself when the data terminal ready + (DTR) line goes from on to off. It should + probably use RTS/CTS flow control or no + local flow control at all. Finally, it must use a constant + speed between the computer and itself, but (to be nice to your + callers) it should negotiate a speed between itself and the + remote modem. -For many Hayes command-set--compatible modems, this command will -make these settings and store them in nonvolatile memory: + For many Hayes command-set--compatible modems, this + command will make these settings and store them in + nonvolatile memory: -AT &C1 &D3 &K3 &Q6 S0=1 &W + AT &C1 &D3 &K3 &Q6 S0=1 &W -See the section on sending AT commands below for information on how to make these settings -without resorting to an MS-DOS terminal program. + See the section on sending AT + commands below for information on how to make these + settings without resorting to an MS-DOS terminal program. -Next, make an entry in /etc/ttys for the -modem. This file lists all the ports on which the operating system will -await logins. Add a line that looks something like this: + Next, make an entry in + /etc/ttys for the modem. This file lists all the ports + on which the operating system will await logins. Add a line + that looks something like this: -ttyd1 "/usr/libexec/getty std.57600" dialup on insecure + ttyd1 "/usr/libexec/getty std.57600" dialup on insecure -This line indicates that the second serial port -(/dev/ttyd1) has a modem connected running at 57600 bps -and no parity (std.57600, which comes from the file -/etc/gettytab). The terminal type for this port is -dialup. The port is on and is insecure---meaning -root logins on the port aren't allowed. For dialin ports like -this one, use the ttydX entry. + This line indicates that the second serial port + (/dev/ttyd1) has a modem connected + running at 57600 bps and no parity + (std.57600, which comes from the file /etc/gettytab). + The terminal type for this port is dialup. + The port is on and is + insecure---meaning root logins on the port + aren't allowed. For dialin ports like this one, use the + ttydX entry. -It's common practice to use dialup as the terminal type. -Many users set up in their .profile or .login files a prompt for -the actual terminal type if the starting type is dialup. The -example shows the port as insecure. To become root on this port, -you have to login as a regular user, then su to become -root. If you use secure then -root can login in directly. + It's common practice to use dialup as + the terminal type. Many users set up in their .profile or + .login files a prompt for the actual terminal type if the + starting type is dialup. The example shows the port as + insecure. To become root on this port, you have to login as a + regular user, then su to become + root. If you use secure + then root can login in directly. -After making modifications to /etc/ttys, you -need to send a hangup or HUP signal to the init process: + After making modifications to + /etc/ttys, you need to send a hangup or + HUP signal to the + init process: -&prompt.root; kill -HUP 1 + &prompt.root; kill -HUP 1 -This forces the init process to reread /etc/ttys. The -init process will then start getty processes on all on ports. -You can find out if logins are available for your port by typing + This forces the init process to reread + /etc/ttys. The init process will then start getty + processes on all on ports. You can find + out if logins are available for your port by typing -&prompt.user; ps -ax | grep '[t]tyd1' + &prompt.user; ps -ax | grep '[t]tyd1' -You should see something like: + You should see something like: -747 ?? I 0:00.04 /usr/libexec/getty std.57600 ttyd1 + 747 ?? I 0:00.04 /usr/libexec/getty std.57600 ttyd1 - + + - -How can I connect a dumb terminal to my FreeBSD box? + + + How can I connect a dumb terminal to my FreeBSD + box? + -If you're using another computer as a terminal into your FreeBSD -system, get a null modem cable to go between the two serial -ports. If you're using an actual terminal, see its accompanying -instructions. + + If you're using another computer as a terminal into your + FreeBSD system, get a null modem cable to go between the two + serial ports. If you're using an actual terminal, see its + accompanying instructions. -Then, modify /etc/ttys, like above. For example, if you're hooking up a -WYSE-50 terminal to the fifth serial port, use an entry like this: + Then, modify + /etc/ttys, like above. For example, if you're + hooking up a WYSE-50 terminal to the fifth serial port, + use an entry like this: -ttyd4 "/usr/libexec/getty std.38400" wyse50 on secure + ttyd4 "/usr/libexec/getty std.38400" wyse50 on secure -This example shows that the port on /dev/ttyd4 has a -wyse50 terminal connected at 38400 bps with no parity -(std.38400 from /etc/gettytab) and -root logins are allowed (secure). + This example shows that the port on + /dev/ttyd4 has a wyse50 terminal + connected at 38400 bps with no parity + (std.38400 from + /etc/gettytab) and root logins are + allowed (secure). - + + - -Why can't I run tip or cu? + + + Why can't I run tip or + cu? + -On your system, the programs tip and cu are probably -executable only by uucp and group -dialer. You can use the group dialer -to control who has access to your modem or remote systems. Just add -yourself to group dialer. + + On your system, the programs tip + and + cu are probably executable only by uucp + and group dialer. You can use the group + dialer to control who has access to your + modem or remote systems. Just add yourself to group + dialer. -Alternatively, you can let everyone on your system run tip -and cu by typing: + Alternatively, you can let everyone on your system + run tip and cu by + typing: -&prompt.root; chmod 4511 /usr/bin/cu + &prompt.root; chmod 4511 /usr/bin/cu &prompt.root; chmod 4511 /usr/bin/tip - + + - -My stock Hayes modem isn't supported---what can I do? + + + My stock Hayes modem isn't supported---what + can I do? + -Actually, the man page for tip is out of -date. There is a generic Hayes dialer already built in. Just use -at=hayes in your /etc/remote file. + + Actually, the man page for tip is + out of date. There is a generic Hayes dialer already built in. + Just use at=hayes in your + /etc/remote file. -The Hayes driver isn't smart enough to recognize some of the -advanced features of newer modems---messages like BUSY, -NO DIALTONE, or CONNECT 115200 will just confuse it. -You should turn those messages off when you use tip (using -ATX0&W). + The Hayes driver isn't smart enough to recognize some of + the advanced features of newer modems---messages like + BUSY, NO DIALTONE, or + CONNECT 115200 will just confuse it. You + should turn those messages off when you use tip + (using ATX0&W). -Also, the dial timeout for tip is 60 seconds. Your modem -should use something less, or else tip will think there's a -communication problem. Try ATS7=45&W. + Also, the dial timeout for tip is 60 + seconds. Your modem should use something less, or else tip + will think there's a communication problem. Try + ATS7=45&W. -Actually, as shipped tip doesn't yet support it fully. The -solution is to edit the file tipconf.h in the directory -/usr/src/usr.bin/tip/tip. Obviously you need the source -distribution to do this. + Actually, as shipped tip doesn't yet + support it fully. The solution is to edit the file + tipconf.h in the directory + /usr/src/usr.bin/tip/tip. Obviously you + need the source distribution to do this. -Edit the line #define HAYES 0 to #define HAYES 1. -Then make and make install. Everything -works nicely after that. + Edit the line #define HAYES 0 + to #define HAYES 1. Then + make and make install. + Everything works nicely after that. - + + - - How am I expected to enter these AT commands? - + + + How am I expected to enter these AT commands? + -Make what's called a direct entry in your -/etc/remote file. For example, if your modem's hooked -up to the first serial port, /dev/cuaa0, then put in the -following line: + + Make what's called a direct entry in your + + /etc/remote file. For example, if your modem's hooked + up to the first serial port, /dev/cuaa0, + then put in the following line: -cuaa0:dv=/dev/cuaa0:br#19200:pa=none + cuaa0:dv=/dev/cuaa0:br#19200:pa=none -Use the highest bps rate your modem supports in the br -capability. Then, type tip cuaa0 and -you'll be connected to your modem. + Use the highest bps rate your modem supports in the br + capability. Then, type tip cuaa0 + and you'll be connected to your modem. -If there is no /dev/cuaa0 on your system, do this: + If there is no /dev/cuaa0 on your + system, do this: -&prompt.root; cd /dev + &prompt.root; cd /dev &prompt.root; sh MAKEDEV cuaa0 -Or use cu as root with the following command: + Or use cu as root with the following command: -&prompt.root; cu -lline -sspeed + &prompt.root; cu -lline -sspeed -with line being the serial port (e.g./dev/cuaa0) -and speed being the speed (e.g.57600). When you are done -entering the AT commands hit ~. to exit. + with line being the serial port (e.g. + /dev/cuaa0) and speed being the speed + (e.g.57600). When you are done entering + the AT commands hit ~. to exit. - + + - -The <@> sign for the pn capability doesn't work! + + + The <@> sign for the pn + capability doesn't work! -The <@> sign in the phone number capability tells tip to look in -/etc/phones for a phone number. But the <@> sign is -also a special character in capability files like -/etc/remote. Escape it with a backslash: + The <@> sign in the phone number + capability tells tip to look in + /etc/phones for a phone number. But the + <@> sign is also a special character + in capability files like /etc/remote. + Escape it with a backslash: -pn=\@ + pn=\@ - + + - -How can I dial a phone number on the command line? + + + How can I dial a phone number on the command + line? + -Put what's called a generic entry in your -/etc/remote file. For example: + Put what's called a generic entry in your + + /etc/remote file. For example: -tip115200|Dial any phone number at 115200 bps:\ + tip115200|Dial any phone number at 115200 bps:\ :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du: tip57600|Dial any phone number at 57600 bps:\ :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du: -Then you can do something like tip -115200 5551234. If you -prefer cu over tip, use a -generic cu entry: + Then you can do something like tip -115200 + 5551234. If you prefer cu + over + tip, use a generic cu entry: -cu115200|Use cu to dial any number at 115200bps:\ + cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: -and type cu 5551234 -s 115200. + and type cu 5551234 -s 115200. - + + - -Do I have to type in the bps rate every time I do that? + + + Do I have to type in the bps rate every time I do + that? + -Put in an entry for tip1200 or cu1200, but go ahead and -use whatever bps rate is appropriate with the br capability. tip thinks a good -default is 1200 bps which is why it looks for a tip1200 entry. -You don't have to use 1200 bps, though. + Put in an entry for tip1200 or + cu1200, but go ahead and use whatever bps + rate is appropriate with the br capability. tip + thinks a good default is 1200 bps which is why it looks for + a tip1200 entry. You don't have to use 1200 + bps, though. - + + - -I access a number of hosts through a terminal server. + + + I access a number of hosts through a terminal + server. + -Rather than waiting until you're connected and typing -CONNECT host each time, use tip's cm -capability. For example, these entries in -/etc/remote: + + Rather than waiting until you're connected and typing + CONNECT host + each time, use tip's cm capability. For + example, these entries in + /etc/remote: -pain|pain.deep13.com|Forrester's machine:\ + pain|pain.deep13.com|Forrester's machine:\ :cm=CONNECT pain\n:tc=deep13: muffin|muffin.deep13.com|Frank's machine:\ :cm=CONNECT muffin\n:tc=deep13: deep13:Gizmonics Institute terminal server:\ :dv=/dev/cua02:br#38400:at=hayes:du:pa=none:pn=5551234: -will let you type tip pain or tip muffin to -connect to the hosts pain or muffin; -and tip deep13 to -get to the terminal server. + will let you type tip pain or + tip muffin to connect to the hosts + pain or muffin; and + tip deep13 to get to the terminal + server. - + + - -Can tip try more than one line for each site? + + + Can tip try more than one line for each site? + -This is often a problem where a university has several modem lines -and several thousand students trying to use them... + + This is often a problem where a university has several + modem lines and several thousand students trying to use + them... -Make an entry for your university in /etc/remote -and use <\@> for the pn capability: + Make an entry for your university in + /etc/remote and use <\@> for + the pn capability: -big-university:\ + big-university:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: -Then, list the phone numbers for the university in -/etc/phones: + Then, list the phone numbers for the university in + + /etc/phones: -big-university 5551111 + big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114 -tip will try each one in the listed order, then give up. If -you want to keep retrying, run tip in a while loop. + + tip will try each one in the listed order, then give + up. If you want to keep retrying, run tip + in a while loop. - + + - -Why do I have to hit CTRL+P twice to send CTRL+P once? + + + Why do I have to hit CTRL+P twice to send CTRL+P + once? + -CTRL+P is the default force character, used to tell -tip -that the next character is literal data. You can set the force -character to any other character with the ~s escape, which -means set a variable. + + CTRL+P is the default force character, + used to tell tip + that the next character is literal data. You can set the + force character to any other character with the + ~s escape, which means set a + variable. -Type ~sforce=single-char followed by a newline. -single-char is any single character. If you leave -out single-char, then the force character is the nul -character, which you can get by typing CTRL+2 or CTRL+SPACE. A -pretty good value for single-char is SHIFT+CTRL+6, -which I've seen only used on some terminal servers. + Type ~sforce=single-char + followed by a newline. + single-char is any single character. + If you leave out single-char, + then the force character is the nul character, which you can + get by typing CTRL+2 or CTRL+SPACE. A pretty good value for + single-char is SHIFT+CTRL+6, which + I've seen only used on some terminal servers. -You can have the force character be whatever you want by -specifying the following in your $HOME/.tiprc -file: + You can have the force character be whatever you want by + specifying the following in your + $HOME/.tiprc file: -force=single-char + force=single-char - + + - -Suddenly everything I type is in UPPER CASE?? + + + Suddenly everything I type is in UPPER CASE?? + -You must've pressed CTRL+A, tip raise -character, specially designed for people with broken caps-lock keys. -Use ~s as above and set the variable raisechar to something -reasonable. In fact, you can set it to the same as the force -character, if you never expect to use either of these features. + + You must've pressed CTRL+A, + tip raise character, specially + designed for people with broken caps-lock keys. Use + ~s as above and set the variable + raisechar to something reasonable. In fact, + you can set it to the same as the force character, if you + never expect to use either of these features. -Here's a sample .tiprc file perfect for Emacs users who need to -type CTRL+2 and CTRL+A a lot: + Here's a sample .tiprc file perfect for Emacs users who + need to type CTRL+2 and CTRL+A a lot: -force=^^ + force=^^ raisechar=^^ The ^^ is SHIFT+CTRL+6. - + + - -How can I do file transfers with tip? + + + How can I do file transfers with + tip? + -If you're talking to another UNIX system, you can send and -receive files with ~p (put) and ~t (take). These -commands run cat and echo on the remote system to accept and send files. The syntax -is: + + If you're talking to another UNIX system, you can send + and receive files with ~p (put) and + ~t (take). These commands run cat and + + echo on the remote system to accept and send files. + The syntax is: -~p <local-file> [<remote-file>] + ~p <local-file> [<remote-file>] ~t <remote-file> [<local-file>] -There's no error checking, so you probably should use another -protocol, like zmodem. + There's no error checking, so you probably should use + another protocol, like zmodem. - + + - -How can I run zmodem with tip? + + + How can I run zmodem with + tip? + -First, install one of the zmodem programs from the ports -collection (such as one of the two from the comms category, -lrzsz -and rzsz). + + First, install one of the zmodem programs from the ports + collection (such as one of the two from the comms category, + + lrzsz and + rzsz). -To receive files, start the sending program on the remote end. -Then, press enter and type ~C rz (or ~C lrz if -you installed lrzsz) to begin receiving them locally. + To receive files, start the sending program on the + remote end. Then, press enter and type + ~C rz (or ~C lrz if you + installed lrzsz) to begin + receiving them locally. -To send files, start the receiving program on the remote end. -Then, press enter and type ~C sz files (or -~C lsz files) to send them to the -remote system. + To send files, start the receiving program on the remote + end. Then, press enter and type + ~C sz files + (or ~C lsz files) + to send them to the remote system. - + + - -FreeBSD can't seem to find my serial ports, even when the - settings are correct. + + + FreeBSD can't seem to find my serial ports, even when + the settings are correct. + -Motherboards and cards with Acer UARTs do not probe properly under -the FreeBSD sio probe. Obtain a patch from -www.lemis.com to fix your problem. + + Motherboards and cards with Acer UARTs do not probe + properly under the FreeBSD sio probe. Obtain a patch from + + www.lemis.com to fix your problem. - - + + + + diff --git a/en_US.ISO_8859-1/books/faq/book.sgml b/en_US.ISO_8859-1/books/faq/book.sgml index 2dd9a30208..7956369953 100644 --- a/en_US.ISO_8859-1/books/faq/book.sgml +++ b/en_US.ISO_8859-1/books/faq/book.sgml @@ -15,7 +15,7 @@ - $FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.103 2000/09/26 12:40:11 marko Exp $ + $FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.104 2000/09/26 16:26:15 marko Exp $ This is the FAQ for FreeBSD versions 2.X, 3.X, and 4.X. @@ -7316,255 +7316,352 @@ Key F15 A A Menu Workplace Nop - -Networking - - - -Where can I get information on diskless booting? - -Diskless booting means that the FreeBSD box is booted over a -network, and reads the necessary files from a server instead of -its hard disk. For full details, please read -the Handbook entry on diskless booting - - - - - Can a FreeBSD box be used as a dedicated network router? - - -Internet standards and good engineering practice prohibit us from -providing packet forwarding by default in FreeBSD. You can -however enable this feature by changing the following variable to -YES in rc.conf: - -gateway_enable=YES # Set to YES if this host will be a gateway - -This option will put the sysctl variable -net.inet.ip.forwarding to 1. - -In most cases, you will also need to run a routing process to -tell other systems on your network about your router; FreeBSD -comes with the standard BSD routing daemon -routed, or for more complex situations you may want to try -GaTeD (available from http://www.gated.org/ ) which -supports FreeBSD as of 3_5Alpha7. - -It is our duty to warn you that, even when FreeBSD is configured -in this way, it does not completely comply with the Internet -standard requirements for routers; however, it comes close enough -for ordinary usage. - - - - -Can I connect my Win95 box to the Internet via FreeBSD? - -Typically, people who ask this question have two PC's at home, one -with FreeBSD and one with Win95; the idea is to use the FreeBSD -box to connect to the Internet and then be able to access the -Internet from the Windows95 box through the FreeBSD box. This -is really just a special case of the previous question. - ... and the answer is yes! In FreeBSD 3.x, user-mode ppp contains a - option. If you run ppp with -the , set gateway_enable to -YES in /etc/rc.conf, and -configure your Windows machine correctly, this should work -fine. - -More detailed information about setting this up can be found in -the Pedantic PPP -Primer by Steve Sims. - -If you are using kernel-mode ppp, or have an Ethernet connection -to the Internet, you will have to use natd. Please -look at the natd section of this FAQ. - - - - - Why does recompiling the latest BIND from ISC fail? - - -There is a conflict between the cdefs.h file in the -distribution and the one shipped with FreeBSD. Just remove -compat/include/sys/cdefs.h. - - - - -Does FreeBSD support SLIP and PPP? - -Yes. See the man pages for -slattach, sliplogin, -pppd and -ppp. -pppd and ppp provide support for both incoming and outgoing -connections. Sliplogin deals exclusively with incoming connections and -slattach deals exclusively with outgoing connections. - -These programs are described in the following sections of the -handbook: - - - - - -Handbook entry on SLIP (server side) - - - - -Handbook entry on SLIP (client side) - - - - -Handbook entry on PPP (kernel version) - - - - -Handbook entry on PPP (user-mode version) - - - - - -If you only have access to the Internet through a shell -account, you may want to have a look at the slirp -package. It can provide you with (limited) access to services -such as ftp and http direct from your local machine. - - - - - Does FreeBSD support NAT or Masquerading - - -If you have a local subnet (one or more local machines), but have -been allocated only a single IP number from your Internet provider -(or even if you receive a dynamic IP number), you may want to look at -the natd -program. natd allows you to connect an entire subnet to the -internet using only a single IP number. - -The ppp program has similar functionality built in via -the switch. The alias library -is used in both cases. - - - - - -I can't create a /dev/ed0 device! - -In the Berkeley networking framework, network interfaces are only -directly accessible by kernel code. Please see the -/etc/rc.network file and the manual pages for the various -network programs mentioned there for more information. If this -leaves you totally confused, then you should pick up a book -describing network administration on another BSD-related -operating system; with few significant exceptions, administering -networking on FreeBSD is basically the same as on SunOS 4.0 or -Ultrix. - - - - -How can I setup Ethernet aliases? - -Add netmask 0xffffffff to your ifconfig -command-line like the following: - -&prompt.root; ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff - - - - -How do I get my 3C503 to use the other network port? - -If you want to use the other ports, you'll have to specify an -additional parameter on the -ifconfig command line. The -default port is link0. To use the AUI port instead of -the BNC one, use link2. These flags should be specified -using the ifconfig_* variables in /etc/rc.conf. - - - - -I'm having problems with NFS to/from FreeBSD. - -Certain PC network cards are better than others (to put it -mildly) and can sometimes cause problems with network intensive -applications like NFS. - -See the Handbook entry on NFS -for more information on this topic. - - - - -Why can't I NFS-mount from a Linux box? - -Some versions of the Linux NFS code only accept mount requests -from a privileged port; try - -&prompt.root; mount -o -P linuxbox:/blah /mnt - - - - -Why can't I NFS-mount from a Sun box? - -Sun workstations running SunOS 4.X only accept mount requests -from a privileged port; try - -&prompt.root; mount -o -P sunbox:/blah /mnt - - - - -I'm having problems talking PPP to NeXTStep machines. - -Try disabling the TCP extensions in /etc/rc.conf by -changing the following variable to NO: - -tcp_extensions=NO - -Xylogic's Annex boxes are also broken in this regard and you must -use the above change to connect thru them. - - - - -How do I enable IP multicast support? - -Multicast host operations are fully supported in FreeBSD 2.0 and -later by default. If you want your box to run as a multicast router, -you will need to recompile your kernel with the MROUTING -option and run mrouted. FreeBSD 2.2 and later will start -mrouted at boot time if the flag mrouted_enable is set -to "YES" in /etc/rc.conf. - -MBONE tools are available in their own ports category, mbone. If -you are looking for the conference tools vic and -vat, -look there! - -For more information, see the -Mbone Information Web. - - - - -Which network cards are based on the DEC PCI chipset? - -Here is a list compiled by Glen Foster, with some more modern additions: + + Networking + + + + + Where can I get information on + diskless booting? + + + + Diskless booting means that the FreeBSD + box is booted over a network, and reads the necessary files + from a server instead of its hard disk. For full details, + please read the + Handbook entry on diskless booting + + + + + + + Can a FreeBSD box be used as a dedicated network + router? + + + + Internet standards and good engineering practice prohibit + us from providing packet forwarding by default in FreeBSD. You + can however enable this feature by changing the following + variable to YES in + rc.conf: + + gateway_enable=YES # Set to YES if this host will be a gateway + + This option will put the + sysctl variable + net.inet.ip.forwarding + to 1. + + In most cases, you will also need to run a routing process + to tell other systems on your network about your router; + FreeBSD comes with the standard BSD routing daemon routed, + or for more complex situations you may want to try + GaTeD (available from http://www.gated.org/ ) + which supports FreeBSD as of 3_5Alpha7. + + It is our duty to warn you that, even when FreeBSD is + configured in this way, it does not completely comply with + the Internet standard requirements for routers; however, + it comes close enough for ordinary usage. + + + + + + + Can I connect my Win95 box to the Internet via + FreeBSD? + + + + Typically, people who ask this question have two PC's + at home, one with FreeBSD and one with Win95; the idea is to + use the FreeBSD box to connect to the Internet and then be able + to access the Internet from the Windows95 box through the + FreeBSD box. This is really just a special case of the previous + question. ... and the answer is yes! In FreeBSD + 3.x, user-mode ppp contains a option. If + you run ppp with the , + set gateway_enable to + YES in /etc/rc.conf, + and configure your Windows machine correctly, this should work + fine. + + More detailed information about setting this up can be + found in the + Pedantic PPP Primer by Steve Sims. + + If you are using kernel-mode ppp, or have an Ethernet + connection to the Internet, you will have to use + natd. Please look at the + natd section of this FAQ. + + + + + + + Why does recompiling the latest BIND from ISC fail? + + + + There is a conflict between the + cdefs.h file in the distribution and the + one shipped with FreeBSD. Just remove + compat/include/sys/cdefs.h. + + + + + + + Does FreeBSD support SLIP and PPP? + + + + Yes. See the man pages for + slattach, + sliplogin, pppd and + ppp. + pppd and ppp provide + support for both incoming and outgoing connections. + Sliplogin deals exclusively with incoming connections + and + slattach deals exclusively with outgoing + connections. + + These programs are described in the following sections of + the handbook: + + + + + Handbook entry + on SLIP (server side) + + + + + Handbook entry + on SLIP (client side) + + + + Handbook entry on + PPP (kernel version) + + + + + Handbook entry on PPP (user-mode version) + + + + If you only have access to the Internet through a + shell account, you may want to have a look at + the + slirp package. It can provide you with (limited) + access to services such as ftp and http direct from your local + machine. + + + + + + + Does FreeBSD support NAT or Masquerading + + + + If you have a local subnet (one or more local machines), + but have been allocated only a single IP number from your + Internet provider (or even if you receive a dynamic IP number), + you may want to look at the natd + program. natd allows you to connect an + entire subnet to the internet using only a single IP + number. + + The + ppp program has similar functionality built in via + the switch. The + alias library is used in both cases. + + + + + + + I can't create a /dev/ed0 + device! + + + + + In the Berkeley networking framework, network interfaces + are only directly accessible by kernel code. Please see the + /etc/rc.network file and the manual pages + for the various network programs mentioned there for more + information. If this leaves you totally confused, then you + should pick up a book describing network administration on + another BSD-related operating system; with few significant + exceptions, administering networking on FreeBSD is basically + the same as on SunOS 4.0 or Ultrix. + + + + + + + How can I setup Ethernet aliases? + + + Add netmask 0xffffffff to your + ifconfig command-line like the following: + + &prompt.root; ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff + + + + + + + How do I get my 3C503 to use the other network + port? + + + + If you want to use the other ports, you'll have to specify + an additional parameter on the + ifconfig command line. The default port is + link0. To use the AUI port instead of the + BNC one, use link2. These flags should be + specified using the ifconfig_* variables in + /etc/rc.conf. + + + + + + + I'm having problems with NFS to/from FreeBSD. + + + + Certain PC network cards are better than others (to put + it mildly) and can sometimes cause problems with network + intensive applications like NFS. + + See + the Handbook entry on NFS for more information on + this topic. + + + + + + + Why can't I NFS-mount from a Linux box? + + + + Some versions of the Linux NFS code only accept mount + requests from a privileged port; try + + &prompt.root; mount -o -P linuxbox:/blah /mnt + + + + + + + Why can't I NFS-mount from a Sun box? + + + + Sun workstations running SunOS 4.X only accept mount + requests from a privileged port; try + + &prompt.root; mount -o -P sunbox:/blah /mnt + + + + + + + I'm having problems talking PPP to NeXTStep + machines. + + + + + Try disabling the TCP extensions in + /etc/rc.conf by changing the following variable to + NO: + + tcp_extensions=NO + + Xylogic's Annex boxes are also broken in this regard and + you must use the above change to connect thru them. + + + + + + + How do I enable IP multicast support? + + + + Multicast host operations are fully supported in FreeBSD + 2.0 and later by default. If you want your box to run as a + multicast router, you will need to recompile your kernel with + the MROUTING option and run + mrouted. FreeBSD 2.2 and later will start + mrouted at boot time if the flag + mrouted_enable is set to + "YES" in + /etc/rc.conf. + + MBONE tools are available in their own ports category, + mbone. If you are looking for the conference tools + vic and vat, + look there! + + For more information, see the + Mbone Information Web. + + + + + + + Which network cards are based on the DEC PCI + chipset? + + + Here is a list compiled by Glen Foster, + with some more modern additions: Vendor Model ---------------------------------------------- @@ -7584,789 +7681,1005 @@ SMC EtherPower (Model 8432) TopWare TE-3500P Znyx (2.2.x) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348 (3.x) ZX345Q, ZX346Q, ZX348Q, ZX412Q, ZX414, ZX442, - ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd) + ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd) + - + + - -Why do I have to use the FQDN for hosts on my site? + + + Why do I have to use the FQDN for hosts on my + site? + -You will probably find that the host is actually in a different -domain; for example, if you are in foo.bar.edu and you wish to reach -a host called mumble in the bar.edu domain, you will have to -refer to it by the fully-qualified domain name, mumble.bar.edu, -instead of just mumble. + + You will probably find that the host is actually in a + different domain; for example, if you are in foo.bar.edu and + you wish to reach a host called mumble in the + bar.edu domain, you will + have to refer to it by the fully-qualified domain name, mumble.bar.edu, instead of just + mumble. -Traditionally, this was allowed by BSD BIND resolvers. However -the current version of bind that ships -with FreeBSD no longer provides default abbreviations for non-fully -qualified domain names other than the domain you are in. -So an unqualified host mumble must either be found -as mumble.foo.bar.edu, or it will be searched for -in the root domain. + Traditionally, this was allowed by BSD BIND resolvers. + However the current version of bind + that ships with FreeBSD no longer provides default + abbreviations for non-fully qualified domain names other than + the domain you are in. So an unqualified host + mumble must either be found as mumble.foo.bar.edu, or it will be searched + for in the root domain. -This is different from the previous behavior, where the -search continued across mumble.bar.edu, and -mumble.edu. Have a look at RFC 1535 for why this -was considered bad practice, or even a security hole. + This is different from the previous behavior, where the + search continued across + mumble.bar.edu, and + mumble.edu. Have a look at + RFC 1535 for why this was considered bad practice, or even a + security hole. -As a good workaround, you can place the line + As a good workaround, you can place the line -search foo.bar.edu bar.edu + search foo.bar.edu bar.edu -instead of the previous + instead of the previous -domain foo.bar.edu + domain foo.bar.edu -into your /etc/resolv.conf file. However, make sure that the search order -does not go beyond the boundary between local and public -administration, as RFC 1535 calls it. + into your + /etc/resolv.conf file. However, make sure that the + search order does not go beyond the boundary between + local and public administration, as RFC 1535 calls + it. - + + - -Permission denied for all networking operations. + + + Permission denied for all networking + operations. + -If you have compiled your kernel with the IPFIREWALL -option, you need to be aware that the default policy as of -2.1.7R (this actually changed during 2.1-STABLE development) -is to deny all packets that are not explicitly allowed. + + If you have compiled your kernel with the + IPFIREWALL option, you need to be aware + that the default policy as of 2.1.7R (this actually changed + during 2.1-STABLE development) is to deny all packets that are + not explicitly allowed. -If you had unintentionally misconfigured your system for -firewalling, you can restore network operability by typing -the following while logged in as root: + If you had unintentionally misconfigured your system for + firewalling, you can restore network operability by typing + the following while logged in as root: -&prompt.root; ipfw add 65534 allow all from any to any + &prompt.root; ipfw add 65534 allow all from any to any -You can also set firewall_type="open" in /etc/rc.conf. + You can also set firewall_type="open" + in /etc/rc.conf. -For further information on configuring a FreeBSD firewall, -see the Handbook section. + For further information on configuring a FreeBSD firewall, + see the + Handbook section. - + + - -How much overhead does IPFW incur? + + + How much overhead does IPFW incur? + -The answer to this depends mostly on your rule set and processor -speed. For most applications dealing with ethernet and small -rule sets, the answer is, negligible. For those of you that need -actual measurements to satisfy your curiosity, read on. + + The answer to this depends mostly on your rule set and + processor speed. For most applications dealing with ethernet + and small rule sets, the answer is, negligible. For those of + you that need actual measurements to satisfy your curiosity, + read on. -The following measurements were made using 2.2.5-STABLE on -a 486-66. IPFW was modified to measure the time spent within -the ip_fw_chk routine, displaying the results to the console -every 1000 packets. + The following measurements were made using 2.2.5-STABLE + on a 486-66. IPFW was modified to measure the time spent + within the ip_fw_chk routine, displaying + the results to the console every 1000 packets. -Two rule sets, each with 1000 rules were tested. The first set -was designed to demonstrate a worst case scenario by repeating the -rule: + Two rule sets, each with 1000 rules were tested. The + first set was designed to demonstrate a worst case scenario + by repeating the rule: -&prompt.root; ipfw add deny tcp from any to any 55555 + &prompt.root; ipfw add deny tcp from any to any 55555 -This demonstrates worst case by causing most of IPFW's packet -check routine to be executed before finally deciding that the -packet does not match the rule (by virtue of the port number). -Following the 999th iteration of this rule was an allow ip -from any to any. + This demonstrates worst case by causing most of IPFW's + packet check routine to be executed before finally deciding + that the packet does not match the rule (by virtue of the port + number). Following the 999th iteration of this rule was an + allow ip from any to any. -The second set of rules were designed to abort the rule -check quickly: + The second set of rules were designed to abort the rule + check quickly: -&prompt.root; ipfw add deny ip from 1.2.3.4 to 1.2.3.4 + &prompt.root; ipfw add deny ip from 1.2.3.4 to 1.2.3.4 -The nonmatching source IP address for the above rule causes -these rules to be skipped very quickly. As before, the 1000th -rule was an allow ip from any to any. + The nonmatching source IP address for the above rule causes + these rules to be skipped very quickly. As before, the 1000th + rule was an allow ip from any to any. -The per-packet processing overhead in the former case was -approximately 2.703ms/packet, or roughly 2.7 microseconds per -rule. Thus the theoretical packet processing limit with these -rules is around 370 packets per second. Assuming 10Mbps ethernet -and a ~1500 byte packet size, we would only be able to achieve a -55.5% bandwidth utilization. + The per-packet processing overhead in the former case was + approximately 2.703ms/packet, or roughly 2.7 microseconds per + rule. Thus the theoretical packet processing limit with these + rules is around 370 packets per second. Assuming 10Mbps + ethernet and a ~1500 byte packet size, we would only be able to + achieve a 55.5% bandwidth utilization. -For the latter case each packet was processed in -approximately 1.172ms, or roughly 1.2 microseconds per rule. -The theoretical packet processing limit here would be about -853 packets per second, which could consume 10Mbps ethernet -bandwidth. + For the latter case each packet was processed in + approximately 1.172ms, or roughly 1.2 microseconds per rule. + The theoretical packet processing limit here would be about + 853 packets per second, which could consume 10Mbps ethernet + bandwidth. -The excessive number of rules tested and the nature of those -rules do not provide a real-world scenario -- they were used only -to generate the timing information presented here. Here are a -few things to keep in mind when building an efficient rule set: + The excessive number of rules tested and the nature of + those rules do not provide a real-world scenario -- they were + used only to generate the timing information presented here. + Here are a few things to keep in mind when building an + efficient rule set: - - + + + + Place an established rule early + on to handle the majority of TCP traffic. Don't put any + allow tcp statements before this + rule. + - -Place an established rule early on to handle the -majority of TCP traffic. Don't put any allow tcp -statements before this rule. - - + + Place heavily triggered rules earlier in the rule + set than those rarely used (without + changing the permissiveness of the firewall, + of course). You can see which rules are used most often + by examining the packet counting statistics with + ipfw -a l. + + - -Place heavily triggered rules earlier in the rule -set than those rarely used (without changing the -permissiveness of the firewall, of course). You can see -which rules are used most often by examining the packet counting -statistics with ipfw -a l. - - + + - - + + + How can I redirect service requests from one machine to + another? + - + + You can redirect FTP (and other service) request with + the socket package, available in the ports + tree in category sysutils. Simply replace the + service's commandline to call socket instead, like so: - -How can I redirect service requests from one machine to another? - + ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp -You can redirect FTP (and other service) request with the socket -package, available in the ports tree in category sysutils. -Simply replace the service's commandline to call socket instead, like so: + where ftp.foo.com and + ftp are the host and port to + redirect to, respectively. -ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp + + -where ftp.foo.com and ftp are the host and port to redirect to, -respectively. + + + Where can I get a bandwidth management tool? + - + + There are two bandwidth management tools available for + FreeBSD. + ALTQ is available for free; Bandwidth Manager from + Emerging Technologies + is a commercial product. - -Where can I get a bandwidth management tool? + + -There are two bandwidth management tools available for FreeBSD. -ALTQ is available for free; Bandwidth Manager from -Emerging Technologies is -a commercial product. + + + Why do I get /dev/bpf0: device not + configured? + - + + The Berkeley Packet Filter (bpf) + driver needs to be enabled before running programs that + utilize it. Add this to your kernel config file and build + a new kernel: - -Why do I get /dev/bpf0: device not configured? + pseudo-device bpfilter # Berkeley Packet Filter -The Berkeley Packet Filter (bpf) driver -needs to be enabled before running programs that utilize it. -Add this to your kernel config file and build a new kernel: + Secondly, after rebooting you will have to create the + device node. This can be accomplished by a change to the + /dev directory, followed by the execution + of: -pseudo-device bpfilter # Berkeley Packet Filter + &prompt.root; sh MAKEDEV bpf0 -Secondly, after rebooting you will have to create the device -node. This can be accomplished by a change to the /dev -directory, followed by the execution of: + Please see the + handbook's entry on device nodes for more information + on creating devices. -&prompt.root; sh MAKEDEV bpf0 + + -Please see the handbook's entry on device nodes for more information -on creating devices. + + + How do I mount a disk from a Windows machine that's on my + network, like smbmount in Linux? + - + + Use the + sharity light package in the ports collection. - - - How do I mount a disk from a Windows machine that's on my - network, like smbmount in Linux? - - - Use the sharity - light package in the ports collection. - - - - + + + + - -PPP - - - I can't make ppp work. What am I doing wrong ? - + + PPP -You should first read the ppp man page and -the ppp section of the handbook. Enable logging with the command + + + + I can't make ppp work. What am I doing wrong ? + -set log Phase Chat Connect Carrier lcp ipcp ccp command + + You should first read the + ppp man page and the + ppp section of the handbook. Enable logging with + the command -This command may be typed at the ppp command prompt or -it may be entered in the /etc/ppp/ppp.conf configuration file -(the start of the default section is the best place to put it). -Make sure that /etc/syslog.conf contains the lines + set log Phase Chat Connect Carrier lcp ipcp ccp command -!ppp + This command may be typed at the + ppp command prompt or it may be + entered in the /etc/ppp/ppp.conf + configuration file (the start of the + default section is the best + place to put it). Make sure that + /etc/syslog.conf contains the lines + + !ppp *.* /var/log/ppp.log -and that the file /var/log/ppp.log exists. You can -now find out a lot about what's going on from the log file. -Don't worry if it doesn't all make sense. If you need to -get help from someone, it may make sense to them. + and that the file /var/log/ppp.log + exists. You can now find out a lot about what's going on + from the log file. Don't worry if it doesn't all make sense. + If you need to get help from someone, it may make sense to + them. -If your version of ppp doesn't understand the set log -command, you should download the -latest version. -It will build on FreeBSD version 2.1.5 and higher. - - + If your version of ppp doesn't understand the + set log command, you should download the + + latest version. It will build on FreeBSD version + 2.1.5 and higher. + + - -Ppp just hangs when I run it + + + Ppp just hangs when I run it + -This is usually because your hostname won't resolve. The best -way to fix this is to make sure that /etc/hosts is -consoluted by your resolver first by editing /etc/host.conf -and putting the hosts line first. Then, simply put an -entry in /etc/hosts for your local machine. If you have -no local network, change your localhost line: + + This is usually because your hostname won't resolve. + The best way to fix this is to make sure that + /etc/hosts is consoluted by your + resolver first by editing /etc/host.conf + and putting the hosts line first. Then, + simply put an entry in /etc/hosts for + your local machine. If you have no local network, change your + localhost line: -127.0.0.1 foo.bar.com foo localhost + 127.0.0.1 foo.bar.com foo localhost -Otherwise, simply add another entry for your host. Consult the -relevant man pages for more details. + Otherwise, simply add another entry for your host. + Consult the relevant man pages for more details. -You should be able to successfully ping -c1 `hostname` -when you're done. + You should be able to successfully + ping -c1 `hostname` when you're done. - + + - -Ppp won't dial in -auto mode + + + Ppp won't dial in -auto mode + -First, check that you've got a default route. By running -netstat -rn, -you should see two entries like this: + + First, check that you've got a default route. By running + + netstat -rn, you should see two entries like this: -Destination Gateway Flags Refs Use Netif Expire + Destination Gateway Flags Refs Use Netif Expire default 10.0.0.2 UGSc 0 0 tun0 10.0.0.2 10.0.0.1 UH 0 0 tun0 -This is assuming that you've used the addresses from the -handbook, the man page or from the ppp.conf.sample file. -If you haven't got a default route, it may be because you're -running an old version of ppp that doesn't understand the -word HISADDR in the ppp.conf file. If your version of -ppp is from before FreeBSD 2.2.5, change the + This is assuming that you've used the addresses from the + handbook, the man page or from the ppp.conf.sample file. + If you haven't got a default route, it may be because you're + running an old version of ppp + that doesn't understand the word HISADDR + in the ppp.conf file. If your version of + ppp is from before FreeBSD + 2.2.5, change the -add 0 0 HISADDR + add 0 0 HISADDR -line to one saying + line to one saying -add 0 0 10.0.0.2 + add 0 0 10.0.0.2 -Another reason for the default route line being missing is that -you have mistakenly set up a default router in your -/etc/rc.conf file (this file was called -/etc/sysconfig prior to release 2.2.2), and you have -omitted the line saying + Another reason for the default route line being missing + is that you have mistakenly set up a default router in your + + /etc/rc.conf file (this file was called + /etc/sysconfig prior to release 2.2.2), + and you have omitted the line saying -delete ALL + delete ALL -from ppp.conf. If this is the case, go back to the -Final system configuration section of the handbook. + from ppp.conf. If this is the case, + go back to the + Final system configuration section of the + handbook. - + + - -What does No route to host mean + + + What does No route to host mean + -This error is usually due to a missing + + This error is usually due to a missing -MYADDR: + MYADDR: delete ALL add 0 0 HISADDR -section in your /etc/ppp/ppp.linkup file. This is -only necessary if you have a dynamic IP address or don't know the -address of your gateway. If you're using interactive mode, you can -type the following after entering packet mode (packet mode is -indicated by the capitalized PPP in the prompt): + section in your /etc/ppp/ppp.linkup + file. This is only necessary if you have a dynamic IP address + or don't know the address of your gateway. If you're using + interactive mode, you can type the following after entering + packet mode (packet mode is + indicated by the capitalized PPP in the + prompt): -delete ALL + delete ALL add 0 0 HISADDR -Refer to the PPP and Dynamic IP addresses section of the handbook -for further details. + Refer to the + PPP and Dynamic IP addresses section of the handbook + for further details. - + + - -My connection drops after about 3 minutes + + + My connection drops after about 3 minutes + -The default ppp timeout is 3 minutes. This can be adjusted -with the line + + The default ppp timeout is 3 minutes. This can be + adjusted with the line -set timeout NNN + set timeout NNN -where NNN is the number of seconds of inactivity before the -connection is closed. If NNN is zero, the connection is -never closed due to a timeout. It is possible to put this command in -the ppp.conf file, or to type it at the prompt in -interactive mode. It is also possible to adjust it on the fly while -the line is active by connecting to ppps server socket using -telnet -or pppctl. Refer to the -ppp man -page for further details. + where NNN is the number of + seconds of inactivity before the connection is closed. If + NNN is zero, the connection is never + closed due to a timeout. It is possible to put this command in + the ppp.conf file, or to type it at the + prompt in interactive mode. It is also possible to adjust it on + the fly while the line is active by connecting to ppps server socket using telnet + or pppctl. + Refer to the ppp man + page for further details. - + + - -My connection drops under heavy load + + + My connection drops under heavy load + -If you have Link Quality Reporting (LQR) configured, it is -possible that too many LQR packets are lost between your -machine and the peer. Ppp deduces that the line must therefore -be bad, and disconnects. Prior to FreeBSD version 2.2.5, -LQR was enabled by default. It is now disabled by default. -LQR can be disabled with the line + + If you have Link Quality Reporting (LQR) configured, + it is possible that too many LQR packets are lost between + your machine and the peer. Ppp deduces that the line must + therefore be bad, and disconnects. Prior to FreeBSD version + 2.2.5, LQR was enabled by default. It is now disabled by + default. LQR can be disabled with the line -disable lqr + disable lqr - + + - -My connection drops after a random amount of time + + + My connection drops after a random amount of time + -Sometimes, on a noisy phone line or even on a line with -call waiting enabled, your modem may hang up because it -thinks (incorrectly) that it lost carrier. + + Sometimes, on a noisy phone line or even on a line with + call waiting enabled, your modem may hang up because it + thinks (incorrectly) that it lost carrier. -There's a setting on most modems for determining how tolerant -it should be to temporary losses of carrier. On a USR -Sportster for example, this is measured by the S10 register in -tenths of a second. To make your modem more forgiving, you could -add the following send-expect sequence to your dial string: + There's a setting on most modems for determining how + tolerant it should be to temporary losses of carrier. On a + USR Sportster for example, this is measured by the S10 + register in tenths of a second. To make your modem more + forgiving, you could add the following send-expect sequence + to your dial string: -set dial "...... ATS10=10 OK ......" + set dial "...... ATS10=10 OK ......" -Refer to your modem manual for details. + Refer to your modem manual for details. - + + - -My connection hangs after a random amount of time + + + My connection hangs after a random amount of time + -Many people experience hung connections with no apparent -explaination. The first thing to establish is which side of the -link is hung. + Many people experience hung connections with no apparent + explaination. The first thing to establish is which side of + the link is hung. -If you are using an external modem, you can simply try using -ping to see if the TD light is flashing when you -transmit data. If it flashes (and the RD light doesn't), the -problem is with the remote end. If TD doesn't flash, the problem -is local. With an internal modem, you'll need to use the set -server command in your ppp.conf file. When the hang occurs, -connect to ppp using pppctl. If your network connection suddenly -revives (ppp was revived due to the activity on the diagnostic socket) -or if you can't connect (assuming the set socket command -succeeded at startup time), the problem is local. If you can connect -and things are still hung, enable local async logging with set log -local async and use ping from another window or terminal to make -use of the link. The async logging will show you the data being -transmitted and received on the link. If data is going out and not -coming back, the problem is remote. + If you are using an external modem, you can simply try + using ping to see if the + TD light is flashing when you transmit data. + If it flashes (and the RD light doesn't), + the problem is with the remote end. If TD + doesn't flash, the problem is local. With an internal modem, + you'll need to use the set server command in + your ppp.conf file. When the hang occurs, + connect to ppp using pppctl. If your network connection + suddenly revives (ppp was revived due to the activity on the + diagnostic socket) or if you can't connect (assuming the + set socket command succeeded at startup + time), the problem is local. If you can connect and things are + still hung, enable local async logging with set log + local async and use ping from + another window or terminal to make use of the link. The async + logging will show you the data being transmitted and received + on the link. If data is going out and not coming back, the + problem is remote. -Having established whether the problem is local or remote, -you now have two possibilities: - - + Having established whether the problem is local or remote, + you now have two possibilities: + + - -The remote end isn't responding + + + The remote end isn't responding + -There's very little you can do about this. Most ISPs will -refuse to help if you're not running a Microsoft OS. You can -enable lqr in your ppp.conf file, allowing ppp to -detect the remote failure and hang up, but this detection is -relatively slow and therefore not that useful. You may want -to avoid telling your ISP that you're running user-ppp.... + + There's very little you can do about this. Most ISPs + will refuse to help if you're not running a Microsoft OS. + You can enable lqr in your + ppp.conf file, allowing ppp to detect + the remote failure and hang up, but this detection is + relatively slow and therefore not that useful. You may want to + avoid telling your ISP that you're running user-ppp.... -First, try disabling all local compression by adding the -following to your configuration: + First, try disabling all local compression by adding the + following to your configuration: -disable pred1 deflate deflate24 protocomp acfcomp shortseq vj + disable pred1 deflate deflate24 protocomp acfcomp shortseq vj deny pred1 deflate deflate24 protocomp acfcomp shortseq vj -Then reconnect to ensure that this makes no difference. -If things improve or if the problem is solved completely, -determine which setting makes the difference through trial -and error. This will provide good amunition when you contact -your ISP (although it may make it apparent that you're not -running a Microsoft product). + Then reconnect to ensure that this makes no difference. + If things improve or if the problem is solved completely, + determine which setting makes the difference through trial + and error. This will provide good amunition when you contact + your ISP (although it may make it apparent that you're not + running a Microsoft product). -Before contacting your ISP, enable async logging locally -and wait until the connection hangs again. This may use up -quite a bit of disk space. The last data read from the port -may be of interest. It is usually ascii data, and may even -describe the problem (Memory fault, core dumped ?). + Before contacting your ISP, enable async logging locally + and wait until the connection hangs again. This may use up + quite a bit of disk space. The last data read from the port + may be of interest. It is usually ascii data, and may even + describe the problem + (Memory fault, core dumped ?). -If your ISP is helpful, they should be able to enable logging -on their end, then when the next link drop occurs, they may be -able to tell you why their side is having a problem. Feel free -to send the details to &a.brian;, or even to ask your ISP to -contact me directly. + If your ISP is helpful, they should be able to enable + logging on their end, then when the next link drop occurs, + they may be able to tell you why their side is having a + problem. Feel free to send the details to &a.brian;, or + even to ask your ISP to contact me directly. - + + - -Ppp is hung + + + Ppp is hung + -Your best bet here is to rebuild ppp by adding CFLAGS+=-g -and STRIP= to the end of the Makefile, then doing a -make clean && make && make install. When -ppp hangs, find the ppp process id with ps ajxww | fgrep ppp -and run gdb ppp PID. From the gdb prompt, you can then use -bt to get a stack trace. + + Your best bet here is to rebuild ppp by adding + CFLAGS+=-g and STRIP= + to the end of the Makefile, then doing a + make clean && make && make + install. When ppp hangs, find the ppp process id + with ps ajxww | fgrep ppp and run + gdb ppp PID. + From the gdb prompt, you can then use bt + to get a stack trace. -Send the results to brian@Awfulhak.org. + Send the results to brian@Awfulhak.org. - + + - -Nothing happens after the Login OK! message + + + Nothing happens after the Login OK! message + -Prior to FreeBSD version 2.2.5, once the link was established, -ppp would wait for the peer to initiate the Line Control -Protocol (LCP). Many ISPs will not initiate negotiations and -expect the client to do so. To force ppp to initiate -the LCP, use the following line: + + Prior to FreeBSD version 2.2.5, once the link was + established, ppp + would wait for the peer to initiate the Line Control Protocol + (LCP). Many ISPs will not initiate negotiations and expect + the client to do so. To force + ppp to initiate the LCP, use the + following line: -set openmode active + set openmode active -Note: It usually does no harm if both sides initiate -negotiation, so openmode is now active by default. However, -the next section explains when it does do some harm. + Note: It usually does no + harm if both sides initiate negotiation, so openmode is now + active by default. However, the next section explains when + it does do some harm. - + + - -I keep seeing errors about magic being the same + + + I keep seeing errors about magic being the same + -Occasionally, just after connecting, you may see messages in -the log that say magic is the same. Sometimes, these -messages are harmless, and sometimes one side or the other -exits. Most ppp implementations cannot survive this problem, and -even if the link seems to come up, you'll see repeated configure -requests and configure acknowledgements in the log file until -ppp eventually gives up and closes the connection. + + Occasionally, just after connecting, you may see messages + in the log that say magic is the same. + Sometimes, these messages are harmless, and sometimes one side + or the other exits. Most ppp implementations cannot survive + this problem, and even if the link seems to come up, you'll see + repeated configure requests and configure acknowledgements in + the log file until ppp eventually gives up and closes the + connection. -This normally happens on server machines with slow disks that -are spawning a getty on the port, and executing ppp from a -login script or program after login. I've also heard reports -of it happening consistently when using slirp. The reason is -that in the time taken between getty exiting and ppp starting, the -client-side ppp starts sending Line Control Protocol (LCP) -packets. Because ECHO is still switched on for the port on -the server, the client ppp sees these packets reflect back. + This normally happens on server machines with slow disks + that are spawning a getty on the port, and executing ppp from + a login script or program after login. I've also heard reports + of it happening consistently when using slirp. The reason is + that in the time taken between getty exiting and ppp starting, + the client-side ppp starts sending Line Control Protocol (LCP) + packets. Because ECHO is still switched on for the port on + the server, the client ppp sees these packets + reflect back. -One part of the LCP negotiation is to establish a magic number -for each side of the link so that reflections can be detected. -The protocol says that when the peer tries to negotiate -the same magic number, a NAK should be sent and a new magic -number should be chosen. During the period that the server -port has ECHO turned on, the client ppp sends LCP packets, -sees the same magic in the reflected packet and NAKs it. It -also sees the NAK reflect (which also means ppp must change -its magic). This produces a potentially enormous number of -magic number changes, all of which are happily piling into -the server's tty buffer. As soon as ppp starts on the server, -it's flooded with magic number changes and almost immediately -decides it's tried enough to negotiate LCP and gives up. -Meanwhile, the client, who no longer sees the reflections, -becomes happy just in time to see a hangup from the server. + One part of the LCP negotiation is to establish a magic + number for each side of the link so that + reflections can be detected. The protocol says + that when the peer tries to negotiate the same magic number, a + NAK should be sent and a new magic number should be chosen. + During the period that the server port has ECHO turned on, the + client ppp sends LCP packets, sees the same magic in the + reflected packet and NAKs it. It also sees the NAK reflect + (which also means ppp must change its magic). This produces a + potentially enormous number of magic number changes, all of + which are happily piling into the server's tty buffer. As soon + as ppp starts on the server, it's flooded with magic number + changes and almost immediately decides it's tried enough to + negotiate LCP and gives up. Meanwhile, the client, who no + longer sees the reflections, becomes happy just in time to see + a hangup from the server. -This can be avoided by allowing the peer to start negotiating -with the following line in your ppp.conf file: + This can be avoided by allowing the peer to start + negotiating with the following line in your ppp.conf + file: -set openmode passive + set openmode passive -This tells ppp to wait for the server to initiate LCP -negotiations. Some servers however may never initiate negotiations. -If this is the case, you can do something like: + This tells ppp to wait for the server to initiate LCP + negotiations. Some servers however may never initiate + negotiations. If this is the case, you can do something + like: -set openmode active 3 + set openmode active 3 -This tells ppp to be passive for 3 seconds, and then to start -sending LCP requests. If the peer starts sending requests during -this period, ppp will immediately respond rather than waiting for -the full 3 second period. + This tells ppp to be passive for 3 seconds, and then to + start sending LCP requests. If the peer starts sending + requests during this period, ppp will immediately respond + rather than waiting for the full 3 second period. - + + - - LCP negotiations continue 'till the connection is closed - + + + LCP negotiations continue 'till the connection is + closed + -There is currently an implementation mis-feature in ppp -where it doesn't associate LCP, CCP & IPCP responses with -their original requests. As a result, if one ppp -implementation is more than 6 seconds slower than the other side, -the other side will send two additional LCP configuration requests. -This is fatal. + + There is currently an implementation mis-feature in + ppp where it doesn't associate + LCP, CCP & IPCP responses with their original requests. As + a result, if one ppp + implementation is more than 6 seconds slower than the other + side, the other side will send two additional LCP configuration + requests. This is fatal. -Consider two implementations, A and B. A starts -sending LCP requests immediately after connecting and B takes -7 seconds to start. When B starts, A has sent 3 LCP -REQs. We're assuming the line has ECHO switched off, otherwise -we'd see magic number problems as described in the previous section. -B sends a REQ, then an ACK to the first of A's REQs. -This results in A entering the OPENED state and sending -and ACK (the first) back to B. In the meantime, B sends -back two more ACKs in response to the two additional REQs sent by -A before B started up. B then receives the first -ACK from A and enters the OPENED state. A receives -the second ACK from B and goes back to the REQ-SENT state, -sending another (forth) REQ as per the RFC. It then receives the -third ACK and enters the OPENED state. In the meantime, -B receives the forth REQ from A, resulting in it reverting -to the ACK-SENT state and sending another (second) REQ and -(forth) ACK as per the RFC. A gets the REQ, goes into -REQ-SENT and sends another REQ. It immediately receives the -following ACK and enters OPENED. + Consider two implementations, + A and B. A starts + sending LCP requests immediately after connecting and B takes 7 seconds to start. When B starts, A + has sent 3 LCP REQs. We're assuming the line has ECHO switched + off, otherwise we'd see magic number problems as described in + the previous section. B sends a + REQ, then an ACK to the first of A's REQs. This results in A entering the OPENED + state and sending and ACK (the first) back to B. In the meantime, B sends back two more ACKs in response to + the two additional REQs sent by A + before B started up. B then receives the first ACK from + A and enters the + OPENED state. A receives the second ACK from B and goes back to the REQ-SENT state, sending another (forth) REQ + as per the RFC. It then receives the third ACK and enters the + OPENED state. In the meantime, B receives the forth REQ from A, resulting in it reverting to the + ACK-SENT state and sending + another (second) REQ and (forth) ACK as per the RFC. A gets the REQ, goes into REQ-SENT and sends another REQ. It + immediately receives the following ACK and enters + OPENED. -This goes on 'till one side figures out that they're getting -nowhere and gives up. + This goes on 'till one side figures out that they're + getting nowhere and gives up. -The best way to avoid this is to configure one side to be -passive - that is, make one side wait for the other to start -negotiating. This can be done with the + The best way to avoid this is to configure one side to be + passive - that is, make one side + wait for the other to start negotiating. This can be done + with the -set openmode passive + set openmode passive -command. Care should be taken with this option. You should also -use the + command. Care should be taken with this option. You + should also use the -set stopped N + set stopped N -command to limit the amount of time that ppp waits for the peer -to begin negotiations. Alternatively, the + command to limit the amount of time that + ppp waits for the peer to begin + negotiations. Alternatively, the -set openmode active N + set openmode active N -command (where N is the number of seconds to wait before -starting negotiations) can be used. Check the manual page for -details. + command (where N is the + number of seconds to wait before starting negotiations) can be + used. Check the manual page for details. - + + - -Ppp locks up shortly after connecting + + + Ppp locks up shortly after connecting + -Prior to version 2.2.5 of FreeBSD, it was possible that your -link was disabled shortly after connection due to ppp -mis-handling Predictor1 compression negotiation. This would -only happen if both sides tried to negotiate different -Compression Control Protocols (CCP). This problem is now -corrected, but if you're still running an old version of -ppp, the problem can be circumvented with the line + + Prior to version 2.2.5 of FreeBSD, it was possible that + your link was disabled shortly after connection due to + ppp mis-handling Predictor1 + compression negotiation. This would only happen if both sides + tried to negotiate different Compression Control Protocols + (CCP). This problem is now corrected, but if you're still + running an old version of ppp, + the problem can be circumvented with the line -disable pred1 + disable pred1 - + + - -Ppp locks up when I shell out to test it + + + Ppp locks up when I shell out to test it + -When you execute the shell or ! command, -ppp -executes a shell (or if you've passed any arguements, ppp -will execute those arguements). Ppp will wait for the command -to complete before continuing. If you attempt to use the -ppp link while running the command, the link will appear to have -frozen. This is because ppp is waiting for the command -to complete. + + When you execute the shell or + ! command, ppp executes a + shell (or if you've passed any arguements, + ppp will execute those arguements). Ppp will + wait for the command to complete before continuing. If you + attempt to use the ppp link while running the command, the link + will appear to have frozen. This is because + ppp is waiting for the command to + complete. -If you wish to execute commands like this, use the -!bg command instead. This will execute the given command -in the background, and ppp can continue to service the link. + If you wish to execute commands like this, use the + !bg command instead. This will execute + the given command in the background, and ppp can continue to + service the link. - + + - -Ppp over a null-modem cable never exits + + + Ppp over a null-modem cable never exits + -There is no way for ppp to automatically determine that -a direct connection has been dropped. This is due to the -lines that are used in a null-modem serial cable. When using -this sort of connection, LQR should always be enabled with -the line + + There is no way for ppp to + automatically determine that a direct connection has been + dropped. This is due to the lines that are used in a + null-modem serial cable. When using this sort of connection, + LQR should always be enabled with the line -enable lqr + enable lqr -LQR is accepted by default if negotiated by the peer. + LQR is accepted by default if negotiated by the peer. - + + - -Why does ppp dial for no reason in -auto mode + + + Why does ppp dial for no reason in -auto mode + -If ppp is dialing unexpectedly, you must determine the -cause, and set up Dial filters (dfilters) to prevent such dialing. + If ppp is dialing + unexpectedly, you must determine the cause, and set up Dial + filters (dfilters) to prevent such dialing. -To determine the cause, use the following line: + To determine the cause, use the following line: -set log +tcp/ip + set log +tcp/ip -This will log all traffic through the connection. The next -time the line comes up unexpectedly, you will see the reason -logged with a convenient timestamp next to it. + This will log all traffic through the connection. The + next time the line comes up unexpectedly, you will see the + reason logged with a convenient timestamp next to it. -You can now disable dialing under these circumstances. Usually, -this sort of problem arises due to DNS lookups. To prevent -DNS lookups from establishing a connection (this will not -prevent ppp from passing the packets through an established -connection), use the following: + You can now disable dialing under these circumstances. + Usually, this sort of problem arises due to DNS lookups. To + prevent DNS lookups from establishing a connection (this will + not prevent + ppp from passing the packets + through an established connection), use the following: -set dfilter 1 deny udp src eq 53 + set dfilter 1 deny udp src eq 53 set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0 -This is not always suitable, as it will effectively break your -demand-dial capabilities - most programs will need a DNS lookup -before doing any other network related things. + This is not always suitable, as it will effectively break + your demand-dial capabilities - most programs will need a DNS + lookup before doing any other network related things. -In the DNS case, you should try to determine what is actually -trying to resolve a host name. A lot of the time, -sendmail is the culprit. You should make sure that you tell -sendmail not to do any DNS lookups in its configuration file. See -the section on Mail Configuration for -details on how to create your own configuration file and what should -go into it. You may also want to add the following line to your -.mc file: + In the DNS case, you should try to determine what is + actually trying to resolve a host name. A lot of the time, + + sendmail is the culprit. You should make sure that + you tell sendmail not to do any DNS lookups in its + configuration file. See the section on + Mail Configuration for details + on how to create your own configuration file and what should + go into it. You may also want to add the following line to + your .mc file: -define(`confDELIVERY_MODE', `d')dnl + define(`confDELIVERY_MODE', `d')dnl -This will make sendmail queue everything until the queue is -run (usually, sendmail is invoked with , telling it -to run the queue every 30 minutes) or until a sendmail -q -is done (perhaps from your ppp.linkup file). + This will make sendmail queue everything until the queue + is run (usually, sendmail is invoked with + , telling it to run the queue every + 30 minutes) or until a sendmail -q is done + (perhaps from your ppp.linkup file). - + + - -What do these CCP errors mean + + + What do these CCP errors mean + -I keep seeing the following errors in my log file: + + I keep seeing the following errors in my log file: -CCP: CcpSendConfigReq + CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) -This is because ppp is trying to negotiate Predictor1 -compression, and the peer does not want to negotiate any -compression at all. The messages are harmless, but if you -wish to remove them, you can disable Predictor1 compression -locally too: + This is because ppp is trying to negotiate Predictor1 + compression, and the peer does not want to negotiate any + compression at all. The messages are harmless, but if you + wish to remove them, you can disable Predictor1 compression + locally too: -disable pred1 + disable pred1 - + + - -Ppp locks up during file transfers with IO errors + + + Ppp locks up during file transfers with IO errors + -Under FreeBSD 2.2.2 and before, there was a bug in the tun -driver that prevents incoming packets of a size larger than -the tun interface's MTU size. Receipt of a packet greater than -the MTU size results in an IO error being logged via syslogd. + + Under FreeBSD 2.2.2 and before, there was a bug in the + tun driver that prevents incoming packets of a size larger + than the tun interface's MTU size. Receipt of a packet + greater than the MTU size results in an IO error being logged + via syslogd. -The ppp specification says that an MRU of 1500 should -always be accepted as a minimum, despite any LCP -negotiations, therefore it is possible that should you decrease -the MTU to less than 1500, your ISP will transmit packets of -1500 regardless, and you will tickle this non-feature - locking -up your link. + The ppp specification says that an MRU of 1500 should + always be accepted as a minimum, + despite any LCP negotiations, therefore it is possible that + should you decrease the MTU to less than 1500, your ISP will + transmit packets of 1500 regardless, and you will tickle this + non-feature - locking up your link. -The problem can be circumvented by never setting an MTU of -less than 1500 under FreeBSD 2.2.2 or before. + The problem can be circumvented by never setting an MTU of + less than 1500 under FreeBSD 2.2.2 or before. - + + - -Why doesn't ppp log my connection speed? + + + Why doesn't ppp log my connection speed? + -In order to log all lines of your modem conversation, -you must enable the following: + -set log +connect + In order to log all lines of your modem + conversation, you must enable the + following: -This will make -ppp -log everything up until the last requested expect string. + set log +connect -If you wish to see your connect speed and are using PAP or CHAP -(and therefore don't have anything to chat after the CONNECT -in the dial script - no set login script), you must make sure that -you instruct ppp to expect the whole CONNECT line, something like -this: + This will make ppp log + everything up until the last requested expect + string. -set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \ + If you wish to see your connect speed and are using PAP + or CHAP (and therefore don't have anything to + chat after the CONNECT in the dial script - no + set login script), you must make sure that + you instruct ppp to expect the whole CONNECT + line, something like this: + + set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \ \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" -Here, we get our CONNECT, send nothing, then expect a line-feed, -forcing ppp to read the whole CONNECT response. + Here, we get our CONNECT, send nothing, then expect a + line-feed, forcing ppp to read + the whole CONNECT response. - + + - -Ppp ignores the \ character in my chat script + + + Ppp ignores the \ character in my + chat script + -Ppp parses each line in your config files so that it can -interpret strings such as set phone "123 456 789" correctly -(and realize that the number is actually only one argument. -In order to specify a " character, you must escape it using -a backslash (\). + Ppp parses each line in your config files so that it can + interpret strings such as + set phone "123 456 789" correctly (and + realize that the number is actually only + one argument. In order to specify + a " character, you must escape it using a + backslash (\). -When the chat interpreter parses each argument, it re-interprets -the argument in order to find any special escape sequences such -as \P or \T (see the man page). As a result of this -double-parsing, you must remember to use the correct number of -escapes. + When the chat interpreter parses each argument, it + re-interprets the argument in order to find any special + escape sequences such as \P or + \T (see the man page). As a result of this + double-parsing, you must remember to use the correct number of + escapes. -If you wish to actually send a \ character to (say) your -modem, you'd need something like: + If you wish to actually send a \ + character to (say) your modem, you'd need something + like: -set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" + set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" -resulting in the following sequence: + resulting in the following sequence: -ATZ + ATZ OK AT\X OK -or + or -set phone 1234567 + set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" -resulting in the following sequence: + resulting in the following sequence: -ATZ + ATZ OK ATDT1234567 - + + - -Ppp gets a seg-fault, but I see no ppp.core file + + + Ppp gets a seg-fault, but I see no + ppp.core file + -Ppp (or any other program for that matter) should never -dump core. Because ppp runs with an effective user id of 0, -the operating system will not write ppps core image to disk -before terminating it. If, however ppp is actually -termating due to a segmentation violation or some other -signal that normally causes core to be dumped, and you're -sure you're using the latest version (see the start of this -section), then you should do the following: + + Ppp (or any other program for that matter) should never + dump core. Because ppp runs with an effective user id of 0, + the operating system will not write ppps core image to disk + before terminating it. If, however ppp + is actually termating due to a + segmentation violation or some other signal that normally + causes core to be dumped, and + you're sure you're using the latest version (see the start of + this section), then you should do the following: -&prompt.user; tar xfz ppp-*.src.tar.gz + &prompt.user; tar xfz ppp-*.src.tar.gz &prompt.user; cd ppp*/ppp &prompt.user; echo STRIP= >>Makefile &prompt.user; echo CFLAGS+=-g >>Makefile @@ -8375,16 +8688,16 @@ section), then you should do the following: &prompt.root; make install &prompt.root; chmod 555 /usr/sbin/ppp -You will now have a debuggable version of ppp installed. You -will have to be root to run ppp as all of its privileges have -been revoked. When you start ppp, take a careful note of what -your current directory was at the time. + You will now have a debuggable version of ppp installed. + You will have to be root to run ppp as all of its privileges + have been revoked. When you start ppp, take a careful note + of what your current directory was at the time. -Now, if and when ppp receives the segmentation violation, it -will dump a core file called ppp.core. You should then do the -following: + Now, if and when ppp receives the segmentation violation, + it will dump a core file called ppp.core. You should then do + the following: -&prompt.user; su + &prompt.user; su &prompt.root; gdb /usr/sbin/ppp ppp.core (gdb) bt ..... @@ -8395,812 +8708,1047 @@ following: (gdb) l ..... -All of this information should be given alongside your -question, making it possible to diagnose the problem. + All of this information should be given alongside your + question, making it possible to diagnose the problem. -If you're familiar with gdb, you may wish to find out some -other bits and pieces such as what actually caused the dump and -the addresses & values of the relevant variables. + If you're familiar with gdb, you may wish to find out some + other bits and pieces such as what actually caused the dump and + the addresses & values of the relevant variables. - + + - - The process that forces a dial in auto mode never connects - + + + The process that forces a dial in auto mode never + connects + -This was a known problem with ppp set up to negotiate -a dynamic local IP number with the peer in auto mode. It is -fixed in the latest version - search the man page for iface. + + This was a known problem with + ppp set up to negotiate a + dynamic local IP number with the peer in auto mode. It is + fixed in the latest version - search the man page for + iface. -The problem was that when that initial program calls -connect(2), the IP number of the tun interface is -assigned to the socket endpoint. The kernel creates the first -outgoing packet and writes it to the tun device. Ppp then -reads the packet and establishes a connection. If, as a result -of ppps dynamic IP assignment, the interface address is changed, -the original socket endpoint will be invalid. Any subsequent -packets sent to the peer will usually be dropped. Even if -they aren't, any responses will not route back to the originating -machine as the IP number is no longer owned by that machine. + The problem was that when that initial program calls + + connect(2), the IP number of the tun interface is + assigned to the socket endpoint. The kernel creates the first + outgoing packet and writes it to the tun device. Ppp then reads the packet and establishes a + connection. If, as a result of ppps dynamic IP assignment, the interface + address is changed, the original socket endpoint will be + invalid. Any subsequent packets sent to the peer will usually + be dropped. Even if they aren't, any responses will not route + back to the originating machine as the IP number is no longer + owned by that machine. -There are several theoretical ways to approach this problem. -It would be nicest if the peer would re-assign the same IP number -if possible :-) The current version of ppp does this, -but most other implementations don't. + There are several theoretical ways to approach this + problem. It would be nicest if the peer would re-assign the + same IP number if possible :-) + The current version of ppp does + this, but most other implementations don't. -The easiest method from our side would be to never change the -tun interface IP number, but instead to change all outgoing packets -so that the source IP number is changed from the interface IP to -the negotiated IP on the fly. This is essentially what the -iface-alias option in the latest version of ppp is -doing (with the help of libalias(3) -and ppp's switch) - it's maintaining all previous -interface addresses and NATing them to the last negotiated address. + The easiest method from our side would be to never change + the tun interface IP number, but instead to change all outgoing + packets so that the source IP number is changed from the + interface IP to the negotiated IP on the fly. This is + essentially what the iface-alias option in + the latest version of ppp is + doing (with the help of + libalias(3) and ppp's switch) - + it's maintaining all previous interface addresses and NATing + them to the last negotiated address. -Another alternative (and probably the most reliable) would be -to implement a system call that changes all bound sockets from one -IP to another. Ppp would use this call to modify the -sockets of all existing programs when a new IP number is -negotiated. The same system call could be used by dhcp clients -when they are forced to re-bind() their sockets. + Another alternative (and probably the most reliable) would + be to implement a system call that changes all bound sockets + from one IP to another. Ppp would + use this call to modify the sockets of all existing programs + when a new IP number is negotiated. The same system call could + be used by dhcp clients when they are forced to re-bind() their + sockets. -Yet another possibility is to allow an interface to be brought -up without an IP number. Outgoing packets would be given -an IP number of 255.255.255.255 up until the first SIOCAIFADDR -ioctl is done. This would result in fully binding the socket. It -would be up to ppp to change the source IP number, but only if -it's set to 255.255.255.255, and only the IP number and IP checksum -would need to change. This, however is a bit of a hack as -the kernel would be sending bad packets to an improperly -configured interface, on the assumption that some other mechanism -is capable of fixing things retrospectively. + Yet another possibility is to allow an interface to be + brought up without an IP number. Outgoing packets would be + given an IP number of 255.255.255.255 up until the first + SIOCAIFADDR ioctl is done. This would result in fully binding + the socket. It would be up to ppp + to change the source IP number, but only if it's set to + 255.255.255.255, and only the IP number and IP checksum would + need to change. This, however is a bit of a hack as the kernel + would be sending bad packets to an improperly configured + interface, on the assumption that some other mechanism is + capable of fixing things retrospectively. - + + - -Why don't most games work with the -nat switch + + + Why don't most games work with the -nat switch + -The reason games and the like don't work when libalias is -in use is that the machine on the outside will try to open a -connection or send (unsolicited) UDP packets to the machine -on the inside. The NAT software doesn't know that -it should send these packets to the interior machine. + + The reason games and the like don't work when libalias + is in use is that the machine on the outside will try to open a + connection or send (unsolicited) UDP packets to the machine on + the inside. The NAT software doesn't know that it should send + these packets to the interior machine. -To make things work, make sure that the only thing running -is the software that you're having problems with, then either -run tcpdump on the tun interface of the gateway or enable ppp -tcp/ip logging (set log +tcp/ip) on the gateway. + To make things work, make sure that the only thing + running is the software that you're having problems with, then + either run tcpdump on the tun interface of the gateway or + enable ppp tcp/ip logging (set log +tcp/ip) + on the gateway. -When you start the offending software, you should see packets -passing through the gateway machine. When something comes back -from the outside, it'll be dropped (that's the problem). Note -the port number of these packets then shut down the offending -software. Do this a few times to see if the port numbers are -consistent. If they are, then the following line in the relevant -section of /etc/ppp/ppp.conf will make the software functional: + When you start the offending software, you should see + packets passing through the gateway machine. When something + comes back from the outside, it'll be dropped (that's the + problem). Note the port number of these packets then shut down + the offending software. Do this a few times to see if the port + numbers are consistent. If they are, then the following line in + the relevant section of /etc/ppp/ppp.conf will make the + software functional: -nat port proto internalmachine:port port + nat port proto internalmachine:port port -where proto is either tcp or udp, -internalmachine is the machine that you want the packets -to be sent to and port is the destination port number of -the packets. + where proto is either + tcp or udp, + internalmachine is the machine that + you want the packets to be sent to and + port is the destination port number + of the packets. -You won't be able to use the software on other machines -without changing the above command, and running the software -on two internal machines at the same time is out of the question -- after all, the outside world is seeing your entire internal -network as being just a single machine. + You won't be able to use the software on other machines + without changing the above command, and running the software + on two internal machines at the same time is out of the question + - after all, the outside world is seeing your entire internal + network as being just a single machine. -If the port numbers aren't consistent, there are three more -options: + If the port numbers aren't consistent, there are three + more options: -1) Submit support in libalias. Examples of special -cases can be found in /usr/src/lib/libalias/alias_*.c (alias_ftp.c -is a good prototype). This usually involves reading certain -recognised outgoing packets, identifying the instruction that -tells the outside machine to initiate a connection back to the -internal machine on a specific (random) port and setting up a -route in the alias table so that the subsequent packets -know where to go. + 1) Submit support in + libalias. Examples of special cases can be found + in /usr/src/lib/libalias/alias_*.c + (alias_ftp.c is a good prototype). This + usually involves reading certain recognised outgoing packets, + identifying the instruction that tells the outside machine to + initiate a connection back to the internal machine on a + specific (random) port and setting up a route in + the alias table so that the subsequent packets know where to + go. -This is the most difficult solution, but it is the best and -will make the software work with multiple machines. + This is the most difficult solution, but it is the best + and will make the software work with multiple machines. -2) Use a proxy. The application may support socks5 -for example, or (as in the cvsup case) may have a passive -option that avoids ever requesting that the peer open connections -back to the local machine. + 2) Use a proxy. The + application may support socks5 for example, or (as in the + cvsup case) may have a passive + option that avoids ever requesting that the peer open + connections back to the local machine. -3) Redirect everything to the internal machine using -nat addr. This is the sledge-hammer approach. - - + 3) Redirect everything to + the internal machine using nat addr. This + is the sledge-hammer approach. + + - -Has anybody made a list of useful port numbers ? + + + Has anybody made a list of useful port numbers ? + -Not yet, but this is intended to grow into such a list (if -any interest is shown). In each example, internal should -be replaced with the IP number of the machine playing the game. + Not yet, but this is intended to grow into such a list + (if any interest is shown). In each example, + internal should be replaced with + the IP number of the machine playing the game. - + + + Asheron's Call - -Asheron's Call - + nat port udp + internal + :65000 65000 -nat port udp internal:65000 65000 + Manually change the port number within the game to + 65000. If you've got a number of machines that you wish + to play on assign a unique port number for each (i.e. + 65001, 65002, etc) and add a nat port + line for each one. + -Manually change the port number within the game to 65000. -If you've got a number of machines that you wish to play on assign -a unique port number for each (i.e. 65001, 65002, etc) and add a -nat port line for each one. - + + Half Life - -Half Life - + nat port udp + internal:27005 + 27015 + -nat port udp internal:27005 27015 - + + PCAnywhere 8.0 - -PCAnywhere 8.0 - + nat port udp + internal:5632 + 5632 -nat port udp internal:5632 5632 + nat port tcp + internal:5631 + 5631 + -nat port tcp internal:5631 5631 - + + Quake - -Quake - + nat port udp + internal:6112 + 6112 -nat port udp internal:6112 6112 + Alternatively, you may want to take a look at + www.battle.net for Quake proxy support. + -Alternatively, you may want to take a look at -www.battle.net for Quake proxy support. - + + Quake 2 - -Quake 2 - + nat port udp + internal:27901 + 27910 + -nat port udp internal:27901 27910 - + + Red Alert - -Red Alert - + nat port udp + internal:8675 + 8675 -nat port udp internal:8675 8675 + nat port udp + internal:5009 + 5009 + + -nat port udp internal:5009 5009 - + + - + + + What are FCS errors ? + - + + FCS stands for Frame + Check + Sequence. Each ppp packet + has a checksum attached to ensure that the data being + received is the data being sent. If the FCS of an incoming + packet is incorrect, the packet is dropped and the HDLC FCS + count is increased. The HDLC error values can be displayed + using the show hdlc command. - -What are FCS errors ? + If your link is bad (or if your serial driver is dropping + packets), you will see the occasional FCS error. This is not + usually worth worrying about although it does slow down the + compression protocols substantially. If you have an external + modem, make sure your cable is properly shielded from + interference - this may eradicate the problem. -FCS stands for Frame Check Sequence. Each -ppp packet has a checksum attached to ensure that the data -being received is the data being sent. If the FCS of an -incoming packet is incorrect, the packet is dropped and the -HDLC FCS count is increased. The HDLC error values can be -displayed using the show hdlc command. + If your link freezes as soon as you've connected and you + see a large number of FCS errors, this may be because your link + is not 8 bit clean. Make sure your modem is not using software + flow control (XON/XOFF). If your datalink + must use software flow control, use the + command set accmap 0x000a0000 to tell + ppp to escape the ^Q and + ^S characters. -If your link is bad (or if your serial driver is dropping -packets), you will see the occasional FCS error. This is not -usually worth worrying about although it does slow down the -compression protocols substantially. If you have an external -modem, make sure your cable is properly shielded from -interference - this may eradicate the problem. + Another reason for seeing too many FCS errors may be that + the remote end has stopped talking PPP. You + may want to enable async logging at this + point to determine if the incoming data is actually a login or + shell prompt. If you have a shell prompt at the remote end, + it's possible to terminate ppp without dropping the line by + using the close lcp command (a following + term command will reconnect you to the shell + on the remote machine. -If your link freezes as soon as you've connected and you see -a large number of FCS errors, this may be because your link is -not 8 bit clean. Make sure your modem is not using software -flow control (XON/XOFF). If your datalink must use -software flow control, use the command -set accmap 0x000a0000 to tell ppp to escape -the ^Q and ^S characters. + If nothing in your log file indicates why the link might + have been terminated, you should ask the remote administrator + (your ISP?) why the session was terminated. -Another reason for seeing too many FCS errors may be that -the remote end has stopped talking PPP. You may want to -enable async logging at this point to determine if the -incoming data is actually a login or shell prompt. If you -have a shell prompt at the remote end, it's possible to -terminate ppp without dropping the line by using the -close lcp command (a following term command -will reconnect you to the shell on the remote machine. + + -If nothing in your log file indicates why the link might -have been terminated, you should ask the remote administrator -(your ISP?) why the session was terminated. + + + Why do MacOS and Windows 98 connections freeze when + running PPPoE on the gateway + - + + Thanks to Michael Wozniak + mwozniak@netcom.ca for figuring this out and + Dan Flemming danflemming@mac.com for the Mac + solution: - + This is due to what's called a Black Hole + router. MacOS and Windows 98 (and maybe other Microsoft OSs) + send TCP packets with a requested segment size too big to fit + into a PPPoE frame (MTU is 1500 by default for ethernet) + and have the don't + fragment bit set (default of TCP) and the Telco router + is not sending ICMP must fragment back to the + www site you are trying to load. When the www server is sending + you frames that don't fit into the PPPoE pipe the Telco router + drops them on the floor and your page doesn't load (some + pages/graphics do as they are smaller than a MSS.) This seems + to be the default of most Telco PPPoE configurations (if only + they knew how to program a router... sigh...) - - Why do MacOS and Windows 98 connections freeze when running PPPoE on the gateway - + One fix is to use regedit on your 95/98 boxes to add the + following registry entry... - - - - Thanks to Michael Wozniak mwozniak@netcom.ca for figuring - this out and Dan Flemming danflemming@mac.com for the Mac - solution: - - - - This is due to what's called a Black Hole router. MacOS and Windows 98 (and - maybe other Microsoft OSs) send TCP packets with a requested - segment size too big to fit into a PPPoE frame (MTU is 1500 by default - for ethernet) and have the don't fragment - bit set (default of TCP) and the Telco router is not sending ICMP must - fragment back to the www site you are trying to load. When the www - server is sending you frames that don't fit into the PPPoE pipe the Telco - router drops them on the floor and your page doesn't load (some - pages/graphics do as they are smaller than a MSS.) This seems to be the - default of most Telco PPPoE configurations (if only they knew how to - program a router... sigh...) - - - - One fix is to use regedit on your 95/98 boxes to add the following - registry entry... - - - + HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU - - It should be a string with a value 1450 (more accurately it - should be 1464 to fit TCP packets into a PPPoE frame - perfectly but the 1450 gives you a margin of error for - other IP protocols you may encounter). - + It should be a string with a value 1450 + (more accurately it should be 1464 to fit TCP + packets into a PPPoE frame perfectly but the + 1450 gives you a margin of error for other IP + protocols you may encounter). - - Refer to MS KB # Q158474 - Windows TCPIP Registry Entries - and Q120642 - TCPIP & NBT Configuration Parameters for Windows NT - for more information on changing Windoze MTU to work with a - FreeBSD/NAT/PPPoE router. - + Refer to MS KB # Q158474 - Windows TCPIP Registry + Entries and Q120642 - TCPIP & NBT Configuration + Parameters for Windows NT for more information on + changing Windoze MTU to work with a FreeBSD/NAT/PPPoE + router. - - Unfortunately, MacOS does not provide an interface for changing TCP/IP - settings. However, there is commercial software available, such as - OTAdvancedTuner (OT for OpenTransport, the MacOS TCP/IP stack) by - Sustainable Softworks, - that will allow users to customize TCP/IP settings. MacOS NAT users - should select ip_interface_MTU from the drop-down - menu, enter 1450 instead of 1500 - in the box, click the box next to Save as Auto - Configure, and click Make Active. - + Unfortunately, MacOS does not provide an interface for + changing TCP/IP settings. However, there is commercial software + available, such as OTAdvancedTuner (OT for OpenTransport, the + MacOS TCP/IP stack) by Sustainable Softworks, + that will allow users to customize TCP/IP settings. MacOS NAT + users should select ip_interface_MTU from + the drop-down menu, enter 1450 instead of + 1500 in the box, click the box next to + Save as Auto Configure, and click + Make Active. - - + + - -None of this helps - I'm desperate ! + + + None of this helps - I'm desperate ! + -If all else fails, send as much information as you can, -including your config files, how you're starting ppp, -the relevant parts of your log file and the output of the -netstat -rn command (before and after connecting) to the -freebsd-questions@FreeBSD.org mailing list or the -comp.unix.bsd.freebsd.misc news group, and someone -should point you in the right direction. + + If all else fails, send as much information as you can, + including your config files, how you're starting + ppp, the relevant parts of your + log file and the output of the + netstat -rn command (before and after connecting) to + the freebsd-questions@FreeBSD.org mailing list + or the + comp.unix.bsd.freebsd.misc news group, and someone + should point you in the right direction. - - - + + + + - -Serial Communications + + Serial Communications -This section answers common questions about serial communications -with FreeBSD. PPP and SLIP are covered in the section. + This section answers common questions about serial + communications with FreeBSD. PPP and SLIP are covered in the + section. - -How do I tell if FreeBSD found my serial ports? + + + + How do I tell if FreeBSD found my serial ports? + -As the FreeBSD kernel boots, it will probe for the serial ports -in your system for which the kernel was configured. You can -either watch your system closely for the messages it prints or -run the command + + As the FreeBSD kernel boots, it will probe for the serial + ports in your system for which the kernel was configured. + You can either watch your system closely for the messages it + prints or run the command -&prompt.user; dmesg | grep sio + &prompt.user; dmesg | grep sio -after your system's up and running. + after your system's up and running. -Here's some example output from the above command: + Here's some example output from the above command: -sio0 at 0x3f8-0x3ff irq 4 on isa + sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A -This shows two serial ports. The first is on irq 4, is using -port address 0x3f8, and has a 16550A-type UART chip. The -second uses the same kind of chip but is on irq 3 and is at port -address 0x2f8. Internal modem cards are treated just like -serial ports---except that they always have a modem attached -to the port. + This shows two serial ports. The first is on irq 4, is + using port address 0x3f8, and has a + 16550A-type UART chip. The second uses the same kind of chip + but is on irq 3 and is at port address 0x2f8. + Internal modem cards are treated just like serial ports---except + that they always have a modem attached to the + port. -The GENERIC kernel includes support for two serial ports -using the same irq and port address settings in the above -example. If these settings aren't right for your system, or if -you've added modem cards or have more serial ports than your -kernel is configured for, just reconfigure your kernel. See -section about building a kernel for -more details. + The GENERIC kernel includes support + for two serial ports using the same irq and port address + settings in the above example. If these settings aren't + right for your system, or if you've added modem cards or have + more serial ports than your kernel is configured for, just + reconfigure your kernel. See section + about building a kernel for + more details. - + + - -How do I tell if FreeBSD found my modem cards? + + + How do I tell if FreeBSD found my modem cards? + -Refer to the answer to the previous question. + + Refer to the answer to the previous question. - + + - -I just upgraded to 2.0.5 and my tty0X are missing! + + + I just upgraded to 2.0.5 and my + tty0X are missing! + -Don't worry, they have been merged with the ttydX devices. -You'll have to change any old configuration files you have, though. + + Don't worry, they have been merged with the + ttydX devices. You'll have to change + any old configuration files you have, though. - + + - -How do I access the serial ports on FreeBSD? + + + How do I access the serial ports on FreeBSD? + -The third serial port, sio2 (known as -COM3 in DOS), is on /dev/cuaa2 for dial-out devices, and on -/dev/ttyd2 for dial-in devices. What's the difference -between these two classes of devices? + + The third serial port, sio2 + (known as COM3 in DOS), is on /dev/cuaa2 + for dial-out devices, and on /dev/ttyd2 + for dial-in devices. What's the difference between these two + classes of devices? -You use ttydX for dial-ins. When opening /dev/ttydX -in blocking mode, a process will wait for the corresponding -cuaaX device to become inactive, and then wait -for the carrier detect line to go active. When you open the -cuaaX device, it makes sure the serial port isn't already in -use by the ttydX device. If the port's available, it -steals it from the ttydX device. Also, -the cuaXX -device doesn't care about carrier detect. With this scheme and -an auto-answer modem, you can have remote users log in and you -can still dialout with the same modem and the system will take -care of all the conflicts. + You use ttydX for dial-ins. When + opening /dev/ttydX in blocking mode, a + process will wait for the corresponding + cuaaX device to become inactive, and then + wait for the carrier detect line to go active. When you open + the cuaaX device, it makes sure the serial + port isn't already in use by the ttydX + device. If the port's available, it steals it + from the ttydX device. Also, the + cuaXX device doesn't care about carrier + detect. With this scheme and an auto-answer modem, you can have + remote users log in and you can still dialout with the same + modem and the system will take care of all the + conflicts. - + + - -How do I enable support for a multiport serial card? + + + How do I enable support for a multiport serial + card? + -Again, the section on kernel configuration provides information -about configuring your kernel. For a multiport serial card, -place an sio line for each serial port on the card in the -kernel configuration file. But place the irq and vector -specifiers on only one of the entries. All of the ports on the -card should share one irq. For consistency, use the last serial -port to specify the irq. Also, specify the COM_MULTIPORT -option. + + Again, the section on kernel configuration provides + information about configuring your kernel. For a multiport + serial card, place an sio line + for each serial port on the card in the kernel configuration + file. But place the irq and vector specifiers on only one of + the entries. All of the ports on the card should share one irq. + For consistency, use the last serial port to specify the irq. + Also, specify the COM_MULTIPORT + option. -The following example is for an AST 4-port serial card on irq 7: + The following example is for an AST 4-port serial card on + irq 7: -options "COM_MULTIPORT" + options "COM_MULTIPORT" device sio4 at isa? port 0x2a0 tty flags 0x781 device sio5 at isa? port 0x2a8 tty flags 0x781 device sio6 at isa? port 0x2b0 tty flags 0x781 device sio7 at isa? port 0x2b8 tty flags 0x781 irq 7 vector siointr -The flags indicate that the master port has minor number 7 -(0x700), diagnostics enabled during probe (0x080), and -all the ports share an irq (0x001). + The flags indicate that the master port has minor number 7 + (0x700), diagnostics enabled during probe + (0x080), and all the ports share an irq + (0x001). - + + - -Can FreeBSD handle multiport serial cards sharing irqs? + + + Can FreeBSD handle multiport serial cards sharing + irqs? + -Not yet. You'll have to use a different irq for each card. + + Not yet. You'll have to use a different irq for each + card. - + + - -Can I set the default serial parameters for a port? + + + Can I set the default serial parameters for a + port? + -The ttydX (or cuaaX) device is the regular device -you'll want to open for your applications. When a process opens -the device, it'll have a default set of terminal I/O settings. -You can see these settings with the command + + The ttydX (or + cuaaX) device is the regular device + you'll want to open for your applications. When a process + opens the device, it'll have a default set of terminal I/O + settings. You can see these settings with the command -&prompt.root; stty -a -f /dev/ttyd1 + &prompt.root; stty -a -f /dev/ttyd1 -When you change the settings to this device, the settings are in -effect until the device is closed. When it's reopened, it goes -back to the default set. To make changes to the default set, you -can open and adjust the settings of the initial state device. -For example, to turn on CLOCAL mode, 8 bits, and -XON/XOFF flow control by default for ttyd5, do: + When you change the settings to this device, the settings + are in effect until the device is closed. When it's reopened, + it goes back to the default set. To make changes to the + default set, you can open and adjust the settings of the + initial state device. For example, to turn on + CLOCAL mode, 8 bits, and + XON/XOFF flow control by default for + ttyd5, do: -&prompt.root; stty -f /dev/ttyid5 clocal cs8 ixon ixoff + &prompt.root; stty -f /dev/ttyid5 clocal cs8 ixon ixoff -A good place to do this is in /etc/rc.serial. Now, an -application will have these settings by default when it opens -ttyd5. It can still change these settings to its liking, -though. + A good place to do this is in + /etc/rc.serial. Now, an application will + have these settings by default when it opens + ttyd5. It can still change these settings + to its liking, though. -You can also prevent certain settings from being changed by an -application by making adjustments to the lock state device. -For example, to lock the speed of ttyd5 to 57600 bps, do + You can also prevent certain settings from being changed + by an application by making adjustments to the + lock state device. For example, to lock the + speed of ttyd5 to 57600 bps, do -&prompt.root; stty -f /dev/ttyld5 57600 + &prompt.root; stty -f /dev/ttyld5 57600 -Now, an application that opens ttyd5 and tries to change the -speed of the port will be stuck with 57600 bps. + Now, an application that opens ttyd5 + and tries to change the speed of the port will be stuck with + 57600 bps. -Naturally, you should make the initial state and lock state -devices writable only by root. The -MAKEDEV -script does NOT do this when it creates the -device entries. + Naturally, you should make the initial state and lock state + devices writable only by root. The MAKEDEV + script does NOT do this when it creates the + device entries. - + + - -How can I enable dialup logins on my modem? + + + How can I enable dialup logins on my modem? + -So you want to become an Internet service provider, eh? First, -you'll need one or more modems that can auto-answer. Your modem -will need to assert carrier-detect when it detects a carrier and -not assert it all the time. It will need to hang up the phone -and reset itself when the data terminal ready (DTR) line -goes from on to off. It should probably use RTS/CTS -flow control or no local flow control at all. Finally, it must -use a constant speed between the computer and itself, but (to be -nice to your callers) it should negotiate a speed between itself -and the remote modem. + + So you want to become an Internet service provider, eh? + First, you'll need one or more modems that can auto-answer. + Your modem will need to assert carrier-detect when it detects a + carrier and not assert it all the time. It will need to hang up + the phone and reset itself when the data terminal ready + (DTR) line goes from on to off. It should + probably use RTS/CTS flow control or no + local flow control at all. Finally, it must use a constant + speed between the computer and itself, but (to be nice to your + callers) it should negotiate a speed between itself and the + remote modem. -For many Hayes command-set--compatible modems, this command will -make these settings and store them in nonvolatile memory: + For many Hayes command-set--compatible modems, this + command will make these settings and store them in + nonvolatile memory: -AT &C1 &D3 &K3 &Q6 S0=1 &W + AT &C1 &D3 &K3 &Q6 S0=1 &W -See the section on sending AT commands below for information on how to make these settings -without resorting to an MS-DOS terminal program. + See the section on sending AT + commands below for information on how to make these + settings without resorting to an MS-DOS terminal program. -Next, make an entry in /etc/ttys for the -modem. This file lists all the ports on which the operating system will -await logins. Add a line that looks something like this: + Next, make an entry in + /etc/ttys for the modem. This file lists all the ports + on which the operating system will await logins. Add a line + that looks something like this: -ttyd1 "/usr/libexec/getty std.57600" dialup on insecure + ttyd1 "/usr/libexec/getty std.57600" dialup on insecure -This line indicates that the second serial port -(/dev/ttyd1) has a modem connected running at 57600 bps -and no parity (std.57600, which comes from the file -/etc/gettytab). The terminal type for this port is -dialup. The port is on and is insecure---meaning -root logins on the port aren't allowed. For dialin ports like -this one, use the ttydX entry. + This line indicates that the second serial port + (/dev/ttyd1) has a modem connected + running at 57600 bps and no parity + (std.57600, which comes from the file /etc/gettytab). + The terminal type for this port is dialup. + The port is on and is + insecure---meaning root logins on the port + aren't allowed. For dialin ports like this one, use the + ttydX entry. -It's common practice to use dialup as the terminal type. -Many users set up in their .profile or .login files a prompt for -the actual terminal type if the starting type is dialup. The -example shows the port as insecure. To become root on this port, -you have to login as a regular user, then su to become -root. If you use secure then -root can login in directly. + It's common practice to use dialup as + the terminal type. Many users set up in their .profile or + .login files a prompt for the actual terminal type if the + starting type is dialup. The example shows the port as + insecure. To become root on this port, you have to login as a + regular user, then su to become + root. If you use secure + then root can login in directly. -After making modifications to /etc/ttys, you -need to send a hangup or HUP signal to the init process: + After making modifications to + /etc/ttys, you need to send a hangup or + HUP signal to the + init process: -&prompt.root; kill -HUP 1 + &prompt.root; kill -HUP 1 -This forces the init process to reread /etc/ttys. The -init process will then start getty processes on all on ports. -You can find out if logins are available for your port by typing + This forces the init process to reread + /etc/ttys. The init process will then start getty + processes on all on ports. You can find + out if logins are available for your port by typing -&prompt.user; ps -ax | grep '[t]tyd1' + &prompt.user; ps -ax | grep '[t]tyd1' -You should see something like: + You should see something like: -747 ?? I 0:00.04 /usr/libexec/getty std.57600 ttyd1 + 747 ?? I 0:00.04 /usr/libexec/getty std.57600 ttyd1 - + + - -How can I connect a dumb terminal to my FreeBSD box? + + + How can I connect a dumb terminal to my FreeBSD + box? + -If you're using another computer as a terminal into your FreeBSD -system, get a null modem cable to go between the two serial -ports. If you're using an actual terminal, see its accompanying -instructions. + + If you're using another computer as a terminal into your + FreeBSD system, get a null modem cable to go between the two + serial ports. If you're using an actual terminal, see its + accompanying instructions. -Then, modify /etc/ttys, like above. For example, if you're hooking up a -WYSE-50 terminal to the fifth serial port, use an entry like this: + Then, modify + /etc/ttys, like above. For example, if you're + hooking up a WYSE-50 terminal to the fifth serial port, + use an entry like this: -ttyd4 "/usr/libexec/getty std.38400" wyse50 on secure + ttyd4 "/usr/libexec/getty std.38400" wyse50 on secure -This example shows that the port on /dev/ttyd4 has a -wyse50 terminal connected at 38400 bps with no parity -(std.38400 from /etc/gettytab) and -root logins are allowed (secure). + This example shows that the port on + /dev/ttyd4 has a wyse50 terminal + connected at 38400 bps with no parity + (std.38400 from + /etc/gettytab) and root logins are + allowed (secure). - + + - -Why can't I run tip or cu? + + + Why can't I run tip or + cu? + -On your system, the programs tip and cu are probably -executable only by uucp and group -dialer. You can use the group dialer -to control who has access to your modem or remote systems. Just add -yourself to group dialer. + + On your system, the programs tip + and + cu are probably executable only by uucp + and group dialer. You can use the group + dialer to control who has access to your + modem or remote systems. Just add yourself to group + dialer. -Alternatively, you can let everyone on your system run tip -and cu by typing: + Alternatively, you can let everyone on your system + run tip and cu by + typing: -&prompt.root; chmod 4511 /usr/bin/cu + &prompt.root; chmod 4511 /usr/bin/cu &prompt.root; chmod 4511 /usr/bin/tip - + + - -My stock Hayes modem isn't supported---what can I do? + + + My stock Hayes modem isn't supported---what + can I do? + -Actually, the man page for tip is out of -date. There is a generic Hayes dialer already built in. Just use -at=hayes in your /etc/remote file. + + Actually, the man page for tip is + out of date. There is a generic Hayes dialer already built in. + Just use at=hayes in your + /etc/remote file. -The Hayes driver isn't smart enough to recognize some of the -advanced features of newer modems---messages like BUSY, -NO DIALTONE, or CONNECT 115200 will just confuse it. -You should turn those messages off when you use tip (using -ATX0&W). + The Hayes driver isn't smart enough to recognize some of + the advanced features of newer modems---messages like + BUSY, NO DIALTONE, or + CONNECT 115200 will just confuse it. You + should turn those messages off when you use tip + (using ATX0&W). -Also, the dial timeout for tip is 60 seconds. Your modem -should use something less, or else tip will think there's a -communication problem. Try ATS7=45&W. + Also, the dial timeout for tip is 60 + seconds. Your modem should use something less, or else tip + will think there's a communication problem. Try + ATS7=45&W. -Actually, as shipped tip doesn't yet support it fully. The -solution is to edit the file tipconf.h in the directory -/usr/src/usr.bin/tip/tip. Obviously you need the source -distribution to do this. + Actually, as shipped tip doesn't yet + support it fully. The solution is to edit the file + tipconf.h in the directory + /usr/src/usr.bin/tip/tip. Obviously you + need the source distribution to do this. -Edit the line #define HAYES 0 to #define HAYES 1. -Then make and make install. Everything -works nicely after that. + Edit the line #define HAYES 0 + to #define HAYES 1. Then + make and make install. + Everything works nicely after that. - + + - - How am I expected to enter these AT commands? - + + + How am I expected to enter these AT commands? + -Make what's called a direct entry in your -/etc/remote file. For example, if your modem's hooked -up to the first serial port, /dev/cuaa0, then put in the -following line: + + Make what's called a direct entry in your + + /etc/remote file. For example, if your modem's hooked + up to the first serial port, /dev/cuaa0, + then put in the following line: -cuaa0:dv=/dev/cuaa0:br#19200:pa=none + cuaa0:dv=/dev/cuaa0:br#19200:pa=none -Use the highest bps rate your modem supports in the br -capability. Then, type tip cuaa0 and -you'll be connected to your modem. + Use the highest bps rate your modem supports in the br + capability. Then, type tip cuaa0 + and you'll be connected to your modem. -If there is no /dev/cuaa0 on your system, do this: + If there is no /dev/cuaa0 on your + system, do this: -&prompt.root; cd /dev + &prompt.root; cd /dev &prompt.root; sh MAKEDEV cuaa0 -Or use cu as root with the following command: + Or use cu as root with the following command: -&prompt.root; cu -lline -sspeed + &prompt.root; cu -lline -sspeed -with line being the serial port (e.g./dev/cuaa0) -and speed being the speed (e.g.57600). When you are done -entering the AT commands hit ~. to exit. + with line being the serial port (e.g. + /dev/cuaa0) and speed being the speed + (e.g.57600). When you are done entering + the AT commands hit ~. to exit. - + + - -The <@> sign for the pn capability doesn't work! + + + The <@> sign for the pn + capability doesn't work! -The <@> sign in the phone number capability tells tip to look in -/etc/phones for a phone number. But the <@> sign is -also a special character in capability files like -/etc/remote. Escape it with a backslash: + The <@> sign in the phone number + capability tells tip to look in + /etc/phones for a phone number. But the + <@> sign is also a special character + in capability files like /etc/remote. + Escape it with a backslash: -pn=\@ + pn=\@ - + + - -How can I dial a phone number on the command line? + + + How can I dial a phone number on the command + line? + -Put what's called a generic entry in your -/etc/remote file. For example: + Put what's called a generic entry in your + + /etc/remote file. For example: -tip115200|Dial any phone number at 115200 bps:\ + tip115200|Dial any phone number at 115200 bps:\ :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du: tip57600|Dial any phone number at 57600 bps:\ :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du: -Then you can do something like tip -115200 5551234. If you -prefer cu over tip, use a -generic cu entry: + Then you can do something like tip -115200 + 5551234. If you prefer cu + over + tip, use a generic cu entry: -cu115200|Use cu to dial any number at 115200bps:\ + cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: -and type cu 5551234 -s 115200. + and type cu 5551234 -s 115200. - + + - -Do I have to type in the bps rate every time I do that? + + + Do I have to type in the bps rate every time I do + that? + -Put in an entry for tip1200 or cu1200, but go ahead and -use whatever bps rate is appropriate with the br capability. tip thinks a good -default is 1200 bps which is why it looks for a tip1200 entry. -You don't have to use 1200 bps, though. + Put in an entry for tip1200 or + cu1200, but go ahead and use whatever bps + rate is appropriate with the br capability. tip + thinks a good default is 1200 bps which is why it looks for + a tip1200 entry. You don't have to use 1200 + bps, though. - + + - -I access a number of hosts through a terminal server. + + + I access a number of hosts through a terminal + server. + -Rather than waiting until you're connected and typing -CONNECT host each time, use tip's cm -capability. For example, these entries in -/etc/remote: + + Rather than waiting until you're connected and typing + CONNECT host + each time, use tip's cm capability. For + example, these entries in + /etc/remote: -pain|pain.deep13.com|Forrester's machine:\ + pain|pain.deep13.com|Forrester's machine:\ :cm=CONNECT pain\n:tc=deep13: muffin|muffin.deep13.com|Frank's machine:\ :cm=CONNECT muffin\n:tc=deep13: deep13:Gizmonics Institute terminal server:\ :dv=/dev/cua02:br#38400:at=hayes:du:pa=none:pn=5551234: -will let you type tip pain or tip muffin to -connect to the hosts pain or muffin; -and tip deep13 to -get to the terminal server. + will let you type tip pain or + tip muffin to connect to the hosts + pain or muffin; and + tip deep13 to get to the terminal + server. - + + - -Can tip try more than one line for each site? + + + Can tip try more than one line for each site? + -This is often a problem where a university has several modem lines -and several thousand students trying to use them... + + This is often a problem where a university has several + modem lines and several thousand students trying to use + them... -Make an entry for your university in /etc/remote -and use <\@> for the pn capability: + Make an entry for your university in + /etc/remote and use <\@> for + the pn capability: -big-university:\ + big-university:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: -Then, list the phone numbers for the university in -/etc/phones: + Then, list the phone numbers for the university in + + /etc/phones: -big-university 5551111 + big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114 -tip will try each one in the listed order, then give up. If -you want to keep retrying, run tip in a while loop. + + tip will try each one in the listed order, then give + up. If you want to keep retrying, run tip + in a while loop. - + + - -Why do I have to hit CTRL+P twice to send CTRL+P once? + + + Why do I have to hit CTRL+P twice to send CTRL+P + once? + -CTRL+P is the default force character, used to tell -tip -that the next character is literal data. You can set the force -character to any other character with the ~s escape, which -means set a variable. + + CTRL+P is the default force character, + used to tell tip + that the next character is literal data. You can set the + force character to any other character with the + ~s escape, which means set a + variable. -Type ~sforce=single-char followed by a newline. -single-char is any single character. If you leave -out single-char, then the force character is the nul -character, which you can get by typing CTRL+2 or CTRL+SPACE. A -pretty good value for single-char is SHIFT+CTRL+6, -which I've seen only used on some terminal servers. + Type ~sforce=single-char + followed by a newline. + single-char is any single character. + If you leave out single-char, + then the force character is the nul character, which you can + get by typing CTRL+2 or CTRL+SPACE. A pretty good value for + single-char is SHIFT+CTRL+6, which + I've seen only used on some terminal servers. -You can have the force character be whatever you want by -specifying the following in your $HOME/.tiprc -file: + You can have the force character be whatever you want by + specifying the following in your + $HOME/.tiprc file: -force=single-char + force=single-char - + + - -Suddenly everything I type is in UPPER CASE?? + + + Suddenly everything I type is in UPPER CASE?? + -You must've pressed CTRL+A, tip raise -character, specially designed for people with broken caps-lock keys. -Use ~s as above and set the variable raisechar to something -reasonable. In fact, you can set it to the same as the force -character, if you never expect to use either of these features. + + You must've pressed CTRL+A, + tip raise character, specially + designed for people with broken caps-lock keys. Use + ~s as above and set the variable + raisechar to something reasonable. In fact, + you can set it to the same as the force character, if you + never expect to use either of these features. -Here's a sample .tiprc file perfect for Emacs users who need to -type CTRL+2 and CTRL+A a lot: + Here's a sample .tiprc file perfect for Emacs users who + need to type CTRL+2 and CTRL+A a lot: -force=^^ + force=^^ raisechar=^^ The ^^ is SHIFT+CTRL+6. - + + - -How can I do file transfers with tip? + + + How can I do file transfers with + tip? + -If you're talking to another UNIX system, you can send and -receive files with ~p (put) and ~t (take). These -commands run cat and echo on the remote system to accept and send files. The syntax -is: + + If you're talking to another UNIX system, you can send + and receive files with ~p (put) and + ~t (take). These commands run cat and + + echo on the remote system to accept and send files. + The syntax is: -~p <local-file> [<remote-file>] + ~p <local-file> [<remote-file>] ~t <remote-file> [<local-file>] -There's no error checking, so you probably should use another -protocol, like zmodem. + There's no error checking, so you probably should use + another protocol, like zmodem. - + + - -How can I run zmodem with tip? + + + How can I run zmodem with + tip? + -First, install one of the zmodem programs from the ports -collection (such as one of the two from the comms category, -lrzsz -and rzsz). + + First, install one of the zmodem programs from the ports + collection (such as one of the two from the comms category, + + lrzsz and + rzsz). -To receive files, start the sending program on the remote end. -Then, press enter and type ~C rz (or ~C lrz if -you installed lrzsz) to begin receiving them locally. + To receive files, start the sending program on the + remote end. Then, press enter and type + ~C rz (or ~C lrz if you + installed lrzsz) to begin + receiving them locally. -To send files, start the receiving program on the remote end. -Then, press enter and type ~C sz files (or -~C lsz files) to send them to the -remote system. + To send files, start the receiving program on the remote + end. Then, press enter and type + ~C sz files + (or ~C lsz files) + to send them to the remote system. - + + - -FreeBSD can't seem to find my serial ports, even when the - settings are correct. + + + FreeBSD can't seem to find my serial ports, even when + the settings are correct. + -Motherboards and cards with Acer UARTs do not probe properly under -the FreeBSD sio probe. Obtain a patch from -www.lemis.com to fix your problem. + + Motherboards and cards with Acer UARTs do not probe + properly under the FreeBSD sio probe. Obtain a patch from + + www.lemis.com to fix your problem. - - + + + +