welinux.ru/Есть вопрос! — PPPoE-подключение: требуется костоправ

20.06.09 13:34Elijah

Есть вопрос! — PPPoE-подключение: требуется костоправ

В одно прекрасное утро у меня сломались эти ваши интернеты.

Доступ к внешним ресурсам стал весьма неровным: к большинству можно было приконнектиться, не с ощутимой задержкой; иногда законнектиться было ни к чему нельзя; попытки запинговать какой-нибудь ресурс, даже доступный из браузера, приводят примерно к следующему: "30 packets transmitted, 0 received, 100% packet loss, time 29026ms"; из репозиториев ничего закачать нельзя - rpmdrake надолго уходит в анабиоз, а потом сообщает о недоступности всего, что должно быть доступно :)

Что ж, загружаемся в установленную на той же машине винду, и видим, что под виндой коннект довольно ровный, без описанных выше чудес. "не везёт с Мандривой, повезёт с виндой" :))

Провайдер, как обычно в таких случаях, клянётся и божится, что ни-ни-ни.

Возник не только обычный русский вопрос "что делать?", но и познавательный интерес: как найти, где прячется баг?

Запрашиваю ifconfig.

[user@localhost ~]$ sudo ifconfig
eth1 Link encap:Ethernet HWaddr 00:01:6C:F4:4A:D7
inet addr:192.168.0.37 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::201:6cff:fef4:4ad7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:51259 errors:0 dropped:0 overruns:0 frame:0
TX packets:18423 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:17979758 (17.1 MiB) TX bytes:2447593 (2.3 MiB)
Interrupt:21 Base address:0x6000

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:5824 errors:0 dropped:0 overruns:0 frame:0
TX packets:5824 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:320340 (312.8 KiB) TX bytes:320340 (312.8 KiB)

ppp0 Link encap:Point-to-Point Protocol
inet addr:91.xxx.xx.xxx P-t-P:217.xx.xxx.x Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:33 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:1698 (1.6 KiB) TX bytes:54 (54.0 b)

То есть всё как бы работает.

Смотрим pppoe-status:

[user@localhost ~]$ sudo pppoe-status
pppoe-status: Link is down (can't read pppoe PID file /var/run/pppoe.conf-pppoe.pid.pppoe)

Это уже сюрприз. Что ж, запускам pppoe-start, и в вывод ifconfig'а добавляется ещё одна секция (при том, что прежняя ppp0 не исчезает даже при помощи pppoe-stop):

ppp1 Link encap:Point-to-Point Protocol
inet addr:91.xxx.xx.xxx P-t-P:217.xx.xxx.x Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:54 (54.0 b) TX bytes:67 (67.0 b)

Энторнеты же как работали хреново (см. выше), так и работают.

1. Как исправить сложившуюся ситуацию?
2. Каков наилучший способ мониторить pppoe-подключение для выявления багов?

+1–

Mandriva pppoe

cppmm20.06.09 13:56# +1–

Что в процессах? Посмотрите, кто создаёт интерфейс ppp. Я, например для этого использую pppd напрямую обычно. Т.е., сделав файл настроек, вызываю его с помощью pppd call my_vpn_network. Тогда прозрачно видно, кто поднимает интерфейс, и где искать ошибку.

Elijah20.06.09 17:23#↑ +0–

"pppd напрямую обычно" -- а как именно это делается, "нгапрямую"?

cppmm20.06.09 22:53#↑ +0–

Ну я же объяснил. :)
Я создаю в /etc/ppp/peers/ файл настройки подключения, а потом говорю на этот файл pppd call. Получается, что нет посредников между мной и pppd, который всё-равно так или иначе вызывается, насколько я знаю.

Elijah21.06.09 08:37#↑ +0–

А зачем мне так извращаться, ведь штатный путь для поднятия соединения -- это скрипт pppoe-start (который вызывает, в свою очередь, скрипт pppoe-connect., а уже он - pppd?). Впрочем, возможно, я вашу мысль недопонял.

cppmm21.06.09 13:06#↑ +0–

Ну вы же хотите разобраться, как написали выше.
Если pppd отработает нормально, значит проблема в костыле, который вы называете штатным скриптом. :)

P.S. Я приверженец принципа KISS, поэтому большинство надстроек недолюбливаю.

: Elijah21.06.09 14:14#↑ +0–

Не думаю, что в скрипте проблема: до этого он работал нормально, со времени установки не менялся - почему же именно в нём?

Username20.06.09 14:39# +1–

