From owner-freebsd-stable Tue Jun 5 12:18: 7 2001 Delivered-To: freebsd-stable@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 11DE237B403 for ; Tue, 5 Jun 2001 12:17:56 -0700 (PDT) (envelope-from Gerhard.Sittig@gmx.net) Received: (qmail 27669 invoked by uid 0); 5 Jun 2001 19:17:54 -0000 Received: from p3ee20aa6.dip.t-dialin.net (HELO speedy.gsinet) (62.226.10.166) by mail.gmx.net (mail06) with SMTP; 5 Jun 2001 19:17:54 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id UAA17619 for freebsd-stable@FreeBSD.ORG; Tue, 5 Jun 2001 20:49:34 +0200 Date: Tue, 5 Jun 2001 20:49:34 +0200 From: Gerhard Sittig To: freebsd-stable@FreeBSD.ORG Subject: Re: /usr/bin/host doesn't work in jail ...? Message-ID: <20010605204934.B17514@speedy.gsinet> Mail-Followup-To: freebsd-stable@FreeBSD.ORG References: <20010604224217.A253@speedy.gsinet> <200106051225.OAA74361@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200106051225.OAA74361@lurza.secnetix.de>; from olli@secnetix.de on Tue, Jun 05, 2001 at 02:25:40PM +0200 Organization: System Defenestrators Inc. Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jun 05, 2001 at 14:25 +0200, Oliver Fromme wrote: > > Gerhard Sittig 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