Hi folks - wanted to drop a note to the list in the hopes someone can help me in diagnosing a problem. I've been using diald for some time now (love it - next best thing to DSL only slower) but I've never been able to make it behave the way I think it should. In particular, HTTP works just fine - once a page is hit, the link has an additional 10 minutes of live time, however despite many efforts at tweaking the filter set - I can't replicate this behavior for other protocols (i.e. POP3 and SMTP). I've attached my standard.filter for your edification -- it's pretty standard. What I think should be simple (replicate the two lines present for HTTP and alter the protocol) doesn't work -- instead the connection *starts* out right, but as soon as the TCP session is finished (i.e. the mail is sent, the POP session over) the timer on that item in the queue drops to 5 seconds (always the same number). I finally managed to get a quiet network this evening (my linux machine is IP masquerading for other hosts) and captured the following: Time 0 - a quiet link: Jun 8 19:42:02 rage diald[610]: User requested dump of firewall queue. Jun 8 19:42:02 rage diald[610]: -------------------------------------- Jun 8 19:42:02 rage diald[610]: up = 1, forcing = 0, impulse = 1, iitime = 0, itime = 0, ifuzz = 0, itimeout = -101250, timeout = -14593, next alarm = 0 Jun 8 19:42:02 rage diald[610]: -------------------------------------- Time 1 - I telnet'd to my mail server's SMTP port - simulating sending mail and sent diald SIGUSR2 - notice the only things holding the connection up are the name resolution (the udp's on port 53) and the telnet (tcp to port 25) Jun 8 19:42:27 rage diald[610]: User requested dump of firewall queue. Jun 8 19:42:27 rage diald[610]: -------------------------------------- Jun 8 19:42:27 rage diald[610]: up = 1, forcing = 0, impulse = 1, iitime = 0, itime = 0, ifuzz = 0, itimeout = -101275, timeout = -14618, next alarm = 20 Jun 8 19:42:27 rage diald[610]: ttl 896, 6 - 199.35.100.80/1283 => 206.214.98.8/25 (tcp state ([0,0] 0,3)) Jun 8 19:42:27 rage diald[610]: ttl 26, 17 - 199.35.100.80/1081 => 199.182.120.202/53 (tcp state ([0,0] 0,0)) Jun 8 19:42:27 rage diald[610]: ttl 20, 17 - 199.35.100.80/1024 => 206.214.98.98/53 (tcp state ([0,0] 0,0)) Jun 8 19:42:27 rage diald[610]: ttl 20, 17 - 199.35.100.80/1024 => 199.183.9.5/53 (tcp state ([0,0] 0,0)) Jun 8 19:42:27 rage diald[610]: ttl 20, 17 - 199.35.100.80/1024 => 206.217.29.221/53 (tcp state ([0,0] 0,0)) Jun 8 19:42:27 rage diald[610]: -------------------------------------- Time 1 - I QUIT the connection to the SMTP server, simulating completion of mail transfer. Some of the UDP's have timed out and gone away (good behavior). Jun 8 19:42:47 rage diald[610]: User requested dump of firewall queue. Jun 8 19:42:47 rage diald[610]: -------------------------------------- Jun 8 19:42:47 rage diald[610]: up = 1, forcing = 0, impulse = 1, iitime = 0, itime = 0, ifuzz = 0, itimeout = -101295, timeout = -14638, next alarm = 4 Jun 8 19:42:47 rage diald[610]: ttl 4, 6 - 199.35.100.80/1283 => 206.214.98.8/25 (tcp state ([7da9a106,78322746] 3,0)) Jun 8 19:42:47 rage diald[610]: ttl 6, 17 - 199.35.100.80/1081 => 199.182.120.202/53 (tcp state ([0,0] 0,0)) Jun 8 19:42:47 rage diald[610]: -------------------------------------- Time 2 - a few seconds later -- notice the TCP connection is gone - far too soon: Jun 8 19:42:54 rage diald[610]: User requested dump of firewall queue. Jun 8 19:42:54 rage diald[610]: -------------------------------------- Jun 8 19:42:54 rage diald[610]: up = 1, forcing = 0, impulse = 1, iitime = 0, itime = 0, ifuzz = 0, itimeout = -101302, timeout = -14645, next alarm = 0 Jun 8 19:42:54 rage diald[610]: -------------------------------------- Another example, this time with HTTP: Time 0 - quiet link Jun 8 19:44:24 rage diald[610]: User requested dump of firewall queue. Jun 8 19:44:24 rage diald[610]: -------------------------------------- Jun 8 19:44:24 rage diald[610]: up = 1, forcing = 0, impulse = 1, iitime = 0, itime = 0, ifuzz = 0, itimeout = -101392, timeout = -14735, next alarm = 0 Jun 8 19:44:24 rage diald[610]: -------------------------------------- Time 1 - telnet to my favorite web server and do a HEAD / HTTP/1.0 <cr><cr> - which closes the connection once it returns the requested data... Jun 8 19:45:01 rage diald[610]: User requested dump of firewall queue. Jun 8 19:45:01 rage diald[610]: -------------------------------------- Jun 8 19:45:01 rage diald[610]: up = 1, forcing = 0, impulse = 1, iitime = 0, itime = 0, ifuzz = 0, itimeout = -101429, timeout = -14772, next alarm = 27 Jun 8 19:45:01 rage diald[610]: ttl 597, 6 - 199.35.100.80/1284 => 206.217.29.10/80 (tcp state ([0,0] 0,3)) Jun 8 19:45:01 rage diald[610]: ttl 27, 17 - 199.35.100.80/1024 => 199.183.9.5/53 (tcp state ([0,0] 0,0)) Jun 8 19:45:01 rage diald[610]: -------------------------------------- Time 2 - several minutes later, that TCP Connection is still holding the link up - as expected: Jun 8 19:46:02 rage diald[610]: User requested dump of firewall queue. Jun 8 19:46:02 rage diald[610]: -------------------------------------- Jun 8 19:46:02 rage diald[610]: up = 1, forcing = 0, impulse = 1, iitime = 0, itime = 0, ifuzz = 0, itimeout = -101490, timeout = -14833, next alarm = 555 Jun 8 19:46:02 rage diald[610]: ttl 555, 6 - 199.35.100.80/1284 => 206.217.29.10/80 (tcp state ([86485ad4,37d99f37] 1,3)) Jun 8 19:46:02 rage diald[610]: -------------------------------------- I'm running RedHat 6.0 - kernel 2.2.5, pppd 2.3.7. Prior to this I was running RedHat 5.2 and I couldn't swear I saw the same behavior. When I noticed it under RH 6.0, I recompiled diald and nothing changed. Any suggestions? Thanks much. -- Dan Berger [[EMAIL PROTECTED]] http://www.ix.netcom.com/~dberger
# 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 15 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 10 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 # 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 120 tcp.dest=tcp.ftp accept tcp 120 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 120 tcp.dest=tcp.ftp-data accept tcp 120 tcp.source=tcp.ftp-data # a POP3 connection doesn't need to live much longer than it's active #accept tcp 300 tcp.dest=tcp.pop #accept tcp 300 tcp.source=tcp.pop # a SMTP connection doesn't need to live much longer than it's active #accept tcp 600 tcp.dest=tcp.smtp #accept tcp 600 tcp.source=tcp.smtp # If we don't catch it above, give the link 15 minutes up time. accept tcp 900 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 30 udp.dest=udp.domain accept udp 30 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 30 udp.dest=udp.netbios-ns accept udp 30 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 gets 5 minutes. accept udp 300 any # Catch any packets that we didn't catch above and give the connection # 90 seconds of live time. accept any 90 any
