SHERWOOD@DALAC.BITNET (John Sherwood) (07/16/88)
Fellow Netlanders: We have been seeing some heavy (bogus?) ethernet packet traffic from a SUN4 running 3.2 SUNOS: DEST SRC SUMMARY SUN4 VMS ARP C PA=[129.173.1.20] PRO=IP VMS SUN4 ARP R PA=[129.173.1.20] HA=AA0004001E14 PRO=IP SUN4 VMS TCP D=25 S=32523 SYN SEQ=3205758976 LEN=0 WIN=4096 VMS SUN4 TCP D=32523 S=25 SYN ACK=3205758977 SEQ=9828161 LEN=0 WIN=4096 SUN4 VMS TCP D=25 S=32523 ACK=9828162 WIN=4096 VMS SUN4 TCP D=32523 S=25 ACK=3205758977 WIN=4096 VMS SUN4 SMTP R PORT=32523 220 Golly wosh! Sendmail 5.51++/Vxxi.... SUN4 VMS TCP D=25 S=32523 ACK=9828229 WIN=4029 VMS SUN4 TCP D=32523 S=25 ACK=3205758977 WIN=4096 SUN4 VMS SMTP C PORT=32523 HELO DALAC<0D><0A> VMS SUN4 TCP D=32523 S=25 ACK=3205758989 WIN=4084 VMS SUN4 TCP D=32523 S=25 ACK=3205758989 WIN=4085 VMS SUN4 TCP D=32523 S=25 ACK=3205758989 WIN=4086 VMS SUN4 TCP D=32523 S=25 ACK=3205758989 WIN=4087 VMS SUN4 TCP D=32523 S=25 ACK=3205758989 WIN=4088 VMS SUN4 TCP D=32523 S=25 ACK=3205758989 WIN=4089 VMS SUN4 TCP D=32523 S=25 ACK=3205758989 WIN=4090 VMS SUN4 TCP D=32523 S=25 ACK=3205758989 WIN=4091 VMS SUN4 TCP D=32523 S=25 ACK=3205758989 WIN=4092 VMS SUN4 TCP D=32523 S=25 ACK=3205758989 WIN=4093 VMS SUN4 TCP D=32523 S=25 ACK=3205758989 WIN=4094 VMS SUN4 TCP D=32523 S=25 ACK=3205758989 WIN=4095 VMS SUN4 TCP D=32523 S=25 ACK=3205758989 WIN=4096 VMS SUN4 SMTP R PORT=32523 250 Hello dalac.UUCP, ..... SUN4 VMS TCP D=25 S=32523 ACK=9828284 WIN=3974 VMS SUN4 TCP D=32523 S=25 ACK=3205758989 WIN=4096 SUN4 VMS SMTP C PORT=32523 MAIL FROM:<SHERWOOD@DALAC><0D><0A> VMS SUN4 TCP D=32523 S=25 ACK=3205759017 WIN=4068 VMS SUN4 TCP D=32523 S=25 ACK=3205759017 WIN=4069 VMS SUN4 TCP D=32523 S=25 ACK=3205759017 WIN=4070 VMS SUN4 TCP D=32523 S=25 ACK=3205759017 WIN=4071 ...and so on (VMS is node DALAC, a VAX 8800 running CMU 6.3 TCP/IP code; SUN4 is DALCS, the 3.2 SUNOS culprit). As you can see, the SUN is very concerned about keeping the other system up to date about its window size, so much so that it generates about 2000 packets/second of ACK's (one for every byte of data). The trigger is always SMTP mail heading to the SUN4 from some other system. We see the problem with either CMU 6.2, CMU 6.3 or BSD 4.3 as the client system. The client isn't too happy having to deal with all this extra traffic and generally manages to have a rotten day. SUN has been no help with this problem so far. We are waiting to upgrade to SUNOS4.0 as a possible fix, but that is not possible until CommonLisp is available. Any ideas? Is this a known bug? Is it better in 4.0? Are there workarounds? Thanks John Sherwood Dalhousie University Halifax, Nova Scotia SHERWOOD@DALAC (NetNorth/BITNET/EARN)