Groups > comp.os.linux.networking > #276 > unrolled thread

Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

Started by	Mark Hobley <markhobley@yahoo.donottypethisbit.co>
First post	2011-05-21 14:58 +0000
Last post	2011-05-22 00:44 -0400
Articles	20 on this page of 29 — 8 participants

Back to article view | Back to comp.os.linux.networking

  Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Mark Hobley <markhobley@yahoo.donottypethisbit.co> - 2011-05-21 14:58 +0000
    Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2011-05-21 15:16 -0400
      Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-21 22:02 +0000
        Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2011-05-22 19:59 +0300
          Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Mark Hobley <markhobley@yahoo.donottypethisbit.co> - 2011-05-22 17:09 +0000
    Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Mark Hobley <markhobley@yahoo.donottypethisbit.co> - 2011-05-21 20:20 +0000
      Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-21 22:47 +0100
      Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-21 22:28 +0000
        Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Mark Hobley <markhobley@yahoo.donottypethisbit.co> - 2011-05-22 01:15 +0000
          Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-22 06:01 +0000
            Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Mark Hobley <markhobley@yahoo.donottypethisbit.co> - 2011-05-22 07:28 +0000
              Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Andy Furniss <spam@andyfurniss.entadsl.com> - 2011-05-22 11:40 +0100
                Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Mark Hobley <markhobley@yahoo.donottypethisbit.co> - 2011-05-22 12:25 +0000
                  Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Andy Furniss <spam@andyfurniss.entadsl.com> - 2011-05-22 20:40 +0100
                    Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Andy Furniss <spam@andyfurniss.entadsl.com> - 2011-05-22 20:56 +0100
                      Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Mark Hobley <markhobley@yahoo.donottypethisbit.co> - 2011-05-22 22:57 +0000
                    Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Mark Hobley <markhobley@yahoo.donottypethisbit.co> - 2011-05-22 23:12 +0000
              Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-22 11:31 +0000
                Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Mark Hobley <markhobley@yahoo.donottypethisbit.co> - 2011-05-22 11:50 +0000
                  Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-22 12:52 +0000
                    Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Mark Hobley <markhobley@yahoo.donottypethisbit.co> - 2011-05-22 13:27 +0000
                      Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-22 19:19 +0000
                        Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Mark Hobley <markhobley@yahoo.donottypethisbit.co> - 2011-05-22 22:12 +0000
                          Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Mark Hobley <markhobley@yahoo.donottypethisbit.co> - 2011-05-25 15:55 +0000
                            ip route - Wrong Maximum Segment Size being advertised Mark Hobley <markhobley@yahoo.donottypethisbit.co> - 2011-05-25 17:27 +0000
                              Re: Linux 2.6.39.1 - Wrong Maximum Segment Size in both directions Mark Hobley <markhobley@yahoo.donottypethisbit.co> - 2011-05-29 00:34 +0000
                                Re: Linux 2.6.39.1 - Wrong Maximum Segment Size in both directions Andy Furniss <spam@andyfurniss.entadsl.com> - 2011-05-29 11:11 +0100
                    Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Martijn Lievaart <m@rtij.nl.invlalid> - 2011-05-23 08:13 +0200
      Re: Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised Barry Margolin <barmar@alum.mit.edu> - 2011-05-22 00:44 -0400

Page 1 of 2 [1] 2 Next page →

#276 — Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

From	Mark Hobley <markhobley@yahoo.donottypethisbit.co>
Date	2011-05-21 14:58 +0000
Subject	Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised
Message-ID	<ir8jui$l3k$1@dont-email.me>

I am upgraded my Debian system to experimental kernel 2.6.39-rc7. This has
caused an old network problem to reoccur, which I believe is related to the
network Maximum Segment Size that my ISP can convey.

On startup of my computer, I issue a command to clamp the size of all
externally bound traffic (destined for routing via the default gateway at
10.0.0.1) as follows:

ip route change default via 10.0.0.1 mtu lock 1412

Where 1412 is the maximum transmission unit for my ISP (Three mobile).
I now attempt to post a usenet article, and the newsreader hangs.

I have used tcpdump to examine the communications, and here is the output:

