User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 Dialup on demand for computers on LANs needs to distinguish between SERVERS and CLIENTS. If it is running on a SERVER it should dialup, whereas it should not on a CLIENT. For example: I have a home LAN network with a desktop and a laptop. The laptop is a CLIENT that connects to the net through the desktop SERVER when it is on the LAN or by direct dial when it is not.. When I bring up Mozilla on the server I expect it to connect via my dial up modem. It does not because Moz detects the LAN connection and doesn't dial. OTOH if I bring up Moz on the laptop when it is connected to the L.AN, it should not direct dial. Reproducible: Always Steps to Reproduce: 1. Establish a LAN with SERVER A and CLIENT B 2. Start Mozilla on A and try to access the net (e.g., Get mail) Actual Results: Dialup on demand did not work. Manual intervention was required to dial my ISP. Expected Results: Automatically connect to my ISP

If you use other browsers, does auto-dial work the way you want? I'm nominating this nsbeta1 because I think it is a pretty reasonable sounding configuration that I think we overlooked when we implemented the feature. The pref either needs a 3rd mode (dial no matter what) or we need to think about other siutations as well. If anyone knows what Windows 9x does in this situation, please let me know.

NS 4.79 does not dialup on demand. IE 6.x does (even with the LAN connected). Since LAN "administrators" are (or ought to be) fairly sophisticated users, I think a simple solution might work: turn autodial ON or OFF (ignoring the existence of LANs). Then one can turn it ON on servers and OFF on clients. It would be nice if this were available as an Advanced EDIT preference.

You can disable the feature completely in Mozilla by setting the pref network.autodial-helper.enabled to false. There are no plans for a UI.

adt: nsbeta1-

By desciption this could be duplicate of bug 465158.