Comment 2 for bug 825593

Hi Stefano,

Thank you so much for your quick response :).

I have just installed the cntlm 0.91rc6 a couple of days ago via aptitude, so it should have your fix in '/etc/network/if-up.d/' (I will verify this on Mon. when I get back to the office). But from the boot log, I do notice the 2nd round print about ACLs are being added. It kind of puzzled me before, but after I read your fix, I understand that this got to be the 2nd attempt to start cntlm when the network interface is finally up.

This is my situation. I have 2 network interface, eth00 (192.168.1.1) and eth10(192.168.241.1 and a bunch of other secondaries IPs). Based on the my cntlm config 1 (that I described in my original posting), I get error print on the boot log stating that the last 'Listen' interface is not available. So I guess it takes longer to bring up eth10 as it has several IPs bound to it. So when eth00 is up and invokes '/etc/network/if-up.d/', the eth10 is not ready when cntlm is started. And when finally eth10 is up, the 2nd invocation of '/etc/network/if-up.d/' won't do anything to cntlm as start-stop-daemon simply quits as cntlm has been started. The 'netstat -an | grep LISTEN' seems to confirm this situation.

So I got into thinking, may be it's better to do 'restart' rather than 'start' in '/etc/network/if-up.d/'. With this, and ifup event will restart cntlm, so when some body do ifdown & then ifup manually, the cntlm is restarted and if the cntlm listen to the newly up interface, it will now listen properly. Of course there is a possible drawback, that if the cntlm does not listen to this newly up interface, then it may be restarted for nothing.

Btw, I have just learn linux (ubuntu) a few months back, so there might be some stuff I mentioned above is completely stupid or non-sense :(.

Do you know what happen with cntlm (or any process that open a socket for listening) if the listened interface suffers link failure? Will the socket connection is closed? Hence when the interface recovers later on, it will not listen to it any longer?

Will '/etc/network/if-up.d/' executed when the link recovers? Or it will only be executed on manual ifup?

If my suggestion using 'restart' instead of 'start' is acceptable, will you be kind propose the change? Also please incorporate: http://sourceforge.net/tracker/?func=detail&aid=3206995&group_id=197861&atid=963162
changes that actually check the '/etc/rc<x>.d/', whether the cntlm is supposed to be started at the current runlevel or not.

OK, now about the Config 2 of my cntlm. This one I still get puzzled :(. I configured cntlm as gateway, hence it open a socket connection '0.0.0.0:8081'. So during the '/etc/network/if-up.d/' invocation when eth00 is up, managed to start cntlm correctly (at least based on 'netstat -an | grep LISTEN'). So when the eth10 is up, even though the cntlm is not restart, it should still work as the linux network driver will forward the incoming packet to cntlm as the socket was opened with '0.0.0.0' address. And the fact that I got HTTP 502 result from cntlm, this confirms that cntlm does receive the HTTP GET coming from eth10. Btw, I also configure cntlm as standalone proxy (NoProxy *), so this request will result direct_request() in direct.c is called. And the only place in direct.c that generates HTTP 502 is if the host_connect() call failed. And I simply can't figure it out why on earth at this point the host_connect() fails. My IP trace on eth10 shows that cntlm doesn't even try to open TCP connection (SYN) to the requested server at all. A simple manual restart of cntlm fix this. Do you have any thought on this matter?

Btw, I also can't find where cntlm try to check the connectivity to it's parent proxy at startup, do you mind point me to it?

Again, many thanks for your kind response and I hope you have time to response to my lengthy questions :).

Cheers //Edo