18: Flags [S.], seq 3385954279, ack 3902988975, win 5792, options [mss 1380,sackOK,TS val 140346418 ecr 47079743,nop,wscale 7], length 0
03:40:13.539947 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [.], ack 1, win 457, options [nop,nop,TS val 47079880 ecr 140346418], length 0
03:40:14.079843 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.51218: Flags [P.], seq 1:107, ack 1, win 46, options [nop,nop,TS val 140346550 ecr 47079880], length 106
03:40:14.079914 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [.], ack 107, win 457, options [nop,nop,TS val 47080015 ecr 140346550], length 0
03:40:14.080345 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [P.], seq 1:23, ack 107, win 457, options [nop,nop,TS val 47080016 ecr 140346550], length 22
03:40:14.829571 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.51218: Flags [.], ack 23, win 46, options [nop,nop,TS val 140346745 ecr 47080016], length 0
03:40:14.869553 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.51218: Flags [P.], seq 107:127, ack 23, win 46, options [nop,nop,TS val 140346745 ecr 47080016], length 20
03:40:14.870604 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [P.], seq 23:47, ack 127, win 457, options [nop,nop,TS val 47080213 ecr 140346745], length 24
03:40:15.509493 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.51218: Flags [.], ack 47, win 46, options [nop,nop,TS val 140346913 ecr 47080213], length 0
03:40:15.759474 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.51218: Flags [P.], seq 127:157, ack 47, win 46, options [nop,nop,TS val 140346967 ecr 47080213], length 30
03:40:15.759754 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [P.], seq 47:60, ack 157, win 457, options [nop,nop,TS val 47080435 ecr 140346967], length 13
03:40:16.300519 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.51218: Flags [.], ack 60, win 46, options [nop,nop,TS val 140347111 ecr 47080435], length 0
03:40:16.339579 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.51218: Flags [P.], seq 157:263, ack 60, win 46, options [nop,nop,TS val 140347111 ecr 47080435], length 106
03:40:16.340742 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [P.], seq 60:66, ack 263, win 457, options [nop,nop,TS val 47080581 ecr 140347111], length 6
03:40:16.941302 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.51218: Flags [P.], seq 263:324, ack 66, win 46, options [nop,nop,TS val 140347268 ecr 47080581], length 61
03:40:16.941635 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47080731 ecr 140347268], length 1368
03:40:16.941686 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [P.], seq 1434:2113, ack 324, win 457, options [nop,nop,TS val 47080731 ecr 140347268], length 679
03:40:16.941731 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [.], seq 2113:3481, ack 324, win 457, options [nop,nop,TS val 47080731 ecr 140347268], length 1368
03:40:16.941995 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [.], seq 3481:4849, ack 324, win 457, options [nop,nop,TS val 47080731 ecr 140347268], length 1368
03:40:18.168057 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.51218: Flags [P.], seq 263:324, ack 66, win 46, options [nop,nop,TS val 140347601 ecr 47080581], length 61
03:40:18.168130 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [.], ack 324, win 457, options [nop,nop,TS val 47081037 ecr 140347601,nop,nop,sack 1 {263:324}], length 0
03:40:18.388264 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.51218: Flags [.], ack 66, win 46, options [nop,nop,TS val 140347656 ecr 47080581,nop,nop,sack 1 {108444702:108445381}], length 0
03:40:18.544109 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47081132 ecr 140347656], length 1368
03:40:21.752110 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47081934 ecr 140347656], length 1368
03:40:28.160112 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47083536 ecr 140347656], length 1368
03:40:40.992116 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47086744 ecr 140347656], length 1368
03:40:46.942740 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [FP.], seq 4849:5371, ack 324, win 457, options [nop,nop,TS val 47088231 ecr 140347656], length 522
03:40:48.745614 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [S], seq 185692436, win 14600, options [mss 1460,sackOK,TS val 47088682 ecr 0,nop,wscale 5], length 0
03:40:48.745939 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.51218: Flags [.], ack 66, win 46, options [nop,nop,TS val 140355243 ecr 47080581,nop,nop,sack 2 {108448117:108448640}{108444702:108445381}], length 0
03:40:48.863069 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52196: Flags [S.], seq 3936843225, ack 185692437, win 5792, options [mss 1380,sackOK,TS val 140355273 ecr 47088682,nop,wscale 7], length 0
03:40:48.863153 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [.], ack 1, win 457, options [nop,nop,TS val 47088711 ecr 140355273], length 0
03:40:48.973427 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52196: Flags [P.], seq 1:107, ack 1, win 46, options [nop,nop,TS val 140355304 ecr 47088711], length 106
03:40:48.973497 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [.], ack 107, win 457, options [nop,nop,TS val 47088739 ecr 140355304], length 0
03:40:48.973831 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [P.], seq 1:23, ack 107, win 457, options [nop,nop,TS val 47088739 ecr 140355304], length 22
03:40:49.103319 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52196: Flags [.], ack 23, win 46, options [nop,nop,TS val 140355332 ecr 47088739], length 0
03:40:49.104431 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52196: Flags [P.], seq 107:127, ack 23, win 46, options [nop,nop,TS val 140355332 ecr 47088739], length 20
03:40:49.104729 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [P.], seq 23:47, ack 127, win 457, options [nop,nop,TS val 47088772 ecr 140355332], length 24
03:40:49.263060 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52196: Flags [.], ack 47, win 46, options [nop,nop,TS val 140355373 ecr 47088772], length 0
03:40:49.443101 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52196: Flags [P.], seq 127:157, ack 47, win 46, options [nop,nop,TS val 140355420 ecr 47088772], length 30
03:40:49.443438 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [P.], seq 47:60, ack 157, win 457, options [nop,nop,TS val 47088856 ecr 140355420], length 13
03:40:49.553169 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52196: Flags [.], ack 60, win 46, options [nop,nop,TS val 140355447 ecr 47088856], length 0
03:40:49.553943 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52196: Flags [P.], seq 157:263, ack 60, win 46, options [nop,nop,TS val 140355447 ecr 47088856], length 106
03:40:49.554864 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [P.], seq 60:66, ack 263, win 457, options [nop,nop,TS val 47088884 ecr 140355447], length 6
03:40:49.663214 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52196: Flags [P.], seq 263:324, ack 66, win 46, options [nop,nop,TS val 140355475 ecr 47088884], length 61
03:40:49.663616 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47088911 ecr 140355475], length 1368
03:40:49.663751 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [P.], seq 1434:2113, ack 324, win 457, options [nop,nop,TS val 47088911 ecr 140355475], length 679
03:40:49.663820 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [.], seq 2113:3481, ack 324, win 457, options [nop,nop,TS val 47088911 ecr 140355475], length 1368
03:40:49.663883 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [.], seq 3481:4849, ack 324, win 457, options [nop,nop,TS val 47088911 ecr 140355475], length 1368
03:40:49.833205 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52196: Flags [.], ack 66, win 46, options [nop,nop,TS val 140355515 ecr 47088884,nop,nop,sack 1 {1136656415:1136657094}], length 0
03:40:51.120106 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47089276 ecr 140355515], length 1368
03:40:54.040109 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47090006 ecr 140355515], length 1368
03:40:59.872112 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47091464 ecr 140355515], length 1368
03:41:06.624110 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47093152 ecr 140355243], length 1368
03:41:11.552115 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47094384 ecr 140355515], length 1368
03:41:19.664368 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [FP.], seq 4849:5371, ack 324, win 457, options [nop,nop,TS val 47096412 ecr 140355515], length 522
03:41:21.333831 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [S], seq 693658575, win 14600, options [mss 1460,sackOK,TS val 47096829 ecr 0,nop,wscale 5], length 0
03:41:21.352674 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52196: Flags [.], ack 66, win 46, options [nop,nop,TS val 140363396 ecr 47088884,nop,nop,sack 2 {1136659830:1136660353}{1136656415:1136657094}], length 0
03:41:21.453043 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52197: Flags [S.], seq 156904658, ack 693658576, win 5792, options [mss 1380,sackOK,TS val 140363421 ecr 47096829,nop,wscale 7], length 0
03:41:21.453127 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [.], ack 1, win 457, options [nop,nop,TS val 47096859 ecr 140363421], length 0
03:41:21.572897 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52197: Flags [P.], seq 1:107, ack 1, win 46, options [nop,nop,TS val 140363451 ecr 47096859], length 106
03:41:21.572967 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [.], ack 107, win 457, options [nop,nop,TS val 47096889 ecr 140363451], length 0
03:41:21.573318 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [P.], seq 1:23, ack 107, win 457, options [nop,nop,TS val 47096889 ecr 140363451], length 22
03:41:21.702709 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52197: Flags [.], ack 23, win 46, options [nop,nop,TS val 140363483 ecr 47096889], length 0
03:41:21.703423 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52197: Flags [P.], seq 107:127, ack 23, win 46, options [nop,nop,TS val 140363483 ecr 47096889], length 20
03:41:21.703722 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [P.], seq 23:47, ack 127, win 457, options [nop,nop,TS val 47096921 ecr 140363483], length 24
03:41:21.862808 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52197: Flags [.], ack 47, win 46, options [nop,nop,TS val 140363523 ecr 47096921], length 0
03:41:22.062740 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52197: Flags [P.], seq 127:157, ack 47, win 46, options [nop,nop,TS val 140363573 ecr 47096921], length 30
03:41:22.063102 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [P.], seq 47:60, ack 157, win 457, options [nop,nop,TS val 47097011 ecr 140363573], length 13
03:41:22.182911 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52197: Flags [.], ack 60, win 46, options [nop,nop,TS val 140363603 ecr 47097011], length 0
03:41:22.183880 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52197: Flags [P.], seq 157:263, ack 60, win 46, options [nop,nop,TS val 140363603 ecr 47097011], length 106
03:41:22.184818 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [P.], seq 60:66, ack 263, win 457, options [nop,nop,TS val 47097042 ecr 140363603], length 6
03:41:22.302817 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52197: Flags [P.], seq 263:324, ack 66, win 46, options [nop,nop,TS val 140363633 ecr 47097042], length 61
03:41:22.303201 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47097071 ecr 140363633], length 1368
03:41:22.303250 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [P.], seq 1434:2113, ack 324, win 457, options [nop,nop,TS val 47097071 ecr 140363633], length 679
03:41:22.303293 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [.], seq 2113:3481, ack 324, win 457, options [nop,nop,TS val 47097071 ecr 140363633], length 1368
03:41:22.303467 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [.], seq 3481:4849, ack 324, win 457, options [nop,nop,TS val 47097071 ecr 140363633], length 1368
03:41:22.472809 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52197: Flags [.], ack 66, win 46, options [nop,nop,TS val 140363676 ecr 47097042,nop,nop,sack 1 {3773242939:3773243618}], length 0
03:41:23.748109 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47097433 ecr 140363676], length 1368
03:41:26.640110 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47098156 ecr 140363676], length 1368
03:41:32.432107 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47099604 ecr 140363676], length 1368
03:41:34.912108 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47100224 ecr 140363396], length 1368
03:41:44.000113 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47102496 ecr 140363676], length 1368
03:41:52.304227 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [FP.], seq 4849:5371, ack 324, win 457, options [nop,nop,TS val 47104572 ecr 140363676], length 522
03:41:54.123370 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [S], seq 1215827121, win 14600, options [mss 1460,sackOK,TS val 47105026 ecr 0,nop,wscale 5], length 0
03:41:54.132221 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52197: Flags [.], ack 66, win 46, options [nop,nop,TS val 140371591 ecr 47097042,nop,nop,sack 2 {3773246354:3773246877}{3773242939:3773243618}], length 0
03:41:54.242321 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52198: Flags [S.], seq 664320455, ack 1215827122, win 5792, options [mss 1380,sackOK,TS val 140371618 ecr 47105026,nop,wscale 7], length 0
03:41:54.242407 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [.], ack 1, win 457, options [nop,nop,TS val 47105056 ecr 140371618], length 0
03:41:54.372280 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52198: Flags [P.], seq 1:107, ack 1, win 46, options [nop,nop,TS val 140371649 ecr 47105056], length 106
03:41:54.372351 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [.], ack 107, win 457, options [nop,nop,TS val 47105089 ecr 140371649], length 0
03:41:54.372683 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [P.], seq 1:23, ack 107, win 457, options [nop,nop,TS val 47105089 ecr 140371649], length 22
03:41:54.492582 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52198: Flags [.], ack 23, win 46, options [nop,nop,TS val 140371680 ecr 47105089], length 0
03:41:54.493552 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52198: Flags [P.], seq 107:127, ack 23, win 46, options [nop,nop,TS val 140371680 ecr 47105089], length 20
03:41:54.493840 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [P.], seq 23:47, ack 127, win 457, options [nop,nop,TS val 47105119 ecr 140371680], length 24
03:41:54.652325 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52198: Flags [.], ack 47, win 46, options [nop,nop,TS val 140371721 ecr 47105119], length 0
03:41:54.832400 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52198: Flags [P.], seq 127:157, ack 47, win 46, options [nop,nop,TS val 140371767 ecr 47105119], length 30
03:41:54.832738 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [P.], seq 47:60, ack 157, win 457, options [nop,nop,TS val 47105204 ecr 140371767], length 13
03:41:54.952403 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52198: Flags [.], ack 60, win 46, options [nop,nop,TS val 140371796 ecr 47105204], length 0
03:41:54.953236 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52198: Flags [P.], seq 157:263, ack 60, win 46, options [nop,nop,TS val 140371796 ecr 47105204], length 106
03:41:54.954135 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [P.], seq 60:66, ack 263, win 457, options [nop,nop,TS val 47105234 ecr 140371796], length 6
03:41:55.072439 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52198: Flags [P.], seq 263:324, ack 66, win 46, options [nop,nop,TS val 140371826 ecr 47105234], length 61
03:41:55.072935 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47105264 ecr 140371826], length 1368
03:41:55.072986 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [P.], seq 1434:2113, ack 324, win 457, options [nop,nop,TS val 47105264 ecr 140371826], length 679
03:41:55.073028 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [.], seq 2113:3481, ack 324, win 457, options [nop,nop,TS val 47105264 ecr 140371826], length 1368
03:41:55.073074 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [.], seq 3481:4849, ack 324, win 457, options [nop,nop,TS val 47105264 ecr 140371826], length 1368
03:41:55.242762 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52198: Flags [.], ack 66, win 46, options [nop,nop,TS val 140371868 ecr 47105234,nop,nop,sack 1 {3715427543:3715428222}], length 0
03:41:56.524109 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47105627 ecr 140371868], length 1368
03:41:57.952132 IP venus.markhobley.yi.org.51218 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47105984 ecr 140355243], length 1368
03:41:59.424110 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47106352 ecr 140371868], length 1368
03:42:05.232112 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47107804 ecr 140371868], length 1368
03:42:07.168110 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47108288 ecr 140371591], length 1368
03:42:16.832117 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47110704 ecr 140371868], length 1368
03:42:21.632113 IP venus.markhobley.yi.org.52196 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47111904 ecr 140363396], length 1368
03:42:25.093656 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [FP.], seq 4849:5371, ack 324, win 457, options [nop,nop,TS val 47112769 ecr 140371868], length 522
03:42:26.863526 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [S], seq 1725633662, win 14600, options [mss 1460,sackOK,TS val 47113211 ecr 0,nop,wscale 5], length 0
03:42:26.872096 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52198: Flags [.], ack 66, win 46, options [nop,nop,TS val 140379776 ecr 47105234,nop,nop,sack 2 {3715430958:3715431481}{3715427543:3715428222}], length 0
03:42:26.982276 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52199: Flags [S.], seq 1178329563, ack 1725633663, win 5792, options [mss 1380,sackOK,TS val 140379803 ecr 47113211,nop,wscale 7], length 0
03:42:26.982362 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [.], ack 1, win 457, options [nop,nop,TS val 47113241 ecr 140379803], length 0
03:42:27.102306 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52199: Flags [P.], seq 1:107, ack 1, win 46, options [nop,nop,TS val 140379834 ecr 47113241], length 106
03:42:27.102379 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [.], ack 107, win 457, options [nop,nop,TS val 47113271 ecr 140379834], length 0
03:42:27.102731 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [P.], seq 1:23, ack 107, win 457, options [nop,nop,TS val 47113271 ecr 140379834], length 22
03:42:27.232157 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52199: Flags [.], ack 23, win 46, options [nop,nop,TS val 140379866 ecr 47113271], length 0
03:42:27.232883 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52199: Flags [P.], seq 107:127, ack 23, win 46, options [nop,nop,TS val 140379866 ecr 47113271], length 20
03:42:27.233161 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [P.], seq 23:47, ack 127, win 457, options [nop,nop,TS val 47113304 ecr 140379866], length 24
03:42:27.402170 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52199: Flags [.], ack 47, win 46, options [nop,nop,TS val 140379911 ecr 47113304], length 0
03:42:27.612972 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52199: Flags [P.], seq 127:157, ack 47, win 46, options [nop,nop,TS val 140379962 ecr 47113304], length 30
03:42:27.613330 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [P.], seq 47:60, ack 157, win 457, options [nop,nop,TS val 47113399 ecr 140379962], length 13
03:42:27.732360 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52199: Flags [.], ack 60, win 46, options [nop,nop,TS val 140379991 ecr 47113399], length 0
03:42:27.733341 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52199: Flags [P.], seq 157:263, ack 60, win 46, options [nop,nop,TS val 140379991 ecr 47113399], length 106
03:42:27.734237 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [P.], seq 60:66, ack 263, win 457, options [nop,nop,TS val 47113429 ecr 140379991], length 6
03:42:27.842217 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52199: Flags [P.], seq 263:324, ack 66, win 46, options [nop,nop,TS val 140380020 ecr 47113429], length 61
03:42:27.842599 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47113456 ecr 140380020], length 1368
03:42:27.842626 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [P.], seq 1434:2113, ack 324, win 457, options [nop,nop,TS val 47113456 ecr 140380020], length 679
03:42:27.842652 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [.], seq 2113:3481, ack 324, win 457, options [nop,nop,TS val 47113456 ecr 140380020], length 1368
03:42:27.842687 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [.], seq 3481:4849, ack 324, win 457, options [nop,nop,TS val 47113456 ecr 140380020], length 1368
03:42:28.012253 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52199: Flags [.], ack 66, win 46, options [nop,nop,TS val 140380062 ecr 47113429,nop,nop,sack 1 {2477460020:2477460699}], length 0
03:42:29.292107 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47113819 ecr 140380062], length 1368
03:42:32.192137 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47114544 ecr 140380062], length 1368
03:42:38.000125 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47115996 ecr 140380062], length 1368
03:42:40.064116 IP venus.markhobley.yi.org.52198 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47116512 ecr 140379776], length 1368
03:42:49.600135 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47118896 ecr 140380062], length 1368
03:42:50.439130 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.51218: Flags [R], seq 4178125634, win 0, length 0
03:42:53.504132 IP venus.markhobley.yi.org.52197 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47119872 ecr 140371591], length 1368
03:42:57.843979 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [FP.], seq 4849:5371, ack 324, win 457, options [nop,nop,TS val 47120956 ecr 140380062], length 522
03:42:59.663041 IP venus.markhobley.yi.org.52200 > news.eternal-september.org.nntp: Flags [S], seq 2233139354, win 14600, options [mss 1460,sackOK,TS val 47121411 ecr 0,nop,wscale 5], length 0
03:42:59.663736 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52199: Flags [.], ack 66, win 46, options [nop,nop,TS val 140387975 ecr 47113429,nop,nop,sack 2 {2477463435:2477463958}{2477460020:2477460699}], length 0
03:42:59.770427 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52200: Flags [S.], seq 1693600159, ack 2233139355, win 5792, options [mss 1380,sackOK,TS val 140388003 ecr 47121411,nop,wscale 7], length 0
03:42:59.770510 IP venus.markhobley.yi.org.52200 > news.eternal-september.org.nntp: Flags [.], ack 1, win 457, options [nop,nop,TS val 47121438 ecr 140388003], length 0
03:42:59.880540 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52200: Flags [P.], seq 1:48, ack 1, win 46, options [nop,nop,TS val 140388031 ecr 47121438], length 47
03:42:59.880612 IP venus.markhobley.yi.org.52200 > news.eternal-september.org.nntp: Flags [.], ack 48, win 457, options [nop,nop,TS val 47121466 ecr 140388031], length 0
03:42:59.880857 IP venus.markhobley.yi.org.52200 > news.eternal-september.org.nntp: Flags [F.], seq 1, ack 48, win 457, options [nop,nop,TS val 47121466 ecr 140388031], length 0
03:42:59.881260 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52200: Flags [F.], seq 48, ack 1, win 46, options [nop,nop,TS val 140388031 ecr 47121438], length 0
03:42:59.881282 IP venus.markhobley.yi.org.52200 > news.eternal-september.org.nntp: Flags [.], ack 49, win 457, options [nop,nop,TS val 47121466 ecr 140388031], length 0
03:42:59.990509 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52200: Flags [.], ack 2, win 46, options [nop,nop,TS val 140388058 ecr 47121466], length 0
03:43:04.320740 IP venus.markhobley.yi.org.52201 > news.eternal-september.org.nntp: Flags [S], seq 2304145392, win 14600, options [mss 1460,sackOK,TS val 47122576 ecr 0,nop,wscale 5], length 0
03:43:04.500693 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52201: Flags [S.], seq 1766167236, ack 2304145393, win 5792, options [mss 1380,sackOK,TS val 140389170 ecr 47122576,nop,wscale 7], length 0
03:43:04.500777 IP venus.markhobley.yi.org.52201 > news.eternal-september.org.nntp: Flags [.], ack 1, win 457, options [nop,nop,TS val 47122621 ecr 140389170], length 0
03:43:04.680475 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52201: Flags [P.], seq 1:48, ack 1, win 46, options [nop,nop,TS val 140389215 ecr 47122621], length 47
03:43:04.680550 IP venus.markhobley.yi.org.52201 > news.eternal-september.org.nntp: Flags [.], ack 48, win 457, options [nop,nop,TS val 47122666 ecr 140389215], length 0
03:43:04.680953 IP venus.markhobley.yi.org.52201 > news.eternal-september.org.nntp: Flags [F.], seq 1, ack 48, win 457, options [nop,nop,TS val 47122666 ecr 140389215], length 0
03:43:04.700317 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52201: Flags [F.], seq 48, ack 1, win 46, options [nop,nop,TS val 140389215 ecr 47122621], length 0
03:43:04.700381 IP venus.markhobley.yi.org.52201 > news.eternal-september.org.nntp: Flags [.], ack 49, win 457, options [nop,nop,TS val 47122671 ecr 140389215], length 0
03:43:04.860278 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52201: Flags [.], ack 2, win 46, options [nop,nop,TS val 140389261 ecr 47122666], length 0
03:43:11.182591 IP venus.markhobley.yi.org.52202 > news.eternal-september.org.nntp: Flags [S], seq 2424765077, win 14600, options [mss 1460,sackOK,TS val 47124291 ecr 0,nop,wscale 5], length 0
03:43:11.752242 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52202: Flags [S.], seq 1875583976, ack 2424765078, win 5792, options [mss 1380,sackOK,TS val 140390973 ecr 47124291,nop,wscale 7], length 0
03:43:11.752329 IP venus.markhobley.yi.org.52202 > news.eternal-september.org.nntp: Flags [.], ack 1, win 457, options [nop,nop,TS val 47124434 ecr 140390973], length 0
03:43:12.302119 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52202: Flags [P.], seq 1:48, ack 1, win 46, options [nop,nop,TS val 140391105 ecr 47124434], length 47
03:43:12.302192 IP venus.markhobley.yi.org.52202 > news.eternal-september.org.nntp: Flags [.], ack 48, win 457, options [nop,nop,TS val 47124571 ecr 140391105], length 0
03:43:12.302435 IP venus.markhobley.yi.org.52202 > news.eternal-september.org.nntp: Flags [F.], seq 1, ack 48, win 457, options [nop,nop,TS val 47124571 ecr 140391105], length 0
03:43:12.342004 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52202: Flags [F.], seq 48, ack 1, win 46, options [nop,nop,TS val 140391105 ecr 47124434], length 0
03:43:12.342072 IP venus.markhobley.yi.org.52202 > news.eternal-september.org.nntp: Flags [.], ack 49, win 457, options [nop,nop,TS val 47124581 ecr 140391105], length 0
03:43:12.832110 IP venus.markhobley.yi.org.52199 > news.eternal-september.org.nntp: Flags [.], seq 66:1434, ack 324, win 457, options [nop,nop,TS val 47124704 ecr 140387975], length 1368
03:43:13.072128 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52202: Flags [.], ack 2, win 46, options [nop,nop,TS val 140391306 ecr 47124571], length 0
03:43:14.812402 IP venus.markhobley.yi.org.52203 > news.eternal-september.org.nntp: Flags [S], seq 2475930012, win 14600, options [mss 1460,sackOK,TS val 47125199 ecr 0,nop,wscale 5], length 0
03:43:15.343213 IP news.eternal-september.org.nntp > venus.markhobley.yi.org.52203: Flags [S.], seq 1926348286, ack 2475930013, win 5792, options [mss 1380,sackOK,TS val 140391873 ecr 47125199,nop,wscale 7], length 0
03:43:15.343299 IP venus.markhobley.yi.org.52203 > news.eternal-september.org.nntp: Flags [.], ack 1, win 457, options [nop,nop,TS val 47125331 ecr 140391873], length 0

