>I dunno whose problem this is, it may be a weird interaction of several
>different packages.
>Sometimes (not infrequently) if you're not careful how you operate
>the AOL client, it appears to spit out a packet destined for some
>unnamed server at AOL (based on searches with nslookup and similar
>tools) into the in-house network instead of sending it out over its
>own dialup connection. This, of course, causes diald to pick up the
>phone thereby disconnecting the direct dialup connection AOL has
>established on its local modem.
I'd suggest that you modify your ip masquerading rules to block
these packets that bring up the connection. If you have a port
number and a source/destination, it shouldn't be that hard to
do.
You could also put it into your diald filter and tell diald to
ignore such packets.
>This commonly happens because of a prompt for password that appears to
>come from the SMB subsystem every time one fires up AOL. If you click
>the CANCEL button on this dialog you get these stray packets that
>cause diald to try to bring up the modem.
This sounds pretty scary to me. Why should an AOL client prompt for
a password from the SMB subsystem?
>One way to "fix" it is to reconfigure the AOL client so it uses a
>TCP/IP connection to AOL (thereby forcing it to use diald to bring
>up the link for its main connection). But the person who uses the AOL
>client for some reason I fail to understand insists on using the local
>modem instead.
I can understand that. It's her/his modem, she/he has paid for it, why
not use it? As well, she/he doesn't have to share bandwidth with
the masqueraded connection.
HTH
Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
