Hmmm - probably not MTU related then. That won’t change the effect of a ping 
with the DF bit set. Its only for TCP.

Not sure what the issue could be. Is it packetloss related? Has the DLINK 
decided to be dumb/start to fail?


> On 7/06/2015, at 2:16 pm, steve <[email protected]> wrote:
> 
> 
> 
> On 07/06/15 15:30, Fraser McGlinn wrote:
>> If you do a iptables -L -t mangle -vn and see if you’ve got any rules for 
>> mangling the TCP MSS. If you don’t set the following:
> 
> Doesn't look like it...
> 
> # iptables -L -t mangle -vn
> Chain PREROUTING (policy ACCEPT 259M packets, 168G bytes)
>  pkts bytes target     prot opt in     out     source               
> destination
> 
> Chain INPUT (policy ACCEPT 416K packets, 251M bytes)
>  pkts bytes target     prot opt in     out     source               
> destination
> 
> Chain FORWARD (policy ACCEPT 259M packets, 167G bytes)
>  pkts bytes target     prot opt in     out     source               
> destination
> 
> Chain OUTPUT (policy ACCEPT 228K packets, 88M bytes)
>  pkts bytes target     prot opt in     out     source               
> destination
> 
> Chain POSTROUTING (policy ACCEPT 259M packets, 167G bytes)
>  pkts bytes target     prot opt in     out     source               
> destination
> 
>> 
>> iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ppp0 -j 
>> TCPMSS --set-mss 1400
> Done. I now see
> 
> Chain POSTROUTING (policy ACCEPT 259M packets, 167G bytes)
>  pkts bytes target     prot opt in     out     source               
> destination
>   169 10140 TCPMSS     tcp  --  *      ppp0    0.0.0.0/0            0.0.0.0/0 
>          tcp flags:0x06/0x02 TCPMSS set 1400
> 
>> 
>> This is slightly below the MTU on the link, but it should prove the point of 
>> if this is the problem or not.
> 
> Exited the router and
> 
>  ping -M do 8.8.8.8 -s 1464 from my 'firewall' still returns multiple
> From 10.100.0.1 icmp_seq=1 Frag needed and DF set (mtu = 1460)
> 
> 
> I don't really see any difference from my workstation.
> 
> Does this help?
> 
> 
> Steve
> 
>> 
>> The TL;DR of what TCP MSS is that its setting the ‘Maximum Segment Size’ in 
>> the TCP SYN, and RST SYN packets to tell the remote server what the maximum 
>> TCP payload you can receive back.
>> 
>> Let me know if that helps at all.
>> 
>> 
>>> On 7/06/2015, at 1:01 pm, steve <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>> OK, This tells me it's 1460 bytes I assume... ( it's an old DLink router ).
>>> 
>>> From 10.100.0.1 icmp_seq=1 Frag needed and DF set (mtu = 1460)
>>> ...
>>> 
>>> 
>>> Whereas  locally it's 1500 bytes.
>>> 
>>> If I log on to the router,
>>> 
>>> # ifconfig br0
>>> br0       Link encap:Ethernet  HWaddr 00:1B:11:D3:31:A9
>>>           inet addr:10.100.0.138  Bcast:10.255.255.255  Mask:255.0.0.0
>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1  ASYMMTU:1500
>>>           RX packets:120497052 errors:0 dropped:0 overruns:0 frame:0
>>>           TX packets:139131496 errors:0 dropped:0 overruns:0 carrier:0
>>>           collisions:0 txqueuelen:0
>>>           RX bytes:2397316505 (2286.2 Mb)  TX bytes:1297785614 (1237.6 Mb)
>>> 
>>> # ifconfig ppp0
>>> ppp0      Link encap:Point-Point Protocol
>>>           inet addr:a.b.c.d  P-t-P:a.b.c.254  Mask:255.255.255.255
>>>           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1460  Metric:1  
>>> ASYMMTU:1500
>>>           RX packets:72694426 errors:0 dropped:0 overruns:0 frame:0
>>>           TX packets:46502303 errors:0 dropped:0 overruns:0 carrier:0
>>>           collisions:0 txqueuelen:100
>>>           RX bytes:836829099 (798.0 Mb)  TX bytes:1469766225 (1401.6 Mb)
>>> 
>>> 
>>> So it looks like the ADSL connection has a MTU of 1460b, and nothing seems 
>>> to be reporting any errors.
>>> 
>>> Where to from here? I'm also confused as to why it's changed...
>>> 
>>> 
>>> Steve
>>> 
>>> 
>>> 
>>> On 06/06/15 21:10, Fraser McGlinn wrote:
>>>> Hi Steve,
>>>> 
>>>> Have you checked the MTU and tcp-mss? This smells MTU related.
>>>> 
>>>> Generally speaking most DSL’s should be either 1492 or 1500 bytes. So to 
>>>> check this do the following:
>>>> 
>>>> ping -M do 8.8.8.8 -s 1464 #check if its 1492 bytes
>>>> ping -M do 8.8.8.8 -s 1472 #check if its 1500 bytes
>>>> 
>>>> Remember the size value is the payload size so this excludes the IP header 
>>>> (20 bytes) and ICMP header (8 bytes).
>>>> 
>>>> Cheers,
>>>> 
>>>> Fraser
>>>> 
>>>>> On 6/06/2015, at 3:00 pm, steve <[email protected]> 
>>>>> <mailto:[email protected]> wrote:
>>>>> 
>>>>> Hi folks,
>>>>> 
>>>>> Am nearing wits end... been away on hols for a month and my network 
>>>>> performance has plummeted.
>>>>> 
>>>>> The best way of describing the problem is that you need to refresh a web 
>>>>> page before you get any content. In addition, bulk loading across a VPN ( 
>>>>> eg scp ) fails regularly.
>>>>> 
>>>>> Basic design of network: 'firewall' server runs fail2ban and links 
>>>>> upstream ADSL to local wireless and wired subnets. It also provides DNS ( 
>>>>> caching server ), DHCP, OpenVPN etc services.
>>>>> 
>>>>> I initially thought it was a DNS problem, and have migrated from the 
>>>>> local ( Voda ) DNS servers to OpenDNS, having briefly tried Googles 
>>>>> resolvers on the way. No improvement.
>>>>> 
>>>>> Any thoughts on what I can try to identify the real problem? My thought 
>>>>> is that the GCSB are involved somewhere along the line, but as a SysAdm I 
>>>>> am paid to be paranoid!
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Steve
>>>>> 
>>>>> --
>>>>> Steve Holdoway BSc(Hons) MIITP
>>>>> http://www.greengecko.co.nz <http://www.greengecko.co.nz/>
>>>>> Linkedin: http://www.linkedin.com/in/steveholdoway 
>>>>> <http://www.linkedin.com/in/steveholdoway>
>>>>> Skype: sholdowa
>>>>> 
>>>>> _______________________________________________
>>>>> Linux-users mailing list
>>>>> [email protected] 
>>>>> <mailto:[email protected]>
>>>>> http://lists.canterbury.ac.nz/mailman/listinfo/linux-users 
>>>>> <http://lists.canterbury.ac.nz/mailman/listinfo/linux-users>
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Linux-users mailing list
>>>> [email protected] 
>>>> <mailto:[email protected]>
>>>> http://lists.canterbury.ac.nz/mailman/listinfo/linux-users 
>>>> <http://lists.canterbury.ac.nz/mailman/listinfo/linux-users>
>>> 
>>> --
>>> Steve Holdoway BSc(Hons) MIITP
>>> http://www.greengecko.co.nz <http://www.greengecko.co.nz/>
>>> Linkedin: http://www.linkedin.com/in/steveholdoway 
>>> <http://www.linkedin.com/in/steveholdoway>
>>> Skype: sholdowa
>>> _______________________________________________
>>> Linux-users mailing list
>>> [email protected] 
>>> <mailto:[email protected]>
>>> http://lists.canterbury.ac.nz/mailman/listinfo/linux-users 
>>> <http://lists.canterbury.ac.nz/mailman/listinfo/linux-users>
>> 
>> 
>> 
>> _______________________________________________
>> Linux-users mailing list
>> [email protected] 
>> <mailto:[email protected]>
>> http://lists.canterbury.ac.nz/mailman/listinfo/linux-users 
>> <http://lists.canterbury.ac.nz/mailman/listinfo/linux-users>
> 
> --
> Steve Holdoway BSc(Hons) MIITP
> http://www.greengecko.co.nz <http://www.greengecko.co.nz/>
> Linkedin: http://www.linkedin.com/in/steveholdoway 
> <http://www.linkedin.com/in/steveholdoway>
> Skype: sholdowa
> _______________________________________________
> Linux-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.canterbury.ac.nz/mailman/listinfo/linux-users 
> <http://lists.canterbury.ac.nz/mailman/listinfo/linux-users>

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users

Reply via email to