поэкспериментируй, замочив все ппп
poff -a
запустив один

На мой взгляд, тебе мешает что-нить вроде нетворк-манагера

: Elijah20.06.09 17:24#↑ +0–

Проэкспериментировал - нет толку :(

cyrus20.06.09 15:17# +1–

В pppd есть ключ debug. Про pppoe не знаю. Может быть это поможет.

Elijah20.06.09 17:25#↑ +0–

Удивительное дело - не могу скачать пакет!

cyrus20.06.09 18:23#↑ +1–

А точно должен быть eth1? обычно же eth0
Ещё в нете видел такой фокус у некоторых был: чтобы инет работал через pppoe они делали
ifconfig eth0 down
pppoe-start

: Elijah20.06.09 18:25#↑ +0–

eth1, да. Не знаю уж, почему определилось именно так (сетевых карт две штуки, соотв. определились как eth1 и eth2).

Рецепт ваш попробую.

zivot_je_cudo20.06.09 19:39#↑ +1–

В pppd есть ключ debug.

Должен сработать и в /etc/ppp/pppoe.conf.
Автор, логи, логи! cat /var/log/messages | grep pppd

: Username20.06.09 20:04#↑ +0–

ну или plog хотя бы

: Elijah21.06.09 08:43#↑ +0–

Логи эти оказались чрезвычайно любопытными. По-видимому, всё дело было вот в чём:

Jun 20 15:42:30 localhost pppd[28762]: not replacing existing default route via 192.168.0.1

NucleoFag20.06.09 15:27# +2–

Тебе уже верно посоветовали. 1 - отруби всяческие нетворк-манагеры, перенастрой, отключив все интерфейсы ppp (poff -a) и заново подключи. Ну и как бы от рута, да, или под судо. Далее - проверь сетевой интерфейс сам, мож у тебя из-за обновления он вообще к примеру не eth0 а eth1 стал. Возможно виноват mtu, но вряд ли, потому как пинг бы был. Пров еще по маку может банить, это тоже проверь. Далее - для pppoe есть несколько способов, попробуй все. Хотя бы pppoe-start и pon dsl-proivider. Может локальный баг с пакетом. Еще дело мб в файрволле, для этого, как тоже верно подсказали сверху - проверь само подключение с ключом debug и посмотри кто его создает. Ах да, еще дистр укажи, если конечно не я пропустил. Мож у тя сусь к примеру при запуске яста все твои конфиги переписывает успешно =)

Ну и это, p.s. типа:
Извиняюсь если говорю очевидные вещи, или уже проверенные (типа sudo или mtu который верный для обычного pppoe и указан сверху) и/или повторяю вышесказанное. Просто захотелось поподробнее расписать чтобы было понятно и очевидно, а не просто выполнить там такую то команду и все запашет.

cyrus20.06.09 15:50#↑ +0–

про дистр вроде как

"не везёт с Мандривой, повезёт с виндой"

Как я понял мандрива стоит.

: NucleoFag20.06.09 15:56#↑ +0–

Спасибо. Беглым взглядом не заметил, да. Благодарю. А мандриву 2 года не юзал, может там drake* софт постарался

Elijah20.06.09 17:22#↑ +0–

0. Нетворк-менеджера прибил.

1. poff -a не работает (видимо, это специфика мандривы). Пришлось смотреть через ps ай-ди процессов pppoe и прибивать их вручную (а было их там три - ppp0, ppp1, ppp2!)

2. Сетевой интерфейс под прежним номером.

3. Бана по маку нет.

4. "Проверь само подключение с ключом debug" - а это как? Если имеется в виду #pppd debug, то эта команда отвечает весьма своеобразно: бесконечно выпечатывает последовательность ~�}#�!}!}!} }4}"}&} } } } }%}&} ��},}'}"}(}"|�

Username20.06.09 17:36#↑ +0–

блин
Настрой подключение средствами Мандри, там вроде нормальная гуевина-то, работает

: Elijah20.06.09 17:37#↑ +0–

Так настраивал, и не раз...

cyrus20.06.09 17:42#↑ +0–

Если интернет, например, включать так "pon internet" или "pppd call internet", то нужно вбить "/usr/sbin/pppd nodetach debug call internet"
С pppoe как-то по аналогии наверно надо..

: Elijah20.06.09 18:05#↑ +0–

У меня он подключается скриптом pppoe-start

Elijah20.06.09 18:13# +0–

