Open jonathanperret opened 3 months ago
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 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!
Currently
sliplib.encode
inserts anEND
(0xc3
) byte at the start as well as the end of the SLIP packet:Reading the "nonstandard" https://datatracker.ietf.org/doc/html/rfc1055.html I see:
The next paragraph does suggest the possibility of starting packets with an
END
byte: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 thatsliplib
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.