Linux-Networking Digest #157, Volume #10 Tue, 9 Feb 99 12:13:45 EST
Contents:
Re: kppp problem for non root user (Christian Wagner)
Re: [help] DHCP (Corey J. Steele)
Re: ipfwadm: setsockopt failed (Darren Greer)
Re: 10/100 Ethernet SWITCH (to be used for Fast Ethernet LAN, and 10-BaseT cable
modem) ("J. Clarke")
Re: PPP conection problems (Christian Wagner)
Re: ip addresses (Stef)
Re: diald pppd time out (Philboyd Studge)
CPU 0.1% idle after X login by root ? (Y W Wong)
Re: GTE, DSL and Linux (Stephen Carville)
Re: Windows login to corporate domain thru Linux server (Edwin Calimbo)
Re: will virus affect? (Todd Knarr)
PROB: IPMasq entries not clearing from kernel? (Mike Root)
Re: ipfwadm: setsockopt failed (Chris Funk)
Re: diald: first connection doesn't respond (Declan)
----------------------------------------------------------------------------
From: Christian Wagner <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: kppp problem for non root user
Date: Tue, 09 Feb 1999 14:27:29 +0100
Try to look at your
/var/log/messages
file.
There should be something like:
Feb 8 12:13:21 hostname pppd[603]: Couldn't initialize modem.
I think you are not allowed to use the modem device as any other user than
"root"
In order to use the modem, the user must be in group
uucp
Hope it'll work with that...
Greetings,
Christian
--
We are the small voice that whispers to you in the lonely hours of
the night. We call to the darkness within all of you. We came from
the dark and to the dark we shall all return.
---ICQ#21196326---http://www.tu-harburg.de/~secw2604/---
------------------------------
From: Corey J. Steele <[EMAIL PROTECTED]>
Subject: Re: [help] DHCP
Date: Tue, 9 Feb 1999 07:27:05 -0600
RTFM > Ethernet-HOWTO & DHCP-HOWTO, both available from
http://metalab.unc.edu/LDP/
-C
On Thu, 04 Feb 1999, Mr. Han-Man wrote:
>I have RedHat Linux 5.2, kernel version 2.0.36, and a 3com Etherlink XL
>3C905B NIC. I was hoping someone could tell me how to access an Ethernet
>using DHCP. Any help would be greatly appreciated.
>
>Thanks
------------------------------
From: [EMAIL PROTECTED] (Darren Greer)
Subject: Re: ipfwadm: setsockopt failed
Date: Tue, 09 Feb 1999 04:14:59 GMT
What kernel are you running?
The newer kernels do not support ipfwadm anymore
Read up on ipchains
Darren
On Mon, 08 Feb 1999 21:04:55 -0700, Chris Funk <[EMAIL PROTECTED]>
wrote:
-->Hi, I am trying to get ip masq. set up.
-->I have the pppd part working, but when i try to issue any ipfwadm
-->commands I get the following errors
-->
-->[ns2]# ipfwadm -F -p deny
-->"ipfwadm: setsockopt failed: Invalid argument
-->[ns2]# ipfwadm -F -a m -S 192.168.0.1/32 -D 0.0.0.0/0
-->"ipfwadm: setsockopt failed: No such file or directory
-->
-->I compiled in ip masq. etc. Did i miss something?
-->
-->Also, I have the demand line in my /etc/ppp/options file.
-->Should a pppd :xxx.xxx.xxx.xxx command fire up the modem?
-->I thought that it required me to ping something on the outside world
-->before it would dial the modem
-->
-->Thanks
--> Chris Funk
-->
------------------------------
Reply-To: "J. Clarke" <[EMAIL PROTECTED]>
From: "J. Clarke" <[EMAIL PROTECTED]>
Crossposted-To:
comp.dcom.lans.ethernet,linux.redhat.misc,linux.samba,comp.os.linux.hardware
Subject: Re: 10/100 Ethernet SWITCH (to be used for Fast Ethernet LAN, and 10-BaseT
cable modem)
Date: Tue, 9 Feb 1999 09:36:17 -0500
Before you spend for Fast Ethernet, do some tests. I've never managed to
successfully record a CD-R across a Fast Ethernet, even when the data was
contained entirely within the RAM cache of the server (eliminates disk
performance as an issue). The problem appears to be latency--while the data
rate is high, it's not consistently high for all machines--there are short
gaps that are long enough to interrupt the stream.
Just a suggestion, but you'll likely get more benefit by installing a fast
drive in the local machine and using it to buffer the files you're working
on, then copy them back up to the server or delete them if you don't need to
do that. Of course the best of all worlds is to do both.
--
--
--John
Reply to jclarke at eye bee em dot net
Microsoft <[EMAIL PROTECTED]> wrote in message
news:01be5318$54742190$0200a8c0@mycompnt...
>The reason I would like to use 100-BaseT Ethernet at home is so that I can
>use SMB-mounted drives as source for CD-R. 10-BaseT is too unreliable for
>any serious CD-R recording, especially at 4x and 8x speeds. 100-BaseT is
>the only practical solution for this, also when I am doing disk intensive
>tasks directly ober the network, such as using vcdgear to convert a .dat to
>a .mpg (500 MB+ file) over a network mounted drive, 10-BaseT takes upwards
>of an hour to do this, which is a total waste of time. If I has 100-BaseT,
>network mounted drives would be basically about as fast as local drives.
>
>�Comprende?
>
>
>Stephen Carville <[EMAIL PROTECTED]> wrote in article
><[EMAIL PROTECTED]>...
>> Christian Aasland wrote:
>> >
>> > As stated, the switches are really expensive... not really sure a full
>switch
>> > is better than a hub for small networks, as switches only prevent
>collisions
>> > on busy nets.
>>
>> I have found that, on small networks, a switch can dramatically improve
>> throughput if the server is on a 100 Mbps port and the rest of the nodes
>> are on 10 Mbps. I've seen such a switched setup (one server and 20 WS)
>> equal the performance of a shared 100 Mbps network with a similar
>geometry
>> and traffic.
>>
>> With the cost of 10/100 switches dropping it is a practical solution for
>a
>> small office. I don't think the home user with less than four or five
>> machines will get any discernible advantage unless he is running some
>> bandwidth hungry client server apps. For surfing the net it is moot.
>Even
>> a full T1 is not going to saturate a 10Mbps ethernet.
>>
>> --
>> Stephen Carville
>> [EMAIL PROTECTED]
>> ----------------------------------------------------
>> Management: The art of hiring intelligent, skilled individuals and then
>> ignoring their advice.
>>
------------------------------
From: Christian Wagner <[EMAIL PROTECTED]>
Subject: Re: PPP conection problems
Date: Tue, 09 Feb 1999 14:38:20 +0100
Eduardo Mendes wrote:
> =
> Hi ... I=B4m with problems to connect with my provider using Linux and
> kppp program.
> =
> In my script login i wrote :
> =
> expect login:
> send my ID
> expect Password:
> send my password
> expect granted
> send ppp
> =
> (I saw that in a example of login script)
> =
> ok ... then I begin the connection, after i receive the Password, i sen=
d
> =
> mine and a message says " starting ppp session" and lots of trash becam=
e
> =
> to appear ... (I stay waiting granted, but i don=B4t know if that=B4s t=
he
> right thing to do !!!!) after some time ...
> the connection falls and a message appears .... NO CARRIER !!!!
> =
> What is the problem ? Is the script login wrong ? Or what should i do
> when the trash starts to appear ?
> =
> Please, i would like your help ...
> =
> Greatfull...
> =
> Eduardo.
Well, as you can see, the server is starting the ppp session without send=
ing
something like "granted"
just delete the two entries =
> expect granted
> send ppp
(you may replace it with one line "expect 'starting ppp session'" but it'=
s
optional)
and everything should work fine.
greetings, Christian
-- =
We are the small voice that whispers to you in the lonely hours of
the night. We call to the darkness within all of you. We came from =
the dark and to the dark we shall all return.
---ICQ#21196326---http://www.tu-harburg.de/~secw2604/---
------------------------------
From: Stef <[EMAIL PROTECTED]>
Subject: Re: ip addresses
Date: 9 Feb 1999 15:38:24 +0100
: I have ordinary internet account and only one (static) ip address. But
: if I want to connect both machines connected to the internet they must
: have different ip addresses because they have different hostnames. Can I
: have two ip addresses on one line and how? And if not, is there another
: solution?
For outgoing connections you can use IP-Masquerading. Check the
IP-Masquerade mini HOWTO.
If you want your hosts to be visible to the internet, your ISP must
provide you with a second IP.
Stef
--
WebMaster D-WERK
President SOS-ETH
ETH Zurich
[EMAIL PROTECTED] http://hoes.li
------------------------------
From: [EMAIL PROTECTED] (Philboyd Studge)
Subject: Re: diald pppd time out
Date: Sun, 07 Feb 1999 22:00:45 GMT
make sure you are not defining anything in /etc/ppp/options that can
be defined in your diald.conf
here's a link to how I set mine up:
http://members.psesd.org/~slindell/rh52-2.html
hth
On Fri, 05 Feb 1999 00:50:50 GMT, [EMAIL PROTECTED] wrote:
:::Can someone tell me why my pppd dies when I use diald. I recieve the
:::following message "pppd startup timed out. check your ppp options. killing
:::pppd."
:::
:::I have tried setting up-delay to 0,2 and 5 in diald.conf. Can someone tell me
:::how to correct this. ppp works fine by itself.
:::thanks
:::
:::-----------== Posted via Deja News, The Discussion Network ==----------
:::http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Y W Wong <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: CPU 0.1% idle after X login by root ?
Date: Tue, 09 Feb 1999 12:06:48 +0800
The CPU states shown 0.1% idle after using X-Term to login to my Linux
box.
The "top" result is as follow :-
[root@gpus1 wong]# top
9:18am up 31 days, 15:14, 2 users, load average: 1.08, 1.17, 1.17
49 processes: 46 sleeping, 3 running, 0 zombie, 0 stopped
CPU states: 98.9% user, 1.1% system, 0.0% nice, 0.1% idle
Mem: 63140K av, 37628K used, 25512K free, 25632K shrd, 17908K buff
Swap: 68508K av, 2788K used, 65720K free 7908K
cached
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME
COMMAND
21640 root 17 0 1640 1640 1244 R 0 98.1 2.5 5528m
control-panel
22660 root 3 0 712 712 548 R 0 1.7 1.1 0:00 top
22644 root 0 0 684 684 528 R 0 0.1 1.0 0:00
in.telnetd
1 root 0 0 336 324 264 S 0 0.0 0.5 0:07 init
2 root 0 0 0 0 0 SW 0 0.0 0.0 1:01
kflushd
[root@gpus1 wong]# kill 21640
[root@gpus1 wong]# top
9:18am up 31 days, 15:15, 2 users, load average: 0.91, 1.12, 1.16
48 processes: 47 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 0.9% user, 0.7% system, 0.0% nice, 98.3% idle
Mem: 63140K av, 37232K used, 25908K free, 24392K shrd, 17908K buff
Swap: 68508K av, 2788K used, 65720K free 7924K
cached
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME
COMMAND
22661 root 11 0 712 712 548 R 0 1.7 1.1 0:00 top
1 root 0 0 336 324 264 S 0 0.0 0.5 0:07 init
2 root 0 0 0 0 0 SW 0 0.0 0.0 1:01
kflushd
3 root -12 -12 0 0 0 SW< 0 0.0 0.0 0:01
kswapd
Why the control-panel take 98% of the CPU resources even I have already
logout
from a remote X-Term ? ( Resource cannot release )
Is it a bug of Linux xdm ?
Y W Wong
------------------------------
From: Stephen Carville <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.xdsl
Subject: Re: GTE, DSL and Linux
Date: 9 Feb 1999 04:32:14 GMT
ellis wrote:
>
> In article <[EMAIL PROTECTED]>,
> Stephen Carville <[EMAIL PROTECTED]> wrote:
>
> >I just got off the phone with a GTE rep who told me in no uncertain
> >terms that GTE will not install ADSL if the connected machine runs
> >UNIX, Linux, any MacOS, or Win 3.1.
>
> Funny, GTE installed ADSL at my house and it is connected to a machine
> running linux.
>
> Are you talking about GTE.NET or GTE the phone company? If GTE.NET, just
> find a better ISP to take the order.
I discovered the difference after making a few phone calls. GTE the ISP is
populated by Win bigots. GTE the telco just moves bits around for
dollars. I am having the DSL hardware installed this Wednesday
BTW, I advise anyone considering DSL to do some price comparisons. The
local loop charges are fixed by tariff but the ISP charges can vary a
_lot_. I found silver level services (384K/384k) costing from $85/mo to
$175/mo.
--
Stephen Carville
[EMAIL PROTECTED]
====================================================
Management: The art of hiring intelligent, skilled individuals and then
ignoring their advice.
------------------------------
From: [EMAIL PROTECTED] (Edwin Calimbo)
Subject: Re: Windows login to corporate domain thru Linux server
Date: 29 Jan 99 06:40:54 GMT
Christopher G. Petty ([EMAIL PROTECTED]) wrote:
: Here's one for the thinkers out there. I'll admit I'm stumped on this
: one.
: I'm trying to allow remote windows users to login to my local LAN vial a
: DoD Linux box. The problem is that the domain information refuses to
: pass thru the PPP link. Services such as Micro$loth Exchange, Mail, etc
: are not seen, nor are the machines on the other side of the PPP link.
: I can ping both ways across the PPP link, so routing is not the issue.
: The Linux server at the remote site is dialing into an NT 4 SP4 server.
: When the link is up, I can ping the remote workstations, the remote
: linux box, telnet to the remote linux box, and thru it, ping both remote
: and local machines, but none of the NT domain information is being
: passed.
When you talk about "NT domain information" do you mean shared resources,
local/global groups (domains) etc?
On your NT (RAS) server the protocol is probably set to *bind* to
TCP/IP first and then to NetBIOS etc. Also, NetBIOS is not routable.
: Anyone got a clue on how I can get this to work?
: Thanks in advance.
: _CGP
--
====================
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: Todd Knarr <[EMAIL PROTECTED]>
Subject: Re: will virus affect?
Date: 9 Feb 1999 04:52:17 GMT
[EMAIL PROTECTED] wrote:
> sure...
> But what when I'm running windows on the same machine with access to the
>Linux-partitions?
> This is what I mean, and this was the question....
In that case Wine or Dosemu is using the network redirector services to
make the Linux filesystems appear to the program. Whatever the virus does,
the Linux filesystem drivers will apply the standard file permissions and
your user privileges, and I doubt they'd allow you to write to the raw
partition ( check the permissions on /dev/hd* and /dev/sd* for whether
non-owner users are permitted to write to them ). There can be holes
in Wine and Dosemu that'd let a virus get past the checks, but the
virus would have to recognize that it's running in emulation on a Linux
system and take appropriate action.
If you mean really running Windows, then since Windows has no protection
on devices any program there can scribble over any part of the disk it
wants ( NT might modify this, but in it's default config it's entirely
likely to allow that sort of behavior ). My advice: if you absolutely
must run Windows, at least run NT Workstation and invest the several
hundred dollars in the tools and courses needed to lock it down properly.
You can keep a Win95 or unsecured NT system clean, but it requires serious
paranoia. [ NB: 20 years clean, and not about to change that just because
someone else doesn't want to learn how to make Word97 spit out RTF or some
other innocuous format. ]
--
If you'll excuse me - I have fifteen things fighting for my attention, all
of them annoying.
-- Susan Ivanova
------------------------------
From: Mike Root <[EMAIL PROTECTED]>
Subject: PROB: IPMasq entries not clearing from kernel?
Date: Mon, 08 Feb 1999 17:13:21 -0800
Hi. I've got a Pentium Linux box set up running RedHat 5.1, with the
new 2.2.1 kernel. The IPChains (1.3.8) firewall is working fine, as is
IP Masquerading. The machine ("firewall") has two NICs, one for the
internal net (192.168.1.0/24) and one for an external net
(192.168.2.0/24). The firewall machine also runs the bind 8.1.2
nameserver, set up to resolve local addresses and forward internet
addresses. The internal network has SGIs, Macs, and NT boxes. The only
things on the external net are the firewall itself and an Ascend
Pipeline 75 ISDN router. The pipeline dials out to our ISP, where it
gets a dynamic IP and does NAT. I know the Pipeline is overkill, but
that's just what I had to work with...
Anyway, the problem is that there are times when IP Masquerading
entries seem to get "stuck" in the kernel. For example, there are
currently about 70 entries listed (ipchains -M -L or netstat -M) that
indicate http connections from one of our local machines to a remote
website. However, the local machine in question hasn't been used for
the last three days. The masquerading timeouts (ipchains -M -S x y z)
don't seem to have any impact on whether this behavior occurs. They are
currently set to the default 15, 2, and 5 minutes respectively (speaking
of which, why isn't there a way to list the current values?), but I have
shifted them dramatically up and down without any positive results.
This is really a problem, as the stuck entries are holding up the
ISDN line, which costs us extra money, which makes the bosses unhappy.
There doesn't seem to be any way to clear the entries from the kernel.
Rebooting doesn't do it. I even tried deleting /proc/net/ip_masquerade,
but after rebooting, they were back. They just won't go away.
Rebooting the machine whose masq entries are stuck DOES seem to fix the
problem. I've searched all the IPMasq HOW-TOs, FAQs, and Websites and
no one else seems to have reported this problem or a fix.
Note that this problem does not occur all the time, or with any one
machine. I have seen entries coming from various SGIs, PCs, and Macs
all get stuck. This problem also occurred with our previous config,
which was the 2.0.34 kernel and ipfwadm.
What I really need is a way to clear out the entries via a cron job
(without rebooting any of the workstations) so things don't get stuck in
there for days. Any advice on what I could do about this problem would
be greatly appreciated.
Thanks.
- Mike (m-root1@<nospam>uiuc.edu)
------------------------------
Date: Mon, 08 Feb 1999 21:57:27 -0700
From: Chris Funk <[EMAIL PROTECTED]>
Subject: Re: ipfwadm: setsockopt failed
Whoops I forot,
I am using Kernel 2.2.1
Chris Funk wrote:
> Hi, I am trying to get ip masq. set up.
> I have the pppd part working, but when i try to issue any ipfwadm
> commands I get the following errors
>
> [ns2]# ipfwadm -F -p deny
> "ipfwadm: setsockopt failed: Invalid argument
> [ns2]# ipfwadm -F -a m -S 192.168.0.1/32 -D 0.0.0.0/0
> "ipfwadm: setsockopt failed: No such file or directory
>
> I compiled in ip masq. etc. Did i miss something?
>
> Also, I have the demand line in my /etc/ppp/options file.
> Should a pppd :xxx.xxx.xxx.xxx command fire up the modem?
> I thought that it required me to ping something on the outside world
> before it would dial the modem
>
> Thanks
> Chris Funk
------------------------------
From: Declan <[EMAIL PROTECTED]>
Crossposted-To:
linux.debian.qa,linux.debian.user,comp.os.linux.help,comp.os.linux.questions
Subject: Re: diald: first connection doesn't respond
Date: Tue, 9 Feb 1999 11:09:00 -0500
I had this problem too. I *think* its because the first sent package (to the
proxy) is lost to the proxy. ie/ it never gets sent though the new ip address
that is assigned once the connection is made.
On Tue, 9 Feb 1999, MikeF wrote:
>I'm running diald .16.5-2 in debian 2.0. It will dial automatically when it
>senses ip traffic, but any connections (http,tcp,ping,udp,icmp) that are started
>before/during the dialup scripts are running don't go through. They just
>time-out. How can I fix this? I'm including any relevant config files and my
>ppp log (which includes the diald logs).
>
>/etc/diald/diald.options:
>pppd-options user mikef :209.75.192.5
>device /dev/ttyS3
>connect "/usr/sbin/chat -v -f /etc/chatscripts/net999"
>buffer_size 131072
>local 127.0.0.2
>remote 127.0.0.3
>include /etc/diald/standard.filter
>mode ppp
>speed 57600
>window 3000
>mtu 552
>mru 552
>defaultroute
>lock
>modem
>crtscts
>dynamic
>retry-count 5
>
>/etc/chatscripts/net999:
>ABORT BUSY
>ABORT "NO CARRIER"
>ABORT VOICE
>ABORT "NO DIALTONE"
>ABORT "NO ANSWER"
>"" ATh0zm0
>OK ATDT9051267
>CONNECT \d\c
>
>an ordinary connect cycle in /var/log/ppp.log:
>Feb 8 12:01:26 debian diald[156]: Running connect (pid = 602).
>Feb 8 12:01:26 debian chat[602]: abort on (BUSY)
>Feb 8 12:01:26 debian chat[602]: abort on (NO CARRIER)
>Feb 8 12:01:26 debian chat[602]: abort on (VOICE)
>Feb 8 12:01:26 debian chat[602]: abort on (NO DIALTONE)
>Feb 8 12:01:26 debian chat[602]: abort on (NO ANSWER)
>Feb 8 12:01:26 debian chat[602]: send (ATh0zm0^M)
>Feb 8 12:01:27 debian chat[602]: expect (OK)
>Feb 8 12:01:27 debian chat[602]: ATh0zm0^M^M
>Feb 8 12:01:27 debian chat[602]: OK
>Feb 8 12:01:27 debian chat[602]: -- got it
>Feb 8 12:01:27 debian chat[602]: send (ATDT9051267^M)
>Feb 8 12:01:27 debian chat[602]: expect (CONNECT)
>Feb 8 12:01:27 debian chat[602]: ^M
>Feb 8 12:01:47 debian chat[602]: ATDT9051267^M^M
>Feb 8 12:01:47 debian chat[602]: CONNECT
>Feb 8 12:01:47 debian chat[602]: -- got it
>Feb 8 12:01:47 debian chat[602]: send (\d)
>Feb 8 12:01:48 debian diald[156]: Running pppd (pid = 603).
>Feb 8 12:01:48 debian diald[603]: Running pppd: /usr/sbin/pppd -detach modem
>crtscts mtu 552 mru 552 user mikef :209.75.192.5
>Feb 8 12:01:49 debian pppd[603]: pppd 2.3.5 started by root, uid 0
>Feb 8 12:01:49 debian pppd[603]: Using interface ppp0
>Feb 8 12:01:49 debian pppd[603]: Connect: ppp0 <--> /dev/ttyS3
>Feb 8 12:01:53 debian pppd[603]: Remote message:
>Feb 8 12:01:53 debian pppd[603]: local IP address 209.75.192.37
>Feb 8 12:01:53 debian pppd[603]: remote IP address 209.75.192.5
>Feb 8 12:01:54 debian diald[156]: New addresses: local 209.75.192.37, remote
>209.75.192.5.
>Feb 8 12:13:19 debian diald[156]: Closing down idle link.
>Feb 8 12:13:21 debian pppd[603]: Terminating on signal 2.
>Feb 8 12:13:21 debian pppd[603]: Connection terminated.
>Feb 8 12:13:21 debian pppd[603]: Exit.
>Feb 8 12:13:23 debian diald[156]: Delaying 30 seconds before clear to dial.
>/etc/diald/standard.filter:
># This is a pretty complicated set of filter rules.
># (These are the rules I use myself.)
>#
># I've divided the rules up into four sections.
># TCP packets, UDP packets, ICMP packets and a general catch all rule
># at the end.
>
>
>#------------------------------------------------------------------------------
># Rules for TCP packets.
>#------------------------------------------------------------------------------
># General comments on the rule set:
>#
># In general we would like to treat only data on a TCP link as signficant
># for timeouts. Therefore, we try to ignore packets with no data.
># Since the shortest possible set of headers in a TCP/IP packet is 40 bytes.
># Any packet with length 40 must have no data riding in it.
># We may miss some empty packets this way (optional routing information
># and other extras may be present in the IP header), but we should get
># most of them. Note that we don't want to filter out packets with
># tcp.live clear, since we use them later to speedup disconnects
># on some TCP links.
>#
># We also want to make sure WWW packets live even if the TCP socket
># is shut down. We do this because WWW doesn't keep connections open
># once the data has been transfered, and it would be annoying to have the link
># keep bouncing up and down every time you get a document.
>#
># Outside of WWW the most common use of TCP is for long lived connections,
># that once they are gone mean we no longer need the network connection.
># We don't neccessarily want to wait 10 minutes for the connection
># to go down when we don't have any telnet's or rlogin's running,
># so we want to speed up the timeout on TCP connections that have
># shutdown. We do this by catching packets that do not have the live flag set.
>
># --- start of rule set proper ---
>
># When initiating a connection we only give the link 15 seconds initially.
># The idea here is to deal with possibility that the network on the opposite
># end of the connection is unreachable. In this case you don't really
># want to give the link 10 minutes up time. With the rule below
># we only give the link 15 seconds initially. If the network is reachable
># then we will normally get a response that actually contains some
># data within 15 seconds. If this causes problems because you have a slow
># response time at some site you want to regularly access, you can either
># increase the timeout or remove this rule.
>accept tcp 300 tcp.syn
>
># Keep named xfers from holding the link up
>ignore tcp tcp.dest=tcp.domain
>ignore tcp tcp.source=tcp.domain
>
># (Ack! SCO telnet starts by sending empty SYNs and only opens the
># connection if it gets a response. Sheesh..)
>accept tcp 5 ip.tot_len=40,tcp.syn
>
># keep empty packets from holding the link up (other than empty SYN packets)
>ignore tcp ip.tot_len=40,tcp.live
>
># make sure http transfers hold the link for 2 minutes, even after they end.
># NOTE: Your /etc/services may not define the tcp service www, in which
># case you should comment out the following two lines or get a more
># up to date /etc/services file. See the FAQ for information on obtaining
># a new /etc/services file.
>accept tcp 600 tcp.dest=tcp.www
>accept tcp 600 tcp.source=tcp.www
># Same for https
>accept tcp 600 tcp.dest=tcp.443
>accept tcp 600 tcp.source=tcp.443
>
># Once the link is no longer live, we try to shut down the connection
># quickly. Note that if the link is already down, a state change
># will not bring it back up.
>keepup tcp 5 !tcp.live
>ignore tcp !tcp.live
>
># an ftp-data or ftp connection can be expected to show reasonably frequent
># traffic.
>accept tcp 600 tcp.dest=tcp.ftp
>accept tcp 600 tcp.source=tcp.ftp
>
>#NOTE: ftp-data is not defined in the /etc/services file provided with
># the latest versions of NETKIT, so I've got this commented out here.
># If you want to define it add the following line to your /etc/services:
># ftp-data 20/tcp
># and uncomment the following two rules.
>accept tcp 600 tcp.dest=tcp.ftp-data
>accept tcp 600 tcp.source=tcp.ftp-data
>
># If we don't catch it above, give the link 10 minutes up time.
>accept tcp 600 any
>
># Rules for UDP packets
>#
># We time out domain requests right away, we just want them to bring
># the link up, not keep it around for very long.
># This is because the network will usually come up on a call
># from the resolver library (unless you have all your commonly
># used addresses in /etc/hosts, in which case you will discover
># other problems.)
># Note that you should not make the timeout shorter than the time you
># might expect your DNS server to take to respond. Otherwise
># when the initial link gets established there might be a delay
># greater than this between the initial series of packets before
># any packets that keep the link up longer pass over the link.
>
># Don't bring the link up for rwho.
>ignore udp udp.dest=udp.who
>ignore udp udp.source=udp.who
># Don't bring the link up for RIP.
>ignore udp udp.dest=udp.route
>ignore udp udp.source=udp.route
># Don't bring the link up for NTP or timed.
>ignore udp udp.dest=udp.ntp
>ignore udp udp.source=udp.ntp
>ignore udp udp.dest=udp.timed
>ignore udp udp.source=udp.timed
># Don't bring up on domain name requests between two running nameds.
>ignore udp udp.dest=udp.domain,udp.source=udp.domain
># Bring up the network whenever we make a domain request from someplace
># other than named.
>accept udp 120 udp.dest=udp.domain
>accept udp 120 udp.source=udp.domain
># Do the same for netbios-ns broadcasts
># NOTE: your /etc/services file may not define the netbios-ns service
># in which case you should comment out the next three lines.
>ignore udp udp.source=udp.netbios-ns,udp.dest=udp.netbios-ns
>accept udp 120 udp.dest=udp.netbios-ns
>accept udp 120 udp.source=udp.netbios-ns
># keep routed and gated transfers from holding the link up
>ignore udp tcp.dest=udp.route
>ignore udp tcp.source=udp.route
># Anything else gest 2 minutes.
>accept udp 600 any
>
># Catch any packets that we didn't catch above and give the connection
># 30 seconds of live time.
>accept any 600 any
>
>
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.networking) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Networking Digest
******************************
