[tex-live] www.tug.org unreachable

[Denis Bitouzé]

Hi,

though I still receive mails from tug.org, I cannot access to
www.tug.org since a few weeks.

AFAICS, not everybody is affected by this problem:
┌────
│ http://downforeveryoneorjustme.com/tug.org
└────

I noticed tug.org is hosted by OVH (at Roubaix, less than 100 km than my
place!) so I asked OVH's team about this issue and I was told that,
since the tug.org IP (91.121.174.77) is not managed by OVH, they cannot
tell at the moment what's cause of the problem.

My Internet service provider is Bouygues Telecom, France and my current
(I guess not fixed) IP is:
┌────
│ 128.79.251.206
└────

- If you blacklisted it or a range it belongs to, could you relax this
policy?
- If not, OVH's team suggested you open a ticket.

Thanks in anticipation.

[Zdenek Wagner]

Hi,

you can try:

traceroute www.tug.org

(or tracerte in Windows) which will tell you where the problem is. Some
sites on the way may be configured not to reply so the problem may be a few
steps further than you will see.


Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

Post by Denis Bitouzé
Hi,
though I still receive mails from tug.org, I cannot access to
www.tug.org since a few weeks.
┌────
│ http://downforeveryoneorjustme.com/tug.org
└────
I noticed tug.org is hosted by OVH (at Roubaix, less than 100 km than my
place!) so I asked OVH's team about this issue and I was told that,
since the tug.org IP (91.121.174.77) is not managed by OVH, they cannot
tell at the moment what's cause of the problem.
My Internet service provider is Bouygues Telecom, France and my current
┌────
│ 128.79.251.206
└────
- If you blacklisted it or a range it belongs to, could you relax this
policy?
- If not, OVH's team suggested you open a ticket.
Thanks in anticipation.
--
Denis

[Denis Bitouzé]

Post by Zdenek Wagner
Hi,

Hi,

Post by Zdenek Wagner
traceroute www.tug.org
(or tracerte in Windows) which will tell you where the problem is. Some
sites on the way may be configured not to reply so the problem may be a few
steps further than you will see.

Here is the result (beyond my computing skills):

┌────
│ $ traceroute www.tug.org
│ traceroute to www.tug.org (91.121.174.77), 30 hops max, 60 byte packets
│ 1 gestionbbox.lan.home (192.168.1.254) 2.856 ms 2.847 ms 2.842 ms
│ 2 10.34.224.1 (10.34.224.1) 9.668 ms 14.870 ms 14.885 ms
│ 3 213-245-252-129.rev.numericable.fr (213.245.252.129) 20.362 ms 24.070 ms 23.983 ms
│ 4 212.194.173.121 (212.194.173.121) 26.848 ms 26.831 ms 26.837 ms
│ 5 350.la101.bsr01-lil.net.bbox.fr (212.194.173.120) 26.836 ms 37.914 ms 37.827 ms
│ 6 be28.cbr01-ntr.net.bbox.fr (212.194.171.70) 37.898 ms 16.232 ms 19.695 ms
│ 7 la13.rpt02-ix2.net.bbox.fr (212.194.171.90) 19.676 ms * *
│ 8 * * *
│ 9 * * *
│ 10 * * *
│ 11 rbx1-c1-a72.fr.eu (91.121.131.219) 33.827 ms vl10.rbx-g3-a72.fr.eu (94.23.122.73) 33.792 ms 33.770 ms
│ 12 * * *
│ 13 * * *
│ 14 * * *
│ 15 * * *
│ 16 * * *
│ 17 * * *
│ 18 * * *
│ 19 * * *
│ 20 * * *
│ 21 * * *
│ 22 * * *
│ 23 * * *
│ 24 * * *
│ 25 * * *
│ 26 * * *
│ 27 * * *
│ 28 * * *
│ 29 * * *
│ 30 * * *
└────

I sent it to OVH's guys. They said that, indeed, the culprit (last) IP
is an OVH one but told me to contact the tug.org administrator since the
tug.org IP (91.121.174.77) is not managed by them.

[Zdenek Wagner]

So rbx1-c1-a72.fr.eu (91.121.131.219) is the last machine which responds,
the promlem is thus somewhere between his machine and www.tug.org. I do not
know whom to contact.

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

Post by Denis Bitouzé

Post by Zdenek Wagner
Hi,

Hi,

Post by Zdenek Wagner
traceroute www.tug.org
(or tracerte in Windows) which will tell you where the problem is. Some
sites on the way may be configured not to reply so the problem may be a

few

Post by Zdenek Wagner
steps further than you will see.

┌────
│ $ traceroute www.tug.org
│ traceroute to www.tug.org (91.121.174.77), 30 hops max, 60 byte
packets
│ 1 gestionbbox.lan.home (192.168.1.254) 2.856 ms 2.847 ms 2.842 ms
│ 2 10.34.224.1 (10.34.224.1) 9.668 ms 14.870 ms 14.885 ms
│ 3 213-245-252-129.rev.numericable.fr (213.245.252.129) 20.362 ms
24.070 ms 23.983 ms
│ 4 212.194.173.121 (212.194.173.121) 26.848 ms 26.831 ms 26.837 ms
│ 5 350.la101.bsr01-lil.net.bbox.fr (212.194.173.120) 26.836 ms
37.914 ms 37.827 ms
│ 6 be28.cbr01-ntr.net.bbox.fr (212.194.171.70) 37.898 ms 16.232
ms 19.695 ms
│ 7 la13.rpt02-ix2.net.bbox.fr (212.194.171.90) 19.676 ms * *
│ 8 * * *
│ 9 * * *
│ 10 * * *
│ 11 rbx1-c1-a72.fr.eu (91.121.131.219) 33.827 ms
vl10.rbx-g3-a72.fr.eu (94.23.122.73) 33.792 ms 33.770 ms
│ 12 * * *
│ 13 * * *
│ 14 * * *
│ 15 * * *
│ 16 * * *
│ 17 * * *
│ 18 * * *
│ 19 * * *
│ 20 * * *
│ 21 * * *
│ 22 * * *
│ 23 * * *
│ 24 * * *
│ 25 * * *
│ 26 * * *
│ 27 * * *
│ 28 * * *
│ 29 * * *
│ 30 * * *
└────
I sent it to OVH's guys. They said that, indeed, the culprit (last) IP
is an OVH one but told me to contact the tug.org administrator since the
tug.org IP (91.121.174.77) is not managed by them.
--
Denis

