DuckCorp Projects: Issueshttps://projects.duckcorp.org/https://projects.duckcorp.org/favicon.ico?16699090422020-12-17T09:34:26ZDuckCorp Projects
Redmine Bip - Enhancement #715 (New): Backlog one channel onlyhttps://projects.duckcorp.org/issues/7152020-12-17T09:34:26ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>The backlog command only allows to backlog all the channels from one network.</p>
<p>It would be nice to fetch backlog from one channel only.</p>
<p>From: Debian bug <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668420" class="external">#668420</a>.</p> mkcert - Review #542 (In Progress): mkcert: allow to specify CONFDIRhttps://projects.duckcorp.org/issues/5422017-05-14T21:57:33ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>Please, could you review branches listed below ?</p>
<ul>
<li><code>Allow-to-define-CONFDIR</code></li>
<li><code>Key-size-synchronize-default-values-sample-values</code></li>
<li><code>Typo</code></li>
<li><code>improve-reliability-enable-some-checks</code></li>
<li><code>Handle-when-mkcert-isn-t-in-PATH</code></li>
<li><code>directory-might-not-exists</code></li>
</ul>
<p>These branches are available here <code>https://vcs-git.duckcorp.org/people/pilou/mkcert.git</code>.</p> DuckCorp Infrastructure - Review #518 (In Progress): Review branch backuphttps://projects.duckcorp.org/issues/5182017-04-03T11:58:27ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>This is a start: the committed configuration backups only PostgreSQL databases hosted on Toushirou.</p>
<p>Other hosts/directories will be added latter.</p> Bip - Bug #481 (In Progress): Fix log level for erroneous messageshttps://projects.duckcorp.org/issues/4812015-10-13T12:54:28ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>Bip should display IRC <a href="https://tools.ietf.org/html/rfc1459#section-6" class="external">errors</a> sent by IRC servers using <code>error</code> log level.</p>
<p>The current behaviour is:<br /><pre>
13-10-2015 14:48:14 DEBUG: ":irc.server.local 432 * Pilou :Nickname too long, max. 9 characters
</pre></p> Bip - Bug #431 (New): bip is leaking file descriptorshttps://projects.duckcorp.org/issues/4312015-01-15T02:01:19ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>fran wrote:</p>
<blockquote>
<p>bip is leaking file descriptors on my server, and the fix is pretty easy: on connection.c, on read_socket, whenever read returns <1 and errno is different to EAGAIN and EINTR, the socket MUST be closed <br />because read will not return 0 on the following iterations of select (cause it's not added to the read fd_set after that), plus after read failing with fatal error it keeps returning -1</p>
</blockquote> Bip - Bug #352 (New): bip & Bitlbeehttps://projects.duckcorp.org/issues/3522014-09-22T18:25:43ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>On 22/09/2014, asteroidmaster wrote:</p>
<blockquote>
<p>I'm having trouble connecting bip to bitlbee. Bitlbee is running and I can connect Weechat to it.<br />But when I try to connect bip to bitlbee, I get a ERROR in getpeername() that Transport Endpoint is not connected,<br />and another error on fd 6 followed by bip throwing a read_lines error. I'm running Ubuntu Server 14.04 and have<br />installed bip from the Ubuntu repos and Bitlbee from their daily build repo.</p>
</blockquote> Bip - Enhancement #343 (New): Allow to blreset all queries or all channelshttps://projects.duckcorp.org/issues/3432014-07-24T00:21:01ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p><code>blreset</code> command allows to reset backlog of an entire connection, a chan, a query.</p>
<p>Be able to reset all queries or all channels would be a nice feature.</p> Bip - Bug #342 (New): 'list connections' command doesn't display status of channelshttps://projects.duckcorp.org/issues/3422014-07-24T00:13:06ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>It seems that output of <code>list connections</code> command should use a suffix on channels without backlog: <a class="source" href="https://projects.duckcorp.org/projects/bip/repository/bip/entry/src/bip.c#L1395">source:src/bip.c#L1395</a>, but this is not the case.</p>
<p><code>list connections</code> doesn't display a suffix on any channel:</p>
<pre>
02:04:18 Pilou | list connections
[...]
02:04:18 -bip | * milkypond to milkypond as "pilou" (pilou!pilou) :
02:04:18 -bip | Options:
02:04:18 -bip | Channels (* with key, ` no backlog) #test #milkypond #DuckCorp
02:04:18 -bip | Status: connected !
</pre> Bip - Bug #341 (New): 'bip list connections' command should display querieshttps://projects.duckcorp.org/issues/3412014-07-24T00:01:23ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>The command <code>bip list connections</code> lists channels for all connections.</p>
<p>Queries could be listed too.</p> Bip - Bug #262 (In Progress): using ircnet bip crashes if a channel has two nicks different only ...https://projects.duckcorp.org/issues/2622011-11-13T15:30:32ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>nitram reported:<br /><pre>
as soon as i join a channel that has the nicks "~mc" and "mc" on ircnet bip crashes with "11-11-2011 15:55:44 FATAL: Element with key mc already in hash b9495ce0
</pre></p>
<p>I found two problems:</p>
<p><strong>First</strong>, in <code>irc_353</code> function ( <a class="source" href="https://projects.duckcorp.org/projects/bip/repository/bip/revisions/a46b8bd2/entry/src/irc.c#L1362">source:src/irc.c@a46b8bd2#L1362</a> ) we discard '~' character when storing operator/voice mask foreach nickname. For example if the irc server send<br /><code>'ircnet.optilian.net' ':ircnet.optilian.net 353 pilou = #plopplopplop :pilou ~lolll219 lolll219 '</code> (user <code>pilou</code> joining <code>ircnet.optilian.net</code> where tho users <code>~lolll219</code> <code>lolll219</code> are here)<br />we store operator/voice mask of <code>lolll219</code> twice (once for <code>~lolll219</code> and another for <code>lolll219</code>).</p>
<p>This lead to many errors:</p>
<ul>
<li>if either <code>lolll219</code> or <code>~lolll219</code> have a not empty operator/voice mask, then problem reported by nitram appears: the second <code>hash_insert</code> fails.</li>
</ul>
<ul>
<li>when <code>~lolll219</code> or <code>lolll219</code> send irc <code>part</code> command, <code>irc_part</code> function ( <a class="source" href="https://projects.duckcorp.org/projects/bip/repository/bip/revisions/a46b8bd2/entry/src/irc.c#L1498">source:src/irc.c@a46b8bd2#L1498</a> ) encounters problem.<br />If <code>~lolll219</code> quit then his operator/voice mask can not be found (it was not stored) and then <code>irc_part</code> return <code>ERR_PROTOCOL</code>:<br /><pre>
13-11-2011 14:38:22 ERROR: [ircnet] Error in protocol, closing...
13-11-2011 14:38:22 ERROR: [ircnet] reconnecting in 0 seconds
</pre></li>
</ul>
<ul>
<li>If <code>lolll219</code> quit then an assertion fails, indeed the <code>lolll219</code> key is present twice in the operator/voice mask hash:<br /><pre>
13-11-2011 14:37:29 FATAL: 80b3288 appears twice in list
</pre></li>
</ul>
<p><strong>Second</strong> problem: it should not be possible to store two identical key in one hash. <code>list_remove_if_exists</code> function ( <a class="source" href="https://projects.duckcorp.org/projects/bip/repository/bip/revisions/a46b8bd2/entry/src/util.c#L370">source:src/util.c@a46b8bd2#L370</a> ) - called by <code>irc_part</code> - verify this assertion and the assertion fails.</p>
<p>Currently insertion of two identical keys occurs because instead of checking if the hash contains already an identical key, we check if the value corresponding to this key is NULL or not ( <a class="source" href="https://projects.duckcorp.org/projects/bip/repository/bip/revisions/a46b8bd2/entry/src/util.c#L566">source:src/util.c@a46b8bd2#L566</a> ):</p>
<pre>
void hash_insert(hash_t *hash, const char *key, void *ptr)
[...]
if (hash_get(hash, key))
fatal("Element with key %s already in hash %x\n", key, hash);
</pre>
<p>So it's possible to store many identical key associated to 0/NULL value.</p>
<p>And the associated value for the key in operator/voice mask hash can be 0/NULL:<br /><pre>
long int ovmask = 0;
[...]
hash_insert(&channel->ovmasks, nick, (void *)ovmask);
</pre></p> Bip - Bug #260 (New): Bad file descriptorhttps://projects.duckcorp.org/issues/2602011-11-09T07:48:24ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>Bip exit with a FATAL error "Bad file descriptor"</p>
<p>Maybe related to <a class="issue tracker-1 status-1 priority-4 priority-default" title="Bug: Bip uses 100% CPU (New)" href="https://projects.duckcorp.org/issues/238">#238</a></p>
<p>Logs:<br /><pre>
09-11-2011 04:28:24 ERROR: read(fd=6): Connection lost: Success
09-11-2011 04:28:24 ERROR: Error while reading on fd 6
09-11-2011 04:28:24 ERROR: [oftc] read_lines error, closing...
09-11-2011 04:28:24 Broken socket: Connection reset by peer.
09-11-2011 04:28:24 ERROR: [oftc] reconnecting in 0 seconds
09-11-2011 04:28:24 FATAL: select(): Bad file descriptor
</pre></p> Bip - Bug #192 (Feedback): using "hide ping pong event" in mIRC doesn't work with biphttps://projects.duckcorp.org/issues/1922011-02-09T18:10:25ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>Reported by DoDzy, thank to him !<br /><pre>
i still get [10:35] * PONG from oftc <
it used to work when i was using psybnc
nvm, after all it is my client misbehaving
"If mIRC sends a PING with a parameter, it expects a PONG response with that parameter. This
is meant to be standard PING/PONG behaviour. If your bouncer is intercepting the message and
is not replying correctly, then mIRC will not work."
</pre></p> Bip - Bug #188 (New): "FATAL: Element with key nohar already in hash 5151a968" when netplit occurshttps://projects.duckcorp.org/issues/1882011-01-19T00:19:39ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>Sometimes when a netsplit occurs, bip exits after logging:</p>
<blockquote>
<p>FATAL: Element with key nohar already in hash 5151a968</p>
</blockquote> Bip - Bug #186 (New): Bip crash after using "/QUOTE BIP TRUST OK" on a new connectionhttps://projects.duckcorp.org/issues/1862011-01-18T02:29:38ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<a name="How-to-reproduce"></a>
<h1 >How to reproduce:<a href="#How-to-reproduce" class="wiki-anchor">¶</a></h1>
<ol>
<li>/etc/bip.conf: add a new ssl connection </li>
<li>restart bip (Debian: <em>/etc/init.d/bip restart</em>)</li>
<li>use <em>/QUOTE BIP TRUST OK</em><br /> # all client connections are disconnected</li>
</ol>
<a name="Logs"></a>
<h1 >Logs<a href="#Logs" class="wiki-anchor">¶</a></h1>
<a name="Client-logs"></a>
<h2 >Client logs:<a href="#Client-logs" class="wiki-anchor">¶</a></h2>
<blockquote>
<p>03:12:08 oftc | irc: connecting to server irc-bouncer/7778...<br />03:12:08 oftc | irc: connected to irc-bouncer<br />03:12:08 oftc -- | b.i.p (b.i.p): This server SSL certificate was not accepted because it is not in your store of trusted certificates:<br />03:12:08 oftc -- | b.i.p (b.i.p): Subject: /C=US/ST=Indiana/L=Indianapolis/O=Software in the Public Interest/OU=hostmaster/CN=Certificate Authority/emailAddress=<a class="email" href="mailto:hostmaster@spi-inc.org">hostmaster@spi-inc.org</a><br />03:12:08 oftc -- | b.i.p (b.i.p): Issuer: /C=US/ST=Indiana/L=Indianapolis/O=Software in the Public Interest/OU=hostmaster/CN=Certificate Authority/emailAddress=<a class="email" href="mailto:hostmaster@spi-inc.org">hostmaster@spi-inc.org</a><br />03:12:08 oftc -- | b.i.p (b.i.p): MD5 fingerprint: 2A:47:9F:60:BB:83:74:6F:01:03:D7:0B:0D:F6:0D:78<br />03:12:08 oftc -- | b.i.p (b.i.p): WARNING: if you've already trusted a certificate for this server before, that probably means it has changed.<br />03:12:08 oftc -- | b.i.p (b.i.p): If so, YOU MAY BE SUBJECT OF A MAN-IN-THE-MIDDLE ATTACK! PLEASE DON'T TRUST THIS CERTIFICATE IF YOU'RE NOT SURE THIS IS NOT THE CASE.<br />03:12:08 oftc -- | b.i.p (b.i.p): Type /QUOTE BIP TRUST OK to trust this certificate, /QUOTE BIP TRUST NO to discard it.<br />03:12:20 oftc -- | irc.bip.net (irc.bip.net): ==== Certificate now trusted.<br />03:12:20 oftc -- | irc.bip.net (irc.bip.net): No more certificates waiting awaiting user trust, thanks!<br />03:12:20 oftc -- | irc.bip.net (irc.bip.net): If the certificate is trusted, bip should be able to connect to the server on the next retry. Please wait a while and try connecting your client again.</p>
</blockquote>
<a name="Bip-logs"></a>
<h2 >Bip logs:<a href="#Bip-logs" class="wiki-anchor">¶</a></h2>
<blockquote>
<p>18-01-2011 03:12:12 ERROR: No certificate in SSL write_socket<br />18-01-2011 03:12:12 ERROR: SSL cert check failed at depth=3: certificate rejected (28)<br />18-01-2011 03:12:12 ERROR: Certificate check failed: certificate rejected (28)!<br />18-01-2011 03:12:12 ERROR: Error on fd 31 (state 9)<br />18-01-2011 03:12:12 ERROR: [oftc] read_lines error, closing...<br />18-01-2011 03:12:12 ERROR: [oftc] reconnecting in 240 seconds<br />18-01-2011 03:12:54 ERROR: No certificate in SSL write_socket</p>
</blockquote> Bip - Bug #165 (New): doesn't load openssl support for sha-256 digesthttps://projects.duckcorp.org/issues/1652010-10-26T00:21:16ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p><a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601021" class="external">Debian bug #601021</a></p>
<blockquote>
<p>As the subject says, bip doesn't make openssl load support for the sha-256<br />digest algorhytm. I've fixed a similar bug in fetchmail a while ago, see<br />Debian bug #576430 for a bit more info on the matter.<br />Attached is a simple patch that forces openssl to load support for everything<br />it knows :)<br />Sjoerd Simons</p>
</blockquote>