[tex-live] www.tug.org unreachable

Rick Graham rickhg12hs at gmail.com
Mon Dec 18 21:30:59 CET 2017


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-
> mtu-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/736439d7/attachment-0001.html>


More information about the tex-live mailing list