[Denis Bitouzé]

Post by Zdenek Wagner
So rbx1-c1-a72.fr.eu (91.121.131.219) is the last machine which
responds, the promlem is thus somewhere between his machine and
www.tug.org. I do not know whom to contact.

Sigh: I don't know either.

[Norbert Preining]

Post by Denis Bitouzé
though I still receive mails from tug.org, I cannot access to
www.tug.org since a few weeks.

Can you connect to www.preining.info which is hosted by the same company
(kimsufi)?

You need to conact kimsufi https://www.kimsufi.com/en/ in case of
connection problems.

Post by Denis Bitouzé
I noticed tug.org is hosted by OVH (at Roubaix, less than 100 km than my
place!) so I asked OVH's team about this issue and I was told that,

The servers are at OVH, but they are leased (AFAIU) by kimsufi and
resold from kimsufi. OVH does not take any responsability.

Post by Denis Bitouzé
- If you blacklisted it or a range it belongs to, could you relax this
policy?

No, we don't blacklist anything AFAIR.
Karl should confirm that.

Norbert

--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

[Denis Bitouzé]

Post by Norbert Preining

Post by Denis Bitouzé
though I still receive mails from tug.org, I cannot access to
www.tug.org since a few weeks.

Can you connect to www.preining.info which is hosted by the same
company (kimsufi)?

Yes.

Post by Norbert Preining
You need to conact kimsufi https://www.kimsufi.com/en/ in case of
connection problems.

No: no connection problem.

Post by Norbert Preining

Post by Denis Bitouzé
I noticed tug.org is hosted by OVH (at Roubaix, less than 100 km than
my place!) so I asked OVH's team about this issue and I was told
that,

The servers are at OVH, but they are leased (AFAIU) by kimsufi and
resold from kimsufi. OVH does not take any responsability.

Ah, I see.

Post by Norbert Preining

Post by Denis Bitouzé
- If you blacklisted it or a range it belongs to, could you relax
this policy?

No, we don't blacklist anything AFAIR.
Karl should confirm that.

OK, thanks.

[Norbert Preining]

Tug.org is also on kimsufi so please contact kimsufi about the problem.

Post by Denis Bitouzé

Post by Norbert Preining

Post by Denis Bitouzé
though I still receive mails from tug.org, I cannot access to
www.tug.org since a few weeks.

Can you connect to www.preining.info which is hosted by the same
company (kimsufi)?

Yes.

Post by Norbert Preining
You need to conact kimsufi https://www.kimsufi.com/en/ in case of
connection problems.

No: no connection problem.

Post by Norbert Preining

Post by Denis Bitouzé
I noticed tug.org is hosted by OVH (at Roubaix, less than 100 km

than

Post by Norbert Preining

Post by Denis Bitouzé
my place!) so I asked OVH's team about this issue and I was told
that,

The servers are at OVH, but they are leased (AFAIU) by kimsufi and
resold from kimsufi. OVH does not take any responsability.

Ah, I see.

Post by Norbert Preining

Post by Denis Bitouzé
- If you blacklisted it or a range it belongs to, could you relax
this policy?

No, we don't blacklist anything AFAIR.
Karl should confirm that.

OK, thanks.

--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

[Denis Bitouzé]

Post by Norbert Preining
Tug.org is also on kimsufi so please contact kimsufi about the problem.

Done.

[Norbert Preining]

Done.

Please let us know what they are responding.

Norbert

--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

[Denis Bitouzé]

Post by Norbert Preining

Done.

Please let us know what they are responding.

Of course :)

[Denis Bitouzé]

Post by Denis Bitouzé

Post by Norbert Preining

Done.

Please let us know what they are responding.

Of course :)

Here it is:

