DuckCorp Projects: Issueshttps://projects.duckcorp.org/https://projects.duckcorp.org/favicon.ico?16699090422024-02-04T14:33:13ZDuckCorp Projects
Redmine Bip - Bug #805 (New): bipmkpw fails compilation (sometimes only?)https://projects.duckcorp.org/issues/8052024-02-04T14:33:13ZLoïc Gomez
<p>While fixing bip/adding code, I've stumbled upon these but not all the time:<br /><pre>
/usr/bin/ld: libbip.a(libbip_a-bip.o):/home/loic/code/bip/src/bip.c:60: multiple definition of `conf_log_system'; bipmkpw-bipmkpw.o:/home/loic/code/bip/src/bipmkpw.c:28: first defined here
/usr/bin/ld: libbip.a(libbip_a-bip.o):/home/loic/code/bip/src/bip.c:43: multiple definition of `conf_log_level'; bipmkpw-bipmkpw.o:/home/loic/code/bip/src/bipmkpw.c:26: first defined here
/usr/bin/ld: libbip.a(libbip_a-bip.o):/home/loic/code/bip/src/bip.c:64: multiple definition of `conf_global_log_file'; bipmkpw-bipmkpw.o:/home/loic/code/bip/src/bipmkpw.c:27: first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:485: bipmkpw] Error 1
</pre></p> Bip - Bug #803 (New): /bip list connections/all_connections/all_links crashes biphttps://projects.duckcorp.org/issues/8032024-02-04T14:29:06ZLoïc Gomez
<p>In 9.4, listing connections, links crashes bip when there is a long line for on_connect_send option.<br />A fix is available.</p> Bip - Bug #793 (New): AC_PROG_LEX without either yywrap or noyywrap is obsoletehttps://projects.duckcorp.org/issues/7932024-02-02T16:48:56ZLoïc Gomez
<pre>
configure.ac:16: warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete
./lib/autoconf/programs.m4:716: _AC_PROG_LEX is expanded from...
./lib/autoconf/programs.m4:709: AC_PROG_LEX is expanded from...
aclocal.m4:1072: AM_PROG_LEX is expanded from...
configure.ac:16: the top level
</pre> Bip - Bug #792 (New): Handle CAP request/reply on client connectionshttps://projects.duckcorp.org/issues/7922024-02-02T16:43:52ZLoïc Gomez
<p>Some clients will expect BIP to send a CAP reply on client connect.<br />For example, Goguma on Android will send something like this:<br /><pre>
02-02-2024 17:45:21 DEBUG: "CAP LS 302"
02-02-2024 17:45:21 DEBUG: "NICK kyoshiro"
02-02-2024 17:45:21 DEBUG: "USER kyoshiro 0 * kyoshiro"
02-02-2024 17:45:21 DEBUG: "CAP REQ sasl"
02-02-2024 17:45:21 DEBUG: "AUTHENTICATE PLAIN"
02-02-2024 17:45:21 DEBUG: "AUTHENTICATE REDACTED_B64"
02-02-2024 17:45:21 DEBUG: "CAP END"
</pre></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 - 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> mkcert - Bug #597 (New): Please review Ansible Vault supporthttps://projects.duckcorp.org/issues/5972017-09-24T06:21:13ZMarc Dequènesduck@duckcorp.org
<p>It has been made as less intrusive as possible to avoid introducing bugs. Most probably a rework of the path variables would be better but this is not the goal of this PR,</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 - 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 #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 #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> UFWI - Bug #416 (New): Missing "Exit" menu entryhttps://projects.duckcorp.org/issues/4162014-11-25T22:41:46ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>In stand-alone mode, the main menu is missing a "Quit" or "Exit" entry.</p>
<p>Added by Laurent Defert</p> UFWI - Bug #415 (New): Remove runtime dependency to ntp modulehttps://projects.duckcorp.org/issues/4152014-11-25T22:41:20ZPierre-Louis Bonicolipierre-louis.bonicoli@ir5.eu
<p>Added by Laurent Defert</p>