DCC use of connect() and sendto() on FreeBSD

Jamie Clark jamie@zeroth.org
Thu Sep 23 15:29:03 UTC 2004

Vernon Schryver wrote:

>(second copy responding to the list this time)
Sorry about that. I've been a bit clumsy with the email of late.

>>Also, running the application in a debugger is not a substitute for
>>a system call trace.
>That is more mistaken than not, because in many UNIX flavors one can
>put breakpoints in/at the system call wrappers and so see the interesting
>system calls the application is making, and in context.
OK, fair point. I was taking the angle that sometimes you might
start with a packet dump - to see what the system thinks is happening
on the wire - then you might use truss/strace if thing look that way...
Depends on where your instinct tells you to look first.
With code that I know well I probably start with instrumentation
and gdb...

>>gdb, strace and truss are all just tools. I have no peeves with
>>any of them, and I pick whichever shines a light on a problem.
>Perhaps people don't send you thousands of irrelevant lines
>of system call traces and expect you to figure what is wrong.
>If I had a dollar for every strace/truss report for a problem
>that turns out to be a configuration error...
OK. Just as bad as those that send thousands of
lines of firewall log and complain that you sent them a

>>I had actually been down this path days ago. I found that If
>>I change the definition of DCC_UDP_DISCON, in the FreeBSD case to:
>>#define DCC_UDP_DISCON  sizeof(ctxt->conn_su)
>>Then the disconnects seem to work. Just as my test code did.
>Huh!  Did I mess that not so minor detail in your previous messages?
Perhaps my fault for taking one too many logical leaps before

>I call connect() with an address size of 0 because that seems to be
>required on some UNIX systems.  I've forgotten exactly which.
>Are you sure you are not using a jail?  
I do run jails, and I started with dccm in a jail (the same jail
that hosts some related mail services), but since
discovering this issue I have kept my diagnostics to 'outside'
any jail.

Maybe there is a side effect of a jailed environment on the
same system?

>The 4.9-RELEASE udp_connect()
>has a test of p->p_prison and a use of prison_remote_ip().
>That use of prison_remote_ip() looks bogus when the address size is zero,
>because it uses the s_addr from the supposedly 0-length address.
>What happens if you apply the following temporary/diagnostic patch?:
>--- dcclib/clnt_send.c 2004/05/02 01:51:55     1.92
>+++ dcclib/clnt_send.c 2004/09/23 13:31:25
>@@ -1496,6 +1496,7 @@
> static void
> disconnect(DCC_CLNT_CTXT *ctxt)
> {
>+       memset(ctxt->conn_su.sa, 0, sizeof(ctxt->conn_su.sa));
>        ctxt->conn_su.sa.sa_family = AF_UNSPEC;
>        connect(ctxt->soc, &ctxt->conn_su.sa, DCC_UDP_DISCON);
> }
I did some experimentation there previously - but might have
discarded that effort too soon. I really wasn't sure if someone
had been down that path already and determined F'BSD to be

I'll take your advice and try zeroing the struct.

At one stage I though I had this working - but it seemed to
regress after time. Possibly I was confused with a real network

>>Exuse my use of truss. I find that it concisely shows the socket
>>operations that I want to see. How to do easily in gdb?
>try  "b connect" and "b sendto"
>or try `grep 'connect(' */*.[ch]` and the set breakpoints at the
>connect() system calls you care about in the application, thereby
>excluding the uses of connect() in the resolver library and elsewhere.
>or look for the error message you were seeing from cdcc in the cdcc source,
>and put breakpoints in places suggested by that analysis.
>I find "b printf" and similar handy when attacking an unfamiliar
Thanks. I'll try rediscovering gdb when I'm in the frame of mind.
I must confess that I often get instant gratification from a
quick strace though.

>trust/strace is like a decompiler, mental or mechanical.  I've done
>things such as patching instructions in running UNIX kernels under the
>watchful eyes of armed soldiers in secure installations, but I avoid
>that sort of incantation until I'm sure it's required.
>>"My question is: is this the precompiler behaviour that was originally
>>intended, or have I broken something?"
>My original answer stands.  Your proposed change turns off the use
>of connected sockets for all systems while leaving a lot of useless
>nasty cruft in the DCC source.  In your situation, if I had felt
>that DCC_UDP_DISCON was a bad idea, then I would have suggested
>removing it, perhaps by offering a patch based on the result of
>`unifdef -UDCC_UDP_DISCON`
>Or move "FreeBSD" from that case statement down to the AIX|OpenUNIX case.
I only noticed this later, not having read thoroughly at first.
I really thought (hoped) that it was a simple problem rather
than a pathological case.

> <>
> But I would not have proposed such changes because they would fail my
> mental test of "Does it work in zillions of other installations? If
> so there must be something odd about what I'm doing and so such a
> change should not be made without really understanding what's happening."
> If I made it anyway just to get things going, I'd not talk about it in
> public.
> I hope that such a major kernel change as what you are implicitly
> suggesting has not been made to a moribund system like FreeBSD 4.*.
> It's possible that connect(fd,asdf,0) has been broken for disconnecting
> a UDP socket between 4.9 and 4.10, but you'd hope not.

I couldn't see any (major changes). I might try a -RELEASE install
from ISO if I reach a dead end and need a system with no jails.

>I'm not eager to change that connect() even just for FreeBSD to use a
>non-zero address size, because of the hassles of testing the change
>on old releases.
I'll go back to my simple test code and exercise a few cases. Something is
fishy with the (dis)connect semantics. If it all works fine on 4.9
then that gives me a good starting place.


More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.