┌────
│ From: Kimsufi Customer Service <***@kimsufi.com>
│ Subject: [TICKET#0346083364]www.tug.org unreachable
│ To: ***@wanadoo.fr
│ Date: Mon, 18 Dec 2017 16:02:58 +0000 (1 minute, 2 seconds ago)
│ Organization: Customer Service
│ X-Mailer: OTRS Mail Service (4.0.5)
│ Message-ID: <***@otrs.interne.ovh.net>
│
│ Hello,
│
│ The page opens and your IP is not in the blacklist of our network. Maybe there
│ is an issue with addresses that may access site? I mean firewall limitation?
│
│ Is it possible to reboot server in rescue mode and simply check connectivity?
│
│ If there is anything else please do not hesitate to contact us.
│
│ Kind Regards,
│ Gytis V.
│
│ Kimsufi Customer Support
│
│ ************************************************
│ NEW: OVH Public Cloud - High performance and security
│ [1]See more details ->
│ ************************************************
│
│ [2]Website [3]About KS [4]Community [5]Support [6]FAQ [7]Control Panel [8]API
│
│
│
│ [1] https://www.ovh.ie/cloud/#xtor=ES-11-[support-cloud]
│ [2] http://www.kimsufi.com/en/
│ [3] http://www.kimsufi.com/en/about-ks/
│ [4] http://www.kimsufi.com/en/community/
│ [5] http://www.kimsufi.com/en/support/
│ [6] http://www.kimsufi.com/en/faq/
│ [7] https://www.kimsufi.com/fr/manager/?lang=en_GB
│ [8] https://eu.api.kimsufi.com/
└────

WDYT?

[Michael Shell]

On Mon, 18 Dec 2017 17:20:00 +0100

WDYT?
From all the information provided, it sure does look like a problem with

the TUG hosting company or ISP.

Now, that said, trying disconnecting your internet connection - power
down and reset your modem/router, even disconnect it from the wall
for an hour or so. Try forcing a change in your router's IP address.
You can find info by doing a search for:

how reset router IP address


The above said, if I had to bet, my money would go on that the problem
you are seeing is the result of a MTU/fragmentation/ECN router bug
issue within an ISP network. See:

https://superuser.com/questions/386708/cant-access-some-websites-possible-mtu-issue-on-the-router
http://blog.glinskiy.com/2009/02/packetization-layer-path-mtu-discovery.html
https://fitzcarraldoblog.wordpress.com/2010/11/30/why-cant-i-access-a-specific-web-site/

In short, something is "special" about the packets your system is
generating, not necessarily "wrong", just "rather unique" and this
is triggering a bug in a router downstream. Of course, the network
provider doesn't believe it is their problem because, "Hey, our
stuff works for everyone else, so we *must* be OK."

Under Linux/Unix, you can do a

ip link list

to see the Maximum Transmit Unit (MTU, aka send packet size) each
of your network interfaces is using. The MTU on the outgoing interface
should not be over 1500. You should try setting it lower, to say, 1450:

ifconfig wlan0 mtu 1450

You can also try enabling Packetization Layer Path MTU Discovery
(PLPMD) and see if that has any effect:

echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

Another source of such problems is buggy routers that do not
support Explicit Congestion Notification (ECN) which is controlled
under the Linux kernel via

/proc/sys/net/ipv4/tcp_ecn

e.g.,
cat /proc/sys/net/ipv4/tcp_ecn
echo 0 > /proc/sys/net/ipv4/tcp_ecn

see for example:

http://bloat.bufferbloat.narkive.com/BtoUTYXS/ecn-blocking-router-found


Anyway, I think the line of reasoning above is on the right track,
even if not perfectly spot on with regard to the name of the
specific network parameter that is triggering the bug in your
case.

If you find the cause, please do let us (as well as the ISP) know
who is the offender.


Cheers,

Mike Shell

[Denis Bitouzé]

Post by Michael Shell
On Mon, 18 Dec 2017 17:20:00 +0100

WDYT?

From all the information provided, it sure does look like a problem
with the TUG hosting company or ISP.

Agree?

Post by Michael Shell
Now, that said, trying disconnecting your internet connection - power
down and reset your modem/router,

That's what I'm doing every evening.

Post by Michael Shell
even disconnect it from the wall for an hour or so.

Not disconnected but powered down every night, is it enough?

Post by Michael Shell
Try forcing a change in your router's IP address. You
how reset router IP address

Sigh... I read on my ISP forums that either my IP is fix and it cannot
be changed, or it is dynamic and I shouldn't have this problem since
such a long time.

Post by Michael Shell
The above said, if I had to bet, my money would go on that the problem
you are seeing is the result of a MTU/fragmentation/ECN router bug
https://superuser.com/questions/386708/cant-access-some-websites-possible-mtu-issue-on-the-router
http://blog.glinskiy.com/2009/02/packetization-layer-path-mtu-discovery.html
https://fitzcarraldoblog.wordpress.com/2010/11/30/why-cant-i-access-a-specific-web-site/

Sigh... beyond my skills.

Post by Michael Shell
In short, something is "special" about the packets your system is
generating, not necessarily "wrong", just "rather unique" and this
is triggering a bug in a router downstream.

I see.

Post by Michael Shell
Of course, the network provider doesn't believe it is their problem
because, "Hey, our stuff works for everyone else, so we *must* be OK."

Sigh...

Post by Michael Shell
Under Linux/Unix, you can do a
ip link list

┌────
│ ╭─***@drums-bis ~/
│ ╰─➤ ip link list
│ 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
│ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
│ 2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
│ link/ether 50:9a:4c:31:ce:9d brd ff:ff:ff:ff:ff:ff
│ 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
│ link/ether 52:54:00:52:29:68 brd ff:ff:ff:ff:ff:ff
│ 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN mode DEFAULT group default qlen 1000
│ link/ether 52:54:00:52:29:68 brd ff:ff:ff:ff:ff:ff
└────

Post by Michael Shell
to see the Maximum Transmit Unit (MTU, aka send packet size) each
of your network interfaces is using. The MTU on the outgoing interface

Except loopback, seems to be OK, isn't it?

Post by Michael Shell
ifconfig wlan0 mtu 1450

┌────
│ ╭─***@drums-bis /home/bitouze
│ ╰─➤ ifconfig enp0s31f6: mtu 1450
└────

but that didn't help.

Post by Michael Shell
You can also try enabling Packetization Layer Path MTU Discovery
echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

Well, I'm not sure: what are the commands to run before?

Post by Michael Shell
Another source of such problems is buggy routers that do not
support Explicit Congestion Notification (ECN) which is controlled
under the Linux kernel via
/proc/sys/net/ipv4/tcp_ecn
e.g.,
cat /proc/sys/net/ipv4/tcp_ecn
echo 0 > /proc/sys/net/ipv4/tcp_ecn
http://bloat.bufferbloat.narkive.com/BtoUTYXS/ecn-blocking-router-found

Sigh... beyond my skills.

I blindly run the commands above but no success for my problem.

Post by Michael Shell
Anyway, I think the line of reasoning above is on the right track,
even if not perfectly spot on with regard to the name of the
specific network parameter that is triggering the bug in your
case.

If my router and/or my ISP were wrong, I probably encountered this
problem with other sites, isn't it?

Post by Michael Shell
If you find the cause, please do let us (as well as the ISP) know
who is the offender.

Of course.

Many thanks for such a detailed message!

Cheers.

[Rick Graham]

Denis,

Sorry for your connectivity issues... but this is the best holiday season
mystery so far. :)

Do all computers, smartphones, etc., from your location show the same
symptoms?

Regards,
Richard

Post by Denis Bitouzé

Post by Michael Shell
On Mon, 18 Dec 2017 17:20:00 +0100

WDYT?

From all the information provided, it sure does look like a problem
with the TUG hosting company or ISP.

Agree?

Post by Michael Shell
Now, that said, trying disconnecting your internet connection - power
down and reset your modem/router,

That's what I'm doing every evening.

Post by Michael Shell
even disconnect it from the wall for an hour or so.

Not disconnected but powered down every night, is it enough?

Post by Michael Shell
Try forcing a change in your router's IP address. You
how reset router IP address

Sigh... I read on my ISP forums that either my IP is fix and it cannot
be changed, or it is dynamic and I shouldn't have this problem since
such a long time.

Post by Michael Shell
The above said, if I had to bet, my money would go on that the problem
you are seeing is the result of a MTU/fragmentation/ECN router bug
https://superuser.com/questions/386708/cant-access-

some-websites-possible-mtu-issue-on-the-router