Я на что ещё хотел обратить внимание: на противоречие между показаниями ifconfig (который говорит, что pppoe поднято успешно) и данными pppoe-status (который, наоборот, сообщает, что Link is down (can't read pppoe PID file /var/run/pppoe.conf-pppoe.pid.pppoe))

Kraplax20.06.09 21:48#↑ +1–

can't read pppoe PID file /var/run/pppoe.conf-pppoe.pid.pppoe

А есть причины по которым он может так говорить? Ну, например, файл сам отсутствует, или, там, права на него не те..?

Elijah21.06.09 08:44#↑ +0–

Причины были - файла не было.

Kraplax21.06.09 09:22#↑ +0–

А права есть на запись в эту папку? По идее этот файл должен ведь создавать сам процесс или нечто его запускающее. А это значит что либо процесс ищет его не там, где файл создается, либо файл не создается из-за недостающих привилегий.

: Elijah21.06.09 10:17#↑ +0–

Права root | root, т.е. само по себе всё должно записываться нормально.

xameleon20.06.09 19:40# +0–

может перенастроить модем - роутером

: zivot_je_cudo20.06.09 19:41#↑ +0–

Интернет заработает, но проблема-то останется. Надо решить.

: Elijah21.06.09 08:44#↑ +0–

Какой модем-то, бог с вами :)

: zivot_je_cudo20.06.09 19:43# +0–

Автор, покажи еще и вывод tcpdump на eth1.

Elijah21.06.09 08:59# +0–

В общем, получилось вот что.

Как мудро посоветовал zivot_je_cudo, я изучил лог /var/log/messages, и обнаружил совершенно ненормальную строчку в них:

Jun 20 15:42:30 localhost pppd[28762]: not replacing existing default route via 192.168.0.1

Как поясняют в энторнетах, это значит, что "соединение устанавливается, но шлюз по умолчанию на него не переводится" / "You configured pppd to create a default route to your new PPP link, which is good. However, pppd does not replace an existing route"

Соответственно предлагаются разные пути решения: от ковыряния в настройках (см. напр. http://forum.himki.net/index.php?&showtopic=47423&st=20&p=734875) до короткого магического заклинания route del default.

Как ясно из тех же интернетов, короткое магическое заклинание помогает далеко не всегда.

Впрочем, воспользоваться ни им, ни чем-то ещё из вычитанного я не успел: после очередного скрупулёзного прибития через kill существующих pppd и pppoe и запуска pppoe штатным скриптом pppoe-start всё заработало.

Вопросы к сообществу:

1. Встречалась ли вам проблема "not replacing existing default route via", как решали?
2. Отчего это вообще бывает?
3. Что ещё можно выудить полезного из лога /var/log/messages? (помимо того, что относится к данной проблеме)

zivot_je_cudo21.06.09 11:08#↑ +1–

Добавь или исправь в /etc/ppp/pppoe.conf строчку DEFAULTROUTE=yes.

Elijah21.06.09 11:42#↑ +0–

Строчка эта там есть, и, по-моему, так и выглядела с самого начала.

NucleoFag21.06.09 11:46#↑ +1–

Да ты просто видимо через гуй или консоль или прога какая - добавили шлюз. Наличие шлюзов проверяется route -n
Если что - ты знаешь что делать =) ПО дефолту их как бы ничего не стартует из прог что я знаю, так что там либо гуевина настраивает либо прога какая либо в стартовых скриптах чего

: Elijah21.06.09 12:55#↑ +0–

хех, ну надеюсь, что знаю....

Username21.06.09 17:51# +0–

факин! Да по-любому не дефолтный маршрут просто

Elijah21.06.09 18:56#↑ +0–

А что это значит и откуда берётся?

Username21.06.09 19:05#↑ +1–

ну. Попробуй указать явно, как маршрут для сети (читай инета) должен быть у тебя по умолчанию. Для этого попробуй подключить через ppp напрямую, то есть путем редактирования конфигов в /etc/ppp и выполнения подключения через pon, а потом добавив дефолтный маршрут командой вроде типа
route add default ppp0

Читани еще ман по route
Таким образом, у тебя будет настроен инет непробиваемым способом.

Кстати говоря, я совсем недавно столкнулся с этой проблемой, почему-то pppoe-setup не мог корректно решить проблему маршрута по умолчанию. Может был какой-то конфликт. Хм, в арче чтоли это было. Не важно.

: Elijah21.06.09 23:21#↑ +0–

Ну pon у меня отсутствует (видимо, это особенность дистрибутива). В остальном же - буду пробовать, если, не дай бог, эта фигня опять начнётся.

—