Adam Hardy 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
Chris Davies on 20/10/10 11:45, wrote:
Adam Hardy 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 nee
Adam Hardy 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 d
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
Chris Davies on 19/10/10 16:24, wrote:
Adam Hardy 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 o
Adam Hardy 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 -
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, an
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 lo
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 n
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 n
Chris Davies on 18/10/10 13:15, wrote:
Adam Hardy 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 fragmen
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 *re
Adam Hardy 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 maxim
Chris Davies on 17/10/10 23:08, wrote:
Adam Hardy 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 cli
Adam Hardy 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 t
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 wel
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...@st
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.
Anticept . on 16/10/10 21:20, wrote:
On Sat, Oct 16, 2010 at 3:11 PM, Adam Hardy 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 i
>
>
>
> 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
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
> pin
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
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 tim
Anticept . on 16/10/10 21:20, wrote:
On Sat, Oct 16, 2010 at 3:11 PM, Adam Hardy 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 i
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
On Sat, Oct 16, 2010 at 5:31 PM, Ron Johnson 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 concern
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
On Sat, Oct 16, 2010 at 3:11 PM, Adam Hardy 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 clie
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
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
30 matches
Mail list logo
