#183 closed defect (fixed)
Random "bind: Can't assign requested address" messages on OS X
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | 1.2 |
Component: | BitlBee | Version: | 1.1dev |
Keywords: | Cc: | ||
IRC client+version: | Client-independent | Operating System: | MacOS |
OS version/distro: |
Description
I get these "bind: Can't assign requested address" messages when I start bitlbee in daemon mode on OS X. I'm sure that there is no other process listening to this port (checked it with "lsof -i 4") and address. Bzero'ing the sockaddr struct in bitlbee.c before calling bind() fixes the problem:
--- bitlbee.c 2006-06-24 16:00:43.000000000 +0200 +++ bitlbee.c.bzero 2006-07-12 10:49:18.000000000 +0200 @@ -63,6 +63,7 @@
log_error( "socket" ); return( -1 );
}
+ bzero((char *) &listen_addr, sizeof(listen_addr));
listen_addr.sin_family = AF_INET; listen_addr.sin_port = htons( global.conf->port ); listen_addr.sin_addr.s_addr = inet_addr( global.conf->iface );
Attachments (2)
Change History (7)
Changed at 2006-07-12T08:58:54Z by
Attachment: | bitlbee.c.bzero.patch added |
---|
comment:1 Changed at 2006-07-12T10:54:09Z by
comment:2 Changed at 2006-10-22T13:44:44Z by
Milestone: | 1.0.3 |
---|
comment:3 Changed at 2007-02-23T11:30:34Z by
Milestone: | → 1.1/1.2 |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
Version: | 1.0.3 → 1.1dev |
Still seems to be broken. :-(
comment:4 Changed at 2007-03-01T21:48:40Z by
This should have been fixed by my patch in http://bugs.bitlbee.org/bitlbee/ticket/230. However, I failed by placing the memset in an if-block, but at least it works if you compile w/o ipv6-support :)
Sorry about the snag. Upping a new patch to the latest snapshot that sould remedy this in a couple of secs.
Changed at 2007-03-01T21:49:37Z by
Attachment: | bitlbee.memset.v2.patch added |
---|
comment:5 Changed at 2007-12-04T23:25:38Z by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
I think Jelmer's getaddrinfo() change will have the same effect.
Thanks for the fix. Can you verify if the current development version also fixes the problem? If you got the time you can get a snapshot using bzr from http://code.bitlbee.org/bitlbee/. (Or use /hgweb to generate a tarball) I worked a lot on the daemon code and also added a ForkDaemon mode (which spawns a separate process for every client, which should be a lot more stable). The listening code should be much better there.