Download your favorite Linux distribution at LQ ISO.
Go Back > Forums > Linux Forums > Linux - Networking
User Name
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.


  Search this Thread
Old 04-10-2017, 05:31 AM   #1
Registered: Dec 2006
Location: Bucharest
Distribution: Ubuntu 16.04 LTS
Posts: 103

Rep: Reputation: 13
Red face pppoe HTTP request sent, awaiting response

Hi, I have a computer with ppp0 direct connection to my ISP (no router/switch involved). When using Windows 7 (+ its firewall blocking everything) I can view the ISP's website When using Ubuntu (+ ufw allowing only 22, 80, 443) the ISP's website is hanging and in the end it fails.

I also tested it with wget:

wget -d
DEBUG output created by Wget 1.17.1 on linux-gnu.

Reading HSTS entries from /home/adr/.wget-hsts
URI encoding = ‘UTF-8’
--2017-04-09 20:10:06--
Resolving (, 2a02:2f0c:8000:1::2
Caching => 2a02:2f0c:8000:1::2
Connecting to (||:80... connected.
Created socket 3.
Releasing 0x000055f73be4ef70 (new refcount 1).

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.17.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
I also used curl (the same is for ISP's site):

... here waiting many seconds, then ...
curl: (56) Recv failure: Connection reset by peer
As you can see not even linuxquestions is visible though it's ip is accessible as you can see below:
traceroute to (, 64 hops max
1 3.115ms 2.720ms 2.121ms
2 5.294ms 27.983ms 4.127ms
3 42.481ms 42.629ms 42.908ms
4 41.885ms 42.258ms 42.543ms
5 46.431ms 46.491ms 46.067ms
6 113.059ms * 111.506ms
7 134.193ms 132.307ms *
8 153.352ms * *
9 150.294ms 150.133ms 149.961ms
10 150.953ms 150.023ms 149.957ms
11 148.894ms 148.974ms 148.323ms
12 149.754ms 150.046ms 149.838ms
Google's website is anyway accessible & visible.

What could be the problem and how could I debug/solve it?

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.2 LTS
Release: 16.04
Codename: xenial

uname -a
Linux adr-desktop 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Last edited by adrhc; 04-10-2017 at 07:51 AM. Reason: improved eloquence
Old 04-10-2017, 02:12 PM   #2
Ser Olmy
Senior Member
Registered: Jan 2012
Distribution: Slackware
Posts: 3,318

Rep: Reputation: Disabled
This sounds very much like an MTU (Maximum Transmission Unit) issue.

PPPoE travels over Ethernet, which typically has an MTU of 1500 bytes, but due to PPPoE overhead, the effective MTU for a PPPoE connection becomes 1492 bytes. ifconfig ppp0 | grep mtu will confirm this.

Attempts to send larger packets would normally result in fragmentation, but if a router along the return path (typically the PPPoE endpoint at your ISP) refuses to do this, and instead erroneously forwards a 1500 byte packet, you have what is known as an MTU blackhole. In this scenario, you will be able to receive packets smaller than or equal to 1492 bytes in size, but larger packets will arrive with some bytes missing and hence be silently dropped. This will basically prevent any TCP stream from functioning.

The following iptables commands implements a workaround:
iptables -t filter -I OUTPUT -o ppp0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -t filter -I FORWARD -o ppp0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
This modifies the Maximum Segment Size parameter in outgoing TCP packets to a value so small, no single packet will ever exceed your interface MTU. Not pretty, but it might work.

(If it does indeed work, you should open a support ticket with your ISP.)
1 members found this post helpful.
Old 04-11-2017, 04:34 AM   #3
Registered: Dec 2006
Location: Bucharest
Distribution: Ubuntu 16.04 LTS
Posts: 103

Original Poster
Rep: Reputation: 13
Indeed the mtu is the problem. I found solutions to learn the right mtu value, e.g. using:

ping -c 1 -M do -s 1500
ping -c 1 -M want -s 1500 -> did't tried this but seems very helpful

Somehow the first ping solution didn't help me but might help others. Theoretically smaller mtu values compared to the ISP's one should work but for me they did not (I tried 1404, 1024, 1280, etc). Instead only the exact ISP's mtu value worked (for my ISP this was 1492).

From ping man page:
-M pmtudisc_opt: select Path MTU Discovery strategy. pmtudisc_option may be either do (prohibit fragmentation, even local one), want (do PMTU discovery, fragment locally when packet size is large), or dont (do not set DF flag)


http, ppp0, pppoe, ubuntu 16.04

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Making delay for apache server to response to http request jhon123 Linux - Server 1 12-27-2013 04:48 PM
Making delay for apache server to response to http request jhon123 Linux - Server 1 12-23-2013 09:09 AM
Making delay for apache server to response to http request jhon123 Linux - Newbie 1 12-22-2013 06:58 AM
Apache response "HTTP request sent; waiting for response" too long ALInux Linux - Server 1 07-19-2011 07:45 PM
HTTP request sent, awaiting response... 401 Unauthorized Franxie Linux - Networking 1 06-17-2009 02:37 AM > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 02:02 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration