Hello, I''ve been trying to track down the answer to questions regarding the output off the mss value reported below. I am coming up empty handed. I''m hoping someone might shed some light on the following. When I do: ************************* root@deadmeat jbanks # netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 63.187.254.9 0.0.0.0 255.255.255.255 UH 40 0 0 ppp0 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1 127.0.0.0 127.0.0.1 255.0.0.0 UG 40 0 0 lo 0.0.0.0 63.187.254.9 0.0.0.0 UG 40 0 0 ppp0 *********************** Why is the __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
Hello,
I''ve been trying to track down the answer to this and am coming up
empty handed. I''m hoping someone might shed some light on the
following regarding mtu/mss values.
When I do: "netstat -rn" or "route -nee"
*************************
root@deadmeat jbanks # netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window
irtt Iface
63.187.254.9 0.0.0.0 255.255.255.255 UH 40 0
0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0
0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0
0 eth1
127.0.0.0 127.0.0.1 255.0.0.0 UG 40 0
0 lo
0.0.0.0 63.187.254.9 0.0.0.0 UG 40 0
0 ppp0
***********************
Why is the "mss" value "40" ? Everything works just fine.
(e.g...
downloading email attatchments and doing file tranfers so I''m
thinking that this is a bug of some sort.)
When I do "ifconfig", it shows the appropriate mtu value but this
isn''t
reflected in the routing table?
eth0 Link encap:Ethernet HWaddr 00:10:4B:72:F8:7E
inet addr:192.168.1.1 Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3962 errors:0 dropped:0 overruns:0 frame:0
TX packets:12601 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:482119 (470.8 Kb) TX bytes:11268641 (10.7 Mb)
Interrupt:9 Base address:0xa000
eth1 Link encap:Ethernet HWaddr 00:A0:CC:D3:DE:3A
inet addr:192.168.1.2 Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:11720 errors:1 dropped:0 overruns:0 frame:0
TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1579402 (1.5 Mb) TX bytes:1680 (1.6 Kb)
Interrupt:5 Base address:0xa400
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:216 errors:0 dropped:0 overruns:0 frame:0
TX packets:216 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:17141 (16.7 Kb) TX bytes:17141 (16.7 Kb)
ppp0 Link encap:Point-to-Point Protocol
inet addr:63.187.232.34 P-t-P:63.187.254.9
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1524 Metric:1
RX packets:7208 errors:0 dropped:0 overruns:0 frame:0
TX packets:7826 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:5965919 (5.6 Mb) TX bytes:940048 (918.0 Kb)
I know that -IP header (20 bytes) and -TCP heard (20 bytes) would give
you MTU -40 bytes wich would give you a MSS value or 1460 bytes for
ethernet. Does anyone have any ideas why or links that point to an
explanation of this low MSS value.
I''m running a 2.4.20r7 kernel.
Thanks,
JBanks
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
On Saturday 13 December 2003 11:36 pm, Joshua Banks wrote:> > Why is the "mss" value "40" ? Everything works just fine. (e.g... > downloading email attatchments and doing file tranfers so I''m > thinking that this is a bug of some sort.) >That would be my guess -- I see zero as the value on all of my firewall''s interfaces. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
--- Tom Eastep <teastep@shorewall.net> wrote:> On Saturday 13 December 2003 11:36 pm, Joshua Banks wrote: > > > > > Why is the "mss" value "40" ? Everything works just fine. (e.g... > > downloading email attatchments and doing file tranfers so I''m > > thinking that this is a bug of some sort.) > > > > That would be my guess -- I see zero as the value on all of my > firewall''s > interfaces.Zero''s? Wow. Well if i got 40''s and you got 0''s and everything works like normal, then there''s something definitely buggy. Did you get the same value when doing "route -nee" ?? Thanks, Joshua Banks __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
Joshua Banks wrote:>Hello, > >I''ve been trying to track down the answer to this and am coming up >empty handed. I''m hoping someone might shed some light on the >following regarding mtu/mss values. > >When I do: "netstat -rn" or "route -nee" > >Why is the "mss" value "40" ? Everything works just fine. (e.g... >downloading email attatchments and doing file tranfers so I''m >thinking that this is a bug of some sort.) > >Well, from what I remember, the MSS value isn''t determined by YOU, it''s set by the RECEIVER of the segment. Therefore, it''s possible that during the establishment of the connections you showed, the receivers set the MSS to 40. OTOH, the MTU value IS set by you...and fragmented as needed as it travels through networks with smaller MTU values....>I know that -IP header (20 bytes) and -TCP heard (20 bytes) would give >you MTU -40 bytes wich would give you a MSS value or 1460 bytes for >ethernet. Does anyone have any ideas why or links that point to an >explanation of this low MSS value. >Not really following how you''re making this calculation, but both TCP and IP headers are a minimum of 20 bytes and can go as high as 60 bytes with the available options. Adding these two together doesn''t determine your MTU since the final frame (which is where the MTU matters) is made up of MORE than just the IP and TCP headers. Another thing, MSS is the size of the DATA package in the TCP segment...NOT the size of the header or header plus data. The name Max Segment Size is really a misnomer since the size of the MSS does not include the size of the header....only the size of the data. Hope maybe this helps somehow. Chris
--- chris <ck2@softhome.net> wrote:> Joshua Banks wrote: > > >Hello, > > > >I''ve been trying to track down the answer to this and am coming up > >empty handed. I''m hoping someone might shed some light on the > >following regarding mtu/mss values. > > > >When I do: "netstat -rn" or "route -nee" > > > >Why is the "mss" value "40" ? Everything works just fine. (e.g... > >downloading email attatchments and doing file tranfers so I''m > >thinking that this is a bug of some sort.) > > > > > > Well, from what I remember, the MSS value isn''t determined by YOU, > it''s > set by the RECEIVER of the segment. Therefore, it''s possible that > during the establishment of the connections you showed, the receivers > > set the MSS to 40.Not really. Packet sniffing helped by some backing of some RFC''s. Mainly 732 and now replaced by RFC 1122. In the initial tcp start or circuit setup sequence, each system knows its MTU value and sends its max MSS value -40 bytes for the IP and TCP headers. (these are the minimum values) In actuallity IP packets have a 20 byte header, with a maximum of 60 bytes being used for data. Tcp segments have same type of value sizes.. And although RFC 1122 states that TCP implementations must set aside 40 bytes of data when a segment is created, this isn''t always enough. (by the way I''m taking some of this info from a book as well called "Internet Core Protocols" The definitive guide. O''Reilly book. I actually had to go out and buy a book to help translate some of the RFC engineering jargon. Pretty dry stuff. Anyways...> > OTOH, the MTU value IS set by you...and fragmented as needed as it > travels through networks with smaller MTU values....This is where Path MTU comes into play and this is where, as Tom puts it so nicely when talking about CLAMPMSS: "This is used to overcome criminally braindead ISPs or servers which # block ICMP Fragmentation Needed packets. The symptoms of this # problem are that everything works fine from your Linux # firewall/router, but machines behind it can never exchange large # packets: # 1) Web browsers connect, then hang with no data received. # 2) Small mail works fine, but large emails hang. # 3) ssh works fine, but scp hangs after initial handshaking." I think that this is part the problem that one of the Shorewall users is facing. Undetermined as of yet though.> > >I know that -IP header (20 bytes) and -TCP heard (20 bytes) would > give > >you MTU -40 bytes wich would give you a MSS value or 1460 bytes for > >ethernet. Does anyone have any ideas why or links that point to an > >explanation of this low MSS value. > > > > Not really following how you''re making this calculation, but both TCP > > and IP headers are a minimum of 20 bytes and can go as high as 60 > bytes > with the available options. Adding these two together doesn''t > determine > your MTU since the final frame (which is where the MTU matters) is > made > up of MORE than just the IP and TCP headers.Correct... but I''m taking the rfc into consideration here.> Another thing, MSS is the size of the DATA package in the TCP > segment...NOT the size of the header or header plus data. The name > Max > Segment Size is really a misnomer since the size of the MSS does not > include the size of the header....only the size of the data.Correct. And thats basically what I stated above. In more words or less using the RFC. max MSS= max MTU -40? Packet sniff and you will see. :P> Hope maybe this helps somehow.Yes, any opinions help me make sure that I''m not understanding something incorrectly Chris. Thanks for the response. Thanks, Joshua Banks __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
> > >>Well, from what I remember, the MSS value isn''t determined by YOU, >>it''s >>set by the RECEIVER of the segment. Therefore, it''s possible that >>during the establishment of the connections you showed, the receivers >> >>set the MSS to 40. >> >> > >Not really. Packet sniffing helped by some backing of some RFC''s. >Mainly 732 and now replaced by RFC 1122. In the initial tcp start or >circuit setup sequence, each system knows its MTU value and sends its >max MSS value -40 bytes for the IP and TCP headers. (these are the >minimum values) In actuallity IP packets have a 20 byte header, with a >maximum of 60 bytes being used for data. Tcp segments have same type of >value sizes.. And although RFC 1122 states that TCP implementations >must set aside 40 bytes of data when a segment is created, this isn''t >always enough. (by the way I''m taking some of this info from a book as >well called "Internet Core Protocols" The definitive guide. O''Reilly >book. >Ok...checked the RFC. The MSS is determined by whichever host has the ''smaller'' of the two advertised MSS options. Also didn''t know that the MSS option is only used if the host sending is using some value other than the DEFAULT value of 536 and if the option is NOT sent, the receiver ASSUMES a MSS value of 536. In any case, is this leading to an answer to the original question? Chris
--- chris <ck2@softhome.net> wrote:> In any case, is this leading to an answer to the original question?To funny. Forgot about the original question. But to answer, I''ve found so far that this must be a bug in the kernel routing table. I''ve packet sniffed while doing ftp, smtp and http tranfers and the mss value in the packet traces is never 40 for either machines participating the connection. But what I do see. is that I always advertise my mss value as being my max mtu "-40" and most others do the same. So this would follow the RFC 1122. So I assume that this is just a stupid insignificant bug in the kernel reporting this value incorrectly. Right now I''m using a dial-up connection. We''ll see if they''re any significant changes in the mss value recorded in the routing table when I switch from dial-up to Comcast cable internet. What do your values state Chris from doing a "netstat -rn" or a "route -nee" ? Just out of curiousity. Thanks, Joshua Banks __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
What do your values state Chris from doing a "netstat -rn" or a "route -nee" ? Just out of curiousity. I''m showin an MSS of 0 for both cases. Haven''t verified this with Ethereal yet tho....that will be interesting to see. If packets indicate proper MSS values then yes, must be a buggy reporting issue of some kind. If it''s actually a bug in the kernel routing TABLE, then wouldn''t the routing table values be used to generate the packets? I''ve never thought this deeply into it, but it leaves me wondering if the routing table is populated irregardless of the actual field values used for packet generation. It seems hard to believe that values during handshaking would be calculated by the protocols and then incorrectly placed into the table. ...time to pull out some books ;) Chris
chris wrote:> What do your values state Chris from doing a "netstat -rn" or a "route > -nee" ? Just out of curiousity. > > I''m showin an MSS of 0 for both cases. Haven''t verified this with > Ethereal yet tho....that will be interesting to see.Verified, MSS is MTU-40 bytes. Chris