I am no expert on breaking the above report down, so I need to read back
through some archives, so I can get my head around the above report. 
However, examining the binary version of the above file for strings, I can
see that fragments of the usenet data are being retransmitted.

What has happened here?

If I disable PMTUD with following command, then usenet works fine (Hence my
theory that the problem is related to packet maximum segment size that
my ISP can convey downstream).

Thanks in advance to anyone who can shine any light on this.

Mark.

-- 
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

[toc] | [next] | [standalone]

#277

From	"David W. Hodgins" <dwhodgins@nomail.afraid.org>
Date	2011-05-21 15:16 -0400
Message-ID	<op.vvuig0j4a3w0dxdave@hodgins.homeip.net>
In reply to	#276

On Sat, 21 May 2011 10:58:32 -0400, Mark Hobley <markhobley@yahoo.donottypethisbit.co> wrote:

> However, examining the binary version of the above file for strings, I can
> see that fragments of the usenet data are being retransmitted.

Most likely the isp, or an isp in between your system and e-s is giving
nntp traffic a low priority, causing packets to timeout.

I had the same problem when my isp's upstream (bell.ca) did the same thing.

To avoid the problems caused by the traffic shaping, use an ssl connection.
I use leafnode, which doesn't suppport ssl, so I'm using stunnel.

