mptcp v0.x site down? breaks curl and tracebox tests

[SriramScorp]

The multipath-tcp.org site seems to be down. curl and tracebox checks against the site to check if ISP is filtering packet headers no longer works.

Same issue with http://amiusingmptcp.de too. This site seem to be broken since long.

[matttbe]

multipath-tcp.org seems working fine for me with a web browser and curl.

(I didn't try with an out-of-tree kernel, just a recent 6.1 one)

[matttbe]

I have the same issue with amiusingmptcp.de, I guess the service has been stopped

[SriramScorp]

The issue lasted for about 30 mins or so. Initially tracebox was working but curl / web requests to http://multipath-tcp.org/ redirected to the https page which showed '403 Forbidden' error. Then tracebox stopped working, followed by site access also failing with the below errors.

curl: (7) Failed to connect to multipath-tcp.org port 80: Connection timed out

curl: (7) Failed to connect to multipath-tcp.org port 80: No route to host

I guess if we intend to self host the http part, that can be done using something like MPTCP-support in Apache? How about tracebox? If I run a trace against my mptcp-capable server running shadowsocks (ss-server), the command exhausts the 64 hops without any header info beyond a few hops. Is there some server-side setup required to handle tracebox requests?

[matttbe]

The issue lasted for about 30 mins or so.

Maybe there was an update of the host, I didn't get any notifications. Everything OK now?

If I run a trace against my mptcp-capable server running shadowsocks (ss-server), the command exhausts the 64 hops without any header info beyond a few hops. Is there some server-side setup required to handle tracebox requests?

Did you specify the destination port? You just need a service listening on a specific port. By default, tracebox uses port 80. There are some examples there: https://hub.docker.com/r/matttbe/tracebox

[SriramScorp]

Everything OK now?

Yeah, everything seems to be working fine now. Only thing I notice is that the http-2-https redirection occurs sometimes, not always; And, the https page is loading some elements via http triggering a 'mixed content' error on the browser console.

Did you specify the destination port? You just need a service listening on a specific port.

Yes, I did specify the TCP port of a service running on the server. However, probe options IP/TCP/MSS/MPCAPABLE/WSCALE/tcp{dst=8010} failed and made me think I need to set something up to make it work. Apparently, the last tcp option was ignored and it was still trying to connect to port 80. Modifying the options to IP/tcp{dst=8010}/MSS/MPCAPABLE/WSCALE resolved the issue.