Date: Tue, 5 Jun 2001 20:49:34 +0200 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-stable@FreeBSD.ORG Subject: Re: /usr/bin/host doesn't work in jail ...? Message-ID: <20010605204934.B17514@speedy.gsinet> In-Reply-To: <200106051225.OAA74361@lurza.secnetix.de>; from olli@secnetix.de on Tue, Jun 05, 2001 at 02:25:40PM %2B0200 References: <20010604224217.A253@speedy.gsinet> <200106051225.OAA74361@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 05, 2001 at 14:25 +0200, Oliver Fromme wrote:
>
> Gerhard Sittig <Gerhard.Sittig@gmx.net> wrote:
>
> [ UDP communication doesn't work from inside jails ]
>
> > - does *any* UDP communication work from inside the jail (to
> > itself and outside)? Can you play with /usr/ports/net/netcat?
> > jail$ echo OHYES | nc -l -u -p 8080
> > jail$ echo HELLO | nc -w 1 -u $IP 8080
> > host$ echo HELLO | nc -w 1 -u $IP 8080
>
> Fails the same inside the jail:
> 86229 nc CALL connect(0x3,0x12005e060,0x10)
> 86229 nc RET connect -1 errno 22 Invalid argument
>
> You're right, it semms to affect all UDP datagram sockets.
>
> [ ... ]
>
> > Can you dump the calling parameters? Does ktrace(1) provide this
> > information?
>
> Unfortunately, it doesn't.
Then I have a dumb - but becoming urgent - question: Which tools
are available to programmers in FreeBSD for this purpose? I'm
under the (fresh) impression of Linux' strace(1) nicely listing
select(2) descriptor fields, read and written data, IP address
structs, and the like, being capable of filtering ("qualifying")
what's to be traced, summarizing (sort of profiling?), keeping
the children's traces separate, etc.
"man -k trace" and "man -a ktrace ptrace truss kdump" as well as
"grep -i trace /usr/ports/INDEX" on a 4.3-STABLE box as of last
Thursday couldn't shed any more light into the dark corner I'm
feeling to be in ... :-/
Is there an alternative to "$CC -g" and gdb(1) I'm not aware of?
Did I miss some ktrace(1)/kdump(1) option when reading their
manpages? But I take it this combo is like profiling: quickly
collecting minimal(?) data, writing in some proprietary format,
and doing the expensive display formatting for the user later.
While strace(1) is more like truss(1), printing "live" formatted
data while the process is running and having access to the
parameters for kind representation. Maybe that's what could be
achieved with kdump's -m switch.
Should kdump know even more function names and their parameter
lists? Should ktrace collect more data?
> > BTW: Wasn't there a bug in the gnats database about
> > processes failing (forgetting) to bind(2) their sockets to
> > an address? Search the PRs for "jail" to see if it's been
> > fixed since.
>
> Oh, hm, that might be it. host and nslookup don't use bind().
>
> I'll dig into the source, add a bind() and see if that changes
> anything. *sigh* There should be a sysctl or something so
> that it binds automatically inside jails if necessary. I guess
> host/nslookup are not the only programs which have problems ...
> :-(
It's wasn't really failing communication AFAIR, but a bug in the
IP stack using the host's(!) primary IP address as the sender's
information. Although communication was initiated from within
the jail it seemed to come from the host. This possibly made the
traffic end in a packet filter's bit bucket. But the problem
seemed to be rather uncommon from the response and age of the PR,
many applications seem to use bind(2) -- or few admins seem to
employ jails. And DNS always worked for me since I'm used to use
djbdns and have the IPSEND setting available. :)
> > > Oh by the way: When I enter the jail, the configuration
> > > of the lo0 interface gets deleted (and I can't bring it
> > > back within the jail):
> >
> > That's one of the design goals of a jail: to provide
> > resources for manipulation only when they are available for
> > the jailed process group exclusively
>
> I'm aware that it's perfectly OK that I can't manipulate lo0
> inside the jail. I'm just worried that it gets deleted as soon
> as I enter the jail, because some things might need a correctly
> configured lo0.
That's when I was talking about the "failed _assumption_ that
there always is some 'localhost' and '127.0.0.1' interface
available under UNIX" in the PR I mentioned. *Not* having these
is soooo hard to imagine an environment that I didn't get *any*
reply from the samba community. Providing patches and offering
to update them didn't matter. :(
If I knew if the method I propose is promising and leads to
something useful when applied to more networked apps I'd be
willing to spend more time on it. But since I'm uncertain ...
Here's a reference again for the interested reader, feedback is
highly appreciated:
http://www.freebsd.org/cgi/query-pr.cgi?pr=22316
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010605204934.B17514>