Install stunnel.  On my Mandriva/Mageia system, I have ...

# grep stunnel /etc/rc.d/rc.local
/usr/bin/stunnel /etc/ssl/stunnel/stunnel.conf & # Setup ssl for fetchnews

# cat /etc/ssl/stunnel/stunnel.conf
debug=info
foreground=no
syslog=no
compression=rle
[nntps]
client=yes
connect=news.eternal-september.org:563
accept=564

Then change the newsreader to use localhost, port 564.

If your newsreader supports ssl, use port 563 directly to e-s.

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

[toc] | [prev] | [next] | [standalone]

#280

From	Jorgen Grahn <grahn+nntp@snipabacken.se>
Date	2011-05-21 22:02 +0000
Message-ID	<slrnitgdjk.gtj.grahn+nntp@frailea.sa.invalid>
In reply to	#277

On Sat, 2011-05-21, David W. Hodgins wrote:
> On Sat, 21 May 2011 10:58:32 -0400, Mark Hobley <markhobley@yahoo.donottypethisbit.co> wrote:
>
>> However, examining the binary version of the above file for strings, I can
>> see that fragments of the usenet data are being retransmitted.
>
> Most likely the isp, or an isp in between your system and e-s is giving
> nntp traffic a low priority, causing packets to timeout.

