Hi,

That's the FreeBSD TCP blackhole: net.inet.tcp.blackhole=2

Unfortunately it also affects localhost, so every packed to an unbound port
is dropped. I am not sure what the sense behind having a blackhole on
localhost is security-wise, but this is how the FreeBSD machines are
configured at Apache.

For Lucene/Solr tests on our FreeBSD slave we use different approaches to
test failed network connections:
- Use invalid IPv6 addresses, they fail wonderfully
- Use another invalid IP address except 127.0.0.1 or localhost

> -----Original Message-----
> From: Keith W [mailto:keith.w...@gmail.com]
> Sent: Monday, February 27, 2012 11:42 PM
> To: builds@apache.org
> Subject: Re: FreeBSD Jenkins slave - no timely "connection refused" when
> connecting to a port is not bound
> 
> Hello builds
> 
> Would anyone be able to take a look at this please?
> 
> Many thanks, Keith.
> 
> On 20 February 2012 09:55, Keith W <keith.w...@gmail.com> wrote:
> > Hello builds
> >
> > I have a question about the FreeBSD Jenkins slave.
> >
> > Our (Qpid) test suite includes a end-to-end test that tests the
> > behaviour of Qpid client when it tries connect to the Qpid server
> > before it is started.  Specifically, this means the client tries to
> > form a TCP/IP connection to an unbound port on localhost.   The test
> > relies on a getting a timely "Connection Refused" type error from the
> > underlying socket connect attempt.
> >
> > The test works without problems on the other Apache Jenkins slaves
> > (ubuntu, solaris etc), but on FreeBSD it consistently fails.
> >
> > I can reproduce the problem outside Qpid by getting a Jenkins job to
> > telnet to an unused port.  The telnet command hangs for over a minute
> > then produces:
> >
> > telnet localhost 45678
> > Operation timed out
> >
> > I would expect an immediate "Connection Refused" when trying to
> > connect to a port which is not bound.
> >
> > Is this behaviour deliberate (part of a FreeBSD jail config??
> > perhaps), or a miss configuration of the FreeBSD instance?
> >
> > Thanks in advance, Keith Wall.

Reply via email to