+ * Print Realtek packets.
+ *
+ * See, for example, section 8.22 "Realtek Echo Protocol" of
+ *
+ * http://realtek.info/pdf/rtl8324.pdf
+ *
+ * and section 7.24 "Realtek Echo Protocol" of
+ *
+ * http://realtek.info/pdf/rtl8326.pdf
+ *
+ * for information on REP.
+ *
+ * See section 8.21 "Network Loop Connection Fault Detection" of
+ *
+ * http://realtek.info/pdf/rtl8324.pdf
+ *
+ * and section 7.23 "Network Loop Connection Fault Detection" of
+ *
+ * http://realtek.info/pdf/rtl8326.pdf
+ *
+ * for information on RLDP.
+ *
+ * See also section 7.3.8 "Loop Detection" of
+ *
+ * http://www.ibselectronics.com/ibsstore/datasheet/RTL8306E-CG.pdf
+ *
+ * (revision 1.1 of the RTL8306E-CG datasheet), which describes a loop
+ * detection protocol for which the payload has a 16-bit (presumably
+ * big-endian) field containing the value 0x0300, followed by what is
+ * presumably a 16-bit big-endian field the upper 12 bits of which are 0
+ * and the lower 4 bits of which are a TTL value, followed by zeroes to
+ * pad the packet out to the minimum Ethernet packet size.
+ *
+ * See also section 7.3.13 "Loop Detection" of
+ *
+ * http://realtek.info/pdf/rtl8305sb.pdf
+ *
+ * (revision 1.3 of the RTL8305SB datasheet), which describes a similar
+ * loop detection protocol that lacks the TTL field - all the bytes
+ * after 0x0300 are zero.
+ *
+ * See also section 7.3.7 "Loop Detection" of
+ *
+ * https://datasheet.lcsc.com/lcsc/1810221720_Realtek-Semicon-RTL8305NB-CG_C52146.pdf
+ *
+ * (revision 1.0 of the RTL8305NB-CT datasheet), which describes a loop
+ * detection protocol similar to the one from the RTL8306E-CG datasheet,
+ * except that the first value is 0x2300, not 0x0300.
+ *
+ * And, on top of all that, I've seen packets where the first octet of
+ * the packet is 0x23, and that's followed by 6 unknown octets (a MAC
+ * address of some sort? It differs from packet to packet in a capture),
+ * followed by the MAC address that appears in the source address in the
+ * Ethernet header (possibly the originator, in case the packet is forwarded,
+ * in which case the forwarded packets won't have the source address from
+ * the Ethernet header there), followed by unknown stuff (0x0d followed by
+ * zeroes for all such packets in one capture, 0x01 followed by zeroes for
+ * all such packets in another capture, 0x07 followed by 0x20's for all
+ * such packets in yet another capture). The OpenRRCP issue at
+ * https://github.com/illarionov/OpenRRCP/issues/3 shows a capture
+ * similar to the last of those, but with 0x02 instead of 0x07. Or is that
+ * just crap in the buffer in which the chip constructed the packet, left
+ * over from something else?