Why should that affect /all/ his large segments, and /only/ the large
segments? It seems very unlikely to me.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#292

From	Tauno Voipio <tauno.voipio@notused.fi.invalid>
Date	2011-05-22 19:59 +0300
Message-ID	<irbfd3$s1n$1@dont-email.me>
In reply to	#280

On 22.5.11 1:02 , Jorgen Grahn wrote:
> On Sat, 2011-05-21, David W. Hodgins wrote:
>> On Sat, 21 May 2011 10:58:32 -0400, Mark Hobley<markhobley@yahoo.donottypethisbit.co>  wrote:
>>
>>> However, examining the binary version of the above file for strings, I can
>>> see that fragments of the usenet data are being retransmitted.
>>
>> Most likely the isp, or an isp in between your system and e-s is giving
>> nntp traffic a low priority, causing packets to timeout.
>
> Why should that affect /all/ his large segments, and /only/ the large
> segments? It seems very unlikely to me.
>
> /Jorgen
>

For me, this smells that someone under way has firewalled
the ICMP messages needed for MSS discovery.

-- 

Tauno Voipio

[toc] | [prev] | [next] | [standalone]

#293

From	Mark Hobley <markhobley@yahoo.donottypethisbit.co>
Date	2011-05-22 17:09 +0000
Message-ID	<irbg0d$h79$3@dont-email.me>
In reply to	#292

On Sun, 22 May 2011 19:59:15 +0300, Tauno Voipio wrote:

> For me, this smells that someone under way has firewalled the ICMP
> messages needed for MSS discovery.

Yeah. I think they have. That is why I have to set this value manually.

Mark.

-- 
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

[toc] | [prev] | [next] | [standalone]

#278

From	Mark Hobley <markhobley@yahoo.donottypethisbit.co>
Date	2011-05-21 20:20 +0000
Message-ID	<ir96q3$565$1@dont-email.me>
In reply to	#276

On Sat, 21 May 2011 14:58:32 +0000, Mark Hobley wrote:

> 18: Flags [S.], seq 3385954279, ack 3902988975, win 5792, options [mss
> 1380,sackOK,TS val 140346418 ecr 47079743,nop,wscale 7], length 0

I'm not sure what this first line is, but win 5792 is bigger than any
datagram that my ISP can carry.

> 03:40:48.745614 IP venus.markhobley.yi.org.52196 >
> news.eternal-september.org.nntp: Flags [S], seq 185692436, win 14600,
> options [mss 1460,sackOK,TS val 47088682 ecr 0,nop,wscale 5], length 0

The value of win 14600 here is presumably the number of bytes of data that
venus is prepared to receive in a single instance. Is that right? Presumably
that is just data, and excludes headers. Is that right? It is bigger than
any datagram that my ISP can carry. Does it have any effect on datagram
sizes?

> news.eternal-september.org.nntp > venus.markhobley.yi.org.52196: Flags
> [S.], seq 3936843225, ack 185692437, win 5792, options [mss
> 1380,sackOK,TS val 140355273 ecr 47088682,nop,wscale 7], length 0

Here I receive a window size. Presumably, that is the size that the remote
host at eternal-september is prepared to accept. Again, I would never be
able to deliver that many bytes in a single datagram.

> 03:41:21.453043 IP news.eternal-september.org.nntp >
> venus.markhobley.yi.org.52197: Flags [S.], seq 156904658, ack 693658576,
> win 5792, options [mss 1380,sackOK,TS val 140363421 ecr
> 47096829,nop,wscale 7], length 0 03:41:21.453127 IP

Here is another big window. I don't know whether that means anything.

> 03:41:54.123370 IP venus.markhobley.yi.org.52198 >
> news.eternal-september.org.nntp: Flags [S], seq 1215827121, win 14600,
> options [mss 1460,sackOK,TS val 47105026 ecr 0,nop,wscale 5], length 0

Another big window.

> news.eternal-september.org.nntp: Flags [S], seq 1725633662, win 14600,
> options [mss 1460,sackOK,TS val 47113211 ecr 0,nop,wscale 5], length 0

and another

> 03:42:26.982276 IP news.eternal-september.org.nntp >
> venus.markhobley.yi.org.52199: Flags [S.], seq 1178329563, ack
> 1725633663, win 5792, options [mss 1380,sackOK,TS val 140379803 ecr
> 47113211,nop,wscale 7], length 0 03:42:26.982362 IP
> 03:42:50.439130 IP news.eternal-september.org.nntp >
> venus.markhobley.yi.org.51218: Flags [R], seq 4178125634, win 0, length
> 0

Hmmm, a window of zero here. Presumably, the remote is busy.

> 03:42:59.663041 IP venus.markhobley.yi.org.52200 >
> news.eternal-september.org.nntp: Flags [S], seq 2233139354, win 14600,
> options [mss 1460,sackOK,TS val 47121411 ecr 0,nop,wscale 5], length 0

A big window.

> 03:42:59.770427 IP news.eternal-september.org.nntp >
> venus.markhobley.yi.org.52200: Flags [S.], seq 1693600159, ack
> 2233139355, win 5792, options [mss 1380,sackOK,TS val 140388003 ecr
> 47121411,nop,wscale 7], length 0 03:42:59.770510 IP

And another

03:43:04.320740 IP venus.markhobley.yi.org.52201 >
> news.eternal-september.org.nntp: Flags [S], seq 2304145392, win 14600,
> options [mss 1460,sackOK,TS val 47122576 ecr 0,nop,wscale 5], length 0

A big window again. Hey look at the mss value! That looks big to me.
My ISP cannot carry a datagram above 1412 bytes.

> 03:43:04.500693 IP news.eternal-september.org.nntp >
> venus.markhobley.yi.org.52201: Flags [S.], seq 1766167236, ack
> 2304145393, win 5792, options [mss 1380,sackOK,TS val 140389170 ecr
> 47122576,nop,wscale 7], length 0

A big window.

> 03:43:11.752242 IP news.eternal-september.org.nntp >
> venus.markhobley.yi.org.52202: Flags [S.], seq 1875583976, ack
> 2424765078, win 5792, options [mss 1380,sackOK,TS val 140390973 ecr
> 47124291,nop,wscale 7], length 0

Another big window

> 03:43:14.812402 IP venus.markhobley.yi.org.52203 >
> news.eternal-september.org.nntp: Flags [S], seq 2475930012, win 14600,
> options [mss 1460,sackOK,TS val 47125199 ecr 0,nop,wscale 5], length 0

There is that big maximum segment size again!

Mark.

-- 
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

[toc] | [prev] | [next] | [standalone]

#279

From	Richard Kettlewell <rjk@greenend.org.uk>
Date	2011-05-21 22:47 +0100
Message-ID	<87aaefvi8l.fsf@araminta.anjou.terraraq.org.uk>
In reply to	#278

Mark Hobley <markhobley@yahoo.donottypethisbit.co> writes:
> On Sat, 21 May 2011 14:58:32 +0000, Mark Hobley wrote:

