This will be a work in progress for a bit, but the goal here is to help spot obvious bugs.

Bare and broad exceptions are a bug

Bare and broad exceptions are considered bugs in the professional projects that I have worked on.

This practice hides coding bugs and makes it harder to debug code, especially something as complex as D-Rats.

A bare exception is "except:" and a broad exception is "except Exception:" or "raise Exception".

New code in d-rats should not have these, in most cases.

In a communication protocol, though, a broad exception handler may be needed to attempt to make sure that communication errors are properly signals to the sending station, as failing to do so can result in protocol hang that can be used in a denial of service attack.

Modules that raise exceptions should raise a d-rats created exception class.

The python pack and unpack structures for numeric types need an endian specifier

With out a an endian specifier, they default to native endian, and that means that data can not be interchanged between some platforms.

Normally "!" for network_endian should be specified, this is the same as big-endian. The x86 platform native endian is little-endian. The AGWPE interface needs little-endian in its structures. The AX25 protocol uses network-endian. Most of D-rats uses network-endian, except for handling file/form transfer size, that is in little-endian.

Watch out for invalid example e-mail domains

The only example e-mail or default e-mail domains that should ever be used are the ones reserved by the IANA.ORG. These are example.com, example.net, and example.org.

Do not use any other domains for example e-mail addresses, as that can result in your application being used in a denial of service attack on another site.

Serial port handling

Per standard:

• A serial port must not assert DTR unless there is a program in control of that port.
• A serial port must assert DTR only when it is ready to process data, and then it must assert DTR as long as it is is processing data.
• A serial port must drop DTR to break an authenticated connection when it detects a DSR drop or when the program considers the connection logged off or broken for any reason.
• DTR should not be used for flow control except for some printer models, and even then, that is a bad idea.
• RTS must be asserted before the application sends any data.
• Reading the DSR/CTS signals should be a configuration option for the port.
• If DSR signal is enabled, then the serial port is considered open or connected only when DSR is seen asserted.
• If dial up style modems are used, then the CD signal must also be asserted for a session to be considered connected.
• if the CTS signal enabled, then the port should not send data unless CTS is asserted, normally this should be handled by the serial port driver provided by the operating system.
• This standard should be always followed in software, even if the DSR/DTR and CTS/RTS signals are not expected to be wired.