[bdNOG] A Bangladesh Open University website (OSAPS) not opening.

Mon Aug 19 17:38:18 BDT 2019

Dear Brian,

Thank you very much for sharing all the technical details. It will help us, the bdNOG community, in future trouble-shootings.

The site has been accessible since Aug 11, 2019 morning as the concerned administrator looked after the issue, although he did not share any details of the problem or its trouble-shooting.

Best regards,

ANIRUDDHA BARUA 
Email: aniruddha.barua at colbd.com, cto at colbd.com

---------- Original Message -----------
From: Brian Candler <brian at nsrc.org> 
To: nog at bdnog.org 
Sent: Sat, 10 Aug 2019 18:23:19 +0100 
Subject: Re: [bdNOG] A Bangladesh Open University website (OSAPS) not opening.

> FWIW: from the UK I can connect to port 80, but get no responsefrom the webserver for a HTTP request for the home page.
> 
> $ ping osaps.bou.edu.bd
> PING osaps.bou.edu.bd (103.103.100.21): 56 data bytes
> 64 bytes from 103.103.100.21: icmp_seq=0 ttl=49time=252.833 ms
> 64 bytes from 103.103.100.21: icmp_seq=1 ttl=49time=253.525 ms
> ^C
> --- osaps.bou.edu.bd ping statistics ---
> 2 packets transmitted, 2 packets received, 0.0% packetloss
> round-trip min/avg/max/stddev =252.833/253.179/253.525/0.346 ms
> $ telnet osaps.bou.edu.bd 80
> Trying 103.103.100.21...
> Won't send login name and/or authentication information.
> Connected to osaps.bou.edu.bd.
> Escape character is '^]'.
> GET / HTTP/1.0
> 
> << hangs here >>
> $ time curl -v osaps.bou.edu.bd
> * Rebuilt URL to: osaps.bou.edu.bd/
> *   Trying 103.103.100.21...
> * TCP_NODELAY set
> * Connected to osaps.bou.edu.bd (103.103.100.21) port 80(#0)
> > GET / HTTP/1.1
> > Host: osaps.bou.edu.bd
> > User-Agent: curl/7.54.0
> > Accept: */*
> >
> 
> << hangs here >>
> * Recv failure: Connection reset by peer
> * stopped the pause stream!
> * Closing connection 0
> curl: (56) Recv failure: Connection reset by peer
> 
> real    4m3.266s
> user    0m0.011s
> sys    0m0.020s
> 
> 
> However, if I request a non-existent page, it's handledcorrectly:
> 
> $ curl -v osaps.bou.edu.bd/zxcv
> ...
> <body>
>     <div id="container">
>         <h1>404 Page Not Found</h1>
>         <p>The page you requested was notfound.</p>    </div>
> </body>
> * Closing connection 0
> Similarly if I make an invalid HTTP request:
> $ telnet osaps.bou.edu.bd 80
> Trying 103.103.100.21...
> Won't send login name and/or authentication information.
> Connected to osaps.bou.edu.bd.
> Escape character is '^]'.
> bluergh
> HTTP/1.1 400 Bad Request
> Date: Sat, 10 Aug 2019 17:21:54 GMT
> Server: Apache/2.2.15 (CentOS)
> Content-Length: 308
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
>  
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>400 Bad Request</title>
> </head><body>
> <h1>Bad Request</h1>
> <p>Your browser sent a request that this server could notunderstand.<br />
> </p>
> <hr>
> <address>Apache/2.2.15 (CentOS) Server at osaps.bou.edu.bdPort 80</address>
> </body></html>
> 
> My first reaction is that this may be something to do with MTU. That is:
> 1. I connect to the webserver
> 2. I send a HTTP request
> 3. The webserver starts sending a large request - the next packetin the TCP stream has MTU 1500 (say)
> 4. But there is a link somewhere which does not support MTU1500.  Rather than fragmenting the packets or sending back ICMPFragmentation Needed, it just throws the packets away.
> This could be a combination of an ISP which uses PPPoE (MTU1492), and a badly-configured firewall at the institution.
> 
> However, ping doesn't support this theory:
> $ ping -D -s1472 osaps.bou.edu.bd
> PING osaps.bou.edu.bd (103.103.100.21): 56 data bytes
> 64 bytes from 103.103.100.21: icmp_seq=0 ttl=49 time=252.326 ms
> 64 bytes from 103.103.100.21: icmp_seq=1 ttl=49 time=252.857 ms
> 64 bytes from 103.103.100.21: icmp_seq=2 ttl=49 time=252.153 ms
> ^C
> --- osaps.bou.edu.bd ping statistics ---
> 3 packets transmitted, 3 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 252.153/252.445/252.857/0.300 ms
> (That's for MacOS. Under Linux, use "-Mdo" instead of "-D" toprevent fragmentation)
> As far as I can see, 1500-byte packets are working end-to-end.(1472 data + 8 bytes ICMP header + 20 bytes IP header = 1500)
> 
> So more likely I think it's a problem with the webserver itself. Maybe it's running some sort of dynamic web page generationsoftware which has locked up.  Maybe it's proxying to a back-endwebserver which has locked up.  This doesn't explain why mobileusers can see the page, unless the mobile network is doingaggressive caching and always returning a cached version of thepage, or different dynamic content is being returned based onsource IP address.
> 
> Debugging on the target webserver would be the best approach IMO.
> 
> HTH,
> Brian.
------- End of Original Message -------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bdnog.org/pipermail/nog/attachments/20190819/918c0e41/attachment.html>