опция ttl в ping не распознается

1

Я проверяю pandaboard Android-2.3 (Linaro Build) на ноутбуке Linux Mint 12 с помощью этой команды:

$ ping -c 5 -t 10 192.168.50.200
PING 192.168.50.200 (192.168.50.200) 56(84) bytes of data.
64 bytes from 192.168.50.200: icmp_req=1 ttl=64 time=360 ms
64 bytes from 192.168.50.200: icmp_req=2 ttl=64 time=401 ms
64 bytes from 192.168.50.200: icmp_req=3 ttl=64 time=404 ms
64 bytes from 192.168.50.200: icmp_req=4 ttl=64 time=402 ms
64 bytes from 192.168.50.200: icmp_req=5 ttl=64 time=603 ms

--- 192.168.50.200 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 360.455/434.506/603.300/85.995 ms

Хотя я указал время жизни 10, команда ping, похоже, сохраняет значение по умолчанию 64.

  1. Что я здесь пропустил?
  2. Как я могу проверить, что моя сетевая конфигурация не препятствует использованию не 64 ТТЛ?

Когда вы делаете наоборот, то есть пингуете мой ноутбук с устройства Android, опция ttl (-t) также не принимается. Спасибо большое за вашу помощь. Эмерик

[РЕДАКТИРОВАТЬ]

# ping -c 10 -t 52 74.125.224.72
PING 74.125.224.72 (74.125.224.72) 56(84) bytes of data.
64 bytes from 74.125.224.72: icmp_seq=1 ttl=52 time=1143 ms
64 bytes from 74.125.224.72: icmp_seq=2 ttl=52 time=81.3 ms
64 bytes from 74.125.224.72: icmp_seq=3 ttl=52 time=80.2 ms
^C
--- 74.125.224.72 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2215ms
rtt min/avg/max/mdev = 80.200/435.170/1143.921/501.162 ms, pipe 2

# ping -c 10 -t 51 74.125.224.72
PING 74.125.224.72 (74.125.224.72) 56(84) bytes of data.
64 bytes from 74.125.224.72: icmp_seq=1 ttl=52 time=78.5 ms
64 bytes from 74.125.224.72: icmp_seq=2 ttl=52 time=78.5 ms
64 bytes from 74.125.224.72: icmp_seq=3 ttl=52 time=81.1 ms
64 bytes from 74.125.224.72: icmp_seq=4 ttl=52 time=78.6 ms
64 bytes from 74.125.224.72: icmp_seq=5 ttl=52 time=84.3 ms
^C
--- 74.125.224.72 ping statistics ---
6 packets transmitted, 5 received, 16% packet loss, time 5556ms
rtt min/avg/max/mdev = 78.507/80.237/84.372/2.290 ms
networking android ping м-RIC
источник

Ответы:

1

TTL, установленный для исходящего трафика, является системным параметром в большинстве операционных систем и устанавливается одинаковым для всего исходящего трафика. Это не имеет ничего общего с ICMP-ответами.

Единственная ситуация, когда системе потребуется уменьшить полученное значение TTL, - это при пересылке точной копии пакета с переписанными адресами источника и назначения из другого интерфейса, то есть при работе в качестве маршрутизатора. Запросы ICMP Echo не попадают в эту категорию.

Тем не менее, вы можете убедиться в этом, запустив перехватчик пакетов на хосте и просматривая записи перехвата входящего трафика или просматривая журналы брандмауэра, если в вашей операционной системе установлено программное обеспечение брандмауэра, которое поддерживает ведение журнала.

LawrenceC
источник
хорошо спасибо. Создание трассировки приводит меня к 13 прыжкам. И действительно, попытка пинговать с ttl из 12 не удалась, тогда как ttl из 13 удался. В любом случае, вводить опцию ttl в команду ping и видеть другое значение ttl в выводе в заблуждение. Подводя итог, вы имеете в виду, что опция "ping -t" бесполезна, кроме маршрутизатора, верно?
M-ric
Могут быть некоторые необычные ситуации, которые уменьшают TTL, когда маршрутизатор не задействован, но я не могу думать ни о чем из головы.
LawrenceC
1
@ m-ric Несмотря на то, что информация о занятом ящике в моем ответе верна, у ультразвука есть правильный ответ. Ответные пакеты создаются другим концом с использованием их собственного TTL. Невозможно увидеть, какие TTL остались в пакетах, которые они получили от вас. Я предполагаю, что реальный вопрос - «что вы пытаетесь достичь?». Почему вы хотите влиять на исходящий TTL в первую очередь?
Пол
Хорошо, спасибо вам обоим за ваше объяснение. Чтобы ответить на вопрос «чего вы пытаетесь достичь?», Он изначально должен был создать некоторый трафик на Wi-Fi, чтобы стимулировать ошибку BT / WLAN, когда оба переходят. Я пришел к опции -ttl, чтобы узнать количество переходов между моим компьютером и терминалом wlan (pandabord), а затем обнаружил, что traceroute - это инструмент, который мне нужен. Но все же я хотел знать об этой странной опции ttl в команде ping. Спасибо за ваше время.
M-ric
2

Pandaboard запускает busybox для обработки наиболее распространенных команд оболочки. Они встроены в двоичный файл busybox, а не запускаются как отдельные исполняемые файлы, как на традиционной машине Linux.

Команда busybox ping имеет только подмножество «правильных» опций, доступных в стандартном исполняемом файле ping.

Возможно, есть полный двоичный файл ping, который вы можете установить, если вам нужен ttl.

Павел
источник
Спасибо, Пол. Параметр ttl описан в ping busybox, поэтому, я считаю, что он распознается. Но кажется, что ttl, отображаемый в выходных данных команды ping, является ttl вызываемого, а не ttl вызывающего. Вы знаете?
M-ric
Хм, по крайней мере, встроенный пинг Android имеет опцию [-t ttl]. Я не использую команду busybox ping.
M-ric
Привет @Emeric - ссылка в моем ответе идет на документацию busybox, которая показывает, что она не поддерживает -t. Где ты видишь, что это делает? Обратите внимание, что текст использования с этими командами часто напрямую извлекается из исполняемого файла и поэтому не всегда отражает функциональность. Кроме того, какой встроенный Android-пинг вы имеете в виду?
Пол
Привет Пол, я фактически использовал встроенную команду ping для Android, а не команду busybox ping. В пинге Android говорится, что у него есть опция -t, а в пинге --help, по крайней мере, так сказано. Но, может быть, это не реализовано? Я только что проверил external / ping / ping.c и увидел, что usage()на него ссылаются. То же самое common_optionsработает с делом «т». Тогда Android встроенный пинг принимает -t я верю :). Мой вопрос вводит в заблуждение, я признаюсь.
м-РИК