>> 18: Flags [S.], seq 3385954279, ack 3902988975, win 5792, options [mss
>> 1380,sackOK,TS val 140346418 ecr 47079743,nop,wscale 7], length 0
>
> I'm not sure what this first line is, but win 5792 is bigger than any
> datagram that my ISP can carry.
>
>> 03:40:48.745614 IP venus.markhobley.yi.org.52196 >
>> news.eternal-september.org.nntp: Flags [S], seq 185692436, win 14600,
>> options [mss 1460,sackOK,TS val 47088682 ecr 0,nop,wscale 5], length 0
>
> The value of win 14600 here is presumably the number of bytes of data
> that venus is prepared to receive in a single instance. Is that right?
> Presumably that is just data, and excludes headers. Is that right? It
> is bigger than any datagram that my ISP can carry. Does it have any
> effect on datagram sizes?

Yes, it's the number of bytes the sender is able to accept.  It's not
connected to packet sizes.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#281

From	Jorgen Grahn <grahn+nntp@snipabacken.se>
Date	2011-05-21 22:28 +0000
Message-ID	<slrnitgf58.gtj.grahn+nntp@frailea.sa.invalid>
In reply to	#278

["Followup-To:" header set to comp.protocols.tcp-ip. You should have
mentioned that you started crossposting.]

On Sat, 2011-05-21, Mark Hobley wrote:
> On Sat, 21 May 2011 14:58:32 +0000, Mark Hobley wrote:
...
>> 03:40:48.745614 IP venus.markhobley.yi.org.52196 >
>> news.eternal-september.org.nntp: Flags [S], seq 185692436, win 14600,
>> options [mss 1460,sackOK,TS val 47088682 ecr 0,nop,wscale 5], length 0
>
> The value of win 14600 here is presumably the number of bytes of data that
> venus is prepared to receive in a single instance. Is that right? Presumably
> that is just data, and excludes headers. Is that right? It is bigger than
> any datagram that my ISP can carry. Does it have any effect on datagram
> sizes?

No.

...
> 03:43:04.320740 IP venus.markhobley.yi.org.52201 >
>> news.eternal-september.org.nntp: Flags [S], seq 2304145392, win 14600,
>> options [mss 1460,sackOK,TS val 47122576 ecr 0,nop,wscale 5], length 0
>
> A big window again. Hey look at the mss value! That looks big to me.
> My ISP cannot carry a datagram above 1412 bytes.

1460 looks perfectly normal to me; it's the mss for a normal Ethernet.
n.e-s.o cannot know that your ISP is weird.  As far as I can tell
you're not using Path MTU discovery, so you're relying on the routers
on the way handling IP fragmentation correctly. Which they must.

Perhaps you should have captured ICMP messages too, in case there are
any which are relevant.

...

I've looked some at your tcpdump.  It's a bit confusing because it
contains multiple sessions -- n.e-s.org times out and forces your
client to reconnect a few times.

Anyway, I don't see anything really strange, apart from the fact that
large segments from you (at least 1368 and upwards) don't get through.
You send a bunch of them and resend them, but the server never ACKs
any of them.  For example in this part (abbreviated for clarity):

1:55.072935 IP C > S: Flags [.], seq 66:1434, ack 324, win 457, length 1368
1:55.072986 IP C > S: Flags [P.], seq 1434:2113, ack 324, win 457, length 679
1:55.073028 IP C > S: Flags [.], seq 2113:3481, ack 324, win 457, length 1368
1:55.073074 IP C > S: Flags [.], seq 3481:4849, ack 324, win 457, length 1368
1:55.242762 IP S > C: Flags [.], ack 66, win 46, length 0
1:56.524109 IP C > S: Flags [.], seq 66:1434, ack 324, win 457, length 1368
1:59.424110 IP C > S: Flags [.], seq 66:1434, ack 324, win 457, length 1368
2:05.232112 IP C > S: Flags [.], seq 66:1434, ack 324, win 457, length 1368
2:16.832117 IP C > S: Flags [.], seq 66:1434, ack 324, win 457, length 1368

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#282

From	Mark Hobley <markhobley@yahoo.donottypethisbit.co>
Date	2011-05-22 01:15 +0000
Message-ID	<ir9o2p$rcu$1@dont-email.me>
In reply to	#281

On Sat, 21 May 2011 22:28:56 +0000, Jorgen Grahn wrote:

> 1460 looks perfectly normal to me; it's the mss for a normal Ethernet.

Yeah, but I am not connected via ethernet (well, I am, but only as far as
the external gateway), the router uses a wireless broadband and it cannot
route ethernet frames, because they are too large.

> n.e-s.o cannot know that your ISP is weird.
I don't know what that means. I tell the routing table that my maximum
transmission unit is 1412. Shouldn't the value provided in the mss field
be less than the routable mtu?

ip route change default via 10.0.0.1 mtu lock 1412 

>  As far as I can tell you're not using Path MTU discovery

I have PMTUD enabled in the kernel:

cat /proc/sys/net/ipv4/ip_no_pmtu_disc
0

However, there is a problem with routers downsteam, so I have to lock the
maximum transmission unit value to 1412, which is the highest value that
downstream can handle.

> Perhaps you should have captured ICMP messages too, in case there are
> any which are relevant.

I don't think that I get any ICMP messages when the system fails, but I will
try and do some retesting to see if I can capture any.

> I've looked some at your tcpdump.  It's a bit confusing because it
> contains multiple sessions -- n.e-s.org times out and forces your client
> to reconnect a few times.

Yeah, I don't know what is happening there. This is the pan newsreader. I
have configured it to have a connection limit of 1 connection, to try and
cut down the confusion from multiple sessions, but hey, it is still
confusing. I guess that as the connection fails, pan retries whilst the
datagrams are still going to and fro causing that chaos.

> Anyway, I don't see anything really strange, apart from the fact that
> large segments from you (at least 1368 and upwards) don't get through.

Yeah, I cannot route the large segments over mobile broadband. A smaller
segment size is needed for outbound traffic going via the default gateway
at 10.0.0.1

> You send a bunch of them and resend them, but the server never ACKs any
> of them.  For example in this part (abbreviated for clarity):

Hmmm, maybe I need to trim the MTU value further.

There is something weird going on.

Back in September:

echo 0 > /proc/sys/net/ipv4/ip_no_pmtu_disc 

ping -s 1384 www.yahoo.com
PING any-fp.wa1.b.yahoo.com (67.195.160.76) 1384(1412) bytes of data.
1392 bytes from ir1.fp.vip.ac4.yahoo.com (67.195.160.76): icmp_seq=2 ttl=45 time=305 ms 

1384 was the maximum value that gave a reply.

Today:

ping -s 1384 news.eternal-september.org  
PING news.eternal-september.org (88.198.244.100) 1384(1412) bytes of data.
1392 bytes from news.eternal-september.org (88.198.244.100): icmp_req=1 ttl=50 time=1132 ms
1392 bytes from news.eternal-september.org (88.198.244.100): icmp_req=2 ttl=50 time=236 ms

ping -s 1386 news.eternal-september.org
(No reply)

However:

ping -s 1386 www.yahoo.com              
PING any-fp.wa1.b.yahoo.com (67.195.160.76) 1386(1414) bytes of data.
1394 bytes from ir1.fp.vip.ac4.yahoo.com (67.195.160.76): icmp_req=1 ttl=47 time=1158 ms
1394 bytes from ir1.fp.vip.ac4.yahoo.com (67.195.160.76): icmp_req=2 ttl=47 time=300 ms

Huh! I get a reply. That never used to happen.

I can go right up to 1472:

ping -s 1472 www.yahoo.com 
PING any-fp.wa1.b.yahoo.com (67.195.160.76) 1472(1500) bytes of data.
1480 bytes from ir1.fp.vip.ac4.yahoo.com (67.195.160.76): icmp_req=1 ttl=47 time=462 ms
1480 bytes from ir1.fp.vip.ac4.yahoo.com (67.195.160.76): icmp_req=2 ttl=47 time=453 ms

Now that is suspicious. Either a downstream ISP has done some upgrades
since September, or firmware updates to my router have enabled me to route
larger packets.

I think its something that ISPs are doing, because the maximum for my
news provider is still 1384.