Post by Michael Shell
http://blog.glinskiy.com/2009/02/packetization-layer-path-

mtu-discovery.html

Post by Michael Shell
https://fitzcarraldoblog.wordpress.com/2010/11/30/why-

cant-i-access-a-specific-web-site/
Sigh... beyond my skills.

Post by Michael Shell
In short, something is "special" about the packets your system is
generating, not necessarily "wrong", just "rather unique" and this
is triggering a bug in a router downstream.

I see.

Post by Michael Shell
Of course, the network provider doesn't believe it is their problem
because, "Hey, our stuff works for everyone else, so we *must* be OK."

Sigh...

Post by Michael Shell
Under Linux/Unix, you can do a
ip link list

┌────
│ ╰─➀ ip link list
│ 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
mode DEFAULT group default qlen 1
│ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
│ 2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
fq_codel state UP mode DEFAULT group default qlen 1000
│ link/ether 50:9a:4c:31:ce:9d brd ff:ff:ff:ff:ff:ff
│ 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state DOWN mode DEFAULT group default qlen 1000
│ link/ether 52:54:00:52:29:68 brd ff:ff:ff:ff:ff:ff
│ 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master
virbr0 state DOWN mode DEFAULT group default qlen 1000
│ link/ether 52:54:00:52:29:68 brd ff:ff:ff:ff:ff:ff
└────

Post by Michael Shell
to see the Maximum Transmit Unit (MTU, aka send packet size) each
of your network interfaces is using. The MTU on the outgoing interface

Except loopback, seems to be OK, isn't it?

Post by Michael Shell
ifconfig wlan0 mtu 1450

┌────
│ ╰─➀ ifconfig enp0s31f6: mtu 1450
└────
but that didn't help.

Post by Michael Shell
You can also try enabling Packetization Layer Path MTU Discovery
echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

Well, I'm not sure: what are the commands to run before?

Post by Michael Shell
Another source of such problems is buggy routers that do not
support Explicit Congestion Notification (ECN) which is controlled
under the Linux kernel via
/proc/sys/net/ipv4/tcp_ecn
e.g.,
cat /proc/sys/net/ipv4/tcp_ecn
echo 0 > /proc/sys/net/ipv4/tcp_ecn
http://bloat.bufferbloat.narkive.com/BtoUTYXS/ecn-blocking-router-found

Sigh... beyond my skills.
I blindly run the commands above but no success for my problem.

Post by Michael Shell
Anyway, I think the line of reasoning above is on the right track,
even if not perfectly spot on with regard to the name of the
specific network parameter that is triggering the bug in your
case.

If my router and/or my ISP were wrong, I probably encountered this
problem with other sites, isn't it?

Post by Michael Shell
If you find the cause, please do let us (as well as the ISP) know
who is the offender.

Of course.
Many thanks for such a detailed message!
Cheers.
--
Denis

[Rick Graham]

... I'm also curious to know if the TOR Browser
<https://www.torproject.org/projects/torbrowser.html.en> works for you,
since it will most assuredly take a different path, etc., to www.tug.org.

Post by Rick Graham
Denis,
Sorry for your connectivity issues... but this is the best holiday season
mystery so far. :)
Do all computers, smartphones, etc., from your location show the same
symptoms?
Regards,
Richard

Post by Denis Bitouzé

Post by Michael Shell
On Mon, 18 Dec 2017 17:20:00 +0100

WDYT?

From all the information provided, it sure does look like a problem
with the TUG hosting company or ISP.

Agree?

Post by Michael Shell
Now, that said, trying disconnecting your internet connection - power
down and reset your modem/router,

That's what I'm doing every evening.

Post by Michael Shell
even disconnect it from the wall for an hour or so.

Not disconnected but powered down every night, is it enough?

Post by Michael Shell
Try forcing a change in your router's IP address. You
how reset router IP address

Sigh... I read on my ISP forums that either my IP is fix and it cannot
be changed, or it is dynamic and I shouldn't have this problem since
such a long time.

Post by Michael Shell
The above said, if I had to bet, my money would go on that the problem
you are seeing is the result of a MTU/fragmentation/ECN router bug
https://superuser.com/questions/386708/cant-access-some-

websites-possible-mtu-issue-on-the-router

Post by Michael Shell
http://blog.glinskiy.com/2009/02/packetization-layer-path-mt

u-discovery.html

Post by Michael Shell
https://fitzcarraldoblog.wordpress.com/2010/11/30/why-cant-

i-access-a-specific-web-site/
Sigh... beyond my skills.

Post by Michael Shell
In short, something is "special" about the packets your system is
generating, not necessarily "wrong", just "rather unique" and this
is triggering a bug in a router downstream.

I see.

Post by Michael Shell
Of course, the network provider doesn't believe it is their problem
because, "Hey, our stuff works for everyone else, so we *must* be OK."

Sigh...

Post by Michael Shell
Under Linux/Unix, you can do a
ip link list

┌────
│ ╰─➀ ip link list
│ 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
mode DEFAULT group default qlen 1
│ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
│ 2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
fq_codel state UP mode DEFAULT group default qlen 1000
│ link/ether 50:9a:4c:31:ce:9d brd ff:ff:ff:ff:ff:ff
│ 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue state DOWN mode DEFAULT group default qlen 1000
│ link/ether 52:54:00:52:29:68 brd ff:ff:ff:ff:ff:ff
│ 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master
virbr0 state DOWN mode DEFAULT group default qlen 1000
│ link/ether 52:54:00:52:29:68 brd ff:ff:ff:ff:ff:ff
└────

Post by Michael Shell
to see the Maximum Transmit Unit (MTU, aka send packet size) each
of your network interfaces is using. The MTU on the outgoing interface

Except loopback, seems to be OK, isn't it?

Post by Michael Shell
ifconfig wlan0 mtu 1450

┌────
│ ╰─➀ ifconfig enp0s31f6: mtu 1450
└────
but that didn't help.

Post by Michael Shell
You can also try enabling Packetization Layer Path MTU Discovery
echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

Well, I'm not sure: what are the commands to run before?

