I wanted to keep pop-3 mail checks from bringing up the link so I did what I felt was obvious; I modified standard.filter to include the following right after the "ignore tcp ip.tot_len=40,tcp.live" rule: ignore tcp tcp.dest=tcp.pop-3 ignore tcp tcp.source=tcp.pop-3 (these are rules 6 and 7) /etc/services defines: pop-3 110/tcp # POP version 3 pop-3 110/udp With debug set to 31, I get the following in syslog as fetcmail polls the server: May 21 00:50:47 layla diald[23015]: filter ignored rule 7 proto 6 len 135 seq 6220f279 ack 419c56cd flags PUSH ACK packet 194.144.156.3,110 => 194.144.158.243,26190 However, strangely enough, I still get this in dctrl's connection queue display: tcp 194.144.156.3/110 194.144.158.243,26190 It starts with a timeout of 15 seconds. The only thing in my filter rules with a 15 second timeout is rule 1: accept tcp 15 tcp.syn. And indeed, I sometimes see an "filter accepter rule 1" just before the ignore message for rule 7. And that match refers to the same port number as the rule 7 match. There isn't one rule 1 match for each rule 7 match, however, and that makes the whole thing even stranger. Now, when I started writing this letter I hadn't realized the significance of those rule 1 matches and now that I have, I've just tried moving rule 7 to the top. The result is that port 110 connections no longer show up in dctrl. So, the message that started out as a plea for help has become a public service announcement and a curiosity driven request for enlightenment. Why did diald behave this way? Haukur Hreinsson - To unsubscribe from this list: send the line "unsubscribe linux-diald" in the body of a message to [EMAIL PROTECTED]
