Re: ping packet loss when size gt 1500
Adam Hardy adam@cyberspaceroad.com wrote: What I need is a ping test or something that I can put in smokeping to alert me when I forget, e.g. this morning there was a power outage that took out the modem. I think there are others here making suggestions for that. What do you mean by 'clamped'? Locked to. At the risk of stating the obvious, do take a look at https://blue-labs.org/howto/mtu-mss.php. What I'm not sure about is whether the clamping actually means a maximum value, or whether it would even refuse to allow the MTU to be reduced. I dropped these firewall rules just now and ping -s 1473 mktgw1.ibllc.com loses all packets, so our thread pretty much only concerns the situation when this firewall is down. Possibly. If there's something else blocking ICMP then your firewall ruleset will be masked by that other device. But if you managed to resolve the issue for the remote device your firewall would still get in the way and muddy the results. My actual question is: what would fail to get through when that firewall was up? For my testing purposes. If I've read the ruleset correctly, it drops all ICMP. This includes host-unreachable, port-unreachable, packet-too-big, in addition to the well known echo/response pair (ping). Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/fv28p7xlb4@news.roaima.co.uk
Re: ping packet loss when size gt 1500
Adam Hardy on 19/10/10 23:16, wrote: My version of traceroute also has the --mtu option, which tries to determine the MTU for the route being traced. It looks perhaps like the firewall for interactivebrokers (IP 208.192.181.62) *may* be blocking too many ICMP control message types - including the MTU/Fragment messages. The problem is, it doesn't look good from their point of view. I have a problem but their other 150,000 customers don't. I have a manually configured gateway, iptables firewall and all - their other 150,000 customers use mostly windows, although there are an unknown number of linux users out there - it's a java app. I have so far only a couple of things to go on - communication with their server shows inexplicable MTU behaviour, and there is a weak link on the British Telecom part of the traceroute. All tests on my LAN show that I am running normally though. I've tested my mtu size, my firewall, my DHCP, my DNS (now using OpenDNS). Just remembered that my DSL modem has some dumb iptables firewall with the following rules: Trying 192.168.1.1... Connected to 192.168.1.1. Escape character is '^]'. login: root Password: BusyBox v0.61.pre (2004.06.18-02:49+) Built-in shell (ash) Enter 'help' for a list of built-in commands. # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS set 1460 Chain OUTPUT (policy ACCEPT) target prot opt source destination DROP icmp -- anywhere anywhere icmp destination-unreachable DROP icmp -- anywhere anywhere state INVALID Normally I log in and drop them all but sometimes after a reboot I forget and the mini-firewall remains in place while I'm trying to solve this networking problem. Is there a test I can put in place to test that I remembered to disable this mini-firewall? Thanks Adam -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbeb45e.9030...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
Adam Hardy adam@cyberspaceroad.com wrote: Chain FORWARD (policy ACCEPT) target prot opt source destination TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS set 1460 So you're clamping TCPMSS at 1460? What if the MSS needs to be lower, i.e. your MTU has dropped? (I'm not sure how iptables handles this situation as I don't usually need to fiddle MSS and MTU.) Would you remove this rule and retest, please? Chain OUTPUT (policy ACCEPT) target prot opt source destination DROP icmp -- anywhere anywhere icmp destination-unreachable DROP icmp -- anywhere anywhere state INVALID I'm nervous of these two rules, too. Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ort2p7xl2t@news.roaima.co.uk
Re: ping packet loss when size gt 1500
Chris Davies on 20/10/10 11:45, wrote: Adam Hardy adam@cyberspaceroad.com wrote: Chain FORWARD (policy ACCEPT) target prot opt source destination TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS set 1460 So you're clamping TCPMSS at 1460? What if the MSS needs to be lower, i.e. your MTU has dropped? (I'm not sure how iptables handles this situation as I don't usually need to fiddle MSS and MTU.) Would you remove this rule and retest, please? Chain OUTPUT (policy ACCEPT) target prot opt source destination DROP icmp -- anywhere anywhere icmp destination-unreachable DROP icmp -- anywhere anywhere state INVALID No, no I'm not deliberately doing that. It's the DLink modem that has this mini-firewall set up in its ROM. I can telnet in drop the rules, but I have to remember to do it every power cycle. What I need is a ping test or something that I can put in smokeping to alert me when I forget, e.g. this morning there was a power outage that took out the modem. What do you mean by 'clamped'? I dropped these firewall rules just now and ping -s 1473 mktgw1.ibllc.com loses all packets, so our thread pretty much only concerns the situation when this firewall is down. My actual question is: what would fail to get through when that firewall was up? For my testing purposes. Regards Adam -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbee0fd.4010...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
Chris Davies on 18/10/10 13:15, wrote: Adam Hardy adam@cyberspaceroad.com wrote: I tried lowering the MTU to 1400 but it made no difference. So ping -s 1372 failed? I thought you said it worked up to -s 1472 (packets of 1500 bytes)? When you drop your MTU to 1400, that means that your local data packets are fragmented as necessary to stay within the maximum packet size. If you generate data with a do not fragment (DF) label attached to it, you have to ensure that each packet is no larger than the available size. (All fairly obvious so far, I trust.) If something between you and the destination is eating the Hey you're MTU's too big for this link messages then there's no way of handling overly large packets - as far as the recipient is concerned they have been discarded en route. Remember that although your packets might be the right size, there is (AFAICR) nothing there that limits the size of the packets being returned to you. And if the too big ICMP messages relating to data from the far end back to you are being discarded then the sender can't know it needs to reduce the packet size in order to reach you. So if there is a black hole router between me and the server I'm having problems with, I still haven't identified it. When I said I reduced my MTU, that was just on the one machine that runs the software that communicates so poorly with the server at mktgw1.ibllc.com I did detect a host at hop 5 on the traceroute to the server which was losing packets according to my monitoring programs, but now the traceroute has changed and that server's not on the route. Actually now I'm checking again, it is back. British Telecom are playing around obviously. I have a question about traceroute that might be relevant. I haven't figured out the traceroute options because on lenny, my traceroute doesn't complete. The last hop to mktgw1.ibllc.com doesn't show - it just counts stars up to 30. But on windows it does complete at 23 - where mktgw1.ibllc.com is the last hop / target. Does this betray anything? lenny traceroute (from gateway 192.168.0.2) 1 192.168.1.1 (192.168.1.1) 0.577 ms 1.303 ms 1.282 ms 2 217.32.146.168 (217.32.146.168) 7.520 ms 7.742 ms 8.567 ms 3 217.32.146.222 (217.32.146.222) 10.190 ms 11.197 ms 11.333 ms 4 213.120.177.58 (213.120.177.58) 11.760 ms 12.444 ms 13.441 ms 5 213.120.176.62 (213.120.176.62) 14.376 ms 14.843 ms 15.810 ms 6 213.120.176.182 (213.120.176.182) 16.794 ms 6.072 ms 6.350 ms 7 acc2-10GigE-0-2-0-4.l-far.21cn-ipp.bt.net (109.159.249.225) 7.532 ms acc2-10GigE-0-2-0-5.l-far.21cn-ipp.bt.net (109.159.249.227) 7.672 ms acc2-10GigE-0-0-0-4.l-far.21cn-ipp.bt.net (109.159.249.194) 9.562 ms 8 core2-te0-14-4-0.ealing.ukcore.bt.net (109.159.249.157) 10.984 ms core2-te0-11-5-0.ealing.ukcore.bt.net (109.159.249.141) 11.736 ms core2-te0-14-4-0.ealing.ukcore.bt.net (109.159.249.157) 12.092 ms 9 transit2-xe0-1-0.ealing.ukcore.bt.net (194.72.17.82) 12.067 ms 13.004 ms 13.899 ms 10 t2c2-ge11-0-0.uk-eal.eu.bt.net (166.49.168.61) 14.442 ms 15.320 ms 16.005 ms 11 so-6-0-2.edge1.London2.Level3.net (212.113.11.253) 17.451 ms 17.698 ms 18.323 ms 12 ae-32-52.ebr2.London2.Level3.net (4.68.117.62) 27.142 ms 8.414 ms 19.868 ms 13 ae-3-3.ebr1.London1.Level3.net (4.69.141.189) 8.819 ms 9.165 ms 10.011 ms 14 ae-100-100.ebr2.London1.Level3.net (4.69.141.166) 10.478 ms 11.449 ms 12.280 ms 15 ae-41-41.ebr1.NewYork1.Level3.net (4.69.137.66) 81.797 ms 82.604 ms ae-42-42.ebr1.NewYork1.Level3.net (4.69.137.70) 83.437 ms 16 ae-4-4.ebr1.NewYork2.Level3.net (4.69.141.18) 83.826 ms 84.588 ms 85.464 ms 17 ae-1-51.edge2.NewYork2.Level3.net (4.69.138.195) 86.162 ms 86.585 ms 87.297 ms 18 mci-level3-oc48-washington1.level3.net (4.68.127.22) 95.632 ms mci-level3-xe.newyork2.Level3.net (4.68.110.106) 87.545 ms 0.ge-2-0-0.BR3.NYC4.ALTER.NET (204.255.173.53) 87.854 ms 19 0.ae3.XL4.NYC4.ALTER.NET (152.63.16.186) 88.335 ms 88.235 ms 0.ae2.XL4.NYC4.ALTER.NET (152.63.3.117) 88.418 ms 20 0.so-7-1-0.XL4.BOS4.ALTER.NET (152.63.0.221) 91.572 ms 92.351 ms 0.ge-7-0-0.XL3.BOS4.ALTER.NET (152.63.0.165) 92.589 ms 21 POS7-0-0.GW12.BOS4.ALTER.NET (152.63.22.181) 91.460 ms 91.469 ms POS6-0-0.GW12.BOS4.ALTER.NET (152.63.22.177) 92.245 ms 22 interactivebrokers-gw.customer.alter.net (208.192.181.62) 100.881 ms 101.943 ms 102.812 ms 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * and the windows traceroute: 1 1 ms1 ms1 ms isengard.localdomain [192.168.0.2] 2 4 ms 1 ms 1 ms 192.168.1.1 3 7 ms 7 ms 6 ms 217.32.146.168 4 7 ms 7 ms 7 ms 217.32.146.222 5 9 ms11 ms 9 ms 213.120.177.58 6 7 ms *8 ms 213.120.176.54 7 8 ms 7 ms 8 ms 213.120.176.182 8 7 ms 7 ms 7 ms acc2-10GigE-0-1-0-4.l-far.21cn-ipp.bt.net [109.159.249.198] 9 9 ms 8 ms 8 ms
Re: ping packet loss when size gt 1500
Ron Johnson on 19/10/10 00:25, wrote: On 10/18/2010 04:54 AM, Adam Hardy wrote: [snip] I'm running a windows app to monitor it called 'ping plotter' which charts the ping responses and flags up the packet loss, and one server out there in particular loses 15% of pings: 213.120.176.62 Maybe not as fancy, but I find that mtr is *really* useful. (It's packaged in Debian...) Oooh, good call. Thanks. I'm also looking at smokeping but I haven't put it into action yet. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbd3ca0.3030...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
Ron Johnson on 19/10/10 00:25, wrote: On 10/18/2010 04:54 AM, Adam Hardy wrote: [snip] I'm running a windows app to monitor it called 'ping plotter' which charts the ping responses and flags up the packet loss, and one server out there in particular loses 15% of pings: 213.120.176.62 Maybe not as fancy, but I find that mtr is *really* useful. (It's packaged in Debian...) In xfce I see it's got an icon for the app in the icon box - I can't figure out where that icon is to put it on my menu. It's actually got the letters mtr in the icon so it's obviously for mtr. Sounds like a daft question but where would that icon be? It doesn't appear to have been installed with the package. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbd651a.7020...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
On 10/19/2010 04:30 AM, Adam Hardy wrote: Ron Johnson on 19/10/10 00:25, wrote: On 10/18/2010 04:54 AM, Adam Hardy wrote: [snip] I'm running a windows app to monitor it called 'ping plotter' which charts the ping responses and flags up the packet loss, and one server out there in particular loses 15% of pings: 213.120.176.62 Maybe not as fancy, but I find that mtr is *really* useful. (It's packaged in Debian...) In xfce I see it's got an icon for the app in the icon box Icon box? - I can't figure out where that icon is to put it on my menu. It's actually got the letters mtr in the icon so it's obviously for mtr. Sounds like a daft question but where would that icon be? It doesn't appear to have been installed with the package. Under Networking? (I just install mtr-tiny and run mtr from the cli.) -- Seek truth from facts. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbd851a.6070...@cox.net
Re: ping packet loss when size gt 1500
Ron Johnson on 19/10/10 12:46, wrote: On 10/19/2010 04:30 AM, Adam Hardy wrote: Ron Johnson on 19/10/10 00:25, wrote: On 10/18/2010 04:54 AM, Adam Hardy wrote: [snip] I'm running a windows app to monitor it called 'ping plotter' which charts the ping responses and flags up the packet loss, and one server out there in particular loses 15% of pings: 213.120.176.62 Maybe not as fancy, but I find that mtr is *really* useful. (It's packaged in Debian...) In xfce I see it's got an icon for the app in the icon box Icon box? - I can't figure out where that icon is to put it on my menu. It's actually got the letters mtr in the icon so it's obviously for mtr. Sounds like a daft question but where would that icon be? It doesn't appear to have been installed with the package. Under Networking? (I just install mtr-tiny and run mtr from the cli.) I figured you might be doing that after I hit 'send'. By icon box I mean the desktop manager's running applications box next to the menu (depending on your choice of desktop manager). It must be an xfce thing - although the icon is quite cool, I can't understand why it wasn't in the package if it's not xfce, but it's not where the other xfce icons are. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbd931d.9080...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
Adam Hardy adam@cyberspaceroad.com wrote: I have a question about traceroute that might be relevant. I haven't figured out the traceroute options because on lenny, my traceroute doesn't complete. The last hop to mktgw1.ibllc.com doesn't show - it just counts stars up to 30. But on windows it does complete at 23 - where mktgw1.ibllc.com is the last hop / target. Does this betray anything? Traceroute on Linux and Windows platforms typically use different packet types. IIRC, tracert uses ICMP 8 (ping) whereas traceroute uses UDP. My flavour of traceroute accepts the -I flag to force ICMP 8. My version of traceroute also has the --mtu option, which tries to determine the MTU for the route being traced. It looks perhaps like the firewall for interactivebrokers (IP 208.192.181.62) *may* be blocking too many ICMP control message types - including the MTU/Fragment messages. Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/qqp0p7xul9@news.roaima.co.uk
Re: ping packet loss when size gt 1500
Chris Davies on 19/10/10 16:24, wrote: Adam Hardy adam@cyberspaceroad.com wrote: I have a question about traceroute that might be relevant. I haven't figured out the traceroute options because on lenny, my traceroute doesn't complete. The last hop to mktgw1.ibllc.com doesn't show - it just counts stars up to 30. But on windows it does complete at 23 - where mktgw1.ibllc.com is the last hop / target. Does this betray anything? Traceroute on Linux and Windows platforms typically use different packet types. IIRC, tracert uses ICMP 8 (ping) whereas traceroute uses UDP. My flavour of traceroute accepts the -I flag to force ICMP 8. My version of traceroute also has the --mtu option, which tries to determine the MTU for the route being traced. It looks perhaps like the firewall for interactivebrokers (IP 208.192.181.62) *may* be blocking too many ICMP control message types - including the MTU/Fragment messages. The problem is, it doesn't look good from their point of view. I have a problem but their other 150,000 customers don't. I have a manually configured gateway, iptables firewall and all - their other 150,000 customers use mostly windows, although there are an unknown number of linux users out there - it's a java app. I have so far only a couple of things to go on - communication with their server shows inexplicable MTU behaviour, and there is a weak link on the British Telecom part of the traceroute. All tests on my LAN show that I am running normally though. I've tested my mtu size, my firewall, my DHCP, my DNS (now using OpenDNS). Any ideas where to go from here? Thanks Adam -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbe18c8.4010...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
Chris Davies on 17/10/10 23:08, wrote: Adam Hardy adam@cyberspaceroad.com wrote: Thanks for all the info. I guess it tells me there's nothing definitely wrong. MTU is a per-link value, and the smallest MTU determines the MTU for all hops that the packet travels between client and server. If something between the client and server eats the ICMP messages that say you're sending packets that are too large - my MTU's only XYZ then you will see this kind of problem, and there's definitely something wrong. Misconfigured firewalls are typical culprits in such instances. You should not have to reduce your MTU to reach a particular server. I tried lowering the MTU to 1400 but it made no difference. Are you saying the same sort of thing as camaleon who responded earlier, quote: It can be a black hole router. Most firewalls block pings that send packets bigger than normal (32-64 bytes) to avoid ping of death and blocking icmp fragment. I'm running a windows app to monitor it called 'ping plotter' which charts the ping responses and flags up the packet loss, and one server out there in particular loses 15% of pings: 213.120.176.62 It's on hop 5 of my 23 hop traceroute to mktgw1.ibllc.com (well it was last night - it's gone now). When I try ping 213.120.176.62 I get Packet filtered errors. But when I ping past it to my target mktgw1.ibllc.com I don't get the filter error. When I try ping -s 1500 213.120.176.62 I also get packet filtered errors, whereas mktgw1.ibllc.com will just eat the packets. Is this a different issue completely? Certainly smells different, but suspicious. Regards Adam -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbc1955.3010...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
Adam Hardy adam@cyberspaceroad.com wrote: I tried lowering the MTU to 1400 but it made no difference. So ping -s 1372 failed? I thought you said it worked up to -s 1472 (packets of 1500 bytes)? When you drop your MTU to 1400, that means that your local data packets are fragmented as necessary to stay within the maximum packet size. If you generate data with a do not fragment (DF) label attached to it, you have to ensure that each packet is no larger than the available size. (All fairly obvious so far, I trust.) If something between you and the destination is eating the Hey you're MTU's too big for this link messages then there's no way of handling overly large packets - as far as the recipient is concerned they have been discarded en route. Remember that although your packets might be the right size, there is (AFAICR) nothing there that limits the size of the packets being returned to you. And if the too big ICMP messages relating to data from the far end back to you are being discarded then the sender can't know it needs to reduce the packet size in order to reach you. Does this help any? Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/kbqto7x7qp@news.roaima.co.uk
Re: ping packet loss when size gt 1500
On 10/18/2010 04:54 AM, Adam Hardy wrote: [snip] I'm running a windows app to monitor it called 'ping plotter' which charts the ping responses and flags up the packet loss, and one server out there in particular loses 15% of pings: 213.120.176.62 Maybe not as fancy, but I find that mtr is *really* useful. (It's packaged in Debian...) -- Seek truth from facts. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbcd756.7040...@cox.net
Re: ping packet loss when size gt 1500
Morgan Gangwere on 16/10/10 21:14, wrote:
On Sat, 16 Oct 2010 20:11:46 +0100 Adam Hardy wrote:
[stuff]
Nope you're not the only one:
( 4:~ )%ping -s 1473 208.245.107.9
PING 208.245.107.9 (208.245.107.9) 1473(1501) bytes of data.
^C --- 208.245.107.9 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3022ms
this also appears to violate the PING standard:
( 5:~ )%ping -s 1470 208.245.107.9
PING 208.245.107.9 (208.245.107.9)
1470(1498) bytes of data. From 192.168.0.2 icmp_seq=1 Frag needed and
DF set (mtu = 1492) ^C
--- 208.245.107.9 ping statistics ---
7 packets transmitted, 0 received, +1 errors, 100% packet loss, time
6040ms
Normal PINGs seem to be fine:
( 7:~ )%ping 208.245.107.9
PING 208.245.107.9 (208.245.107.9) 56(84) bytes of data. 64
bytes from 208.245.107.9: icmp_req=1 ttl=118 time=150 ms 64 bytes from
208.245.107.9: icmp_req=2 ttl=118 time=147 ms 64 bytes from
208.245.107.9: icmp_req=3 ttl=118 time=149 ms 64 bytes from
208.245.107.9: icmp_req=4 ttl=118 time=146 ms ^C
--- 208.245.107.9 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 146.120/148.259/150.102/1.622 ms
The device has a DNS of mktgw1.ibllc.com \footnote{Isn't this sounding
like insecure.org now?} and doesn't respond to nmap's pings. I call
fault on their part.
Are you on a PPPoE connection directly or on a NAT'd network?
I'm on PPPoA connection using a DSL modem on one side of my gateway machine, and
my LAN on the other side. The gateway uses iptables to connect up the LAN to
the net so I believe that's what you mean by a NAT'd network.
What exactly is the violation of the ping standard there in your example?
The ideal solution would be that this firm recognises an error on their server
and fixes it, but (a) I'd need to give them a cast iron error description and
(b) I doubt they'd ever do anything anyway.
Actually I should search google for ping interactivebrokers and maybe there'll
be some other people in this situation.
Thanks
Adam
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cbad7d9.7060...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
Anticept . on 16/10/10 21:20, wrote: On Sat, Oct 16, 2010 at 3:11 PM, Adam Hardy adam@cyberspaceroad.com wrote: I have a bizarre problem with the server at 208.245.107.9, which is an internet broker whose server keeps disconnecting when making data requests. Their support is blaming the problem on me. 208.245.107.9 is used by a huge number of clients and I apparently am the only one suffering. Could it be something on my LAN? Or could it be my ISP (British Telecom) whose DNS server will randomly go down for a while and then come back (not in sync with the appearance of this problem though) - I thought I'd state that to give an idea of the ISP's reliability. Or is this ping problem definitely something I can sort out and perhaps solve it? Use OpenDNS or google DNS. Don't rely on your ISP DNS, as most of them don't know how to run them very well. Also, if British Telecom uses PPPoE, you can't have a packet size over 1492 (MTU size). 1500 is standard on non-PPPoE connections. It's not really an issue at all, just means you will need to transfer a tiny few packets more (you won't notice). In fact, if you are indeed using PPPoE, it would be good to make sure your MTU size is set to 1492 so your router won't have to fragment it to transmit. It's a PPPoA connection so I guess that doesn't apply. Adam -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbad59d.60...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
Morgan Gangwere on 16/10/10 21:14, wrote:
( 7:~ )%ping 208.245.107.9
PING 208.245.107.9 (208.245.107.9) 56(84) bytes of data. 64
bytes from 208.245.107.9: icmp_req=1 ttl=118 time=150 ms 64 bytes from
208.245.107.9: icmp_req=2 ttl=118 time=147 ms 64 bytes from
208.245.107.9: icmp_req=3 ttl=118 time=149 ms 64 bytes from
208.245.107.9: icmp_req=4 ttl=118 time=146 ms ^C
--- 208.245.107.9 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 146.120/148.259/150.102/1.622 ms
The device has a DNS of mktgw1.ibllc.com \footnote{Isn't this sounding
like insecure.org now?} and doesn't respond to nmap's pings. I call
fault on their part.
what is it about the DNS that you don't like? Sorry, I'm a relative neophyte in
this area. And not responding to nmap's pings - isn't that a different symptom
of the same problem?
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cbadb3e.3030...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
Morgan Gangwere on 16/10/10 21:14, wrote: On Sat, 16 Oct 2010 20:11:46 +0100 Adam Hardy wrote: [stuff] Nope you're not the only one: ( 4:~ )%ping -s 1473 208.245.107.9 PING 208.245.107.9 (208.245.107.9) 1473(1501) bytes of data. ^C --- 208.245.107.9 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3022ms Keep discovering things that might be relevant. If I do a tracert (which I just found out is traceroute -I, where -I means use ICMP ECHO for probes I can get a traceroute to the server: a...@isengard:~/tmp$ sudo tracert 208.245.107.9 [sudo] password for adam: traceroute to 208.245.107.9 (208.245.107.9), 30 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * 213.120.176.58 (213.120.176.58) 23.992 ms 24.841 ms 6 213.120.176.182 (213.120.176.182) 26.152 ms 6.453 ms 6.358 ms 7 acc1-10GigE-0-7-0-5.l-far.21cn-ipp.bt.net (109.159.249.214) 6.353 ms 6.134 ms 6.736 ms 8 core2-te0-14-4-0.ealing.ukcore.bt.net (109.159.249.157) 9.568 ms 7.570 ms 7.895 ms 9 transit2-xe0-1-0.ealing.ukcore.bt.net (194.72.17.82) 7.092 ms 7.070 ms 7.097 ms 10 t2c2-ge13-0-0.uk-eal.eu.bt.net (166.49.168.53) 7.122 ms 6.775 ms 7.682 ms 11 so-6-0-2.edge1.London2.Level3.net (212.113.11.253) 7.830 ms 7.052 ms 7.345 ms 12 ae-32-52.ebr2.London2.Level3.net (4.68.117.62) 9.553 ms ae-32-54.ebr2.London2.Level3.net (4.68.117.126) 8.178 ms 7.863 ms 13 ae-3-3.ebr1.London1.Level3.net (4.69.141.189) 7.854 ms 7.405 ms 7.697 ms 14 ae-100-100.ebr2.London1.Level3.net (4.69.141.166) 8.307 ms 8.318 ms 7.832 ms 15 ae-43-43.ebr1.NewYork1.Level3.net (4.69.137.74) 76.600 ms 75.925 ms 76.088 ms 16 ae-4-4.ebr1.NewYork2.Level3.net (4.69.141.18) 82.571 ms 81.033 ms 80.071 ms 17 ae-1-51.edge2.NewYork2.Level3.net (4.69.138.195) 76.163 ms 76.807 ms 78.007 ms 18 mci-level3-xe.newyork2.Level3.net (4.68.110.234) 75.640 ms 75.359 ms 75.371 ms 19 0.ae2.XL4.NYC4.ALTER.NET (152.63.3.117) 76.439 ms 76.328 ms 75.984 ms 20 0.so-7-1-0.XL4.BOS4.ALTER.NET (152.63.0.221) 83.696 ms 84.207 ms 84.064 ms 21 POS7-0-0.GW12.BOS4.ALTER.NET (152.63.22.181) 83.920 ms 83.924 ms 83.927 ms 22 interactivebrokers-gw.customer.alter.net (208.192.181.62) 91.797 ms 91.843 ms 91.479 ms 23 mktgw1.ibllc.com (208.245.107.9) 91.550 ms 91.443 ms 91.647 ms but if I use plain vanilla traceroute, it doesn't make the last hop: a...@isengard:~/tmp$ sudo traceroute 208.245.107.9 traceroute to 208.245.107.9 (208.245.107.9), 30 hops max, 40 byte packets 1 192.168.1.1 (192.168.1.1) 0.784 ms 2.980 ms 2.963 ms 2 217.32.146.168 (217.32.146.168) 7.049 ms 7.743 ms 8.640 ms 3 217.32.146.222 (217.32.146.222) 10.317 ms 10.774 ms 11.482 ms 4 213.120.177.58 (213.120.177.58) 12.197 ms 12.930 ms 13.865 ms 5 213.120.176.58 (213.120.176.58) 14.331 ms 14.797 ms * 6 213.120.176.182 (213.120.176.182) 16.956 ms 6.904 ms 6.828 ms 7 109.159.249.227 (109.159.249.227) 7.831 ms 8.143 ms 109.159.249.231 (109.159.249.231) 9.273 ms 8 core2-te0-14-4-0.ealing.ukcore.bt.net (109.159.249.157) 11.274 ms 109.159.249.149 (109.159.249.149) 11.918 ms core2-te0-15-0-2.ealing.ukcore.bt.net (109.159.249.161) 12.702 ms 9 transit2-xe0-1-0.ealing.ukcore.bt.net (194.72.17.82) 13.146 ms 13.796 ms 14.487 ms 10 t2c2-ge11-0-0.uk-eal.eu.bt.net (166.49.168.61) 15.211 ms 15.661 ms 16.845 ms 11 so-6-0-2.edge1.London2.Level3.net (212.113.11.253) 18.295 ms 20.230 ms 20.443 ms 12 ae-32-54.ebr2.London2.Level3.net (4.68.117.126) 15.073 ms 13.801 ms 8.207 ms 13 ae-3-3.ebr1.London1.Level3.net (4.69.141.189) 8.329 ms 9.897 ms 10.014 ms 14 ae-100-100.ebr2.London1.Level3.net (4.69.141.166) 10.912 ms 11.998 ms 12.871 ms 15 ae-43-43.ebr1.NewYork1.Level3.net (4.69.137.74) 81.782 ms ae-44-44.ebr1.NewYork1.Level3.net (4.69.137.78) 82.138 ms ae-43-43.ebr1.NewYork1.Level3.net (4.69.137.74) 83.191 ms 16 ae-4-4.ebr1.NewYork2.Level3.net (4.69.141.18) 84.379 ms 85.015 ms 85.782 ms 17 ae-1-51.edge2.NewYork2.Level3.net (4.69.138.195) 86.569 ms 86.918 ms 88.560 ms 18 mci-level3-xe.newyork2.Level3.net (4.68.110.234) 81.004 ms mci-level3-xe.newyork2.Level3.net (4.68.110.106) 82.624 ms 4.68.110.70 (4.68.110.70) 102.214 ms 19 0.ae3.XL4.NYC4.ALTER.NET (152.63.16.186) 80.748 ms 80.986 ms 0.ae2.XL4.NYC4.ALTER.NET (152.63.3.117) 81.313 ms 20 0.so-7-1-0.XL3.BOS4.ALTER.NET (152.63.0.209) 108.770 ms 84.001 ms 84.425 ms 21 POS6-0-0.GW12.BOS4.ALTER.NET (152.63.22.177) 84.149 ms 83.413 ms 84.180 ms 22 interactivebrokers-gw.customer.alter.net (208.192.181.62) 92.495 ms 92.240 ms 92.509 ms 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * is this useful or is this just irrelevant? Thanks! Adam -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbadc6b.1090...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
On Sat, 16 Oct 2010 20:11:46 +0100, Adam Hardy wrote: I thought I knew enough to keep my own home LAN going but I'm stuck on this one and I can't work out what to do next. In fact I thought everything was fine until I tried pinging with big packet sizes. ping -s 1472 www.bbc.co.uk ping -s 1472 208.245.107.9 works fine, no packet loss ever. ping -s 1473 www.bbc.co.uk works fine too. ping -s 1473 208.245.107.9 results in 100% packet loss. It can be a black hole router. Most firewalls block pings that send packets bigger than normal (32-64 bytes) to avoid ping of death and blocking icmp fragment. I have a bizarre problem with the server at 208.245.107.9, which is an internet broker whose server keeps disconnecting when making data requests. Their support is blaming the problem on me. I cannot load that site (208.245.107.9) on a web browser :-? s...@stt008:~$ host 208.245.107.9 9.107.245.208.in-addr.arpa domain name pointer mktgw1.ibllc.com. And by its name, seems like a gateway. 208.245.107.9 is used by a huge number of clients and I apparently am the only one suffering. Could it be something on my LAN? Or could it be my ISP (British Telecom) whose DNS server will randomly go down for a while and then come back (not in sync with the appearance of this problem though) - I thought I'd state that to give an idea of the ISP's reliability. Or is this ping problem definitely something I can sort out and perhaps solve it? You can try by reducing your MTU to 1400. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.10.17.12.02...@gmail.com
RE: ping packet loss when size gt 1500
Original Message From: adam@cyberspaceroad.com To: debian-user@lists.debian.org Subject: RE: ping packet loss when size gt 1500 Date: Sat, 16 Oct 2010 20:11:46 +0100 I thought I knew enough to keep my own home LAN going but I'm stuck on this one and I can't work out what to do next. In fact I thought everything was fine until I tried pinging with big packet sizes. ping -s 1472 www.bbc.co.uk ping -s 1472 208.245.107.9 works fine, no packet loss ever. ping -s 1473 www.bbc.co.uk works fine too. ping -s 1473 208.245.107.9 results in 100% packet loss. I have a bizarre problem with the server at 208.245.107.9, which is an internet broker whose server keeps disconnecting when making data requests. Their support is blaming the problem on me. 208.245.107.9 is used by a huge number of clients and I apparently am the only one suffering. Could it be something on my LAN? Or could it be my ISP (British Telecom) whose DNS server will randomly go down for a while and then come back (not in sync with the appearance of this problem though) - I thought I'd state that to give an idea of the ISP's reliability. Or is this ping problem definitely something I can sort out and perhaps solve it? Thanks Adam Just a guess but I would hypothesize that you have bumped up against a Maximum Transmission Unit limit. Larry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cb9f8f2.5040...@cyberspaceroad.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/380-2201010017153025...@netptc.net
Re: ping packet loss when size gt 1500
Anticept . on 16/10/10 21:20, wrote: On Sat, Oct 16, 2010 at 3:11 PM, Adam Hardy adam@cyberspaceroad.com wrote: I have a bizarre problem with the server at 208.245.107.9, which is an internet broker whose server keeps disconnecting when making data requests. Their support is blaming the problem on me. 208.245.107.9 is used by a huge number of clients and I apparently am the only one suffering. Could it be something on my LAN? Or could it be my ISP (British Telecom) whose DNS server will randomly go down for a while and then come back (not in sync with the appearance of this problem though) - I thought I'd state that to give an idea of the ISP's reliability. Or is this ping problem definitely something I can sort out and perhaps solve it? Use OpenDNS or google DNS. Don't rely on your ISP DNS, as most of them don't know how to run them very well. OK, I have ditched BT's DNS and switched over the OpenDNS. Hopefully that will help. After a bit of faffing I even have ddclient working although I guess that's unnecessary. Thanks, Adam -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbb2e46.1010...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
ow...@netptc.net on 17/10/10 16:30, wrote: I thought I knew enough to keep my own home LAN going but I'm stuck on this one and I can't work out what to do next. In fact I thought everything was fine until I tried pinging with big packet sizes. ping -s 1472 www.bbc.co.uk ping -s 1472 208.245.107.9 works fine, no packet loss ever. ping -s 1473 www.bbc.co.uk works fine too. ping -s 1473 208.245.107.9 results in 100% packet loss. I have a bizarre problem with the server at 208.245.107.9, which is an internet broker whose server keeps disconnecting when making data requests. Their support is blaming the problem on me. 208.245.107.9 is used by a huge number of clients and I apparently am the only one suffering. Could it be something on my LAN? Or could it be my ISP (British Telecom) whose DNS server will randomly go down for a while and then come back (not in sync with the appearance of this problem though) - I thought I'd state that to give an idea of the ISP's reliability. Or is this ping problem definitely something I can sort out and perhaps solve it? Just a guess but I would hypothesize that you have bumped up against a Maximum Transmission Unit limit. Thanks for all the info. I guess it tells me there's nothing definitely wrong. Adam -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbb2edc.1030...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
Camaleón on 17/10/10 13:02, wrote: I have a bizarre problem with the server at 208.245.107.9, which is an internet broker whose server keeps disconnecting when making data requests. Their support is blaming the problem on me. I cannot load that site (208.245.107.9) on a web browser :-? s...@stt008:~$ host 208.245.107.9 9.107.245.208.in-addr.arpa domain name pointer mktgw1.ibllc.com. And by its name, seems like a gateway. I'm not sure whether it's just a gateway or whether it is the final server. The gw is what you're looking at? I'll try reducing your MTU to 1400 as you suggest. Regards Adam -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbb2f9a.8030...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
Dne, 17. 10. 2010 19:11:34 je Adam Hardy napisal(a): OK, I have ditched BT's DNS and switched over the OpenDNS. Hopefully that will help. After a bit of faffing I even have ddclient working although I guess that's unnecessary. Quite. This snippet will update your OpenDNS account just as well: code wget --spider --no-proxy --http-user=yourm...@yourprovider.com --http-password=YOUR_PASSWORD_IN_PLAINTEXT https://updates.opendns.com/nic/update?hostname=YOUR_NETWORK_NAME edoc -- Regards, Klistvud Certifiable Loonix User #481801 http://bufferoverflow.tiddlyspot.com Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1287356279.1140...@compax
Re: ping packet loss when size gt 1500
Adam Hardy adam@cyberspaceroad.com wrote: Thanks for all the info. I guess it tells me there's nothing definitely wrong. MTU is a per-link value, and the smallest MTU determines the MTU for all hops that the packet travels between client and server. If something between the client and server eats the ICMP messages that say you're sending packets that are too large - my MTU's only XYZ then you will see this kind of problem, and there's definitely something wrong. Misconfigured firewalls are typical culprits in such instances. You should not have to reduce your MTU to reach a particular server. Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/go8so7xj64@news.roaima.co.uk
ping packet loss when size gt 1500
I thought I knew enough to keep my own home LAN going but I'm stuck on this one and I can't work out what to do next. In fact I thought everything was fine until I tried pinging with big packet sizes. ping -s 1472 www.bbc.co.uk ping -s 1472 208.245.107.9 works fine, no packet loss ever. ping -s 1473 www.bbc.co.uk works fine too. ping -s 1473 208.245.107.9 results in 100% packet loss. I have a bizarre problem with the server at 208.245.107.9, which is an internet broker whose server keeps disconnecting when making data requests. Their support is blaming the problem on me. 208.245.107.9 is used by a huge number of clients and I apparently am the only one suffering. Could it be something on my LAN? Or could it be my ISP (British Telecom) whose DNS server will randomly go down for a while and then come back (not in sync with the appearance of this problem though) - I thought I'd state that to give an idea of the ISP's reliability. Or is this ping problem definitely something I can sort out and perhaps solve it? Thanks Adam -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cb9f8f2.5040...@cyberspaceroad.com
Re: ping packet loss when size gt 1500
On Sat, 16 Oct 2010 20:11:46 +0100 Adam Hardy wrote:
[stuff]
Nope you're not the only one:
( 4:~ )%ping -s 1473 208.245.107.9
PING 208.245.107.9 (208.245.107.9) 1473(1501) bytes of data.
^C --- 208.245.107.9 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3022ms
this also appears to violate the PING standard:
( 5:~ )%ping -s 1470 208.245.107.9
PING 208.245.107.9 (208.245.107.9)
1470(1498) bytes of data. From 192.168.0.2 icmp_seq=1 Frag needed and
DF set (mtu = 1492) ^C
--- 208.245.107.9 ping statistics ---
7 packets transmitted, 0 received, +1 errors, 100% packet loss, time
6040ms
Normal PINGs seem to be fine:
( 7:~ )%ping 208.245.107.9
PING 208.245.107.9 (208.245.107.9) 56(84) bytes of data. 64
bytes from 208.245.107.9: icmp_req=1 ttl=118 time=150 ms 64 bytes from
208.245.107.9: icmp_req=2 ttl=118 time=147 ms 64 bytes from
208.245.107.9: icmp_req=3 ttl=118 time=149 ms 64 bytes from
208.245.107.9: icmp_req=4 ttl=118 time=146 ms ^C
--- 208.245.107.9 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 146.120/148.259/150.102/1.622 ms
The device has a DNS of mktgw1.ibllc.com \footnote{Isn't this sounding
like insecure.org now?} and doesn't respond to nmap's pings. I call
fault on their part.
Are you on a PPPoE connection directly or on a NAT'd network?
--
Morgan Gangwere
PGP Key at http://indrora.homelinux.org/gpg_key.asc
BOFH Excuse #43
MTU set too high.
signature.asc
Description: PGP signature
Re: ping packet loss when size gt 1500
On Sat, Oct 16, 2010 at 3:11 PM, Adam Hardy adam@cyberspaceroad.com wrote: I have a bizarre problem with the server at 208.245.107.9, which is an internet broker whose server keeps disconnecting when making data requests. Their support is blaming the problem on me. 208.245.107.9 is used by a huge number of clients and I apparently am the only one suffering. Could it be something on my LAN? Or could it be my ISP (British Telecom) whose DNS server will randomly go down for a while and then come back (not in sync with the appearance of this problem though) - I thought I'd state that to give an idea of the ISP's reliability. Or is this ping problem definitely something I can sort out and perhaps solve it? Thanks Adam Use OpenDNS or google DNS. Don't rely on your ISP DNS, as most of them don't know how to run them very well. Also, if British Telecom uses PPPoE, you can't have a packet size over 1492 (MTU size). 1500 is standard on non-PPPoE connections. It's not really an issue at all, just means you will need to transfer a tiny few packets more (you won't notice). In fact, if you are indeed using PPPoE, it would be good to make sure your MTU size is set to 1492 so your router won't have to fragment it to transmit. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin3kmugoqhucd3yvfohqhro0mdpgpbm1p7_j...@mail.gmail.com
Re: ping packet loss when size gt 1500
On 10/16/2010 03:20 PM, Anticept . wrote: [snip] Use ... google DNS. So instead of just knowing everything you search, and all of your email, they also know everywhere you surf? -- Seek truth from facts. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cba19b2.9040...@cox.net
Re: ping packet loss when size gt 1500
On Sat, Oct 16, 2010 at 5:31 PM, Ron Johnson ron.l.john...@cox.net wrote: On 10/16/2010 03:20 PM, Anticept . wrote: [snip] Use ... google DNS. So instead of just knowing everything you search, and all of your email, they also know everywhere you surf? -- Seek truth from facts. I'm not concerned over google's information gathering policies. They tell you they gather your information. They've had a few mistakes and oopsies, but have been better than many. -Anticept -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktindcvkunbf01a9bnvmfczsoknvnvpxy5ihul...@mail.gmail.com