Post by Michael Shell
Another source of such problems is buggy routers that do not
support Explicit Congestion Notification (ECN) which is controlled
under the Linux kernel via
/proc/sys/net/ipv4/tcp_ecn
e.g.,
cat /proc/sys/net/ipv4/tcp_ecn
echo 0 > /proc/sys/net/ipv4/tcp_ecn
http://bloat.bufferbloat.narkive.com/BtoUTYXS/ecn-blocking-router-found

Sigh... beyond my skills.
I blindly run the commands above but no success for my problem.

Post by Michael Shell
Anyway, I think the line of reasoning above is on the right track,
even if not perfectly spot on with regard to the name of the
specific network parameter that is triggering the bug in your
case.

If my router and/or my ISP were wrong, I probably encountered this
problem with other sites, isn't it?

Post by Michael Shell
If you find the cause, please do let us (as well as the ISP) know
who is the offender.

Of course.
Many thanks for such a detailed message!
Cheers.
--
Denis

[Denis Bitouzé]

Post by Rick Graham
... I'm also curious to know if the TOR Browser
<https://www.torproject.org/projects/torbrowser.html.en> works for you,
since it will most assuredly take a different path, etc., to
www.tug.org.

Bingo! That works :)

I guess we can conclude neither my router nor my configuration are the
culprits...

[Zdenek Wagner]

Post by Denis Bitouzé

Post by Rick Graham
... I'm also curious to know if the TOR Browser
<https://www.torproject.org/projects/torbrowser.html.en> works for you,
since it will most assuredly take a different path, etc., to
www.tug.org.

Bingo! That works :)
I guess we can conclude neither my router nor my configuration are the
culprits...

Yes, your computer gets and IP address form DNS, your home router can most
probably connect to your ISP only and the next routers try to find the way,
so the problem lies most probably even outside your ISP. Tor is an
anymizing service, so your computer then connects to another server which
finds the way to tug.org from somewhere else.

Post by Denis Bitouzé
--
Denis

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

[Denis Bitouzé]

Post by Zdenek Wagner

Post by Denis Bitouzé

Post by Rick Graham
... I'm also curious to know if the TOR Browser
<https://www.torproject.org/projects/torbrowser.html.en> works for you,
since it will most assuredly take a different path, etc., to www.tug.org.

Bingo! That works :)
I guess we can conclude neither my router nor my configuration are the
culprits...

Yes, your computer gets and IP address form DNS, your home router can
most probably connect to your ISP only and the next routers try to
find the way, so the problem lies most probably even outside your
ISP. Tor is an anymizing service, so your computer then connects to
another server which finds the way to tug.org from somewhere else.

I see.

[Reinhard Kotucha]

Post by Denis Bitouzé

Post by Rick Graham
... I'm also curious to know if the TOR Browser
<https://www.torproject.org/projects/torbrowser.html.en> works for you,
since it will most assuredly take a different path, etc., to
www.tug.org.

Bingo! That works :)

Denis, the actual problem is not solved so far, sorry.

When you start the Tor browswer, it says, for instance

Your IP address appears to be: 62.212.73.141

But this IP address is not yours and you get another one when you
start the browser again.

What happens is that your browser connects to this remote machine and
the remote machine sends your requests to www.tug.org and sends you
the results. This works, of course, because

http://downforeveryoneorjustme.com

already told you that everbody except you can access www.tug.org .

Using the Tor browser is probably a nice workaround for http(s) and
ftp but it doesn't help if you need rsync, for example.

Post by Denis Bitouzé
I guess we can conclude neither my router nor my configuration are
the culprits...

I can't imagine that there is something wrong at your site because you
said that everything else works fine.

BTW, tug.org and preining.info have completely different IP-numbers:

tug.org: 91.121.174.77
preining.info: 142.4.209.99

Maybe one of the routers between Calais and Roubaix is
screwed up. Can anybody tell me what * * * means in the output of
traceroute?

Regards,
Reinhard

[Alan Litchfield]

Given that is the case, has you tried using OpenDNS?

Alan
--
Dr Alan Litchfield
AlphaByte
PO Box 1941
Auckland, New Zealand 1140

Post by Reinhard Kotucha

Post by Denis Bitouzé

Post by Rick Graham
... I'm also curious to know if the TOR Browser
<https://www.torproject.org/projects/torbrowser.html.en> works for you,
since it will most assuredly take a different path, etc., to
www.tug.org.

Bingo! That works :)

Denis, the actual problem is not solved so far, sorry.
When you start the Tor browswer, it says, for instance
Your IP address appears to be: 62.212.73.141
But this IP address is not yours and you get another one when you
start the browser again.
What happens is that your browser connects to this remote machine and
the remote machine sends your requests to www.tug.org and sends you
the results. This works, of course, because
http://downforeveryoneorjustme.com
already told you that everbody except you can access www.tug.org .
Using the Tor browser is probably a nice workaround for http(s) and
ftp but it doesn't help if you need rsync, for example.

Post by Denis Bitouzé
I guess we can conclude neither my router nor my configuration are
the culprits...

I can't imagine that there is something wrong at your site because you
said that everything else works fine.
tug.org: 91.121.174.77
preining.info: 142.4.209.99
Maybe one of the routers between Calais and Roubaix is
screwed up. Can anybody tell me what * * * means in the output of
traceroute?
Regards,
Reinhard
--
------------------------------------------------------------------
Reinhard Kotucha Phone: [phone]
Marschnerstr. 25
------------------------------------------------------------------

[Zdenek Wagner]

Post by Alan Litchfield
Given that is the case, has you tried using OpenDNS?

DNS is not the problem. The problem is that a router finds a way to the IP
address through inaccessible routers.

Post by Alan Litchfield
Alan
--
Dr Alan Litchfield
AlphaByte
PO Box 1941
Auckland, New Zealand 1140

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

