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]> 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
Linkedin:http://www.linkedin.com/in/steveholdoway
Skype: sholdowa
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
--
Steve Holdoway BSc(Hons) MIITP
http://www.greengecko.co.nz
Linkedin: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
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
--
Steve Holdoway BSc(Hons) MIITP
http://www.greengecko.co.nz
Linkedin: http://www.linkedin.com/in/steveholdoway
Skype: sholdowa
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