I will mention my router, just in case it matters. It is an Edimax 3g-6200n
and I am using the latest firmware (version 2.24g). The firmware is Linux
based and open source, but it does not provide shell access. On the back of
the router is a Three Mobile Broadband dongle made by Huawei, which makes
the connection to the outside world.

Mark.

-- 
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

[toc] | [prev] | [next] | [standalone]

#284

From	Jorgen Grahn <grahn+nntp@snipabacken.se>
Date	2011-05-22 06:01 +0000
Message-ID	<slrnith9la.gtj.grahn+nntp@frailea.sa.invalid>
In reply to	#282

On Sun, 2011-05-22, Mark Hobley wrote:
> On Sat, 21 May 2011 22:28:56 +0000, Jorgen Grahn wrote:
>  
>> 1460 looks perfectly normal to me; it's the mss for a normal Ethernet.
>
> Yeah, but I am not connected via ethernet (well, I am, but only as far as
> the external gateway), the router uses a wireless broadband and it cannot
> route ethernet frames, because they are too large.
>
>> n.e-s.o cannot know that your ISP is weird.
> I don't know what that means. I tell the routing table that my maximum
> transmission unit is 1412. Shouldn't the value provided in the mss field
> be less than the routable mtu?
>
> ip route change default via 10.0.0.1 mtu lock 1412 

Ah, sorry! I assumed you were talking about the /server's/ advertised
mss. Please ignore everything I wrote above.

That points to another bizarre fact: the SYNs from n.e-s.org
advertise a low mss (1380).  But when I connect to it, it tells me:

  win 5792, options [mss 1460,sackOK,TS val ... ecr ...,nop,wscale 7]

This makes me think your ISP (or some equipment of yours) does
something tricky to the packets you're seeing. Like "MSS clamping".

[lots more]

...
> I will mention my router, just in case it matters. It is an Edimax 3g-6200n
> and I am using the latest firmware (version 2.24g). The firmware is Linux
> based and open source, but it does not provide shell access. On the back of
> the router is a Three Mobile Broadband dongle made by Huawei, which makes
> the connection to the outside world.

And then you have GTP tunneling between the routers (SGSN, GGSN) in
the 3G network. These frequently pull stupid stunts, too.

I don't know ... you also seem to say that IP fragmentation doesn't work
for you.  That's so abnormal that perhaps you should debug that first.
It would be easier though if you had tcpdump access to a machine on
the other side -- since something inbetween is obviously messing with
your packets.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#285

From	Mark Hobley <markhobley@yahoo.donottypethisbit.co>
Date	2011-05-22 07:28 +0000
Message-ID	<iradu8$nho$1@dont-email.me>
In reply to	#284

On Sun, 22 May 2011 06:01:14 +0000, Jorgen Grahn wrote:

> And then you have GTP tunneling between the routers (SGSN, GGSN) in the
> 3G network. These frequently pull stupid stunts, too.
> 
> I don't know ... you also seem to say that IP fragmentation doesn't work
> for you.  That's so abnormal that perhaps you should debug that first.

I'm trying :)
What is also weird is that my system has been working with previous kernel
versions. It has only just become broken again.

I'll try dropping another 12 bytes off the ip route command and retest:

ip route change default via 10.0.0.1 mtu lock 1400

Am I right in that the below datagram is wrong, because the mss is 1460,
which is above the value of the mtu in the routing table? Shouldn't the
value of the mtu have been factored in here, and a new mss calculated based
on the mtu?

03:43:04.320740 IP venus.markhobley.yi.org.52201 >
> news.eternal-september.org.nntp: Flags [S], seq 2304145392, win 14600,
> options [mss 1460,sackOK,TS val 47122576 ecr 0,nop,wscale 5], length 0

-- 
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

[toc] | [prev] | [next] | [standalone]

#286

From	Andy Furniss <spam@andyfurniss.entadsl.com>
Date	2011-05-22 11:40 +0100
Message-ID	<irap5q$qnu$1@localhost.localdomain>
In reply to	#285

Mark Hobley wrote:
> On Sun, 22 May 2011 06:01:14 +0000, Jorgen Grahn wrote:
>
>> And then you have GTP tunneling between the routers (SGSN, GGSN) in the
>> 3G network. These frequently pull stupid stunts, too.
>>
>> I don't know ... you also seem to say that IP fragmentation doesn't work
>> for you.  That's so abnormal that perhaps you should debug that first.
>
> I'm trying :)
> What is also weird is that my system has been working with previous kernel
> versions. It has only just become broken again.
>
> I'll try dropping another 12 bytes off the ip route command and retest:
>
> ip route change default via 10.0.0.1 mtu lock 1400
>
> Am I right in that the below datagram is wrong, because the mss is 1460,
> which is above the value of the mtu in the routing table? Shouldn't the
> value of the mtu have been factored in here, and a new mss calculated based
> on the mtu?
>
> 03:43:04.320740 IP venus.markhobley.yi.org.52201>
>> news.eternal-september.org.nntp: Flags [S], seq 2304145392, win 14600,
>> options [mss 1460,sackOK,TS val 47122576 ecr 0,nop,wscale 5], length 0
>

I see the same, but don't know what the behavior should be.
If you set mtu on say eth0 then advertised tcp mss will be affected 
(which in a way is setting mtu plus mru for tcp) - maybe the route 
setting really just does mtu alone, which in a way is what you asked for 
- don't send >1400.

If you want to fix up your wan use iptables mss clamping on the gateway 
if you can.

Using ping to try and work out isp behavior can be misleading - you may 
just be seeing the settings of the server/network you are pinging and 
the pings may get fragged/re-assembled without you knowing.

[toc] | [prev] | [next] | [standalone]

#289

From	Mark Hobley <markhobley@yahoo.donottypethisbit.co>
Date	2011-05-22 12:25 +0000
Message-ID	<iravcl$l49$1@dont-email.me>
In reply to	#286

On Sun, 22 May 2011 11:40:16 +0100, Andy Furniss wrote:

> I see the same, but don't know what the behavior should be. If you set
> mtu on say eth0 then advertised tcp mss will be affected (which in a way
> is setting mtu plus mru for tcp) - maybe the route setting really just
> does mtu alone, which in a way is what you asked for

That would not be very good at all, because it breaks PMTUD. I would
obviously want the MTU to match the route.

> If you want to fix up your wan use iptables mss clamping on the gateway
> if you can.

I had a quick look through the router configuration settings and I could not
see such an option, so I guess that this facility is not provided.

> Using ping to try and work out isp behavior can be misleading - you may
> just be seeing the settings of the server/network you are pinging and
> the pings may get fragged/re-assembled without you knowing.

With PMTUD enabled, the Don't Fragment flag is set though, isn't it? So this 
would mean that we have a single datagram end to end.

Mark.

-- 
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

[toc] | [prev] | [next] | [standalone]

#295

From	Andy Furniss <spam@andyfurniss.entadsl.com>
Date	2011-05-22 20:40 +0100
Message-ID	<irborc$3up$1@localhost.localdomain>
In reply to	#289

Mark Hobley wrote:
> On Sun, 22 May 2011 11:40:16 +0100, Andy Furniss wrote:
>
>> I see the same, but don't know what the behavior should be. If you set
>> mtu on say eth0 then advertised tcp mss will be affected (which in a way
>> is setting mtu plus mru for tcp) - maybe the route setting really just
>> does mtu alone, which in a way is what you asked for
>
> That would not be very good at all, because it breaks PMTUD. I would
> obviously want the MTU to match the route.

It doesn't break PMTUD as such - if someone sends you a larger packet 
with DF set than your ISP can send, then your ISP should send a frag 
needed. The trouble is it may never reach the sender so it's best to 
avoid the situation arising (for tcp) by advertising a smaller mss.

>
>> If you want to fix up your wan use iptables mss clamping on the gateway
>> if you can.
>
> I had a quick look through the router configuration settings and I could not
> see such an option, so I guess that this facility is not provided.

Ahh, I see now you don't have shell access. It may be clamping anyway as 
noted elsewhere. Some routers will clamp to the mtu on the wan/ppp 
connection by default, or maybe your ISP is doing some clamping.

