(I'm rolling comments to various bits in this thread into this reply. If I've misattributed something, please forgive me) Hello, (from Martin) > Chris, what problem exactly have you seen that led to this commit? So what was happening was that packets of ETHERTYPE_AARP were failing the packet size integrity check in aarpinput(). The received packets, by the time they got to that check, were exactly four bytes short. They were then dropped. Removing the M_HASFCS check from ether_input() in if_ethersubr.c (thus preserving the last four bytes) resulted in working AppleTalk but broken TCP/UDP. I started dumping raw received packets in the driver receive routine, and noted that the AppleTalk packets *did not* have FCS, but IP packets *did*. "Inside AppleTalk" lists the AppleTalk-Ethernet AARP packet format on page 3-12. It *does* show the data-link header and 802.2 header at the beginning of the packet, but does not show FCS at the end. The final four bytes are, instead, four bytes of destination address. Like everyone else, I was under the impression that Ethernet required FCS, but with IAT not listing FCS bytes in the packet on one hand, received AARP packets lacking FCS on the other hand, and received IP packets having FCS on the third hand, I concluded that this was yet another example of an Apple protocol being weird for the sake of being weird and committed the smallest change that made everything work. (from Robert Swindells, regarding reversion) > I think it should. I agree, because ... (from Martin) > there is bit 7 defined as ACS (Automatic Pad/CRC Stripping) that > should cause the CRC field to be stripped if the length field is <= 1500. ... hmmm ... > maybe the "docs" are wrong, the bits are inverted and > as we set it up now the FCS is *not* stripped for regular packets with > a length field <= 1500 (ACS off) and it is (eroneously) stripped for > the ethertalk packets (with type > 0x600, CST on), but despite the > chip stripping it for us we still used to set M_HASFCS. ... and that provides the answer. The received AARP packets are small (28 bytes IIRC). Setting *_CONF_ACS makes the driver strip FCS from AARP, but larger packets retain their FCS bytes. As discussed, the driver originally set M_HASFCS for all received packets, disregarding the hardware possibly having already removed the FCS bytes. AARP packets would thus have an additional four bytes lopped off, corrupting the packet and breaking AppleTalk thereby. Removing AWIN_GMAC_MAC_CONF_ACS from interface configuration, and reverting the per-protocol FCS bit I committed, appears to do the right thing. AppleTalk works, IP works, and the rockpro64 hasn't fallen over after four hours of moderate testing. I'm going to commit this fix right after I finish writing this email. Martin, would this pass muster for a pullup to the 9.x branch? Thanks, everyone, for the comments that led to the correct fix here. Much appreciated. -- -- Chris GPG key fingerprint B566 051D D99D 37B6 41F2 7593 22EE 9E38 FBA7 7B34
Attachment:
signature.asc
Description: PGP signature