#1602 Startup use case fail: Connecting to quasi-temporary network

[darioshanghai]

Hi,

I know the config file requires the IPs to listen on to be available at start, however I want to point out a situation in which this is a disadvantage (and maybe hear your suggestions for a solution). I have an android phone, a small android tablet, and a Linux Mint computer. I also have a non-techie girlfriend.

We are currently on the go, and we use the phone connection to navigate internet with the laptop and tablet (much better to have a laptop when you have much to write, or big photos to look at and edit etc.

We connect the phone to the computer via USB, tether the connection and then, if needed, connect the tablet to the computer's ad-hoc wifi. We do this instead of just using bluetooth from the phone to extend the benefits of our privoxy/polipo setup on the computer to the tablet as well, to save expensive and rare bandwidth. Privoxy is set up to work with Polipo. It's set up with the localhost and the IP address assigned by the phone's wired network, say 1.2.3.4.

At boot, the services are started. Polipo goes, but Privoxy fails: "Fatal error: can't bind to 1.2.3.4:8118."

Then we have to restart privoxy manually, which I can do, but not my girlfriend. It also annoys me, since no configuration needs to actually be changed. If we disconnect and reconnect the phone's cable, the network keeps working ok, because the IP offered is always 1.2.3.4, as a further indication that, in this use case, the attitude of Privoxy of requiring the IPs to respond at start is a bug, not a feature.

Thank you for reading (and if you have a solution in mind to share).

[Fabian Keil]

Binding to the unavailable address is prevented by the operating system, not by Privoxy itself.

If you are working with known IP addresses I'd let Privoxy bind to localhost only and use the system's packet filter (e.g. IPtables) to redirect requests for "1.2.3.4:8118" coming from the expected addresses to Privoxy.