This updater patches MacTCP to fix the Land attack bug and some others (as discussed below). You will need a fresh copy of MacTCP 2.0.6 from your original installer or system update to use this updater. You may be able to get the updater to work on a used copy of MacTCP 2.0.6 by using ResEdit to clear the System Heap bits on the DRVR 22 resource and the ctrp 130 resource.
After putting the new version of MacTCP in your system folder, open and then close it again to make sure it keeps your settings.
NOTE: This is an unofficial patch and is not officially supported by anyone, use it at your own risk.
Send any feedback or bug reports to mactcp@mactcp.org.nz
Click here to download the MacTCP 2.1 patch (StuffIt archive - 27K).
2.1 is just a user interface change to MacTCP to allow classless subnet mask configuration. The old user interface kept switching to a subnet mask based on the class of the IP address. This tended to confuse things if you were trying to use MacTCP on a network of contiguous class C ranges.
MacTCP would disconnect a TCP connection if the IP precedence changed. RFC 2873 changed this behavior and specifies that TCP should ignore the IP precedence field.
There were still two debugger breaks in MacTCP, they should never trigger but I removed them anyway.
The land attack patch introduced in 2.0.7 had a problem that could cause a crash on some systems.
Changed the control trap patch to be the same as the one used by Open Transport, it requires about half the number of instructions to run.
MacTCP, as it ships, is immune to the Ping of Death. This is only because the memory pool it allocates is too small to reassemble a 64k packet. The normal memory allocations are as follows:
|
System Memory
< 1Mb 1 Mb to 2Mb 2Mb or more |
MacTCP pool
20k 28k 40k |
I increased the memory pool for 2Mb or more up to 256k to be able to handle larger fragmented packets, so MacTCP became vulnerable. It turns out there is a debugger break that is triggered if an IP packet larger than 32k is sent. Once I removed this I found that MacTCP would do a 16 bit calculation on the packet size, and not fragment it if it was larger than 64k as a result. This large packet would then be sent to the ethernet driver, and if the ethernet driver was also doing a 16 bit calculation a crash would result. I have fixed this by changing MacTCP to do a 32 bit calculation on the packet size, and discard anything greater than 64k.
BlockMoveData is a newer version of BlockMove that doesn't flush the instruction cache of the processor. This probably doesn't result in any noticable performance increase, but was a simple find and replace so I did it anyway.
When MacTCP was sending an ICMP packet in response to something, it would copy the TTL (time to live) from the packet it was responding to. This can result in the ICMP response being discarded due to having a TTL that is too small. The most obvious example of this is when tracerouting to a computer running MacTCP, the computer won't actually respond until the trace gets to double the number of hops. The TTL is now reset to 255.
If a TCPClose is issued right after a TCPSend, sometimes a FIN is not sent. This can result in the connection at the remote end being left open until it times out. I was finding with my PowerMac (with OT and Eudora checking mail on a MacTCP server) the result would be a lot of connections being left in the please close state on my PowerMac. MacTCP doesn't send a FIN until all outstanding data being sent is ACKed. If MacTCP is in the CLOSING state or the LAST-ACK state it will go to the TIME-WAIT or CLOSED state if an ACK comes in that ACKs all outstanding data. This happens if the TCPSend is still waiting to be ACKed. I have added a check to make sure that the FIN has been sent before changing states.
MacTCP is vulnerable to the land attack. The land attack is a variant on a spoofed SYN attack where the source address and port are the same as the destination port and address. MacTCP doesn't like this, it gets stuck in a loop sending SYN packets to itself, freezing the Mac. Unfortunately it also sends these packets out onto the rest of the network, which can result in unnecessary network bandwidth usage. I have patched it so that listening streams ignore any packets that have the same source and destination port and address.
Last modified 28 Feburary 2023. Copyright 1997-2023 Glenn Anderson.