Укажите в опциях nomppe-stateful, думаю полегчает.
Укажите в опциях nomppe-stateful, думаю полегчает.
Соединение с этой опцией не устанавливается
#=============================
Feb 28 20:20:22 pppd[858]: pppd 2.4.2 started by admin, uid 0
Feb 28 20:20:22 pppd[858]: Serial connection established.
Feb 28 20:20:22 pppd[858]: Using interface ppp0
Feb 28 20:20:22 pppd[858]: Connect: ppp0 <--> /dev/pts/0
Feb 28 20:20:22 pptp[866]: anon log[mainptp.c:267]: The synchronous pptp option is NOT activated
Feb 28 20:20:22 pptp[868]: anon warn[route_addptp_callmgr.c:457]: route_add: not adding existing route
Feb 28 20:20:22 pptp[868]: anon log[ctrlp_repptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Feb 28 20:20:22 pptp[868]: anon log[ctrlp_dispptp_ctrl.c:732]: Received Start Control Connection Reply
Feb 28 20:20:22 pptp[868]: anon log[ctrlp_dispptp_ctrl.c:766]: Client connection established.
Feb 28 20:20:23 pptp[868]: anon log[ctrlp_repptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Feb 28 20:20:23 pptp[868]: anon log[ctrlp_dispptp_ctrl.c:851]: Received Outgoing Call Reply.
Feb 28 20:20:23 pptp[868]: anon log[ctrlp_dispptp_ctrl.c:890]: Outgoing call established (call ID 0, peer's call ID 40832).
Feb 28 20:20:24 pppd[858]: Received bad configure-nak/rej: 12 06 01 00 00 40
Feb 28 20:20:27 pppd[858]: Received bad configure-nak/rej: 12 06 01 00 00 40
#=============================
В чём _причина_ трабла может скрываться?
В том, что проц реально не справляется с нагрузкой или в том, что драйвер mppe/mppc стоИт кривой?
Если последнее, есть ли возможность сменить драйвер?
Почитал ещё раз пост.
Возможно дело в mtu/mru - попробуйте поиграться с размером пакетов...
Скажем поставить mtu 1500, а потом уменьшать.
MTU больше 1470 не выставляется.
У меня была гипотеза, что трабл происходит из за фрагментации пакетов, т.к. MTU у прочих интерфейсов - 1500.
Но, если пинговать через ppp0 непосредственно с роутера (чтобы не было фрагментации), причём пинговать пакетами ЛЮБЫХ размеров, хоть 1 байт - проблема остаётся.
Так что фрагментация пакетов, как мне кажется, тут не причём.
Привет всем. Купил роутер wl-500g Premium. Задача была соеденить беспроводом комп и бук и раздать на них входящий кабельный Интернет (соответсвенно на комп - кабелем, на бук - беспроводом).
Настроил, вроде бы заработало... Но сначала при попытке что-то скачать - он качает секунд 15 и просто замирает.. окно скачки висит, но прогресса нет. Стал пинговать: оказалось - теряет пакеты даже между компом и роутером (порядка 7%). Если начинаю пинговать внешние серваки - там уже потери 13-15%. Причем потери идут 3-мя строчками превышений интревалов запросов через равные промежутки времени. Если подключаю сетку напрямую к компу - пинги с теми же серваками - 100%-но идеальные.
В чем может быть трабла? Можно ли это вылечить или это аппаратный брак?
Заранее благодарен.
проблема решена установкой прошивки 1.9.7.0
Сегодня, сопоставив все факты, пришёл к интересному выводу.
Дело в том, что затыки возникают только в том случае, если передаются
"трудносжимаемые" данные, например картинки,
архивы, шифрованый трафик (https, ssh) и т.п.
При передаче plain text приём/передача работает как часы.
Если, например, архив подвергнуть uuencode -
передаётся "на счёт раз".
Тот же архив "как есть" - не передаётся ВООБЩЕ - у точки
доступа "срывает крышу" и потери пакетов зашкаливают.
Очевидно, что дело в сжатии MPPC.
Уже пожатые данные этот алгоритм не может дополнительно
сжать и по каким-то причинам затывается.
Возможно из за возникающей фрагментации пакетов - пожатые пакеты
не укладываются в MTU ppp-соединения.
У меня, например, максимально допустимый размер MTU - 1470.
Хотя что дело именно во фрагментации - есть сомнения.
Т.к. я пробовал уменьшать MTU на других интерфейсах,
чтобы исключить фрагментацию - это не помогает.
Т.е. имеем следующие факты:
1. Проблемы совершенно точно взаимоувязаны со "сжимаемостью" или "несжимаемостью" трафика
2. Версия с фрагментацией пакетов (после их сжатия MPPC) экспериментально не подтверждается
3. Через какое-то время после окончания перегонки "несжимаемостью" трафика (до 30 сек.) нормальная работоспособность восстанавливается
Какие отсюда могут следовать умозаключения?
Last edited by despair; 08-03-2007 at 07:23.
Нужен ping с миллисекундным (и более) интервалом отправки пакетов.
Насколько я понял, ping из busybox'а не имеет опции установки интервала отправки пакетов.
Роутер: WL500gP, прошивка: 1.9.2.7-7g, ipkg установлен.
Поиск по конференции использовал, но ничего не нашел, хотя по памяти - вроде бы где-то раньше натыкался на этот вопрос.
ping -f, возможно. Согласно документации, шлёт пакеты либо 100 раз в секунду, либо сразу после получения ответа на предыдущий пакет (что окажется быстрее). Работает только от суперпользователя (uid == 0), за нецелевое использование отрывают ноги по самую голову.
В том то и дело, что в прошивке от Олега используется не стандартный ping, а его упрощенная версия. Этот упрощенный ping реализован как вызов универсальной системной программы busybox.
Конкретно по вашему совету: опции -f в этом ping'е, к сожалению, нет.
Так что по-прежнему жду ваших подсказок
Добрый день!
Приобрёл роутер wl500gp по совету знакомых и хороших отзывов о нём.
Сразу перепрошил его последней прошивкой от Олега.
Проблема заключаёться в том что это чуда передовой техники мне устраивает потери пакетов каждый час, а то два а то весь день нормально работает.
Непонятно ни с того ни с сего пинги подскакивают под 500 - 700 и держуть в этом интервале. Иногда строчки потерь пакетов выдаёт. Поле ребута всё гуд.
Если у вас возьмуться мысли что дело в сервере который я пингую, то их сразу отсеивайте. Пингую и свой VPN сервер, DNS, шлюз, www.ru и т.д.
Потерь к самому роутеру естественно нет.
Вторая проблемка, FTР сервер. Настроено всё чётко по инструкции Олега. Это чудо просто берёться и отваливаеться при частых обращениях. Пробовал его держать и на флэхах и на внешнних хардах и т.л. отваливаеться и всё.
В никсах шарю не очень, поэтому прошу о помощи!
В файле с настройками WL500g.Premium.CFG.txt подписал txt чтоб иметь возможность сохранить на форуме.
Как заставить tcpdump ловить все пакеты? (не работает SIP клиент)
Пробовал tcpdump -i eth0 (eth1, bro, vlan0, vlan1)
ничего кроме текущего telnet соединения не ловит.
ADSL модем в режиме роутеру, ноут с которого и звоню клиентом включены
в соседние Eth порты, никакого wi-fi.
tcpdump -ni vlan1 # для wan соединения
tcpdump -ni ppp0 # для vpn соединения
tcpdump -ni br0 # для lan соединения
Чтоб не ловилось текущее телнет соединение в конец дописать not tcp port 23