Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.networking > #2403 > unrolled thread
| Started by | billy <billy@is.invalid> |
|---|---|
| First post | 2013-10-08 03:32 +0000 |
| Last post | 2013-10-13 02:04 +0200 |
| Articles | 20 on this page of 127 — 22 participants |
Back to article view | Back to comp.os.linux.networking
Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-08 03:32 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out "Gary R. Schmidt" <grschmidt@acm.org> - 2013-10-08 15:37 +1100
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 14:26 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Thomas Keusch <fwd+usenet-spam2013q4-1381444031@spam2013q4.bsd-solutions-duesseldorf.de> - 2013-10-10 22:32 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out David Hough <noone$$@llondel.org> - 2013-10-08 07:30 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out Chris Davies <chris-usenet@roaima.co.uk> - 2013-10-08 19:32 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-10-08 23:16 +0300
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 17:39 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Mike Easter <MikeE@ster.invalid> - 2013-10-09 11:28 -0700
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 18:52 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-10-09 22:47 +0300
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 20:50 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-09 21:30 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 01:05 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 01:09 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-09 19:51 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 20:42 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out ~BD~ <~BD~@nomail.afraid.org> - 2013-10-09 22:09 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 01:07 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out ~BD~ <~BD~@nomail.afraid.org> - 2013-10-10 07:41 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-09 21:36 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Mike Easter <MikeE@ster.invalid> - 2013-10-09 15:51 -0700
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-10 00:15 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 00:19 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 00:33 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 10:54 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 11:09 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out "ps56k" <pschuman_no5pam_m3@interserv.com> - 2013-10-10 16:34 -0500
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-10 22:40 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out "ps56k" <pschuman_no5pam_m3@interserv.com> - 2013-10-10 18:27 -0500
Re: Frustrated that I don't UNDERSTAND why my network times out Thad Floryan <thad@thadlabs.com> - 2013-10-10 16:49 -0700
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 00:40 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Thomas Keusch <fwd+usenet-spam2013q4-1381456101@spam2013q4.bsd-solutions-duesseldorf.de> - 2013-10-11 01:50 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 03:24 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out dyrmak <dyrmak@orange.fr.invalid> - 2013-10-11 08:50 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 14:26 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-11 16:03 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 20:19 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-11 20:38 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-10-11 21:34 +0300
Re: Frustrated that I don't UNDERSTAND why my network times out Chris Davies <chris-usenet@roaima.co.uk> - 2013-10-11 00:00 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 11:18 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-10-09 15:16 +0300
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 17:41 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Chris Davies <chris-usenet@roaima.co.uk> - 2013-10-09 19:22 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 21:18 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Rick Jones <rick.jones2@hp.com> - 2013-10-09 20:44 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-09 21:46 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 00:39 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Rick Jones <rick.jones2@hp.com> - 2013-10-10 01:30 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 01:32 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2013-10-09 22:25 -0400
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 03:48 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-10 05:10 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out ein <ein@no.spam> - 2013-10-10 13:24 +0200
Re: Frustrated that I don't UNDERSTAND why my network times out Chris Davies <chris-usenet@roaima.co.uk> - 2013-10-10 10:31 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-10 17:37 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Chris Davies <chris-usenet@roaima.co.uk> - 2013-10-11 00:01 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 20:21 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-10 21:04 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 01:18 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Chris Davies <chris-usenet@roaima.co.uk> - 2013-10-11 00:03 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 00:57 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 01:07 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Richard Kettlewell <rjk@greenend.org.uk> - 2013-10-11 08:56 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 00:47 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 00:58 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Rick Jones <rick.jones2@hp.com> - 2013-10-10 01:24 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Bit Twister <BitTwister@mouse-potato.com> - 2013-10-09 12:23 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Chris Davies <chris-usenet@roaima.co.uk> - 2013-10-09 19:27 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 21:21 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-09 21:47 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 10:43 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 10:51 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out nemesis <nemesis@home.it> - 2013-10-09 08:14 -0300
Re: Frustrated that I don't UNDERSTAND why my network times out "p-0''0-h the cat (ES)" <super.pooh@furryfreeware.invalid> - 2013-10-09 12:24 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out nemesis <nemesis@home.it> - 2013-10-09 08:42 -0300
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 13:57 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out "p-0''0-h the cat (ES)" <super.pooh@furryfreeware.invalid> - 2013-10-09 15:09 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 11:27 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out nemesis <nemesis@home.it> - 2013-10-09 08:58 -0300
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 18:44 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-09 19:58 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 21:23 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-09 21:38 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Mike Easter <MikeE@ster.invalid> - 2013-10-09 16:14 -0700
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 00:30 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Mike Easter <MikeE@ster.invalid> - 2013-10-09 18:02 -0700
Re: Frustrated that I don't UNDERSTAND why my network times out Rick Jones <rick.jones2@hp.com> - 2013-10-10 01:37 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-10 03:17 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 20:03 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 20:06 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-09 21:27 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-09 22:15 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-10 00:35 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out "p-0''0-h the cat (ES)" <super.pooh@furryfreeware.invalid> - 2013-10-10 09:15 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 01:40 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out nemesis <nemesis@home.it> - 2013-10-10 23:03 -0300
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 14:43 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out ~BD~ <~BD~@nomail.afraid.org> - 2013-10-11 16:11 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-11 04:11 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 04:19 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 04:25 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-11 04:45 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out ein <ein@no.spam> - 2013-10-11 08:06 +0200
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 14:32 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 14:41 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 14:48 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Richard Kettlewell <rjk@greenend.org.uk> - 2013-10-11 09:00 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 14:30 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out Rick Jones <rick.jones2@hp.com> - 2013-10-14 19:20 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out "p-0''0-h the cat (ES)" <super.pooh@furryfreeware.invalid> - 2013-10-11 10:17 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out billy <billy@is.invalid> - 2013-10-11 14:23 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out "p-0''0-h the cat (ES)" <super.pooh@furryfreeware.invalid> - 2013-10-11 22:46 +0100
Re: Frustrated that I don't UNDERSTAND why my network times out Scott Hemphill <hemphill@hemphills.net> - 2013-10-14 16:47 -0400
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-09 16:17 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out "ps56k" <pschuman_no5pam_m3@interserv.com> - 2013-10-10 16:41 -0500
Re: Frustrated that I don't UNDERSTAND why my network times out Mike Easter <MikeE@ster.invalid> - 2013-10-10 15:16 -0700
Re: Frustrated that I don't UNDERSTAND why my network times out Mike Easter <MikeE@ster.invalid> - 2013-10-10 15:18 -0700
Re: Frustrated that I don't UNDERSTAND why my network times out "ps56k" <pschuman_no5pam_m3@interserv.com> - 2013-10-13 14:34 -0500
Re: Frustrated that I don't UNDERSTAND why my network times out Mike Easter <MikeE@ster.invalid> - 2013-10-13 14:27 -0700
Re: Frustrated that I don't UNDERSTAND why my network times out "ps56k" <pschuman_no5pam_m3@interserv.com> - 2013-10-17 14:58 -0500
Re: Frustrated that I don't UNDERSTAND why my network times out "petrus bitbyter" <petrus.bitbyter@hotmail.com> - 2013-10-11 22:17 +0200
Re: Frustrated that I don't UNDERSTAND why my network times out "petrus bitbyter" <petrus.bitbyter@hotmail.com> - 2013-10-11 22:42 +0200
Re: Frustrated that I don't UNDERSTAND why my network times out unruh <unruh@invalid.ca> - 2013-10-11 21:16 +0000
Re: Frustrated that I don't UNDERSTAND why my network times out "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2013-10-11 18:15 -0400
Re: Frustrated that I don't UNDERSTAND why my network times out "petrus bitbyter" <petrus.bitbyter@hotmail.com> - 2013-10-13 02:04 +0200
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Chris Davies <chris-usenet@roaima.co.uk> |
|---|---|
| Date | 2013-10-11 00:00 +0100 |
| Message-ID | <p4ojiaxp05.ln2@news.roaima.co.uk> |
| In reply to | #2481 |
In comp.os.linux.networking ps56k <pschuman_no5pam_m3@interserv.com> wrote: > On the topic of MTU (the size of the packets transmitted) > I have never had a website not respond, I have. Chris
[toc] | [prev] | [next] | [standalone]
| From | billy <billy@is.invalid> |
|---|---|
| Date | 2013-10-09 11:18 +0000 |
| Message-ID | <l33ect$d7t$1@speranza.aioe.org> |
| In reply to | #2407 |
Chris Davies wrote: > You can also reduce your own MTU and see whether this "fixes" > the problem. Try "ifconfig eth0 mtu 1400", and experiment Bearing in mind, the problem is that I'm trying to understand *why* my web traffic is not connecting to centos.org, I'll try any suggested diagnostic procedure using whatever tools I have at hand. I set my packet size on my laptop to a low value: # ifconfig wlan0 mtu 500 And, then ran the traceroute: # traceroute -M icmp centos.org traceroute to centos.org (72.232.194.162), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 5.042 ms 5.029 ms 5.017 ms 2 WISP_IP_REDACTED (xxx.xxx.xxx.xxx) 5.022 ms 8.227 ms 8.227 ms 3 10.50.0.1 (10.50.0.1) 13.820 ms 23.623 ms 25.771 ms 4 10.25.0.1 (10.25.0.1) 25.767 ms 30.879 ms 30.877 ms 5 10.20.0.1 (10.20.0.1) 44.616 ms 46.995 ms 46.992 ms 6 10.0.0.1 (10.0.0.1) 52.204 ms 27.862 ms 31.134 ms 7 69.36.226.193 (69.36.226.193) 35.862 ms 50.007 ms 49.971 ms 8 vl2.core1.scl.layer42.net (69.36.225.129) 49.951 ms 74.962 ms 77.875 ms 9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 77.857 ms 25.678 ms 25.643 ms 10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 71.468 ms 91.228 ms 95.624 ms 11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 155.916 ms 85.719 ms 101.926 ms 12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 95.461 ms 97.164 ms 103.047 ms 13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 103.028 ms 63.041 ms 107.573 ms 14 border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 107.556 ms 70.772 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 70.744 ms 15 layered-11.border1.dal004.pnap.net (63.251.44.74) 70.725 ms 89.757 ms 89.726 ms 16 * * * <=== from experience, I know this is centos.org 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * BTW, I know that, in the case above, hop 16 is centos.org because I've asked neighbors in the past (who are on the same WISP) to run a traceroute, and, every few months, I can connect - so I can see it on my own laptop.
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2013-10-09 15:16 +0300 |
| Message-ID | <l33hf2$j78$1@dont-email.me> |
| In reply to | #2415 |
On 9.10.13 2:18 , billy wrote: > Chris Davies wrote: > >> You can also reduce your own MTU and see whether this "fixes" >> the problem. Try "ifconfig eth0 mtu 1400", and experiment > > Bearing in mind, the problem is that I'm trying to understand > *why* my web traffic is not connecting to centos.org, I'll try > any suggested diagnostic procedure using whatever tools I have > at hand. > > I set my packet size on my laptop to a low value: > # ifconfig wlan0 mtu 500 > > And, then ran the traceroute: > # traceroute -M icmp centos.org > traceroute to centos.org (72.232.194.162), 30 hops max, 60 byte packets > 1 192.168.1.1 (192.168.1.1) 5.042 ms 5.029 ms 5.017 ms > 2 WISP_IP_REDACTED (xxx.xxx.xxx.xxx) 5.022 ms 8.227 ms 8.227 ms > 3 10.50.0.1 (10.50.0.1) 13.820 ms 23.623 ms 25.771 ms > 4 10.25.0.1 (10.25.0.1) 25.767 ms 30.879 ms 30.877 ms > 5 10.20.0.1 (10.20.0.1) 44.616 ms 46.995 ms 46.992 ms > 6 10.0.0.1 (10.0.0.1) 52.204 ms 27.862 ms 31.134 ms > 7 69.36.226.193 (69.36.226.193) 35.862 ms 50.007 ms 49.971 ms > 8 vl2.core1.scl.layer42.net (69.36.225.129) 49.951 ms 74.962 ms 77.875 ms > 9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 77.857 ms 25.678 ms 25.643 ms > 10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 71.468 ms 91.228 ms 95.624 ms > 11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 155.916 ms 85.719 ms 101.926 ms > 12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 95.461 ms 97.164 ms 103.047 ms > 13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 103.028 ms 63.041 ms 107.573 ms > 14 border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 107.556 ms 70.772 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 70.744 > ms > 15 layered-11.border1.dal004.pnap.net (63.251.44.74) 70.725 ms 89.757 ms 89.726 ms > 16 * * * <=== from experience, I know this is centos.org > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > BTW, I know that, in the case above, hop 16 is centos.org because I've asked > neighbors in the past (who are on the same WISP) to run a traceroute, and, > every few months, I can connect - so I can see it on my own laptop. Get a goot text on TCP/IP protocols and learn how TCP does it. There is an ICMP message 'fragmentation needed but DF bit is on'. The segment auto-sizing is an essential part of TCP. If a sysadmin has killed the whole ICMP somewhere in the path, there is little you can do, except whine to him. Traceroute is not of much help here. -- Tauno Voipio
[toc] | [prev] | [next] | [standalone]
| From | billy <billy@is.invalid> |
|---|---|
| Date | 2013-10-09 17:41 +0000 |
| Message-ID | <l344gg$gh9$2@speranza.aioe.org> |
| In reply to | #2419 |
On Wed, 09 Oct 2013 15:16:33 +0300, Tauno Voipio wrote: > If a sysadmin has killed the whole ICMP somewhere in the path, > there is little you can do, except whine to him. > > Traceroute is not of much help here. Just so I understand, are you saying that the web (i.e., http://centos.org) is using ICMP?
[toc] | [prev] | [next] | [standalone]
| From | Chris Davies <chris-usenet@roaima.co.uk> |
|---|---|
| Date | 2013-10-09 19:22 +0100 |
| Message-ID | <ngjgiaxg18.ln2@news.roaima.co.uk> |
| In reply to | #2425 |
In comp.os.linux.networking billy <billy@is.invalid> wrote: > Just so I understand, are you saying that the web > (i.e., http://centos.org) is using ICMP? Yes and no. The data for a website is carried over TCP. The control commands (e.g. "slow down you're filling up the pipe", or "that packet's waayyy too big; make it smaller") are sent over ICMP. Pings and some traceroute programs also use ICMP, but they use a different ICMP message type. A competently configured firewall might be set up to block ICMP ping requests. But there's no way that same firewall should be completely and naively blocking all ICMP packets.
[toc] | [prev] | [next] | [standalone]
| From | billy <billy@is.invalid> |
|---|---|
| Date | 2013-10-09 21:18 +0000 |
| Message-ID | <l34h7g$n2t$1@speranza.aioe.org> |
| In reply to | #2430 |
On Wed, 09 Oct 2013 19:22:48 +0100, Chris Davies wrote: > The data for a website is carried over TCP. The control commands > (e.g. "slow down you're filling up the pipe", or "that packet's waayyy > too big; make it smaller") are sent over ICMP. Pings and some traceroute > programs also use ICMP, but they use a different ICMP message type. > > A competently configured firewall might be set up to block ICMP ping > requests. But there's no way that same firewall should be completely > and naively blocking all ICMP packets. Thanks for that explanation. What I gather is that the "problem" isn't how I'm running ping or traceroute. The network problem is something more abstract. Here's what I know: - I seem to be the only one with this problem. - It does NOT happen when I go to my neighbor's house using my PC. - The problem comes and goes (and stays for months). - Nothing gets past the hop before centos.org. - I can't go around that penultimate router without using Tor. - Since TOR works on all the PCs in the house, it's not the PCs. and - It's not how I'm running the web, traceroute, or ping. Since the problem seems to be at the penultimate hop, is there any way, other than TOR, to get around that hop (from my own home network)? Are there public proxies I can set up for Firefox?
[toc] | [prev] | [next] | [standalone]
| From | Rick Jones <rick.jones2@hp.com> |
|---|---|
| Date | 2013-10-09 20:44 +0000 |
| Message-ID | <l34f80$5c6$1@usenet01.boi.hp.com> |
| In reply to | #2425 |
The protocols layer and in some cases intertwine. What you call "the
web" sits on top of a protocol called HTTP (HyperText Transfer
Protocol). HTTP makes use of the services of TCP (Transmission
Control Protocol). TCP makes use of IP (Internet Protocol). IP will
make use of whatever link-layer protocol is available in its
sitaution. For your end systems that will be "Ethernet" protocol over
your WiFi connection.
HTTP
TCP
IP
Ethernet/WiFi/whatnot
Within/alongside IP is ICMP (Internet Control Message Protocol). ICMP
is used to provide some "Hey, you should know this" kinds of messages
back to traffic sources.
So, simplifying a bit, when you try to access www.centos.org from your
web browser, the browser will generate an HTTP message the browswer
wants to get to HTTP at www.centos.org. That HTTP message will be
handed-off to TCP to transmit in one or more TCP segments to TCP at
www.centos.org (segment = what a packet is called in the context of
TCP). The TCP segment(s) will be handed off to IP, which will
encapsulate them in one or more IP datagrams (datagram = what a packet
is called in the context of IP) destined to the IP address of
www.centos.org. IP will then hand its datagrams to the "data link"
layer (eg Ethernet etc) which will do its encapsulation. It will then
go across the data link destined for IP at the "next hop" where the
data-link layer message will decapsulate the IP datagram and hand it
to IP at that hop. IP at that hop will then decide what to do with
the datagram, which is being sent to the/an IP address for
www.centos.org. There will probably be another "next hop" and so on
until the traffic arrives at www.centos.org. IP at www.centos.org
will then decapsulate the TCP segment from the IP datagram, and TCP
will decapsulate the HTTP message and hand it to the HTTP server.
The HTTP response will flow back to you via a similar mechanism.
Those different lines you see in the output of traceroute are the
"next hops" along the way from your system to www.centos.org.
Now, the data links at all those next hops may have different limits
for how large a packet they can transmit. If an IP datagram arrives
at a "next hop" (aka an IP router), and IP there determines that where
it needs to be sent-out next is over a data link with a packet size
smaller than the IP datagram it needs to send, IP decides to send back
to the traffic's source an ICMP message saying "Hey, the datagram you
sent is too large for me to send, you should send smaller IP
datagrams" (There is more to it than this, but I'm simplifying).
There are other sorts of ICMP "Hey!" messages. One of them is
"Maximum Hop Count Reached" - that is the ICMP message that (default)
traceroute relies upon receiving. In the header of an IP datagram
there is a field called the "TTL" (Time To Live) which is really a
maximum hop count. As the IP datagram passes through an IP router,
the router decrements the count by one, and when it hits zero, that IP
is supposed to send back an ICMP message that says "Hey! The datagram
you sent had its maximum hop count expire before it reached its
destination." Traceroute works by sending an IP datagram over and
over again, with the TTL increased by one each time.
Ping sends a different sort of ICMP message, one that says "Please
tell me that you got this" - more formally known as an ICMP Echo
Request. The destination IP will send an ICMP Echo Response back to
the originator when it receives one.
Now, all these things I've described rely on ICMP messages making it
back to the source of the IP/ICMP datagram triggering them. But some
network administrators feel that allowing (certain) ICMP traffic to
pass represents a security vulnerablity, so they block ICMP traffic.
If ICMP traffic is blocked at a point part-way between you and
www.centos.org, you will see the traceroute "stop" (those '*' lines
starting indicating there was no response with the TTL set to that
many hops). You will also not have ping "work" - it won't see any
ICMP Echo Reply messages.
If TCP tries to send a TCP segment that was carried in an IP datagram
which needed to be fragmented somewhere in the middle there, then when
it goes to send traffic it will appear to disappear - it hits an IP
router (next hop) that tried to send it but couldn't and the "Hey!"
message that IP router tried to send back was blocked.
Now, by default, ping and traceroute do not send very large IP
datagrams, so the chances of those packets arriving at a next hop
where fragmentation is needed is pretty small.
Also, not all TCP segments are the same size - the TCP segments used
to setup a TCP connection for example are pretty small. That is what
was behind some of the "try telnet www.centos.org 80" suggestions -
that is an old school way to just try establishing a TCP connection
but not actually send any data on it. Those TCP segments will be
small.
Why try that? (Or for that matter the pings or traceroutes with
options set to send larger packets) Because it is how one tries to see
if 'the problem" centers on packets which are too large arriving at a
small data link somewhere, or simply a routing issue somewhere in the
middle of the Internet. If the "telnet www.centos.org 80" establishes
the TCP connection, you can assume that it isn't a routing issue. In
that case, a/the remedy is to ensure that TCP at your system and TCP
at the system(s) to which you are connecting never try to send TCP
segments which become IP datagrams which are too large to send without
fragmentation. One can do that by shrinking the MTU of the network
interface of your system. When TCP establishes a connection, part of
that is exchanging with the other side (eg www.centos.org) the Maximum
Segment Size (MSS) for the connection. There are several inputs to
that exchange, one of which is the MTU of your local interface. The
smallest MSS (your's or that of www.centos.org) is the one that will
be used for traffic in both directions.
Now, if the telnet www.centos.org 80 does not succeed, that means
there is some sort of routing issue. That was already partially
suggested by the ping and traceroute "failures" you've already
reported (if memory serves) but since the ICMP traffic on which they
rely can be blocked, their failure is not conclusive.
What sort of routing issue might it be? Well, one could be that there
is a simply problem at or after one of those next hops you see in the
traceroute output. That is why some have suggested you lookup the
information about who runs those and contact them.
It is possible that your source IP has been "black listed" for some
reason or other - either at/past the ISP responsible for the last
"next hop" you see in traceroute or perhaps even at www.centos.org.
Perhaps at one point the IP address you have from your ISP was
involved in something considered nefarious or anti-social.
That you could still get to www.centos.org using TOR would remain
consistent with your IP address (the one being assigned to your home
gateway by your ISP) being blacklisted because the entire point of TOR
(as I understand it) is to hid your actual IP address. It does that
by adding some additional layers to the top of what I mentioned
above. (As I understand it, I don't actually have any practical
experience with TOR).
rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
[toc] | [prev] | [next] | [standalone]
| From | unruh <unruh@invalid.ca> |
|---|---|
| Date | 2013-10-09 21:46 +0000 |
| Message-ID | <L8k5u.32423$Zd1.26534@fx22.iad> |
| In reply to | #2436 |
On 2013-10-09, Rick Jones <rick.jones2@hp.com> wrote: > > The protocols layer and in some cases intertwine. What you call "the > web" sits on top of a protocol called HTTP (HyperText Transfer > Protocol). HTTP makes use of the services of TCP (Transmission > Control Protocol). TCP makes use of IP (Internet Protocol). IP will > make use of whatever link-layer protocol is available in its > sitaution. For your end systems that will be "Ethernet" protocol over > your WiFi connection. > > HTTP > TCP > IP > Ethernet/WiFi/whatnot > > Within/alongside IP is ICMP (Internet Control Message Protocol). ICMP > is used to provide some "Hey, you should know this" kinds of messages > back to traffic sources. > > So, simplifying a bit, when you try to access www.centos.org from your > web browser, the browser will generate an HTTP message the browswer Well, no. He tried telnet centos.org 80 which generates no HTTP message. Just a bare connection request. It fails. > wants to get to HTTP at www.centos.org. That HTTP message will be > handed-off to TCP to transmit in one or more TCP segments to TCP at > www.centos.org (segment = what a packet is called in the context of > TCP). The TCP segment(s) will be handed off to IP, which will > encapsulate them in one or more IP datagrams (datagram = what a packet > is called in the context of IP) destined to the IP address of > www.centos.org. IP will then hand its datagrams to the "data link" > layer (eg Ethernet etc) which will do its encapsulation. It will then > go across the data link destined for IP at the "next hop" where the > data-link layer message will decapsulate the IP datagram and hand it > to IP at that hop. IP at that hop will then decide what to do with > the datagram, which is being sent to the/an IP address for > www.centos.org. There will probably be another "next hop" and so on > until the traffic arrives at www.centos.org. IP at www.centos.org > will then decapsulate the TCP segment from the IP datagram, and TCP > will decapsulate the HTTP message and hand it to the HTTP server. > > The HTTP response will flow back to you via a similar mechanism. > > Those different lines you see in the output of traceroute are the > "next hops" along the way from your system to www.centos.org. > > Now, the data links at all those next hops may have different limits > for how large a packet they can transmit. If an IP datagram arrives > at a "next hop" (aka an IP router), and IP there determines that where > it needs to be sent-out next is over a data link with a packet size > smaller than the IP datagram it needs to send, IP decides to send back > to the traffic's source an ICMP message saying "Hey, the datagram you > sent is too large for me to send, you should send smaller IP > datagrams" (There is more to it than this, but I'm simplifying). He sent really small packets. ping is I believe 80 bytes. And they are not rejecting ping packets (I just checked.) > > There are other sorts of ICMP "Hey!" messages. One of them is > "Maximum Hop Count Reached" - that is the ICMP message that (default) > traceroute relies upon receiving. In the header of an IP datagram > there is a field called the "TTL" (Time To Live) which is really a > maximum hop count. As the IP datagram passes through an IP router, > the router decrements the count by one, and when it hits zero, that IP > is supposed to send back an ICMP message that says "Hey! The datagram > you sent had its maximum hop count expire before it reached its > destination." Traceroute works by sending an IP datagram over and > over again, with the TTL increased by one each time. > > Ping sends a different sort of ICMP message, one that says "Please > tell me that you got this" - more formally known as an ICMP Echo > Request. The destination IP will send an ICMP Echo Response back to > the originator when it receives one. > > Now, all these things I've described rely on ICMP messages making it > back to the source of the IP/ICMP datagram triggering them. But some > network administrators feel that allowing (certain) ICMP traffic to > pass represents a security vulnerablity, so they block ICMP traffic. Except they do not. They come back to me with no trouble. They come back to his neighbour with no trouble. > > If ICMP traffic is blocked at a point part-way between you and > www.centos.org, you will see the traceroute "stop" (those '*' lines > starting indicating there was no response with the TTL set to that > many hops). You will also not have ping "work" - it won't see any > ICMP Echo Reply messages. Yup, but why only to him? > > If TCP tries to send a TCP segment that was carried in an IP datagram > which needed to be fragmented somewhere in the middle there, then when > it goes to send traffic it will appear to disappear - it hits an IP > router (next hop) that tried to send it but couldn't and the "Hey!" > message that IP router tried to send back was blocked. > > Now, by default, ping and traceroute do not send very large IP > datagrams, so the chances of those packets arriving at a next hop > where fragmentation is needed is pretty small. > > Also, not all TCP segments are the same size - the TCP segments used > to setup a TCP connection for example are pretty small. That is what > was behind some of the "try telnet www.centos.org 80" suggestions - > that is an old school way to just try establishing a TCP connection > but not actually send any data on it. Those TCP segments will be > small. And they failed as well, so I think we can eliminate packet size as an issue. > > Why try that? (Or for that matter the pings or traceroutes with > options set to send larger packets) Because it is how one tries to see > if 'the problem" centers on packets which are too large arriving at a > small data link somewhere, or simply a routing issue somewhere in the > middle of the Internet. If the "telnet www.centos.org 80" establishes > the TCP connection, you can assume that it isn't a routing issue. In > that case, a/the remedy is to ensure that TCP at your system and TCP > at the system(s) to which you are connecting never try to send TCP > segments which become IP datagrams which are too large to send without > fragmentation. One can do that by shrinking the MTU of the network > interface of your system. When TCP establishes a connection, part of > that is exchanging with the other side (eg www.centos.org) the Maximum > Segment Size (MSS) for the connection. There are several inputs to > that exchange, one of which is the MTU of your local interface. The > smallest MSS (your's or that of www.centos.org) is the one that will > be used for traffic in both directions. > > Now, if the telnet www.centos.org 80 does not succeed, that means > there is some sort of routing issue. That was already partially > suggested by the ping and traceroute "failures" you've already > reported (if memory serves) but since the ICMP traffic on which they > rely can be blocked, their failure is not conclusive. So, why does the route up to the last hop work, but not that last hop? And why does it work for everyone else. It is really really hard to see it as a routing issue. > > What sort of routing issue might it be? Well, one could be that there > is a simply problem at or after one of those next hops you see in the > traceroute output. That is why some have suggested you lookup the > information about who runs those and contact them. > > It is possible that your source IP has been "black listed" for some > reason or other - either at/past the ISP responsible for the last > "next hop" you see in traceroute or perhaps even at www.centos.org. > Perhaps at one point the IP address you have from your ISP was > involved in something considered nefarious or anti-social. > > That you could still get to www.centos.org using TOR would remain > consistent with your IP address (the one being assigned to your home > gateway by your ISP) being blacklisted because the entire point of TOR > (as I understand it) is to hid your actual IP address. It does that > by adding some additional layers to the top of what I mentioned > above. (As I understand it, I don't actually have any practical > experience with TOR). Yes, I does look like a firewall issue, but he claims that centos claims that there is no such issue. > > rick jones
[toc] | [prev] | [next] | [standalone]
| From | billy <billy@is.invalid> |
|---|---|
| Date | 2013-10-10 00:39 +0000 |
| Message-ID | <l34tbe$hb5$1@speranza.aioe.org> |
| In reply to | #2446 |
unruh wrote: > So, why does the route up to the last hop work, but not that last hop? > And why does it work for everyone else. It is really really hard to see > it as a routing issue. Everything you said is right on the money. It's frustratingly hard to figure out. The only two ideas "I" can come up with are: 1. Someone is blocking me (but I can't imagine why) 2. The path is too long for something (but I don't know what). In the first case, I'm not sure if the blocker would be the 15th hop (which returns packets) not forwarding them on to the Centos server or if it's the 16th hop (the Centos server) not responding back. Is there a way to tell? In the second case, it would be useful to test a similarly long (at least 16 hops) path. Or, maybe there's a way to slow down my pings so that I can reproduce the problem in fewer hops?
[toc] | [prev] | [next] | [standalone]
| From | Rick Jones <rick.jones2@hp.com> |
|---|---|
| Date | 2013-10-10 01:30 +0000 |
| Message-ID | <l34vvc$tki$3@usenet01.boi.hp.com> |
| In reply to | #2456 |
In comp.os.linux.networking billy <billy@is.invalid> wrote: > Everything you said is right on the money. > It's frustratingly hard to figure out. > The only two ideas "I" can come up with are: > 1. Someone is blocking me (but I can't imagine why) They may not be blocking "you" specifically, but the IP address you have from your ISP. > 2. The path is too long for something (but I don't know what). > In the first case, I'm not sure if the blocker would be the > 15th hop (which returns packets) not forwarding them on to > the Centos server or if it's the 16th hop (the Centos server) > not responding back. Is there a way to tell? Only by asking the 15th hop and getting a response. Basically, as frustrating as it is, in this matter you will be dependent on the kindness of strangers at the ISP(s) at/beyond that 15th hop. > In the second case, it would be useful to test a similarly > long (at least 16 hops) path. Or, maybe there's a way to slow > down my pings so that I can reproduce the problem in fewer hops? Hop count to reach a given server depends on topology of the Internet not the rate at which you are issuing either pings or traceroute packets. To make a possibly lame analogy, driving from NY to LA you will go trough the same intermediate cities along the highway no matter how fast you drive. rick jones -- firebug n, the idiot who tosses a lit cigarette out his car window these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
[toc] | [prev] | [next] | [standalone]
| From | billy <billy@is.invalid> |
|---|---|
| Date | 2013-10-10 01:32 +0000 |
| Message-ID | <l350di$ncp$1@speranza.aioe.org> |
| In reply to | #2464 |
Rick Jones wrote: > They may not be blocking "you" specifically, > but the IP address you have from your ISP. Understood. The last time this happened, last March, I searched all the blacklist servers I could find, an my IP address was NOT in any of them.
[toc] | [prev] | [next] | [standalone]
| From | "David W. Hodgins" <dwhodgins@nomail.afraid.org> |
|---|---|
| Date | 2013-10-09 22:25 -0400 |
| Message-ID | <op.w4pvopxla3w0dxdave@hodgins.homeip.net> |
| In reply to | #2466 |
On Wed, 09 Oct 2013 21:32:01 -0400, billy <billy@is.invalid> wrote: > Rick Jones wrote: >> They may not be blocking "you" specifically, >> but the IP address you have from your ISP. > Understood. > The last time this happened, last March, I searched > all the blacklist servers I could find, an my IP > address was NOT in any of them. I've been following the thread. Given the traceroute output, my understanding is that your isp is giving your system an RFC1918 address, within 10.*.*.*, which means the website will be seeing all connections from all customers of your isp as coming from the same ip address. It could well be that their automated software is blocking any ip address that is trying to make too many connections, in a given time frame, and keeping the address in the block list, for a specified amount of time. This may not be obvious to an admin of centos.org, without digging through the logs. 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]
| From | billy <billy@is.invalid> |
|---|---|
| Date | 2013-10-10 03:48 +0000 |
| Message-ID | <l358d9$6mg$1@speranza.aioe.org> |
| In reply to | #2467 |
David W. Hodgins wrote: > Given the traceroute output, my > understanding is that your isp is giving your system an RFC1918 > address, within 10.*.*.*, which means the website will be seeing > all connections from all customers of your isp as coming from the > same ip address. I think I understand what you're saying, because, in effect, it's what our home broadband routers do. Right? For example, the home broadband router has an IP address where all the computers behind it look, to the outside, as the IP address of the router. Are you saying that the exit node of the WISP, which is 10.0.0.1 in the traceroute below, is what they're blocking? traceroute -M icmp google.com traceroute to google.com (74.125.239.135), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 2.841 ms 2.826 ms 2.823 ms 2 67-218-118-85.ridgewireless.net (67.218.118.85) 6.188 ms 6.188 ms 6.186 ms 3 10.50.0.1 (10.50.0.1) 6.186 ms 8.402 ms 12.673 ms 4 10.25.0.1 (10.25.0.1) 12.669 ms 12.666 ms 12.663 ms 5 10.20.0.1 (10.20.0.1) 20.944 ms 59.871 ms 59.875 ms 6 10.0.0.1 (10.0.0.1) 177.035 ms 77.696 ms 77.672 ms 7 69.36.226.193 (69.36.226.193) 77.655 ms 22.190 ms 82.922 ms 8 vl2.core2.scl.layer42.net (69.36.225.130) 134.102 ms 64.071 ms 125.261 ms 9 eqixsj-google-gige.google.com (206.223.116.21) 125.244 ms 52.387 ms 52.368 ms 10 216.239.49.170 (216.239.49.170) 52.340 ms 79.126 ms 82.842 ms 11 66.249.95.31 (66.249.95.31) 82.825 ms 72.917 ms 72.886 ms 12 nuq05s02-in-f7.1e100.net (74.125.239.135) 56.810 ms 17.257 ms 22.447 ms
[toc] | [prev] | [next] | [standalone]
| From | unruh <unruh@invalid.ca> |
|---|---|
| Date | 2013-10-10 05:10 +0000 |
| Message-ID | <1Fq5u.25742$3G3.13324@fx15.iad> |
| In reply to | #2469 |
On 2013-10-10, billy <billy@is.invalid> wrote: > David W. Hodgins wrote: > >> Given the traceroute output, my >> understanding is that your isp is giving your system an RFC1918 >> address, within 10.*.*.*, which means the website will be seeing >> all connections from all customers of your isp as coming from the >> same ip address. > > I think I understand what you're saying, because, in effect, it's > what our home broadband routers do. Right? > > For example, the home broadband router has an IP address where > all the computers behind it look, to the outside, as the IP > address of the router. > > Are you saying that the exit node of the WISP, which is 10.0.0.1 > in the traceroute below, is what they're blocking? No. It had better not be 10.0.0.1 since that would not route in the outside world at all. It would not even get to the first hop, never mind 15 since nothing would know where to send the packet (there are millions of systems with that address in the world). The exit node or something further up the chain had better have a routable address. > > traceroute -M icmp google.com > traceroute to google.com (74.125.239.135), 30 hops max, 60 byte packets > 1 192.168.1.1 (192.168.1.1) 2.841 ms 2.826 ms 2.823 ms > 2 67-218-118-85.ridgewireless.net (67.218.118.85) 6.188 ms 6.188 ms > 6.186 ms > 3 10.50.0.1 (10.50.0.1) 6.186 ms 8.402 ms 12.673 ms > 4 10.25.0.1 (10.25.0.1) 12.669 ms 12.666 ms 12.663 ms > 5 10.20.0.1 (10.20.0.1) 20.944 ms 59.871 ms 59.875 ms o> 6 10.0.0.1 (10.0.0.1) 177.035 ms 77.696 ms 77.672 ms So all of the above are non-routable addresses. (ie, they cannot be routed on the public internet, but can be on a private net). That 10.0.0.1 is the address of that router as seen from inside, rather than the address it presents the world. It is really strange to get a public address and then get a bunch of private addresses. > 7 69.36.226.193 (69.36.226.193) 77.655 ms 22.190 ms 82.922 ms > 8 vl2.core2.scl.layer42.net (69.36.225.130) 134.102 ms 64.071 ms > 125.261 ms > 9 eqixsj-google-gige.google.com (206.223.116.21) 125.244 ms 52.387 > ms 52.368 ms > 10 216.239.49.170 (216.239.49.170) 52.340 ms 79.126 ms 82.842 ms > 11 66.249.95.31 (66.249.95.31) 82.825 ms 72.917 ms 72.886 ms > 12 nuq05s02-in-f7.1e100.net (74.125.239.135) 56.810 ms 17.257 ms > 22.447 ms >
[toc] | [prev] | [next] | [standalone]
| From | ein <ein@no.spam> |
|---|---|
| Date | 2013-10-10 13:24 +0200 |
| Message-ID | <l362q4$rs7$1@node2.news.atman.pl> |
| In reply to | #2470 |
[Multipart message — attachments visible in raw view] — view raw
unruh wrote: > So all of the above are non-routable addresses. (ie, they cannot be > routed on the public internet, but can be on a private net). > That 10.0.0.1 is the address of that router as seen from inside, rather > than the address it presents the world. > It is really strange to get a public address and then get a bunch of > private addresses. IMHO not really. It is a ISPs way to save let's say commonly routable public IP addresses. I've seen this many times.
[toc] | [prev] | [next] | [standalone]
| From | Chris Davies <chris-usenet@roaima.co.uk> |
|---|---|
| Date | 2013-10-10 10:31 +0100 |
| Message-ID | <qo8iiaxglc.ln2@news.roaima.co.uk> |
| In reply to | #2456 |
In comp.os.linux.networking billy <billy@is.invalid> wrote:
> 2. The path is too long for something (but I don't know what).
That's another good theory. Each time a packet goes through a router, its
"TTL" (Time To Live) is decremented. When it reaches zero the packet is
discarded. The reasoning behind this is that it handles looping routes
safely. The downside is that if the target is further away from you than
the initial TTL you can't reach it.
You can check your default TTL with this command:
cat /proc/sys/net/ipv4/ip_default_ttl
On my system it returns 64. You can change the value (as root, of course)
by using echo to write a different value to it:
sudo -s # become root
echo 128 > /proc/sys/net/ipv4/ip_default_ttl
Chris
[toc] | [prev] | [next] | [standalone]
| From | unruh <unruh@invalid.ca> |
|---|---|
| Date | 2013-10-10 17:37 +0000 |
| Message-ID | <4BB5u.32768$Zd1.3543@fx22.iad> |
| In reply to | #2473 |
On 2013-10-10, Chris Davies <chris-usenet@roaima.co.uk> wrote: > In comp.os.linux.networking billy <billy@is.invalid> wrote: >> 2. The path is too long for something (but I don't know what). > > That's another good theory. Each time a packet goes through a router, its > "TTL" (Time To Live) is decremented. When it reaches zero the packet is > discarded. The reasoning behind this is that it handles looping routes > safely. The downside is that if the target is further away from you than > the initial TTL you can't reach it. > > You can check your default TTL with this command: > > cat /proc/sys/net/ipv4/ip_default_ttl > > On my system it returns 64. You can change the value (as root, of course) > by using echo to write a different value to it: > > sudo -s # become root > echo 128 > /proc/sys/net/ipv4/ip_default_ttl > > Chris But surely his chain does not take 64 sec to reach the far end (assuming I am reading that correctly). That would be absurd. But I guess changing that default does not harm much. On the other hand, somewhere down the route that ttl could be changed by one of the other links in the chain.
[toc] | [prev] | [next] | [standalone]
| From | Chris Davies <chris-usenet@roaima.co.uk> |
|---|---|
| Date | 2013-10-11 00:01 +0100 |
| Message-ID | <v7ojiaxp05.ln2@news.roaima.co.uk> |
| In reply to | #2476 |
unruh <unruh@invalid.ca> wrote: > On 2013-10-10, Chris Davies <chris-usenet@roaima.co.uk> wrote: >> You can check your default TTL with this command: >> cat /proc/sys/net/ipv4/ip_default_ttl > But surely his chain does not take 64 sec to reach the far end (assuming > I am reading that correctly). It's not a DNS TTL, it's a hop count. 64 hops is the maximum distance packets from my system can reach. > that default does not harm much. On the other hand, somewhere down the > route that ttl could be changed by one of the other links in the chain. Each hop decrements the value by one until it hits zero. Chris
[toc] | [prev] | [next] | [standalone]
| From | billy <billy@is.invalid> |
|---|---|
| Date | 2013-10-10 20:21 +0000 |
| Message-ID | <l372jm$nd9$1@speranza.aioe.org> |
| In reply to | #2473 |
Chris Davies wrote: > You can check your default TTL with this command: > cat /proc/sys/net/ipv4/ip_default_ttl > On my system it returns 64. > sudo -s # become root > echo 128 > /proc/sys/net/ipv4/ip_default_ttl This is a great detective idea! On Knoppix, my TTL is set, by default, to 64 also: $ cat /proc/sys/net/ipv4/ip_default_ttl ==> 64 If I understand it correctly, that's 64 routers, right? I only seem to be going through 1/4 that many routers, yet, mine fails to complete the route. Still, it seems useful to increase the number & try again. I can't modify the Knoppix TTL since it's on a DVD so I will try it with another operating system and report back.
[toc] | [prev] | [next] | [standalone]
| From | unruh <unruh@invalid.ca> |
|---|---|
| Date | 2013-10-10 21:04 +0000 |
| Message-ID | <kDE5u.24913$uS4.6588@fx19.iad> |
| In reply to | #2479 |
On 2013-10-10, billy <billy@is.invalid> wrote: > Chris Davies wrote: > >> You can check your default TTL with this command: >> cat /proc/sys/net/ipv4/ip_default_ttl >> On my system it returns 64. >> sudo -s # become root >> echo 128 > /proc/sys/net/ipv4/ip_default_ttl > > This is a great detective idea! > > On Knoppix, my TTL is set, by default, to 64 also: > $ cat /proc/sys/net/ipv4/ip_default_ttl > ==> 64 > If I understand it correctly, that's 64 routers, right? > I only seem to be going through 1/4 that many routers, > yet, mine fails to complete the route. > > Still, it seems useful to increase the number & try again. > I can't modify the Knoppix TTL since it's on a DVD so I > will try it with another operating system and report back. Sure you can. Just as he says. Everything in /proc is a fake filesystem, it is NOT on the hard disk or dvd or anything. It is a look into the kernel which is of course in memory. Just do as he says. > >
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.os.linux.networking
csiph-web