+Thu Feb 15 20:07:37 EET 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
+
+ * Added new packet type SILC_PACKET_HEARTBEAT that is used to
+ send keepalive packets. The packet can be sent by clients,
+ servers and routers.
+
+ Added function silc_socket_set_heartbeat into the file
+ lib/silccore/silcsockconn.[ch] to set the heartbeat timeout.
+ If not set, the heartbeat is not performed. The actual
+ heartbeat is implemented in the low level socket connection
+ library. However, application is responsible of actually
+ sending the packet.
+
+ Added silc_server_send_heartbeat to send the actual heartbeat
+ packet into silcd/packet_send.[ch]. Server now performs
+ keepalive with all connections.
+
+ * Added silc_task_get_first function into lib/silcutil/silctask.c
+ to return the timeout task with shortest timeout. There was a bug
+ in task unregistration that caused problems. TODO has been
+ updated to include that task system must be rewritten.
+
+ * The client library will now resolve the client information when
+ receiving JOIN notify from server for client that we know but
+ have incomplete information.
+
+ * Rewrote parts of silc_server_remove_from_channels and
+ silc_server_remove_from_one_channel as they did not remove the
+ channel in some circumstances even though they should've.
+
+ * Encryption problem encountered in server:
+
+ The LEAVE command used to send the Channel Key packet to the
+ router immediately after generating it. However, the code
+ had earlier sent Remove Channel user packet but not immediately,
+ ie. it was put to queue. The order of packets in the router
+ was that Channel Key packet was first and Remove Channel User
+ packet was second, even though they were encrypted in the
+ reverse order. For this reason, MAC check failed. Now, this
+ is fixed by not sending the Channel Key packet immediately but
+ putting it to queue. However, this is more fundamental problem:
+ packets that are in queue should actually not be encrypted
+ because packets that are sent immediately gets encrypted
+ actually with wrong IV (and thus MAC check fails). So, packets
+ that are in queue should be encrypted when they are sent to
+ the wire and not when they put to the queue.
+
+ However, the problem is that the current system has not been
+ designed to work that way. Instead, the packet is encrypted
+ as soon as possible and left to the queue. The queue is then
+ just purged into wire. There won't be any fixes for this
+ any time soon. So, the current semantic for packet sending
+ is as follows:
+
+ o If you send packet to remote host and do not force the send
+ (the packet will be in queue) then all subsequent packets to the
+ same remote host must also be put to the queue. Only after the
+ queue has been purged is it safe again to force the packet
+ send immediately.
+
+ o If you send all packets immediately then it safe to send
+ any of subsequent packets through the queue, however, after
+ the first packet is put to queue then any subsequent packets
+ must also be put to the queue.
+
+ Follow these rules and everything works fine.
+
+Thu Feb 15 14:24:32 EET 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
+
+ * Added new function silc_server_remove_clients_by_server to
+ remove all client entries from ID list when the server connection
+ is lost. In this case it is also important to invalidate all
+ client entires as they hold the invalid server entry. This
+ fixes fatal bug when server has lost connection and will reconnect
+ again.
+
Wed Feb 14 16:03:25 EET 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
* Made some sanity checks to silc_server_daemonise like to check
- whether the reuqested user and group actually exists.
+ whether the requested user and group actually exists.
* Added sanity check to SKE's silc_ske_responder_finish to check
that the public and private key actually is valid.
* Sort the ID Cache in client library when the ID Cache data
has changed (needs sorting).
+ * Do not allow for SILC client to create several connections to
+ several servers. The client does not support windows right now
+ and generating multiple connections causes weird behaviour.
+
+ Irssi-silc client does support windows and can handle several
+ connections without problems, see: www.irssi.org and SILC plugin.
+
+ * Fixed some places where client was added to the IDList. The
+ rule of thumb is following (in order to get everything right):
+ If the client is directly connected local client then the
+ `connection' argument must be set and `router' argument must be
+ NULL to silc_idlist_add_client function. If the client is not
+ directly connected client then the `router' argument must
+ bet set and the `connection' argument must be NULL to the
+ silc_idlist_add_client function.
+
+ * The funtion silc_server_packet_send_local_channel actually did
+ not check whether the client was locally connected or not. It
+ does that now. Fixed a bug related to LEAVE command.
+
+ * Fixed Remove Channel User payload parsing bug in server's
+ silcd/packet_receive.c. Fixed a bug related to LEAVE command.
+
+ * The server's silc_server_save_channel_key now checks also the
+ global ID list for the channel as it might not be in the local
+ list. Fixed a bug related to LEAVE command.
+
+ * Is this the end of the [<unknown>] buglet that has been lurking
+ around for a long time? A little for loop fix in server's
+ silc_server_command_whois_parse that is used by both IDENTIFY
+ and WHOIS command. At least, this was a clear bug and a cause
+ of one type of [<unknown>] buglet.
+
+ * WHOIS and IDENTIFY commands call the function
+ silc_server_command_[whois/identify]_check function even if
+ we are not router server.
+
Tue Feb 13 19:55:59 EET 2001 Pekka Riikonen <priikone@poseidon.pspt.fi>
* Added --with-gmp configuration option. If set the GMP
projects / silc.git / blobdiff