Closed NJRoadfan closed 4 days ago
@NJRoadfan how come this wasn't a problem in netatalk 2.x? We always reported AFP 1.2 - 3.3 in the server info response on that version, if I'm not mistaken.
Most people don't use long host names and/or enable all the UAMs. Netatalk 3.0 added AFP3.4 support (another 7 bytes) which tightened how long a hostname could be before crossing the 512 byte boundary, particularly if you have all the UAMs turned on. Things are even worse if you are using LDAP or the server is advertising multiple listening addresses.
Refer to #1661. Turns out that AppleShare Client 3.7.4 suffers from the 512 byte packet limit bug, including when receiving responses over DSI. Being that this is the only officially supported version with AFP-over-TCP for System 7 clients, it is important that this is fixed.
This change limits Netatalk to replying with AFP versions 2.2 to 3.4 to DSI clients, which poses no compatibility issues as there are technically no TCP/IP clients supporting the older versions.
The only exception to this is the AFPBridge control panel for GS/OS, which identifies as AFPVersion2.0 by default. This TCP/IP client has been tested and still works fine even with this change.