- Печать
Страницы: [1] 2 Все Вниз
Тема: Проблемы шлюза на основе Yota (решено) (Прочитано 14400 раз)
0 Пользователей и 1 Гость просматривают эту тему.
diw-volkodav
Купил для фирмы модем, воткнул, установил дрова. Инет завелся. Поставил firestarter, настроил раздачу инета. Все заработало. На виндовых машинах инет есть, но есть НО: периодически, при от правке большого письма или закачке по FTP, как будто сбрасывается соединение. Ползунок (закачки\отправления) просто зависает на каком-то этапе и все. Манагерам приходится (отправлять письмо\закачивать по FTP) по несколько раз. Стоит Ubuntu Server 8.04.3. Куда копать подскажет кто-нибудь? Спасибо
« Последнее редактирование: 11 Августа 2009, 11:39:32 от diw-volkodav »
AnrDaemon
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.
Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…
diw-volkodav
MTU/MRU проверь.
ну я на шлюзе делаю ifconfig. мне показываются соединения и их MTU. Вижу, что у Йоты 1386(вроде как должно быть). Все правильно делаю?
Пользователь решил продолжить мысль 04 Августа 2009, 20:53:56:
все ли я правильно понимаю: проблема с MTU молжет быть именно на клиентских машинах с виндой?
« Последнее редактирование: 04 Августа 2009, 20:53:56 от diw-volkodav »
AnrDaemon
На шлюзе, ибо он должен пересобрать зароучиваемые пакеты.
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.
Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…
diw-volkodav
ну, вообщем, погуглив, нашел разные MTU для Yotы, но большиство все-таки 1386, как в моем случае. И еще, интерфейс йоты добавляется автоматом при вставке модема, и значение MTU так же выставляется по умолчанию. Но, все-таки, не могу понять, как разобраться, верное ли это значение MTU
AnrDaemon
По-моему тут уже были топики про йоту… фпоиск, та?
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.
Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…
diw-volkodav
эти топики за неделю я уже почти выучил, везде рекомендуют MTU 1386
AnrDaemon
Не знаю, откуда 1386, должно быть 1388 по идее.
Попробуй еще разок уменьшить.
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.
Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…
diw-volkodav
а если настройки ифейса устанавливаются при вставке модема в USB, тогда MTU меняется только на сеанс? Потому что я вытаскивал модем, лез в /etc/network/interfaces так вот там настроек йоты вроде записано не было(проверить не могу сейчас, не на работе)
в одном из топиков про настройку шлюза с йотой видел такую строку
sudo ifconfig wimax0 MTU 1372
значение — все равно, но сам оператор не срабатывает. при такой команде выдается MTU unknown host
AnrDaemon
Через NM настраивается? Тогда да, interfaces будет пустым.
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.
Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…
diw-volkodav
не, настраивается не через NM, я как дрова поставил для модема, так для Йоты вообще ничего не писал, как только модем втыкается, лампочка загорается синим, интерфейс сам подымается. В этом все дело.
AnrDaemon
Поскольку само в линуксе ничего не происходит (вообще), значит, либо NM либо что-то еще.
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.
Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…
diw-volkodav
Итак дамы и господа, все решилось. помог Laplanya и его ветка
https://forum.ubuntu.ru/index.php?topic=61372.msg479833#msg479833
и неделя гугления. Итак, делал я все как указано в ссылочке выше, кроме пункта про дхцп(у меня все IP статичные).
поэтому в dnsmasq.conf пунктик «no dhcp=» раскомментил и поставил yes. Далее все опять как писал Laplanya до пункта со скриптом gateway. Я звонил в Yota, спрашивал какой mtu рекомендован, сказали 1372, все как у него написано. Но в этот же скрипт Laplanya посоветовал мне добавить
ifconfig eth0 mtu 1372, т.е. меняем значение mtu для интерфейса, смотрящего в сеть. Получилось
#!/bin/sh
ifconfig wimax0 mtu 1372
ifconfig eth0 mtu 1372
iptables -t nat -A POSTROUTING -o wimax0 -j MASQUERADE
теперь перезагрузка. Важное дополнение:
все компы у меня пока на виндовз(если это важно кому-то), так вот, на каждой клиентской машине программой drtcp021 менял значение mtu =1350 для сетевых адаптеров. можно, конечно и руками это сделать в реестре, но мне лень было. И только после этого у меня стали быстренько открываться сайты, работать ftp, и нормально отправляться письма. Еще попробовал вариант wimax0 mtu=1386(ставиться драйвером по умолчанию) значение mtu eth0 не менял(1500 стандарт) а у клиентов ставил 1372 и тоже все работало. Как я понял, как кому повезет.
AnrDaemon
Ну, везение тут — штука бессмысленная и бесполезная.
Размер mtu/mru узнается просто — ставишь MTU 1500, пингуешь узел ЗА шлюзом (а лучше — вообще где-нить в инете) нефрагментированными пакетами максимального размера.
Как только пакет перестает проходить — к последнему рабочему значению размера пакета прибавляешь 28.
Пример?
1372+28 = 1400, что предсказуемо — на трассе стоит роутер, подключенный в интернет по VPN. 1400 — стандартное значение MTU для VPN клиентов.
« Последнее редактирование: 11 Августа 2009, 13:45:34 от AnrDaemon »
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.
Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…
diw-volkodav
спасибо, объяснили:)
Пользователь решил продолжить мысль 11 Августа 2009, 14:49:31:
по этой логике получается, что значение MTU для клиентов должно быть 1372-28=1344? или я не прав?
« Последнее редактирование: 11 Августа 2009, 14:49:31 от diw-volkodav »
- Печать
Страницы: [1] 2 Все Вверх
Время на прочтение
4 мин
Количество просмотров 7.4K
В условиях загородного дома тоже хочется иметь качественный и быстрый доступ в интернет.
К сожалению, проводной интернет за городом не всегда возможен ввиду отсутствия проводов (телефонных и/или сетевых от провайдера интернета). А даже при наличии телефонных проводов в доме и установленного на АТС оборудования ADSL, состояние «последней мили» таково, что передача данных по технологии ADSL невозможна (или возможна на таких низких скоростях, что провайдеру ADSL это совершенно не интересно).
В такой ситуации на выручку приходит беспроводной доступ в интернет.
Но и с ним не так все оказывается просто, как того бы хотелось.
Некоторое время назад в нескольких километрах от моего загородного дома Yota установила свою базовую станцию и, судя по карте охвата, мой дом оказался в «зоне уверенного приема» этой сети.
Попытки использования USB-модема от Yota показали неудовлетворительный результат: даже на балконе третьего этажа обращенного к базовой станции уровень сигнала чрезвычайно мал, скорости обмена данными 100-200 килобит в секунду (то есть меньше 25 килобайт в секунду).
Как раз в это время Yota начала продажи своего нового устройства — уличного модема «Yota Street».
Плюсы этого устройства:
- Направленная антенна — высокий коэффициент усиления и чувствительность на порядки превосходящие USB-модем (зимой, когда листва на деревьях не встает на пути радиоволн, скорость на прием бывает до 5-6 мегабит в секунду, а на передачу чуть меньнее того, летом стабильно держится 2 мегабита в обе стороны).
- Уличное исполнение — то есть можно и нужно вынести антенну на мачту высоко над крышей.
- Питание «Power Over Ethernet» — всего один провод для данных и питания.
- Подключается в порт WAN любого роутера, роутер по DHCP получает всю необходимо информацию о внешней сети.
Казалось бы, просто сказка. Включил и наслаждайся. Но, коротким было счастье.
Как только устройство появилось в продаже, оно было приобретено и водружено на крышу дома.
Новое устройство показало себя не с самой лучшей стороны: соединение с сетью Yota периодически обрывалось и для его восстановления приходилось лезть в вэб-интерфейс роутера и до остервенения кликать по кнопке «Подключиться». Иногда соединение возобновлялось, иногда нет. Приходилось на 15-30 минут отключать питание и модему и роутеру.
Все обращения в техподдержку Yota заканчивались предложением показать модем в сервис. Некоторые владельцы соглашались и им иногда даже меняли устройство целиком. Однако, потом выяснялось, что и совершенно новое устройство ведет себя в точности так же.
Потом стали появляться слухи о том, что Yota готовит обновление прошивки «Yota Street», однако, этому так никогда и не суждено было сбыться. Yota просто свернула продажи «Yota Street» и владельцы сего чудесного устройства остались наедине со своими проблемами.
Однако, покуда немалые деньги были потрачены на модем и безлимитный тариф Yota меня более чем устраивал, я решил своими силами постараться наладить работу своего модема.
Мой опыт использования «Yota Street» и обсуждения на форуме YotaTester привели меня к следующим 2-м заключениям:
- Нужно периодически, например раз в сутки, перезагружать модем чтобы у него не образовывался слишком большой uptime в результате которого устройство переставало адекватно работать.
- Нужно заставить роутер обнаруживать обрыв связи и пытаться восстановить соединение (как ранее я делал это руками из вэб-интерфейса роутера).
Первая задача решается просто: покупаем электрический таймер и программируем его на отключение питание ночью с 3-00 до 3-15.
Вторая задача решается несколько сложнее. К счастью роутер у меня оказался не простой, а хорошо известный в узких кругах Asus Wl-500gp. Уже некоторое время он работал под управлением «прошивки от энтузиастов».
Поиски в интернете показали, что в данной прошивке (впрочем, как и во многих других альтернативных прошивках) возможно подключение скриптов для набора событий:
- pre-boot — выполняется до начала загрузки
- post-boot — выполняется после окончания загрузки
- … и так далее…
Мне как раз и была нужна возможность запускать свой скрипт после полного «нормального» старта роутера.
Осталось написать скрипт, следящий за соединением.
И снова поиски в интернете принесли результат: скрипт «always_on» с сайта DD-WRT оказался именно тем, что я искал.
Роутер пингует default gateway и в случае отсутствия ответа, посылает новые запросы discovery от DHCP клиента.
Однако, я немного доработал скрипт с тем, чтобы случайные потери пакетов пинга не приводили к сбросу соединения: только N подряд неудачных пинга ведут к переподключению.
Результат оказался весьма обнадеживающим — доступ в интернет есть практически всегда, лишь порой соединение пропадает с тем чтобы через пару минут восстановиться.
Ну и уж коли я занялся скриптописательством, я добавил еще 2 простых, но весьма полезных скрипта:
- Установка MTU равное рекомендованному Yota 1400 байт. Сложно сказать, повлияло ли это и как сильно на скорость и стабильность работы, но хочется верить, что хуже не стало.
- Проброс вэб-интерфейса Yota-street в локальную сеть. Дело в том, что этот самый веб-интерфейс изначально доступен при непосредственном подключении к устройству по фиксированному адресу: 192.168.1.1. При этом по DHCP роутер от модема получает адрес в совершенно другой подсети (внутренней подсети Yota), то есть из локальной сети за роутером вэб-интерфейс модема недоступен. Однако, iptables позволяют решить и эту проблему.
- И в довершение для своего удобства я оформил в виде скрипта команды для сохранения изменений файловой системы во внутреннюю flash-память.
Итак, у меня получилось 3 «боевых» скрипта и один сервисный.
Для большей гибкости и возможности в дальнейшем модифицировать набор запускаемых скриптов, я реализовал систему наподобие обычных стартовых скриптов в Linux: сложил все скрипты для запуска после загрузки в одну папку «/usr/local/sbin», назвал их с префиксами «SXX» и еще одним скриптом запускаю их в порядке возрастания индекса в префиксе.
Если коротко, то теперь настройка роутера сводится к следующему:
- Логинимся на роутер через telnet и переходим в папку «/usr/local/sbin»
- Кладем в папку «/usr/local/sbin/» «боевые скрипты»: S10setmtu, S20alwayson и S30yotadmin
- Туда же кладем 2 сервисных скрипта: post-boot, который и запускает «боевые скрипты»; и flash.sh, при помощи которого мы сохраняем изменения файловой системы во flash-память роутера.
- Запускаем flash.sh: ./flash.sh
- Перезагружаем роутер: либо командой reboot в терминале, либо передергиваем питание.
Вуаля, интернет работает и радует пользователей!
- Техника
- Cancel
Для нормальной работы через расшаренную на ноутбуке с windows через wi-fi йоту нужно следующее:
1. Чтобы убрать локальные глюки на этом ноуте (в который воткнут модем) нужно сменить mtu для соединения до наибольшего из возможных. Для этого запускаем пинг командой ping ya.ru -f -l 1500, и если получаем «Packet needs to be fragmented but DF set», то уменьшаем размер пакета на 10 и пробуем еще (1490, 1480, …). Когда сообщение пропадет — увеличиваем пакет с шагом в единицу до того, как снова перестанет передаваться одним куском. Запоминаем макс значение при котором мессаджа не было
2. Качаем TCPOptimizer, в настройках выбираем адаптер, внизу ставим галку custom и меняем значение mtu на вычисленное. Там же смотрим mtu для вайфая. Оно должно быть меньше йотовского. Если вдруг нет — меняем на меньшее, напр. 1300, запоминаем это значение
3. На другом ноутбуке, который получает расшаренный интернет, в windows так же TCPOptimizer’ом меняем MTU до запомненного значения на вайфае, либо для мака указываем его вручную в свойствах AirPort.
Все то же самое можно сделать и для проводных соединений. Логика простая: windows по-дефолту предлагают максимальный размер передаваемого пакета в 1400 байт, а при включении ICS (internet connection sharing) компьютер становится шлюзом и windows занижает mtu, чтобы добавить в пакет новые строчки адресов и передаваемые клиентами пакеты начинают фрагментироваться — то есть при mtu на конечном устройстве в 1400 и mtu шлюза 1372 (у меня так) при передаче пакета 28 байт не улетают с первым, а упаковываются во второй. Для локальной работы интернета это не супер, но терпимо, а для расшаренного интернета начинаются проблемы — какие-то страницы не открываются, не работают чувствительные к отклику сервисы (xbox live!, app store). Ручная настройка maximum transmission unit эти проблемы решает
0
1
Проблема стандартная для нестандартного MTU — пинги, трейсы и прочая дигностика рабоает, а сайты открываются не очень хорошо.
Сеть такова: yota-модем вставлен в роутер Keenetic. Роутер подключен в общую сеть. В сети имеется сервак с Ubuntu 10.04. Сервер настроен на раздачу DHCP, сам стоит шлюзом:
# iptables -t mangle -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
# iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 192.168.3.0/24 0.0.0.0/0
# ifconfig
eth0 Link encap:Ethernet HWaddr 50:e5:49:c1:47:8b
inet addr:192.168.3.3 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::52e5:49ff:fec1:478b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:19251625 errors:0 dropped:0 overruns:0 frame:0
TX packets:19599669 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:11066820494 (11.0 GB) TX bytes:12212266417 (12.2 GB)
Interrupt:42
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:18546 errors:0 dropped:0 overruns:0 frame:0
TX packets:18546 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:9815256 (9.8 MB) TX bytes:9815256 (9.8 MB)
Клиентам в качестве главного шлюза присваивается адрес сервака. То биш, весь трафик идёт через него (мониторинг кинетика ето подтвердил — левых соединений нет).
Ситуация с MTU многим, думаю, известна — у них он равен 1400.
Конфиг роутера:
KEENETIC 4G> exec ifconfig
br0 Link encap:Ethernet HWaddr CC:5D:4E:B8:D8:12
inet addr:192.168.3.2 Bcast:192.168.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:876551 errors:0 dropped:0 overruns:0 frame:0
TX packets:901394 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:186258055 (177.6 MiB) TX bytes:614250252 (585.7 MiB)
eth2 Link encap:Ethernet HWaddr CC:5D:4E:B8:D8:12
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:876759 errors:0 dropped:0 overruns:0 frame:0
TX packets:901394 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:202063727 (192.7 MiB) TX bytes:619041599 (590.3 MiB)
Interrupt:3
eth2.1 Link encap:Ethernet HWaddr CC:5D:4E:B8:D8:12
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:876752 errors:0 dropped:0 overruns:0 frame:0
TX packets:901394 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:189788271 (180.9 MiB) TX bytes:617855828 (589.2 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ra0 Link encap:Ethernet HWaddr CC:5D:4E:B8:D8:12
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3685914 errors:0 dropped:0 overruns:0 frame:0
TX packets:41136 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:466992330 (445.3 MiB) TX bytes:0 (0.0 B)
Interrupt:4
wimax0 Link encap:Ethernet HWaddr 00:09:3B:F0:1A:40
inet addr:10.0.0.10 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1400 Metric:1
RX packets:871046 errors:0 dropped:0 overruns:0 frame:0
TX packets:823436 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:592154514 (564.7 MiB) TX bytes:221413667 (211.1 MiB)
KEENETIC 4G> exec iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- 0.0.0.0/0 10.0.0.10 tcp dpt:22 to:192.168.3.3
DNAT udp -- 0.0.0.0/0 10.0.0.10 udp dpt:22 to:192.168.3.3
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE udp -- 192.168.3.0/24 192.168.3.3 udp dpt:22
MASQUERADE tcp -- 192.168.3.0/24 192.168.3.3 tcp dpt:22
SNAT all -- 0.0.0.0/0 0.0.0.0/0 to:10.0.0.10
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
KEENETIC 4G> exec iptables -t mangle -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Казалось бы, при наличии TCPMSS везде, де только можно, клиенты должны договариватся с сервером об MTU, но проблема на месте.
В данный момент поменял настройки на серваке:
Такой размер нашёл здесь: http://kubuntu.ru/node/4559
Дополнительно поменял рамер MTU и на роутере на всех интерфейсах, даже на беспроводной:
# ifconfig br0 mtu 1372
# ifconfig eth2 mtu 1372
# ifconfig eth2.1 mtu 1372
# ifconfig ra0 mtu 1372
В йоте специалисты говорят, что MTU надо менять на клиентах — тогда проблем вобще не будет. Но поменять MTU на компах с WinXP и Win7 в количестве пусть и 20-ти, мне не представляется быстрым и умным.
В чём мои вопросы:
— всё ли я сделал, что мог, для того, чтобы победить проблемы с MTU на уровне шлюзов?
— верить ли спецам из Yota и настраивать ли каждый комп в отдельности?
-
-
Listens: Наив
- IT
- Cancel
Господа!
Вчера и сегодня опять началась проблема с тем, что торренты и файлы закачиваются на скорости от 2-6 Мб в секунду, а страницы в инете либо не открываются, либо с 10-й попытки, либо очень долго, либо криво о-). Танцы с бубнами вокруг DNS уже не помогают. (Надо увеличивать дозу)))) Проблема пришла откуда не ждал совсем. А именно в настройках MTU.
Стал проверять настройки MTU. В июле когда пинговал методом перебора, то размер проходящего пакета был 1392 байта. Сейчас она уменьшилась до 1372 байт. Кто объяснит как такое могло произойти? Причем пинговал московский DNS-сервер Yota. У кого есть время пропингуйте пожалуйста и скиньте сюда свои резалты. Желательно, что бы еще питерские подключились к этому.
C:\Users\user>ping -f -l 1373 94.25.128.74
Обмен пакетами с 94.25.128.74 по с 1373 байтами данных:
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Статистика Ping для 94.25.128.74:
Пакетов: отправлено = 4, получено = 0, потеряно = 4
(100% потерь)
C:\Users\user>ping -f -l 1372 94.25.128.74
Обмен пакетами с 94.25.128.74 по с 1372 байтами данных:
Ответ от 94.25.128.74: число байт=1372 время=103мс TTL=126
Ответ от 94.25.128.74: число байт=1372 время=102мс TTL=126
Ответ от 94.25.128.74: число байт=1372 время=112мс TTL=126
Ответ от 94.25.128.74: число байт=1372 время=100мс TTL=126
Статистика Ping для 94.25.128.74:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 100мсек, Максимальное = 112 мсек, Среднее = 104 мсек