I have been using IRC approximatelly ~15 years. I have begun using IRC at the start of the millenium then on public accesible PC's we have been using public webpage services as proxy to enter a IRC network if no local IRC client has been installed. Nowadays this is stll a popular method. Later as a frequent user XChat has been the first GTK client to connect to IRC networks. Pretty soon I have realized IRC is meant to be used as a 24/7/365 service, but with a graphical client it would not work. My personal PC had to run for days. At that time the quick solution was to use a command line IRC client plus screen. This has been, and probably still is the most favourite combination of programs to have a long term connection to a IRC network. It has only one problem. If the client reboots in case of a power failure there is no way to connect automatically to IRC. The final solution to solve this minor problem is to use a IRC bouncer. There are some out there, the most popular and also still in development is ZNC. ZNC is a powerful application running as a daemon, keeping your nick logged into a IRC network. It works as a relay so one can use the IRC client of the choice to connect to ZNC and ZNC connect to the IRC network.

ZNC has a local webserver to configure the needed parameters but it is also possible to configure ZNC from command line, which is my prefered way of doing it. Since ZNC works as a "fire and forget" service "once configured - runs always" it is hard to remember the command line parameters for me.

All command are meant to be working while connected with a favourite CLI irc client to the znc service. Showing help in CLI :

/msg *status help

Saving current configuration:

/msg *status saveconfig

List all available and configured mods

    /msg *status listmods

Showing configured SASL authentication

/msg *sasl help
/msg *sasl requireauth yes
/msg *sasl set username <username> [<password>]

To see SASL debug messages f.e. to debug or verify encrypted connection use the verbose mode

/msg *sasl verbose yes|no

These are only the very basic commands used to configure and verify the znc daemon, for furhther command line check the website of the ZNC procject. Or the project website.

As I have been working in the "networking industry" for the last 10 years, I had always the chance to work with execptional networking engineers. From each one of them I have been taught very simple but important things on how to debug networking problems as they occur on day to day business. There is even a RFC which I like to refer to it is the RFC 1925 - The twelve networking truths.

Apart from that RFC that is fun to read the very most important thing is to mention if debugging productive networks and seraching for a cause of a failure, is to change one thing at a time and to wait at least 24 hours. That is the case if the cause is not known. This once particular and unwritten best practice hint, (please correct me if I am wrong and you find a RFC or a IEEE about this) has helped me numourous times in finding a possible cause for a failure.

The next very important hint while debugging I have been taught in school in a history lecture. Now you will ask yourself what has got a history taught in school with networking. A teacher told us once that if searching for a reason for something, the cause effect is mostly not monocausal.Things do not have only one cause, most times network failures have different reasons and not only one.

I understand that this is a optimised view on a possible problem and the described methods above do not apply always to a particular problem. Still these both are very important methods and I have made good experience with both along the years working in the network industry.