Request timeout for icmp_seq
I was getting the exact same thing when trying to ping my Mac from my iPhone that were on the same Airport Extreme wifi network. My firewall on my Mac was turned off. I ended up doing a reboot of the Airport Extreme and it all started working.
Apr 6, 2016 at 15:08
1 Answer 1
The reply means the target host is unreachable which is not an error and can happen using a plain ‘ping’ as well. Now, using the -f(lood) option, some firewalls or hosts can believe it’s a DoS attack and drop the icmp packets silently.
Do you really need this -f option ? It can overflow the network and should be avoided as much as possible.
3,985 10 10 gold badges 34 34 silver badges 46 46 bronze badges
answered Feb 25, 2015 at 13:23
Pyrophorus Pyrophorus
289 1 1 silver badge 3 3 bronze badges
If your network settings were wrong, you would have other problems. Now, some hosts don’t reply to icmp at all (for security reasons). Try a simple ‘ping URL’ to see what happens. There is no difference between ping and ping -f packets, only the emission rate. If the plain ping don’t work, the ping -f will certainly not. You can try a port scan as well.
Request timeout for icmp seq что значит
Дорогие пользователи! У нас появился новый форум на платформе tp-link.community (Сообщество)
Если при регистрации в Сообществе Вы укажете адрес электронный почты, который используете на данном форуме, то Ваши данные будут перенесены на форум Сообщества автоматически.
Также, если на форуме Сообщества Ваш никнейм будет занят, то Вам предложат сменить его или оставить, но с приставкой «_RU».
Убедительная просьба не дублировать темы на старом/новом форуме.
Потеря пакетов. Низка скорость интернета
Беспроводной маршрутизатор серии Lite N, до 150Мбит/с
10 сообщений • Страница 1 из 1
usver Сообщения: 5 Зарегистрирован: 09 фев 2017, 15:22 Страна: Россия
Потеря пакетов. Низка скорость интернета
Сообщение usver » 09 фев 2017, 15:36
Название темы : Потеря пакетов. Низка скорость интернета
Аппаратная версия устройства : 1.2
Провайдер : СВС Телеком
Тип подключения : Static IP
Описание проблемы : Здравствуйте. Проблема с роутером довольно банальная, но все же, может быть есть возможность, как-то ее решить? Начал замечать, что скорость загрузки сайтов упала, иногда очень долго загружаются, иногда вообще с первого раза не удается открыть страницу. Начал разбираться и обнаружил, что имеет место быть потеря пакетов. Проверил догадку, подключившись напрямую к кабелю провайдера — все четко. Никаких потерь и задержек. Обновил прошивку с офф. сайта — не помогло. Скажите, есть ли решение данной проблемы?
Результаты диагностики из админки роутера:
Pinging ya.ru [213.180.204.3] with 64 bytes of data: Request timed out. Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=2 Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=3 Request timed out. Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=5 Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=6 Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=7 Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=8 Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=9 Request timed out. Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=11 Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=12 Request timed out. Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=14 Request timed out. Request timed out. Request timed out. Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=18 Request timed out. Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=20 Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=21 Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=22 Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=23 Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=24 Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=25 Request timed out. Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=27 Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=28 Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=29 Reply from 213.180.204.3: bytes=64 time=1 TTL=57 seq=30 Ping statistics for ya.ru Packets: Sent = 30, Received = 21, Lost = 9 (30% loss), Approximate round trip times in milliseconds: Minimum = 1, Maximum = 1, Average = 1
Tracing route to yandex.ru [5.255.255.60] over a maximum of 30 hops 1 1ms 1ms 1ms 10.172.148.1 2 1ms 1ms 1ms 172.16.13.3 3 1ms 1ms 1ms 172.16.10.1 4 1ms 1ms 1ms 91.211.105.57 5 1ms * 1ms 195.208.210.21 6 * * 1ms 213.180.213.88 7 1ms 1ms 1ms 87.250.239.83 8 1ms 1ms 1ms 5.255.255.60 Trace complete.
Web server is working, but ping returns a request timeout for icmp_seq [closed]
The problem is, that when I ping the server, I get this result:
PING XX.XX.XX.XX (XX.XX.XX.XX): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 Request timeout for icmp_seq 4 Request timeout for icmp_seq 5
So I guess it has something to do with the iptables. As you can see, the sites inside the server are running just fine:
nmap -p 80 XX.XX.XX.XX Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-27 09:44 CDT Nmap scan report for XX.XX.XX.XX Host is up (0.0019s latency). PORT STATE SERVICE 80/tcp open http
So, the question is: what can I do to avoid the ping timeout? (and what are the disadvantages of returning a ping timeout?)
Dissecting a U.U.U ping response
Once every so often, in the course of troubleshooting, you’ll encounter a somewhat odd response to a ping: U.U.U. Recall that the dot signifies that a response was not received before the request timed out, while the U indicates an ICMP unreachable message was received from a router somewhere along the path. But why do the responses alternate?
The answer to this question lies in how a router performs ICMP rate limiting. Cisco IOS will, by default, rate-limit ICMP replies to one every 500ms. We can view active ICMP rate-limiting with show ip icmp rate-limit :
Router# show ip icmp rate-limit DF bit unreachables All other unreachables Interval (millisecond) 500 500 Interface # DF bit unreachables # All other unreachables --------- --------------------- ------------------------ FastEthernet0/0 0 0 .
We must also realize that the default ping timeout on IOS is two seconds. Armed with this information, we can trace how the ping results were formed. Assume Router A is attempting to ping an unreachable subnet via Router B.
- Router A sends its first echo request, and Router B responds with an ICMP unreachable message. Router B cannot send another unreachable message for 500ms. Router A receives the unreachable message and reflects it on the console as a U.
- The second echo request is sent by Router A. This time, Router B doesn’t respond with an ICMP unreachable message because the 500ms window has not passed yet.
- Router A waits for two seconds without receiving a response, then sends its third ICMP request. By now, the 500ms window on Router B has expired, so router B responds with a second ICMP unreachable message. Router B starts its 500ms timer again, and the console on router A now reflects U.U
- Router A sends its fourth echo request. Because Router B is waiting for its rate-limit window to expire again, it does not respond. Router A again waits two seconds without receiving an echo reply before marking another . on the console.
- The fifth echo request is answered with an ICMP unreachable message because the two-second delay on Router A again allows the 500ms window on Router B to expire, completing the U.U.U result observed on Router A’s console.
The two response types will alternate indefinitely until the querying router stops sending pings. Note that this example assumes Router B hasn’t responded to any other traffic with ICMP unreachable messages, which would skew its rate-limiting window and likely alter the results observed on Router A. Also keep in mind that other conditions, particularly load-balancing, can create the same effect, but the scenario discussed here is the most probable cause.
Support PacketLife by buying stuff you don’t need!