Post by Alan Litchfield
... I'm also curious to know if the TOR Browser
<https://www.torproject.org/projects/torbrowser.html.en> works for you,
since it will most assuredly take a different path, etc., to
www.tug.org.
Bingo! That works :)
Denis, the actual problem is not solved so far, sorry.
When you start the Tor browswer, it says, for instance
Your IP address appears to be: 62.212.73.141
But this IP address is not yours and you get another one when you
start the browser again.
What happens is that your browser connects to this remote machine and
the remote machine sends your requests to www.tug.org and sends you
the results. This works, of course, because
http://downforeveryoneorjustme.com
already told you that everbody except you can access www.tug.org .
Using the Tor browser is probably a nice workaround for http(s) and
ftp but it doesn't help if you need rsync, for example.
I guess we can conclude neither my router nor my configuration are
the culprits...
I can't imagine that there is something wrong at your site because you
said that everything else works fine.
tug.org: 91.121.174.77
preining.info: 142.4.209.99
Maybe one of the routers between Calais and Roubaix is
screwed up. Can anybody tell me what * * * means in the output of
traceroute?
Regards,
Reinhard
--
------------------------------------------------------------------
Reinhard Kotucha Phone: [phone]
<+49%20511%203373112>
Marschnerstr. 25
<https://maps.google.com/?q=Marschnerstr.+25+D-30167+Hannover&entry=gmail&source=g>
D-30167 Hannover
<https://maps.google.com/?q=Marschnerstr.+25+D-30167+Hannover&entry=gmail&source=g>
------------------------------------------------------------------

[Zdenek Wagner]

Hi all,

it seems to me that the problem is at the router at position 7 in the
traceroute output sent by Denis. Yo can see that if responds only once, the
next two attmpts fail, and when TTL is set to 11 hops, two different paths
are attempted. I tried to access this router just now and it is
inaccessible. Or probably the problem is even on router 6 that should have
never tried the next one and use another path. It is definitely not a
problem of DNS because my computer finds the same IP address. So DNS
spoofing is not the problem. This is my trace:

$ traceroute www.tug.org
traceroute to www.tug.org (91.121.174.77), 30 hops max, 60 byte packets
1 gate.czw57 (192.168.1.1) 9.945 ms 9.936 ms 9.931 ms
2 62-141-11-99.tmcz.cz (62.141.11.99) 10.023 ms 10.235 ms 16.212 ms
3 62-141-13-18.tmcz.cz (62.141.13.18) 16.271 ms 19.412 ms 23.496 ms
4 62.168.52.65 (62.168.52.65) 22.326 ms 24.754 ms 28.199 ms
5 ae-2.fra2027-ex1.gtsce.net (193.85.195.94) 35.877 ms 39.003 ms
41.273 ms
6 * * *
7 be103.rbx-g1-nc5.fr.eu (178.33.100.158) 60.547 ms 58.720 ms 62.512 ms
8 * * *
9 vl10.rbx-g3-a72.fr.eu (94.23.122.73) 55.899 ms 54.242 ms 56.437 ms
10 * * *
11 tug.org (91.121.174.77) 37.863 ms !X 37.069 ms !X 39.435 ms !X

Now, comparing again my route with that found by Denis, I see that
vl10.rbx-g3-a72.fr.eu is on the right path but Denis is sometimes sent by
router #7 to a wrong direction. Both http, https, and ftp are TCP services
and establishing a connection requires sending several packets. If they do
not go correctly to the server, connection will never be established.


Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

Post by Zdenek Wagner

Post by Alan Litchfield
Given that is the case, has you tried using OpenDNS?

DNS is not the problem. The problem is that a router finds a way to the IP
address through inaccessible routers.

Post by Alan Litchfield
Alan
--
Dr Alan Litchfield
AlphaByte
PO Box 1941
Auckland, New Zealand 1140

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

Post by Alan Litchfield
... I'm also curious to know if the TOR Browser
<https://www.torproject.org/projects/torbrowser.html.en> works for you,
since it will most assuredly take a different path, etc., to
www.tug.org.
Bingo! That works :)
Denis, the actual problem is not solved so far, sorry.
When you start the Tor browswer, it says, for instance
Your IP address appears to be: 62.212.73.141
But this IP address is not yours and you get another one when you
start the browser again.
What happens is that your browser connects to this remote machine and
the remote machine sends your requests to www.tug.org and sends you
the results. This works, of course, because
http://downforeveryoneorjustme.com
already told you that everbody except you can access www.tug.org .
Using the Tor browser is probably a nice workaround for http(s) and
ftp but it doesn't help if you need rsync, for example.
I guess we can conclude neither my router nor my configuration are
the culprits...
I can't imagine that there is something wrong at your site because you
said that everything else works fine.
tug.org: 91.121.174.77
preining.info: 142.4.209.99
Maybe one of the routers between Calais and Roubaix is
screwed up. Can anybody tell me what * * * means in the output of
traceroute?
Regards,
Reinhard
--
------------------------------------------------------------------
Reinhard Kotucha Phone: [phone]
<+49%20511%203373112>
Marschnerstr. 25
<https://maps.google.com/?q=Marschnerstr.+25+D-30167+Hannover&entry=gmail&source=g>
D-30167 Hannover
<https://maps.google.com/?q=Marschnerstr.+25+D-30167+Hannover&entry=gmail&source=g>
------------------------------------------------------------------

[Denis Bitouzé]

Post by Zdenek Wagner
Hi all,

Hi Zdenek,

Post by Zdenek Wagner
it seems to me that the problem is at the router at position 7 in the
traceroute output sent by Denis. Yo can see that if responds only
once, the next two attmpts fail, and when TTL is set to 11 hops, two
different paths are attempted. I tried to access this router just now
and it is inaccessible. Or probably the problem is even on router
6 that should have never tried the next one and use another path. It
is definitely not a problem of DNS because my computer finds the same
$ traceroute www.tug.org
traceroute to www.tug.org (91.121.174.77), 30 hops max, 60 byte packets
1 gate.czw57 (192.168.1.1) 9.945 ms 9.936 ms 9.931 ms
2 62-141-11-99.tmcz.cz (62.141.11.99) 10.023 ms 10.235 ms 16.212 ms
3 62-141-13-18.tmcz.cz (62.141.13.18) 16.271 ms 19.412 ms 23.496 ms
4 62.168.52.65 (62.168.52.65) 22.326 ms 24.754 ms 28.199 ms
5 ae-2.fra2027-ex1.gtsce.net (193.85.195.94) 35.877 ms 39.003 ms
41.273 ms
6 * * *
7 be103.rbx-g1-nc5.fr.eu (178.33.100.158) 60.547 ms 58.720 ms 62.512 ms
8 * * *
9 vl10.rbx-g3-a72.fr.eu (94.23.122.73) 55.899 ms 54.242 ms 56.437 ms
10 * * *
11 tug.org (91.121.174.77) 37.863 ms !X 37.069 ms !X 39.435 ms !X
Now, comparing again my route with that found by Denis, I see that
vl10.rbx-g3-a72.fr.eu is on the right path but Denis is sometimes sent
by router #7 to a wrong direction. Both http, https, and ftp are TCP
services and establishing a connection requires sending several
packets. If they do not go correctly to the server, connection will
never be established.

