(No need to CC me, I'm on the list) On Thu, Oct 20, 2005 at 10:31:04PM +0100, Martin Simmons wrote: > A common reason for this problem is that the padding bytes at the end of the > sockaddr_in object (called something like sin_zero) are not actually zero. > Typically this happens when the code fails to initialize them. > > Unfortunately, there has been an outbreak of C++ in this code so it is > impossible to be sure whether it does this :-(
Heh. > If you can look at the raw bytes passed to bind() in the debugger, > then you might be able to see what they are. Ok, I stepped to the point just before the call to bind, and printed what I *think* is the relevant portion: (gdb) print/x *(p->saddr4) $3 = {sin_len = 0x10, sin_family = 0x2, sin_port = 0x238e, sin_addr = { s_addr = 0x7f000001}, sin_zero = {0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55}} And yes, you're correct, the extra stuff is not zero. Gotcha, you little bugger. So: in src/lib/address_conf.c, for both constructors: IPADDR::IPADDR(const IPADDR &src) : type(src.type) IPADDR::IPADDR(int af) : type(R_EMPTY) add: memset(&saddrbuf, 0, sizeof(saddrbuf)); before doing anything else to/with saddrbuf. This fixes the problem: I can now bind to arbitrary addresses (well, at least the ones that exist on the box). Martin, you're my new hero. Kern, did you catch this? Should I send the patch someplace specific? Actually, I prefer that someone who actually understands C++ confirm that this is patch is both correct and sufficient... Thanks, Steve, -- "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. -- (Stolen from the net) ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users