Jail with bitblee running, connection timed out

[Arthur Chance]

On 11/03/2015 14:09, Matthew Seaman wrote:
> On 2015/03/11 13:59, 1126 (Christian Lask) wrote:
>> `stockstat -l4p 6667` reveals that it is indeed listening on the jails
>> IP on port 6667. In Weechat then I added a new server (localhost/6667)
>> and tried to connect to it. This connection however is never established
>> and times out. I do not know how to debug this properly and have no idea
>> what is wrong here. Configuration of both seems pretty straightforward,
>> so I don't know what I am doing wrong here.
>
> Jails tend not to have localhost (ie. 127.0.0.1 or ::1) addresses
> accessible to them[*].  Try logging into the jail and examine the output
> of 'ifconfig -a' -- compare it with what you get on the host system.

The networking code special cases attempts to connect to or listen on 
127.0.0.1 (or ::1 for IPv6) within jails and replaces those addresses 
with the primary IP address for the jail (failing if there isn't one).

Take a look at prison_(local|remote)_ip[46] in 
/usr/src/sys/kern/kern_jail.c and their uses in the inet code. (I'm 
looking at 10.1-REL code).

Did the OP actually have an /etc/hosts in the jail? If not, localhost 
wouldn't resolve. Not sure why that would cause a hang though.

> If you want some processes within the same jail to be able to
> communicate through a network-like protocol, then unix domain sockets
> are the way to go, assuming that the software you want to run supports
> them.  Failing that, you'll have to use the jail's allocated IP number(s).
>
> 	Cheers,
>
> 	Matthew
>
> [*] There is a new alternative style of jail, called a VNET jail, which
> you could use and that do have their own loopback interfaces and
> localhost addresses, but these are still fairly new, somewhat more
> complicated to setup and still not thoroughly debugged.  Last I checked,
> they also required you to run a custom kernel.

-- 
Those who do not learn from computing history are doomed to
GOTO 1