Many thanks for this insightful analysis!

[Denis Bitouzé]

Post by Zdenek Wagner

Post by Alan Litchfield
Given that is the case, has you tried using OpenDNS?

DNS is not the problem. The problem is that a router finds a way to
the IP address through inaccessible routers.

I see.

[Denis Bitouzé]

Post by Alan Litchfield
Given that is the case, has you tried using OpenDNS?

No, I didn't but I could give a try.

[Zdenek Wagner]

Post by Reinhard Kotucha

Post by Denis Bitouzé

Post by Rick Graham
... I'm also curious to know if the TOR Browser
<https://www.torproject.org/projects/torbrowser.html.en> works for

you,

Post by Denis Bitouzé

Post by Rick Graham
since it will most assuredly take a different path, etc., to www.tug.org.

Bingo! That works :)

Denis, the actual problem is not solved so far, sorry.
When you start the Tor browswer, it says, for instance
Your IP address appears to be: 62.212.73.141
But this IP address is not yours and you get another one when you
start the browser again.
What happens is that your browser connects to this remote machine and
the remote machine sends your requests to www.tug.org and sends you
the results. This works, of course, because
http://downforeveryoneorjustme.com
already told you that everbody except you can access www.tug.org .
Using the Tor browser is probably a nice workaround for http(s) and
ftp but it doesn't help if you need rsync, for example.

Exactly. Tor is primarily used to hide your identity from the target
server so that you cannot be tracked and the cookies, if there are used,
cannot identify your computer.

Post by Reinhard Kotucha

Post by Denis Bitouzé
I guess we can conclude neither my router nor my configuration are
the culprits...

I can't imagine that there is something wrong at your site because you
said that everything else works fine.
tug.org: 91.121.174.77
preining.info: 142.4.209.99
Maybe one of the routers between Calais and Roubaix is
screwed up. Can anybody tell me what * * * means in the output of
traceroute?
Regards,
Reinhard
Traceroute tries "ping" to the target with limited TTL (time to live). It

starts with one hop, tries 3 times and then increases the number of hops by
one and tries again until it either reaches the target or 30 hops. If set
initially to 1 hop, the packet expires at the very first router and its IP
address is returned. With 2 hops the IP packet gets on step further so this
way you can trace the whole way. * * * means that no reply packet was
received which may have one of two reasons:

1. The router is configured not to reply for ping packet
2. The router is unreachable

It is quite common to have * * * in the middle of a route but in any cas
you find the IP address of the furthest router that responded.


Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

Post by Reinhard Kotucha
--
------------------------------------------------------------------
Reinhard Kotucha Phone: [phone]
Marschnerstr. 25
------------------------------------------------------------------

[Reinhard Kotucha]

Post by Reinhard Kotucha

Post by Reinhard Kotucha
Can anybody tell me what * * * means in the output of
traceroute?

Traceroute tries "ping" to the target with limited TTL (time to
live). It starts with one hop, tries 3 times and then increases the
number of hops by one and tries again until it either reaches the
target or 30 hops. If set initially to 1 hop, the packet expires at
the very first router and its IP address is returned. With 2 hops
the IP packet gets on step further so this way you can trace the
whole way. * * * means that no reply packet was received which may
1. The router is configured not to reply for ping packet
2. The router is unreachable
It is quite common to have * * * in the middle of a route but in
any cas you find the IP address of the furthest router that
responded.

Thank you Zdeněk

Regards,
Reinhard

[Denis Bitouzé]

Post by Reinhard Kotucha

Post by Denis Bitouzé

Post by Rick Graham
... I'm also curious to know if the TOR Browser
<https://www.torproject.org/projects/torbrowser.html.en> works for you,
since it will most assuredly take a different path, etc., to www.tug.org.

Bingo! That works :)

Denis, the actual problem is not solved so far, sorry.

Sigh...

Post by Reinhard Kotucha
When you start the Tor browswer, it says, for instance
Your IP address appears to be: 62.212.73.141
But this IP address is not yours and you get another one when you
start the browser again.

I see.

Post by Reinhard Kotucha
What happens is that your browser connects to this remote machine and
the remote machine sends your requests to www.tug.org and sends you
the results. This works, of course, because
http://downforeveryoneorjustme.com
already told you that everbody except you can access www.tug.org .
Using the Tor browser is probably a nice workaround for http(s) and
ftp but it doesn't help if you need rsync, for example.

Sigh...

Post by Reinhard Kotucha

Post by Denis Bitouzé
I guess we can conclude neither my router nor my configuration are
the culprits...

I can't imagine that there is something wrong at your site

My site? Probably tug.org instead, isn't it? :)

Post by Reinhard Kotucha
because you said that everything else works fine.
tug.org: 91.121.174.77
preining.info: 142.4.209.99

Okay.

Post by Reinhard Kotucha
Maybe one of the routers between Calais and Roubaix is
screwed up. Can anybody tell me what * * * means in the output of
traceroute?

I don't know exactly myself.

Regards.

[Denis Bitouzé]

Post by Rick Graham
Sorry for your connectivity issues... but this is the best holiday
season mystery so far. :)

;)

Post by Rick Graham
Do all computers, smartphones, etc., from your location show the same
symptoms?

Yes, either with a laptop or a smartphone connected to my router by
WiFi.

Regards.

[Karl Berry]

Denis - please try now, with my apologies. It's all my fault.

Sorry that the mystery is actually so uninteresting, but the answer is
that I do have to blacklist a few addresses/ranges -- spiders that don't
respect robots.txt and try to crawl our entire svn tree (with all
history), which is just too much. I don't have any foolproof way of
detecting them, and I wrongly added 128.79.251.206 to the list at one
point. --sorry, karl.

[Denis Bitouzé]

Post by Karl Berry
Denis - please try now,

Works perfectly! :)

