[sslh] Latest commit breaks fork

[Matt Smith]

Here we go....

Actually it doesn't appear that the program has stopped. But the "master"
process has changed pid which makes my init script think it's stopped. So
it looks like it's common.c line 250.

I should also mention that I use both IPv4 and IPv6. Which is why I have
the hostname in the listen and protocols section, as it makes it
listen/forward on both v4 and v6. And the transparent proxying is set up
for both v4 and v6. Maybe that's a factor?

ipfw add 00020 fwd 10.0.0.10,4444 tcp from 'table(2)' to 10.0.0.10 443 in
via re0
ipfw add 00021 fwd 10.0.0.10,4444 tcp from 10.0.0.10 422,444 to 'table(2)'
out via re0

ipfw add 00022 fwd 2001:8b0:abcd::10,4444 tcp from 'table(2)' to
2001:8b0:abcd::10 443 in via re0
ipfw add 00023 fwd 2001:8b0:abcd::10,4444 tcp from 2001:8b0:abcd::10
422,444 to 'table(2)' out via re0

root at tao[~]# netstat -an | grep 4444
tcp4       0      0 10.0.0.10.4444         *.*                    LISTEN
tcp6       0      0 2001:8b0:fe33::1.4444  *.*                    LISTEN

Jan 11 08:39:07 tao sslh-select[30941]: sslh-select v1.18-83-gc8c6688
started

root at tao[~]# ps waux | grep sslh
root     68311   0.0  0.1   7044   2792  -  Is   08:42       0:00.00
/root/bin/sslh-select -F/usr/local/etc/sslh.conf

(I connect at this point)

Jan 11 08:39:11 tao sslh-select[30941]: common.c:250:getpeername:9:Bad file
descriptor
Jan 11 08:39:11 tao sslh-select[30941]: common.c:250:getpeername:9:Bad file
descriptor

root at tao[~]# ps waux | grep sslh
root     97262   0.0  0.1   7044   2788  -  S    08:42       0:00.00
/root/bin/sslh-select -F/usr/local/etc/sslh.conf

root at tao[~]# service sslh restart
Stopping sslh.
kill: 68311: No such process

Regards, Matt.

On 10 January 2018 at 22:14, Yves Rutschle <yves at rutschle.net> wrote:

> On Wed, Jan 10, 2018 at 01:32:14PM +0000, Matt Smith wrote:
> > Yes I do use transparent proxying. I don't get any messages before or
> after.
>
> I had a theory that it came from there... and realised that
> transparent proxying doesn't work on my system (but I don't
> think that's sslh's fault)...
>
> I can't see an execution path that would go from getpeername
> failing to the program stopping. I just pushed a tiny patch
> to add file and line numbers to the error messages (I can't
> believe I've never put that in), would you confirm which
> getpeername it is that fails?
>
> Cheers,
> Y.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rutschle.net/pipermail/sslh/attachments/20180111/de9902eb/attachment.html>