[tex-live] www.tug.org unreachable

Rick Graham rickhg12hs at gmail.com
Mon Dec 18 21:44:29 CET 2017


... 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.

On Mon, Dec 18, 2017 at 9:30 PM, Rick Graham <rickhg12hs at gmail.com> wrote:

> 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
>
> On Dec 18, 2017 20:03, "Denis Bitouzé" <dbitouze at wanadoo.fr> wrote:
>
>> Le 18/12/17 à 13h20, Michael Shell a écrit :
>>
>> > On Mon, 18 Dec 2017 17:20:00 +0100
>> > Denis Bitouzé <dbitouze at wanadoo.fr> wrote:
>> >
>> >> WDYT?
>> >
>> > From all the information provided, it sure does look like a problem
>> > with the TUG hosting company or ISP.
>>
>> Agree?
>>
>> > Now, that said, trying disconnecting your internet connection - power
>> > down and reset your modem/router,
>>
>> That's what I'm doing every evening.
>>
>> > even disconnect it from the wall for an hour or so.
>>
>> Not disconnected but powered down every night, is it enough?
>>
>> > Try forcing a change in your router's IP address.  You
>> > can find info by doing a search for:
>> >
>> > 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.
>>
>> > 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-mt
>> u-discovery.html
>> > https://fitzcarraldoblog.wordpress.com/2010/11/30/why-cant-
>> i-access-a-specific-web-site/
>>
>> Sigh... beyond my skills.
>>
>> > 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.
>>
>> > 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...
>>
>> > Under Linux/Unix, you can do a
>> >
>> > ip link list
>>
>>   ┌────
>>   │ ╭─bitouze at 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
>>   └────
>>
>> > 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:
>>
>> Except loopback, seems to be OK, isn't it?
>>
>> > ifconfig wlan0 mtu 1450
>>
>>   ┌────
>>   │ ╭─root at drums-bis /home/bitouze
>>   │ ╰─➤  ifconfig enp0s31f6: mtu 1450
>>   └────
>>
>> but that didn't help.
>>
>> > 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
>>
>> Well, I'm not sure: what are the commands to run before?
>>
>> > 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
>>
>> Sigh... beyond my skills.
>>
>> I blindly run the commands above but no success for my problem.
>>
>> > 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?
>>
>> > 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tex-live/attachments/20171218/598c2704/attachment.html>


More information about the tex-live mailing list