DuckCorp Projects: Issueshttps://projects.duckcorp.org/https://projects.duckcorp.org/favicon.ico?16699090422024-02-04T14:36:07ZDuckCorp Projects
Redmine Bip - Enhancement #807 (New): Add IRCv3 capabilitieshttps://projects.duckcorp.org/issues/8072024-02-04T14:36:07ZLoïc Gomez
<p><a class="external" href="https://ircv3.net/specs/extensions/capability-negotiation.html">https://ircv3.net/specs/extensions/capability-negotiation.html</a></p> Bip - Enhancement #800 (In Progress): Update copyright datahttps://projects.duckcorp.org/issues/8002024-02-04T07:30:49ZLoïc Gomez
<p>We need to update copyright details</p> Bip - Bug #763 (New): Backlog is being lost on unstable connectionshttps://projects.duckcorp.org/issues/7632022-03-16T19:03:53ZLoïc Gomez
<p><a class="external" href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595408">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595408</a></p>
<p>Per Arnaud's comment there:</p>
<blockquote>
<p>Tcp will detect such connection breakage only when bip sends data to<br />your ADSL ip and times out waiting for ACKs. So bip indeed<br />approximates when the connection is lost. The blreset_on_talk should<br />be useful to you as bip will replay logs as long as you did not reply<br />anything.</p>
<p>I don't see any trivial way to implement a better connection loss<br />detection for backlog reset. It should be feasible to delay backlog<br />resetting to only when we receive any data from client, which would<br />prevent some errors of the type you described (but not all).<br />Another way would be to poll the tcp buffer size and to reset logs<br />only when it's down to 0. It's probably the best solution.</p>
</blockquote> Bip - Bug #762 (New): Systemctl integration does not actually stop biphttps://projects.duckcorp.org/issues/7622022-03-16T18:55:17ZLoïc Gomez
<p><a class="external" href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963907">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963907</a></p>
<p>Checked up on this but could not reproduce on Ubuntu/hirsute with a fresh start. Although, on Debian stable, it indeed shows up as dead even though restart had occurred less than 2d ago, and I remember having such issue stopping bip:<br /><pre><code>
● bip.service - Bip IRC Proxy
Loaded: loaded (/lib/systemd/system/bip.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/bip.service.d
└─custom.conf, override.conf
Active: inactive (dead) since Thu 2022-03-10 21:29:43 CET; 5 days ago
Main PID: 5508 (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 4668)
Memory: 11.4M
CPU: 1d 4h 57min 33.009s
CGroup: /system.slice/bip.service
└─5509 /usr/bin/bip -f /etc/bip/bip.conf -s /var/lib/bip
Warning: journal has been rotated since unit was started, output may be incomplete.
</code></pre></p>
<p>Couldn't find any difference in systemctl unit</p> Bip - Bug #749 (New): bip doesn't create ~/.bip/ directory when using default PID filehttps://projects.duckcorp.org/issues/7492022-01-03T11:29:06ZLoïc Gomez
<p>30-12-2021 14:34:11 Default pid file: /home/kyoshiro/.bip/bip.pid<br />30-12-2021 14:34:11 FATAL: Cannot write to PID file (/home/kyoshiro/.bip/bip.pid.redacted.3764810) No such file or directory</p> Bip - Enhancement #733 (New): Error message is unclear when SSL server is unresponsivehttps://projects.duckcorp.org/issues/7332021-09-16T13:55:42ZLoïc Gomez
<p>It seems we get these when bip is unable to connect at all to a server using SSL:</p>
<blockquote>
<p>WARNING: mySSL_get_cert() SSL server supplied no certificate !<br />ERROR: No certificate in SSL write_socket</p>
</blockquote>
<p>We need to find a way to make it clear there is a connect() issue and not an SSL related problem.</p> Bip - Enhancement #730 (New): Update /bip backlog [n] to make it backlog private messages toohttps://projects.duckcorp.org/issues/7302021-09-03T12:36:27ZLoïc Gomez
<p>Current /bip backlog command does not backlog private messages.<br />I think it is related to bip not being aware of which private messages to look for, as they're scattered in multiple files.</p>
<p>Maybe it does work with an in-memory backlog setup though (to be tested).</p>
<p>We could probably list changed files in the logdir and backlog the ones matching the [n] parameter.</p> 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> Bip - Bug #641 (New): /who replies aren't routed to correct clienthttps://projects.duckcorp.org/issues/6412018-12-30T12:02:40ZJohn Levon
<p>Using bip on freenode, with two hexchat clients, I get regular noise to the channels<br />corresponding to the output of a /who command. This seems to be from hexchat's /away<br />tracking, which periodically sends this command. It appears that bip doesn't know which<br />client to route the response to, so you get this noise.</p>
<p>In znc, it seems this is fixed by enabling route_replies, but I can't find such a thing<br />in bip.</p> Bip - Bug #500 (New): bip 0.8.9 and 0.9.0 often fail on SSL/TLS connection to Freenodehttps://projects.duckcorp.org/issues/5002016-11-24T20:22:11ZAdam Williamsonadamw@happyassassin.net
<p>After rebooting my Bip server today, I noticed it frequently fails on attempts to connect to Freenode via SSL/TLS, like this:</p>
<pre><code>Nov 24 12:14:20 ircproxy.happyassassin.net bip[1342]: 24-11-2016 12:14:20 [freenode] Connecting user 'adamw' using server chat.freenode.net:7000<br /> Nov 24 12:14:20 ircproxy.happyassassin.net bip[1342]: 24-11-2016 12:14:20 No SSL certificate check store configured. Default store will be used.<br /> Nov 24 12:14:20 ircproxy.happyassassin.net bip[1342]: 24-11-2016 12:14:20 WARNING: mySSL_get_cert() SSL server supplied no certificate !<br /> Nov 24 12:14:20 ircproxy.happyassassin.net bip[1342]: 24-11-2016 12:14:20 ERROR: No certificate in SSL write_socket<br /> Nov 24 12:14:20 ircproxy.happyassassin.net bip[1342]: 24-11-2016 12:14:20 WARNING: mySSL_get_cert() SSL server supplied no certificate !<br /> Nov 24 12:14:20 ircproxy.happyassassin.net bip[1342]: 24-11-2016 12:14:20 ERROR: No certificate in SSL write_socket<br /> Nov 24 12:14:20 ircproxy.happyassassin.net bip[1342]: 24-11-2016 12:14:20 WARNING: mySSL_get_cert() SSL server supplied no certificate !<br /> Nov 24 12:14:20 ircproxy.happyassassin.net bip[1342]: 24-11-2016 12:14:20 ERROR: No certificate in SSL write_socket</code></pre>
<p>It's rather strange, because it suggests that `SSL_get_peer_certificate()` is failing, and I don't know why it would do that (and it doesn't seem very easy to debug. Man I hate openssl.) I can only think there must, somehow, be something wrong with the SSL context.</p>
<p>I don't think there is a server issue here, as HexChat seems to always work when I try it (with SSL). I do note that Hexchat seems to wait for `SSL_is_init_finished` to be true before doing `SSL_get_cert_info`...</p> Bip - Enhancement #492 (New): Logging to syslogd and more explicit error messageshttps://projects.duckcorp.org/issues/4922016-04-13T09:37:53ZAnonymous
<p>This is a missing feature. Please consider adding basic syslogd logging, unless you're willing to work on a more advanced setup, then look how nginx did that.</p> Bip - Bug #445 (New): Asynchrounous socketshttps://projects.duckcorp.org/issues/4452015-02-27T13:02:17ZNeckara NeckaraNeckara@last-project.ovh
<p><code>27-02-2015 13:50:05 [irc.last-project.ovh] backlogging: #last-team<br />27-02-2015 13:50:05 [irc.last-project.ovh] backlogging: #messages<br />27-02-2015 13:52:45 ERROR: read(fd=11): Connection lost: Operation now in progress<br />27-02-2015 13:52:45 ERROR: Error while reading on fd 11<br />27-02-2015 13:52:45 ERROR: client read_lines error, closing...<br />27-02-2015 13:52:46 [irc.last-project.ovh] backlogging: #last-team<br />27-02-2015 13:52:46 [irc.last-project.ovh] backlogging: #messages<br />27-02-2015 13:55:26 ERROR: read(fd=11): Connection lost: Operation now in progress<br />27-02-2015 13:55:26 ERROR: Error while reading on fd 11<br />27-02-2015 13:55:26 ERROR: client read_lines error, closing...<br />27-02-2015 13:55:27 [irc.last-project.ovh] backlogging: #last-team<br />27-02-2015 13:55:27 [irc.last-project.ovh] backlogging: #messages<br /></code></p> Bip - Bug #355 (New): Invalid PONG responsehttps://projects.duckcorp.org/issues/3552014-11-07T16:29:26ZNeckara NeckaraNeckara@last-project.ovh
<p>Hello,</p>
<p>I use bip from the Debian Jessie package (0.8.9, I tried also which the Repo version).<br />Each time my IRC client send a <code>PING</code> request :</p>
<p>"<code>PING _1415376678828</code>"</p>
<p>I get this response :<br />"<code>:127.0.0.1 PONG _1415376678828</code>" instead of "<code>:127.0.0.1 PONG 127.0.0.1 :_1415376678828</code>" others IRC server can send me.<br />Indeed, the RFC ( <a class="external" href="https://tools.ietf.org/html/rfc2812#section-3.7.3">https://tools.ietf.org/html/rfc2812#section-3.7.3</a> or <a class="external" href="https://tools.ietf.org/html/rfc1459#section-4.6.3">https://tools.ietf.org/html/rfc1459#section-4.6.3</a> ) says <code>PONG</code> has as for parameters <code><server> [<server>]</code>.</p>
<p>Each 2-3 minutes, I get disconnected few seconds after the client's PING request.<br />In the bip logs I have :<br /><pre>
07-11-2014 06:47:20 ERROR: read(fd=7): Connection lost: Connection timed out
07-11-2014 06:47:20 ERROR: Error while reading on fd 7
07-11-2014 06:47:20 ERROR: client read_lines error, closing...
07-11-2014 06:50:07 ERROR: read(fd=7): Connection lost: Connection timed out
07-11-2014 06:50:07 ERROR: Error while reading on fd 7
07-11-2014 06:50:07 ERROR: client read_lines error, closing...
[...]
07-11-2014 17:06:48 ERROR: read(fd=5): Connection lost: Resource temporarily unavailable
07-11-2014 17:06:48 ERROR: Error while reading on fd 5
07-11-2014 17:06:48 ERROR: client read_lines error, closing...
07-11-2014 17:09:19 ERROR: read(fd=5): Connection lost: Resource temporarily unavailable
07-11-2014 17:09:19 ERROR: Error while reading on fd 5
07-11-2014 17:09:19 ERROR: client read_lines error, closing...
07-11-2014 17:12:01 ERROR: read(fd=5): Connection lost: Resource temporarily unavailable
07-11-2014 17:12:01 ERROR: Error while reading on fd 5
07-11-2014 17:12:01 ERROR: client read_lines error, closing...
07-11-2014 17:12:45 ERROR: read(fd=6): Connection lost: Resource temporarily unavailable
07-11-2014 17:12:45 ERROR: Error while reading on fd 6
07-11-2014 17:12:45 ERROR: client read_lines error, closing...
</pre></p>
<p>Can you do something about that ?</p>
<p>Cordially,<br />Neckara</p> Bip - Bug #245 (New): bip splits privmsg logs into multiple files; no way to force it to use only...https://projects.duckcorp.org/issues/2452011-09-05T17:46:14ZSelene Scrivenbip-dev@xyzz.org
<p>For some reason, bip splits my privmsg logs into multiple files. It starts with nick.log, then creates nick.log.0, then creates nick.log.1, and so on. This is annoying, since I want to have only one log file per nick. And I haven't found any way to disable this behavior.</p>
<p>My guess is that bip is trying to be helpful by splitting logs into "conversations"... where each file represents one burst of activity, and a new file is started whenever there is a significant gap in activity. But I don't want it to. Could this feature be turned off, or perhaps a config option be added to disable it?</p> Bip - Enhancement #223 (New): Provide a way to reset a specific nickname's backlog (private messa...https://projects.duckcorp.org/issues/2232011-05-16T19:23:16ZJonathan Pryorjon-bip@jprl.com
<p>Imagine this scenario: bip running on a server (common), and you talk to lots of people via private messages (less common?), say, oh, 80 people. Life is good.</p>
<p>Restart the client (not the server), or open another client to the bip server; whatever. Result: 80 "channels" for each of the private messages. This is...overwhelming.</p>
<p>I would like a way to close these private messages.</p>
<p>The ~obvious way would be to use /part:</p>
<pre><code>/part nickname</code></pre>
<p>Unfortunately, this results in an error (from Smuxi):</p>
<pre><code>[403 (ErrorNoSuchChannel) nickname] No such channel</code></pre>
<p>This is because Smuxi requires that you only /part from channels. No matter, we'll do things manually!</p>
/raw part nickname
<ol>
<li><del>or</del><br /> /raw /part nickname</li>
</ol>
<p>ngrep shows that this actually makes it to the client...and it still fails, as /path/to/logs/nickname.log is still open in /proc/PID/fd (which is currently showing 93 files open for me...).</p>
<p>My <em>guess</em> is that `/raw part nickname` fails because irc.c!irc_part() does:</p>
<pre><code>channel = hash_get(&server->channels, s_chan);<br /> /* we can't get part message for chans we're not on */<br /> if (!channel)<br /> return ERR_PROTOCOL;</code></pre>
<p>and the nickname "channel" isn't really a channel, and thus `channel` is NULL, so ERR_PROTOCOL is returned.</p>
<p>TO REPRODUCE:</p>
/msg nickname message
<ol>
<li>look at `ls -l /proc/PID/fd/*` and ensure that nickname.log is open<br /> /raw part nickname # or some other mechanimsm?</li>
<li>look at `ls -l /proc/PID/fd/*` and ensure that nickname.log is NOT open.</li>
</ol>