I would see if the test upload works after you set mtu on the machines 
nic rather than the route.

>
>> Using ping to try and work out isp behavior can be misleading - you may
>> just be seeing the settings of the server/network you are pinging and
>> the pings may get fragged/re-assembled without you knowing.
>
> With PMTUD enabled, the Don't Fragment flag is set though, isn't it? So this
> would mean that we have a single datagram end to end.

A quick test on my box shows that df is only set for ping when < mtu.

If the ping is larger it gets fragged and reply is also fragged.

Assuming iputils ping you can force no frag with ping -M do .....

If you have set mtu low with route/on nic  this will just refuse to send 
 > than that, so to test you need to set higher mtu, and of course be 
aware that what you see may just depend on the settings/net of the 
target rather than your ISP.

[toc] | [prev] | [next] | [standalone]

#296

From	Andy Furniss <spam@andyfurniss.entadsl.com>
Date	2011-05-22 20:56 +0100
Message-ID	<irbpp6$48f$1@localhost.localdomain>
In reply to	#295

Andy Furniss wrote:

> I would see if the test upload works after you set mtu on the machines
> nic rather than the route.

Or as I have just tested and found to work for me -
use the advmss parameter with the ip route command.

[toc] | [prev] | [next] | [standalone]

#298

From	Mark Hobley <markhobley@yahoo.donottypethisbit.co>
Date	2011-05-22 22:57 +0000
Message-ID	<irc4d7$avh$1@dont-email.me>
In reply to	#296

On Sun, 22 May 2011 20:56:44 +0100, Andy Furniss wrote:

> Or as I have just tested and found to work for me - use the advmss
> parameter with the ip route command.

Ahhh, right. I just checked the man page and that might be what caused the
problem. On the old version, if advmss was not specified, it used the same
value as mss. On the upgrade, it takes the value from the interface
information in the routing table, which in my case is not the right value,
because I use larger packets on the LAN, than I do for externally bound
traffic.

Mark.

-- 
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

[toc] | [prev] | [next] | [standalone]

#299

From	Mark Hobley <markhobley@yahoo.donottypethisbit.co>
Date	2011-05-22 23:12 +0000
Message-ID	<irc59m$g67$1@dont-email.me>
In reply to	#295

On Sun, 22 May 2011 20:40:50 +0100, Andy Furniss wrote:

> I would see if the test upload works after you set mtu on the machines
> nic rather than the route.

I did that test a while ago. I think it works, if I set it against the nic.
I didn't want to do that though, because it reduces the size of all the LAN
traffic packets.

> A quick test on my box shows that df is only set for ping when < mtu.
> If the ping is larger it gets fragged and reply is also fragged.

Right. I will look at that yahoo test again.

Cheers,

Mark.

-- 
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

[toc] | [prev] | [next] | [standalone]

#287

From	Jorgen Grahn <grahn+nntp@snipabacken.se>
Date	2011-05-22 11:31 +0000
Message-ID	<slrnitht0c.gtj.grahn+nntp@frailea.sa.invalid>
In reply to	#285

On Sun, 2011-05-22, Mark Hobley wrote:
...
> I'll try dropping another 12 bytes off the ip route command and retest:
>
> ip route change default via 10.0.0.1 mtu lock 1400
>
> Am I right in that the below datagram is wrong, because the mss is 1460,
> which is above the value of the mtu in the routing table? Shouldn't the
> value of the mtu have been factored in here, and a new mss calculated based
> on the mtu?
>
> 03:43:04.320740 IP venus.markhobley.yi.org.52201 >
> news.eternal-september.org.nntp: Flags [S], seq 2304145392, win 14600,
> options [mss 1460,sackOK,TS val 47122576 ecr 0,nop,wscale 5], length 0

Yes, that seems wrong too. I have only messed with that once, as an
experiment, but I am pretty sure my TCP stack understood it and set
mss in the SYN accordingly. (I used 'route ... mss N' to do it, not
ip(8), but that shouldn't matter.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#288

From	Mark Hobley <markhobley@yahoo.donottypethisbit.co>
Date	2011-05-22 11:50 +0000
Message-ID	<irat9b$b68$1@dont-email.me>
In reply to	#287

On Sun, 22 May 2011 11:31:25 +0000, Jorgen Grahn wrote:

> On Sun, 2011-05-22, Mark Hobley wrote: ...
>> I'll try dropping another 12 bytes off the ip route command and retest:
>>
>> ip route change default via 10.0.0.1 mtu lock 1400
>>
>> Am I right in that the below datagram is wrong, because the mss is
>> 1460, which is above the value of the mtu in the routing table?
>> Shouldn't the value of the mtu have been factored in here, and a new
>> mss calculated based on the mtu?
>>
>> 03:43:04.320740 IP venus.markhobley.yi.org.52201 >
>> news.eternal-september.org.nntp: Flags [S], seq 2304145392, win 14600,
>> options [mss 1460,sackOK,TS val 47122576 ecr 0,nop,wscale 5], length 0
> 
> Yes, that seems wrong too. I have only messed with that once, as an
> experiment, but I am pretty sure my TCP stack understood it and set mss
> in the SYN accordingly. (I used 'route ... mss N' to do it, not ip(8),
> but that shouldn't matter.)

Hmmm. So if the datagram is wrong, then we have a bug. Presumably this is
a kernel bug, because it has been working for a couple of months before I
upgraded the kernel. Or could it be a library bug? I might have upgraded
some libraries, for the purpose of being able to use the new kernel.

Mark.

-- 
Mark Hobley
Linux User: #370818  http://markhobley.yi.org/

[toc] | [prev] | [next] | [standalone]

#290

From	Jorgen Grahn <grahn+nntp@snipabacken.se>
Date	2011-05-22 12:52 +0000
Message-ID	<slrniti1p9.gtj.grahn+nntp@frailea.sa.invalid>
In reply to	#288

On Sun, 2011-05-22, Mark Hobley wrote:
> On Sun, 22 May 2011 11:31:25 +0000, Jorgen Grahn wrote:
>
>> On Sun, 2011-05-22, Mark Hobley wrote: ...
>>> I'll try dropping another 12 bytes off the ip route command and retest:
>>>
>>> ip route change default via 10.0.0.1 mtu lock 1400
>>>
>>> Am I right in that the below datagram is wrong, because the mss is
>>> 1460, which is above the value of the mtu in the routing table?
>>> Shouldn't the value of the mtu have been factored in here, and a new
>>> mss calculated based on the mtu?
>>>
>>> 03:43:04.320740 IP venus.markhobley.yi.org.52201 >
>>> news.eternal-september.org.nntp: Flags [S], seq 2304145392, win 14600,
>>> options [mss 1460,sackOK,TS val 47122576 ecr 0,nop,wscale 5], length 0
>> 
>> Yes, that seems wrong too. I have only messed with that once, as an
>> experiment, but I am pretty sure my TCP stack understood it and set mss
>> in the SYN accordingly. (I used 'route ... mss N' to do it, not ip(8),
>> but that shouldn't matter.)
>
> Hmmm. So if the datagram is wrong, then we have a bug. Presumably this is
> a kernel bug, because it has been working for a couple of months before I
> upgraded the kernel. Or could it be a library bug? I might have upgraded
> some libraries, for the purpose of being able to use the new kernel.

It seems to me it's more likely that you're doing something wrong --
people would immediately notice if these parts of the Linux kernel
broke! Is it the right route? Are there others?  What does route -ne say?

I also can't help wondering if you have caused all these problems
somehow.  If the ISP breaks things like this, it's commercial suicide
-- unless they somehow manage to keep Windows unaffected ...

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

Page 1 of 2 [1] 2 Next page →

csiph-web

Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

Contents

#276 — Linux 2.6.39-rc7 - Wrong Maximum Segment Size being advertised

#277

#280

#292

#293

#278

#279

#281

#282

#284

#285

#286

#289

#295

#296

#298

#299

#287

#288

#290