Post by Karl Berry
with my apologies. It's all my fault.

As a sentence, I suggest you entirely rewrite the TeXbook with Word! ;)

Post by Karl Berry
Sorry that the mystery is actually so uninteresting, but the answer is
that I do have to blacklist a few addresses/ranges -- spiders that
don't respect robots.txt and try to crawl our entire svn tree (with
all history), which is just too much. I don't have any foolproof way
of detecting them, and I wrongly added 128.79.251.206

How do you know this is this IP which is involved?

Post by Karl Berry
to the list at one point. --sorry, karl.

You're forgiven, of course! :)

[Werner LEMBERG]

Post by Denis Bitouzé

Post by Karl Berry
Denis - please try now,

Works perfectly! :)

It was interesting to read this discussion, and it is great to see so
many helpful people here. Being a complete noob, however, I wonder
whether there is a possibility to find out such blocking more easily –
if I understand the issue correctly, all of the suggested solutions
were flawed more or less, pointing to the wrong places.


Werner

[Zdenek Wagner]

Post by Werner LEMBERG

Post by Denis Bitouzé

Post by Karl Berry
Denis - please try now,

Works perfectly! :)

It was interesting to read this discussion, and it is great to see so
many helpful people here. Being a complete noob, however, I wonder
whether there is a possibility to find out such blocking more easily –
if I understand the issue correctly, all of the suggested solutions
were flawed more or less, pointing to the wrong places.
If a problem lies somewhere in a network it is always difficult. The

reason can usually be found in the log files but you need log files from
several sites and each of them is accessible by a different person. Thus
you can just guess and try to find a person with access to the right log
file.


Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

Post by Werner LEMBERG
Werner

[Ulrike Fischer]

Post by Denis Bitouzé

Post by Karl Berry
, and I wrongly added 128.79.251.206

How do you know this is this IP which is involved?
My Internet service provider is Bouygues Telecom, France and my current
┌────
│ 128.79.251.206
└────

[Denis Bitouzé]

Post by Denis Bitouzé

Post by Karl Berry
, and I wrongly added 128.79.251.206

How do you know this is this IP which is involved?
My Internet service provider is Bouygues Telecom, France and my current
┌────
│ 128.79.251.206
└────

Ooops! Sorry for the noise.

[Michael Shell]

On Mon, 18 Dec 2017 22:52:32 GMT

I wrongly added 128.79.251.206 to the list at one point.

Thanks for solving it Karl! I had forgetten to cc the list one of my email
replies to Denis. From that, he had indicated that he could reach the
tug webiste via a anonymous web proxy (like the TOR idea from Rick Graham
which worked), but knowing that doesn't help us much to understanding why
he was blocked. Still, it is great to have these workarounds if needed in
a pinch.

A good clue was when Denis said that both his laptop and smartphone were
blocked. So, knowing that, it was then very unlikely to be a network/OS
configuration issue on (both) those very different devices - it then
had to be one of the routers on the chain to tug.org, or the server
itself.

Denis, I would still ask your ISP (and/or do a net search for reset IP
for your router model) to find out if there is anyway for you to be able
to change/reset the IP number your router is using. Because one day this
kind of problem might happen again with another site and there likely
won't be such a helpful "Karl" at the server end to open the blocked
IP for you.


Cheers,

Mike

[Zdenek Wagner]

Post by Michael Shell
On Mon, 18 Dec 2017 22:52:32 GMT

I wrongly added 128.79.251.206 to the list at one point.

...
Denis, I would still ask your ISP (and/or do a net search for reset IP
for your router model) to find out if there is anyway for you to be able
to change/reset the IP number your router is using. Because one day this
kind of problem might happen again with another site and there likely
won't be such a helpful "Karl" at the server end to open the blocked
IP for you.

I believe that it was just a mistake and there is very low probability that
it will become again. And such mistakes remain unnoticed if a person does
not complain because at the server side everything works as it should.
Changing IP address may be impossible, For instance, my home ADLS router
has ficed IP address and I am glad to have it. Other computers (allowed by
me) can automatically connect to my diskstation and send backups. Andsomer
servers allow administrative access from whitelisted IP address so without
a fixed IP address I would not be allowed to do my work. So there are good
reasons to have an unchangable fixed IP address and ISP may assign it as
default.

Post by Michael Shell
Cheers,
Mike

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

[Philip Taylor (RHUoL)]

[...] So there are good reasons to have an unchangable fixed IP
address and ISP may assign it as default.

If only !  I have to pay for a single fixed IP address at home, and in
the hotel we have to pay for a block of five fixed IP addresses on our
FTTP connection and a further one on our ADSL2+; I very much doubt
whether any major ISP offers a fixed IP address without charge.
** Phil.

[Karl Berry]

[We are way off-topic here, but adding one more msg to the pile ...]

Hi Werner,

all of the suggested solutions were flawed more or less,

No: blacklisting was suggested early. But no one besides me had the
crucial information that tug.org was indeed blacklisting a few
addresses, and all the other intervening messages happened before I even
saw the discussion. Unfortunately I did not think of this the first time
Denis raised his issue, a week or two ago.

The traceroutes were consistent with blacklisting -- from Denis's host
it got to the last router before tug and then * * *'d, whereas from
other hosts it got past that to tug. That was the most definitive
information. There's no way to prove blacklisting without access to the
host, as Zdenek said.

FWIW, I have seen all of the other suggested culprits cause
trouble in other situations, from packet fragmentation onward.

I have the idea that fail2ban could be used nowadays to detect
problematic spiders; that would be much preferable to my hardcoded
iptables-level blacklist, since it would expire after a while and give
the IP another chance to behave itself. But the last time I looked at
the various fail2ban filters in this area, none seemed like what I
really wanted -- they wanted heavyweight databases (no thanks), or
depended on third-party blacklists (no thanks), or had other issues, and
I couldn't quite get to hacking one myself. If anyone has any
recommendations in this regard, I'd like to hear them (but probably best
to write me off-list, as this has nothing to do with TeX Live).

Thanks,
Karl

[Werner LEMBERG]

Post by Karl Berry
[We are way off-topic here, but adding one more msg to the pile ...]

Thanks for the explanation! As mentioned before, I'm a complete noob
here, and fortunately I'm not involved in managing such issues...


Werner