Document or make optional the emission of leading END bytes

[jonathanperret]

Currently sliplib.encode inserts an END (0xc3) byte at the start as well as the end of the SLIP packet:

$ python -c 'import sliplib;print(sliplib.encode(b"abc"))'
b'\xc0abc\xc0'

Reading the "nonstandard" https://datatracker.ietf.org/doc/html/rfc1055.html I see:

To send a packet, a SLIP host simply starts sending the data in the packet. If a data byte is the same code as END character, a two byte sequence of ESC and octal 334 (decimal 220) is sent instead. If it the same as an ESC character, an two byte sequence of ESC and octal 335 (decimal 221) is sent instead. When the last byte in the packet has been sent, an END character is then transmitted.

The next paragraph does suggest the possibility of starting packets with an END byte:

Phil Karn suggests a simple change to the algorithm, which is to begin as well as end packets with an END character. This will flush any erroneous bytes which have been caused by line noise. In the normal case, the receiver will simply see two back-to-back END characters, which will generate a bad IP packet. If the SLIP implementation does not throw away the zero-length IP packet, the IP implementation certainly will. If there was line noise, the data received due to it will be discarded without affecting the following packet.

Note that this variant relies on the opposite party throwing away zero-length packets, which is not necessarily obvious now that SLIP is not only (if ever) used for IP packet encoding.

I'm working on an app that uses sliplib to interface with an Arduino running https://github.com/bakercp/PacketSerial . That library does not drop the 0-length packets that sliplib in effect inserts, which can be a problem if the receiving code does not expect them. I know they are very easy to ignore once you know about them, I'm just pointing out a potential "footgun".

I suggest that the sliplib documentation should at least point out the choice of this "deviation" from RFC1055.

[rhjdjong]

Thanks for bringing up this issue. I'm on a short trip right now, but will look into this next week.
Documenting this behavior is one thing, but I think a better approach would be to introduce a module-global toggle that enables or disables sending the leading END byte. Would that also address the issue you are having with communication with the arduino device?

[jonathanperret]

Thanks for bringing up this issue. I'm on a short trip right now, but will look into this next week. Documenting this behavior is one thing, but I think a better approach would be to introduce a module-global toggle that enables or disables sending the leading END byte. Would that also address the issue you are having with communication with the arduino device?

Thanks for the quick feedback. Yes, definitely adding a toggle would be even better (hence why I included "or make optional" in the issue title 😉).

There is absolutely no hurry for me, the issue on the Arduino side is already fixed with a test for zero-length packets. Enjoy your trip!

[rhjdjong]

Solved in release v0.7.0