mosemann@sardion.unl.edu (Russell Mosemann) (03/27/91)
In <1991Mar26.213034.8544@hoss.unl.edu> mosemann@sardion.unl.edu (Russell Mosemann) writes: > Weeks and weeks ago, people were discussing the problem MacTCP has >with determining the MSS (maximum segment size). I read the messages >but never wrote anything down or saved it because we didn't have that >problem before. [...] > I dug into the packets and found that it was requesting a window size >of *10241*. Could someone mail the fix for this (I think it was done by >Steve Dorner)? [...] OK. I got the fix, but it didn't solve the problem. Now for a little more information. I'm using MacTCP 1.0, MacPOP 1.5.7, Systems 6.0.5 and 6.0.7, and Ethernet'ed and LocalTalk'ed Macs (SE/30, SE, and Classic). MacPOP tries to establish the tcp connection. I see the 4 or so packets go to the POP host, but there is no return response. Our sniffer reports: Ethernet: ( router -> pop host) type: IP(0x0800) Internet: Mac IP -> pop host IP hl: 6 ver: 4 tos: 0 len: 48 id: 0x0009 fragoff: 0 flags: 00 ttl: 58 prot: TCP(6) xsum: 0x6a75 bsec resv 4: TCP: 10593 -> POP-2(109) seq: 5d60a560 ack: ---- win: 11648 hl: 6 xsum: 0x3a3a urg: 0 flags: <SYN> mss: 576 Only the Ethernet and IP addresses have been changed. This is from a Mac Classic going through a FastPath 4 running version 8.x of KSTAR. I can telnet to the port and issue commands by hand with no problem. The mss doesn't seem to be the problem that I thought it was. The window size seems a little strange, but maybe it's OK, too. The thing I have never seen in a TCP packet before is the "bsec resv 4:". Does anything look wrong in this packet? Thanks. -- Russell Mosemann Internet: mosemann@unl.edu Network Analyst Bitnet: mosemann@unlvax1 Computing Resource Center UUCP: ..!uunet!hoss.unl.edu!mosemann University of Nebraska - Lincoln Voice: (402) 472-5930 Fax: 472-5280
mosemann@sardion.unl.edu (Russell Mosemann) (03/27/91)
In <1991Mar26.213034.8544@hoss.unl.edu> mosemann@sardion.unl.edu (Russell Mosemann) writes: > Weeks and weeks ago, people were discussing the problem MacTCP has Arg! I forgot to mention that the pop host is a Sun (we've tried a Sparc 1 and a Sparc 2) running SunOS 4.1.1. MacPOP was working a month or two ago. One thing that changed in that time was that we moved from Sun0S 4.0.3 to 4.1 to 4.1.1. -- Russell Mosemann Internet: mosemann@unl.edu Network Analyst Bitnet: mosemann@unlvax1 Computing Resource Center UUCP: ..!uunet!hoss.unl.edu!mosemann University of Nebraska - Lincoln Voice: (402) 472-5930 Fax: 472-5280
jbvb@FTP.COM (James B. Van Bokkelen) (03/30/91)
Ethernet: ( router -> pop host) type: IP(0x0800)
Internet: Mac IP -> pop host IP hl: 6 ver: 4 tos: 0
len: 48 id: 0x0009 fragoff: 0 flags: 00 ttl: 58 prot: TCP(6)
xsum: 0x6a75 bsec resv 4:
TCP: 10593 -> POP-2(109) seq: 5d60a560 ack: ----
win: 11648 hl: 6 xsum: 0x3a3a urg: 0 flags: <SYN> mss: 576
... The thing I have never seen in a TCP packet before is the
"bsec resv 4:".
LANWatch is telling you that your IP header contains the "Basic Security"
IP option, with a "reserved" classification value. This might well be
the problem - many hosts can't grok IP packets with options.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901JSIMPSON@MIAMIU.BITNET (Joe Simpson) (03/30/91)
This is a known problem . MacTCP version 1.0.1 fixed it.