Hi Wilson,
> OK, I've been using my home network a bit more lately and a
> couple (well at
> least one) of things don't quite seem to gel with my filters so ...
>
> First my filters are pretty much just the standard.filter
> with 0.99.3 apart
> from a few minor changes to times and, (I think) one
> addition. I've attached
> them at the end.
>
> AN ANNOYING THING
> OK pop brings the link up. ie:
> Trigger: tcp 192.168.3.50/1035 203.26.10.16/110
>
> I don't have a specific POP rule so I would expect the link
> to stay up for
> 10 minutes because of this rule:
> # If we don't catch it above, give the link 10 minutes up time.
> accept tcp 600 any
>
> But it doesn't. In the Trigger example above there was no
> mail to pick up
> and the link dropped out in 1.0 minute.
>
> Now I suspect that the reason for this is that these rules (which come
> before the tcp catch all) are overriding the accept tcp 600
> any rule. Any
> thoughts ???
> # 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
Exactly, pop-3 works in a single connection. It closes the connection when
it is done. So the !tcp.live rule is matched before you can get down to
accept tcp 600 any. And the timer shifts down to 5 seconds.
People typically want diald to close as soon possible after traffic stops
crossing the link.
> Now if this IS the case then why don't they also override say a www
> connection once the link becomes innactive ? Is it because
> the above rules
> and the "tcp any" rule don't have any identifiers apart from
> protocol and so
> get placed in the same set ? ie. diald-examples says: "If
> <id> is already in
> the set, ... new ... will replace ... old ... the new timeout
> may be less
> than the old ...".
1. http 1.1 keeps the connection open (it doesn't automatically close the
connection after a single item is downloaded).
2. http is typically a series of different connections that open and close
all the time. So !tcp.live does not mean you've stopped using http.
Therefore the rule for matching http connections appears before the rule for
!tcp.live packets (the first rule to match is the one that is used).
> In that case I have changed my catch all to be 10 minutes
> which I would
> guess is a waste of time since once it's finished the drop
> off rule will
> supercede it.
>
> If I am right I guess the only solution if I want POP to keep
> the link up
> for 10 minutes, say, would be to specifically add it. Correct ?
Correct if you want pop traffic to keep the link up for 10 minutes then you
need to add a rule for it before the keepup tcp 5 !tcp.live rule.
If you don't want the drop off rule to apply to any traffic then comment it
out.
> Any comments, confirmations or suggestions ??????
>
> ANOTHER MINOR NIGLING THING
>
> I know there has been a fair bit of discussion about this
> one. In fact too
> much to trawl through it all and summarise the conclusions.
> So I'm hoping
> someone has been involved in examining this and can sum up
> what the results
> were.
>
> My link comes up initailly on bootup with a domain packet
> such as this:
> Trigger: udp 192.168.3.49/1024 128.63.2.53/53
is 192.168.3.49 the machine running diald or another machine?
I'll assume it's the address for the diald machine in my comments below.
> Anyone have an idea what is bringing it up in RH6.1 ? (BTW:
> RH6.1). It's
> only on boot up so it's not really a problem ... the 20 cents
> isn't going to
> break me but it all adds up after a while.
The number of possibilities is too great to count.
1. if you are using bind as a caching name server it will immediately
attempt to reach the root servers. this is normal and expected for bind.
(just don't boot very often, or move diald so it starts long after bind has
timed out, this may not be possible with a new fast processor, it's easily
done with an old 486-33)
2. if you are running sendmail and/or apache (and possibly even more
daemons) they try and lookup the name of the machine they are running on.
make sure you either have a nameserver with forward and reverse zones setup
for the machine (and the local network) or you list all the addresses the
machine will use in the /etc/hosts file. This includes the diald proxy
addresses.
3. if you are running samba, it may try and resolve the workgroup name in
addition to the names of the interfaces.
4. if you defined any firewall rules using names rather than ip addresses
the names will need to be resolved.
Just an example:
/etc/hosts
--
# lo - loopback interface (always exists)
127.0.0.1 localhost localhost.localdomain
# eth0 - nic for the local network
192.168.3.49 thisbox thisbox.mydomain
# tap0 - diald interface
10.0.0.1 diald-local
10.0.0.2 diald-remote
# local network connections
192.168.3.0 workgroup #workgroup name for smb networking
192.168.3.1 workstation workstation.mydomain
192.168.3.2 networkprinter networkprinter.mydomain.com
--
Hope this helps,
Lourdes
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
