Recompile for 68360 box
-----------------------
28, October, 1995
-----------------
1. Improper DEFS.H kept causing compiler GPF's -- Fixed
2. The option union required a tag name for this compiler. Accordingly
   all accesses were to be modified.
3. Urgent data function pointer in the TCP structure was of return type
   int while actually a function with void return type was being assigned.

31, October, 1995
-----------------
4. defs.h was not defining BIG_ENDIAN and __BIG_ENUMS__.

??, October, 1995
-----------------
5. Unused bit setting in the IP code ip header was not being set to 0
   each time an IP packet was being sent.
6. tcp_send() in TCPSEND.C was not handling PSH properly. Introduced
   send_truncated variable and corrected error.

22-November, 1995
-----------------
7. In RST packets sent on non-existent sockets, sequence number was not
   being set to incoming packet's ACK number.

24, November, 1995
------------------
8. If we run out of connection records, further listening is halted 
   because of not reseting the CONNPENDING flag in the listen record.

19, Jan, 1996
-------------
9. tcprtx.c - when retransmit occurs, if a SYN or FIN has to be retransmitted,
   the buffer alloc-ed for retransmit is free-ed and another function is
   called to do the job. When free-ing, the buffer pointer is not adjusted
   properly.

23, June, 1996
--------------
10. tcpsock.c, socket_tcp_send() -- the computation of the amount of free
    space in the send window was computed using the 'send_bstart' and
    'send_bnext' fields of the connection record to determine the amount of
    unack-ed data. But being a circular buffer, when 
    'send_bstart'=='send_bnext', the buffer could be empty or full. The
    computation we were using made it look like the buffer was empty when
    it was full.

    Corrected by introducing a new variable in each connection record that
    continuously tracks amount of unack-ed data. See 'design' file for
    more info.
11. tcpfgnd.c, tcp_send_fgnd() - The condition under which the actual
    send function was being invoked was 

    if ((ptr_conn_info->send_filled != 0) 
	&&
	(((ptr_conn_info->conn_flags & (TCPF_SENDPSH | TCPF_SENDFIN)) != 0)
	||
	(ptr_conn_info->send_filled >= (ptr_conn_info->send_max_advert >> 1))
	||
	(ptr_conn_info->send_filled >= ptr_conn_info->send_mss)))

   But here it is possible that under the wrong max_advert and mss values,
   the condition is never satisfied (it happened once where max_advert was
   4096, mss was 2048 and PSH or FIN wasn't being set).

   So modified this so that if the send_window is more than 3/4th full
   (why 3/4th? -- arbitary), send will be invoked.
12. Had some problem regarding PSH. Our TCP uses a send window of 1.5K. If
    Telnet (TCP app) tries to send larger than 1.5K bytes at one time 
    (say 2k), the send window becomes full with data, but the PSH bit is not
    set when this data is sent out. This is the way the rules are -- PSH 
    should be set only on the last segment of a socket_write() call. But
    this seems to cause problems with some TCP's (PC-TCP) when they have
    a receive window larger than this (say 4K). They don't seem to ACK
    our sends (which do not have the push bit set) as their receive window
    is not full. We are not able to clear our send window as we are waiting
    for the ACK. So a deadlock.
    Fixed this so that if out send window is full, we push every segment that
    is sent.
13. IP does not support fragmenting properly. So if somebody had advertised
    a send mss larger than IP's MTU, TCP may sometimes try to send a packet
    larger than this MTU value. So IP will try to fragment and since this
    does not work properly, things go for a toss.
    So added code to determine the minimum of MTU's as used by all interfaces
    and send mss is adjusted to this so that when TCP send occurs, there is
    no fragmentation.

20, July, 1996
--------------
(Not exactly a bug -- some performance related stuff)
14. The original code used a delayed ACK mechanism as explained in
    Richard Stevens book (see file DESIGN). This causes ACK's to be
    delayed by about 250ms. Changed this so that if in an incoming segment,
    the PUSH bit is set, ACK is sent immediately. Read RFC-813.
15. Standardised on a 4K send and receive window. Earlier we used 1.5K.
    This is better for file transfers.

13, September, 1996
-------------------
16. A performance fix. Earlier, when retransmit timer expires, we were
    retransmitting only the first segment in the retransmit queue. Now
    we retransmit all segments in the retransmit queue. This is because,
    in case the other end is able to accept fresh segments, he still
    will have to wait for the next retransmit timeout to get the next
    retransmit segment. Problem noticed in the RN group when doing
    file transfers.
