1

Вот. Случилась такая фигня. Интернет отваливается через каждые 10 минут.
Всё по порядку:
железо: eeePC 901
ось - runtu 10.04 LXDE
pppoe
Настраивал, не заморачиваясь через pppoeconf. Всё рабтало больше 2-х лет. И вот сейчас - то шлюз потеряю, то DNS. Сегодня приходил сотрудник техподдержки, ему что-то коннектор не понравился. Переобжал. Но - фигня продолжается. Что может быть?

2

mvt пишет:

Что может быть?

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

Был, был и весь вышел...

3 (26.01.2013 13:39:03 отредактировано mvt)

Lupo Alberto пишет:
mvt пишет:

Что может быть?

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

В квартиру заходит витуха. Там, на чердаке - свитч и переход на оптику. При загрузке я всё получаю - и адрес, и шлюз, и DNS'ы. А минут через 10 - всё падает. Я тоже думаю, что проблемы не на моей стороне, но как это объяснить этим ремонтникам, которые Linux даже не видели? (Сегодня он у меня искал кнопку "Пуск" ac )

4

А в логах при падении ничего подозрительного нет ли?

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

5 (26.01.2013 14:03:24 отредактировано mvt)

yars пишет:

А в логах при падении ничего подозрительного нет ли?

А где посмотреть? Прямо в messages?
PS Сегодня суббота, вряд ли я этих ремонтников завтра отловлю. Может, пока какой-нибудь скрипт написать, чтобы стартовал pppoe через каждые минут 7? Помогите, пожалуйста.
А то, честно, достало...

6

mvt пишет:

Прямо в messages?

Ну, по крайней мере, какая-то часть нужных сообщений там и будет, например, сообщения демона pppd.

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

7

mvt пишет:

Я тоже думаю, что проблемы не на моей стороне, но как это объяснить этим ремонтникам, которые Linux даже не видели?

Я очень настойчиво и неоднократно «мучал» техподдержку по телефону. В конце концов заказал тестирование линии. Пришёл инженер, проверил, убедился, что у меня всё в порядке.

Был, был и весь вышел...

8

mvt пишет:

PS Сегодня суббота, вряд ли я этих ремонтников завтра отловлю. Может, пока какой-нибудь скрипт написать, чтобы стартовал pppoe через каждые минут 7?

А как у вас сеть поднимается? Запишите в cron рестарт сети, и никаких скриптов.

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

9

yars пишет:

Запишите в cron рестарт сети, и никаких скриптов.

Это не решение проблемы, а огроменный «костыль»! Тем более велика вероятность, что ошибка «железная» и на стороне провайдера!

Был, был и весь вышел...

10

Lupo Alberto пишет:

Это не решение проблемы, а огроменный «костыль»!

Ну да, тут лучше действительно позвать техников, пусть все сами проверят. Но, как временное решение, я думаю, все же можно применить....

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

11

Ну, да. Как-т так:
Jan 26 11:45:58 eeepc pppd[1022]: PPP session is 38724
Jan 26 11:45:58 eeepc pppd[1022]: Connected to 00:0b:fc:8b:8c:1a via interface eth0
Jan 26 11:45:58 eeepc pppd[1022]: Using interface ppp0
Jan 26 11:45:58 eeepc pppd[1022]: Connect: ppp0 <--> eth0
Jan 26 11:46:01 eeepc pppd[1022]: CHAP authentication succeeded
Jan 26 11:46:01 eeepc pppd[1022]: CHAP authentication succeeded
Jan 26 11:46:01 eeepc pppd[1022]: peer from calling number 00:0B:FC:8B:8C:1A authorized
Jan 26 11:46:01 eeepc pppd[1022]: replacing old default route to eth0 [192.168.0.1]
Jan 26 11:46:01 eeepc pppd[1022]: local  IP address 78.25.184.236
Jan 26 11:46:01 eeepc pppd[1022]: remote IP address 78.25.155.17
Jan 26 11:46:01 eeepc pppd[1022]: primary   DNS address 78.25.155.1
Jan 26 11:46:01 eeepc pppd[1022]: secondary DNS address 78.25.154.254
Jan 26 11:56:10 eeepc pppd[1022]: Modem hangup
Jan 26 11:56:10 eeepc pppd[1022]: Connect time 10.2 minutes.
Jan 26 11:56:10 eeepc pppd[1022]: Sent 6308 bytes, received 8436 bytes.
Jan 26 11:56:10 eeepc pppd[1022]: restoring old default route to eth0 [192.168.0.1]
Jan 26 11:56:10 eeepc pppd[1022]: Connection terminated.

12

mvt пишет:

Jan 26 11:56:10 eeepc pppd[1022]: Modem hangup

А модемом у нас кто работает? У меня бывает похожее, только у меня чистый dial-up на мегафоне. И в моем случае, это от неустойчивости линии, т.е., качество  сигнала играет роль. И падает в зависимости от фазы Луны ab

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

13

yars пишет:
mvt пишет:

Jan 26 11:56:10 eeepc pppd[1022]: Modem hangup

А модемом у нас кто работает? У меня бывает похожее, только у меня чистый dial-up на мегафоне. И в моем случае, это от неустойчивости линии, т.е., качество  сигнала играет роль. И падает в зависимости от фазы Луны ab

Да нет у меня модема... Если используется pppoe, то на сетевухе образуется интерфейс ppp0 и Lnux его воспринимает, как модем... Блин, работало же почти три года...

14

Добавь debug в файл настройки и тогда будет более раскрытый лог. Может чего увидем?

MX 23.6 Libretto x86_64
Чем больше я работаю админом, тем больше понимаю, насколько волшебна фраза - "Нет технической возможности!"

15

mvt пишет:

Да нет у меня модема... Если используется pppoe, то на сетевухе образуется интерфейс ppp0

Вот я и спросил, какая сетевая карта. Немного непонятно выразился, прошу прощения.  Насколько я понимаю, еще бы лог ядра насчет сообщений ядерного модуля , отвечающего за  сетевую карту глянуть не помешало бы...

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

16

yars пишет:
mvt пишет:

Да нет у меня модема... Если используется pppoe, то на сетевухе образуется интерфейс ppp0

Вот я и спросил, какая сетевая карта. Немного непонятно выразился, прошу прощения.  Насколько я понимаю, еще бы лог ядра насчет сообщений ядерного модуля , отвечающего за  сетевую карту глянуть не помешало бы...

Всё-таки думаете, что Ubuntu виновата? Ладно, сейчас зазружусь с другим ядром. Посмотрим?

17

mvt пишет:

Посмотрим?

Диагностировать, так диагностировать по максимуму ab

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

18 (26.01.2013 14:47:00 отредактировано mvt)

yars пишет:
mvt пишет:

Посмотрим?

Диагностировать, так диагностировать по максимуму ab

mvt@eeepc:~$ uname -a
Linux eeepc 2.6.32-44-generic #98-Ubuntu SMP Mon Sep 24 17:32:45 UTC 2012 i686 GNU/Linux
ab
Будем посмотреть...

19

yars
Я уже на третьем ядре. Осталось ещё пару. ab Ща сделаю LiveUSB, загружусь. Вот и посмотрим, кто есть ху ab

20

А на 2.6.32.44 проблемы были?

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

21

yars пишет:

А на 2.6.32.44 проблемы были?

Да Вы знаете, я не заморачивался. Приходили ядра, менялись. Всё работало. Я уже на 4-том ядре загрузился. Пока - всё падало ac

22

mvt пишет:

на сетевухе образуется интерфейс ppp0 и Lnux его воспринимает, как модем...

Может в этом дело? В смысле сетевая карта умирает.
А pppd не должен рестартовать соединение после дисконнекта?

Hunter, who is on the trail ...

23

XliN пишет:

Добавь debug в файл настройки и тогда будет более раскрытый лог. Может чего увидем?

разумный совет

Hunter, who is on the trail ...

24

stalker_tk пишет:

А pppd не должен рестартовать соединение после дисконнекта?

В некоторой степени зависит от настроек.

Был, был и весь вышел...

25

Lupo Alberto пишет:
stalker_tk пишет:

А pppd не должен рестартовать соединение после дисконнекта?

В некоторой степени зависит от настроек.

Как сделать? Ну хоть на два дня?

26

mvt пишет:

Как сделать? Ну хоть на два дня?

mvt, тут такая мысль:
если работало и у себя ничего не меняли,- значит велика вероятность, что проблема не на вашей стороне.И надо заставить провайдера проревизить участок "проводов" от вас и до него.
Можно найти (у соседей) нетбук с 7й, вызвать кудесников от провайдера и сказать= вот мол, сеть отваливается. они тогда не смогут перевсети стрелки на линукс.
И пусть всё смотрят, от вашей квартиры и свитча на чердаке до своей АТС- или что там у них. Вам это не помешает, а может и поможет.
Параллельно это вам не мешает изучать логи,- проверять, что у себя. Хотя обрывы, ИМХО,- от проблем у провайдера,- как вариант от перегрузки сети.

27

Гляньте:

+ man pppd
...
persist
              Do  not exit after a connection is terminated; instead try to reopen the connection. The maxfail option still has an effect on persistent connections.
...
lcp-echo-adaptive
              If this option is used with the lcp-echo-failure option then pppd will send LCP echo-request frames only if no traffic  was received from the peer since the last echo-request was sent.

       lcp-echo-failure n
              If  this  option  is given, pppd will presume the peer to be dead if n LCP echo-requests are sent without receiving a valid LCP echo-reply.  If this happens, pppd will terminate the connection.  Use of this option requires a non-zero value for the lcp-echo-interval  parameter.   This  option can be used to enable pppd to terminate after the physical connection has been broken (e.g., the modem has hung up) in situations where no hardware modem control lines are available.

       lcp-echo-interval n
              If this option is given, pppd will send an LCP echo-request frame to the peer every n seconds.  Normally  the  peer  should respond  to  the echo-request by sending an echo-reply.  This option can be used with the lcp-echo-failure option to detect that the peer is no longer connected.

P.S. Вполне вероятно, что проблема всё-таки «железная». Чтобы более предметно общаться с провайдером, попробуйте подключить машину с Windows (мне, к счастью, удалось обойтись без этого bx )

Был, был и весь вышел...

28

$ sudo mcedit /etc/ppp/peers/dsl-provider

noipdefault

# В таблице маршрутизации сделать данное соединение маршрутом по умолчанию

defaultroute

replacedefaultroute

hide-password

#lcp-echo-interval 30

#lcp-echo-failure 4

noauth

# Восстановить связь в случае разрыва

persist

# Использовать максимальный размер передаваемого пакета в 1492 байт

mtu 1492

usepeerdns

Взято отсюда

Hunter, who is on the trail ...

29

Lupo Alberto
Ну нет у меня Windows... Сейчас загрузился с LiveUSB Да фиг вам, такая же история. Я даже DNS'ы не получил. Всё, прощаюсь до понедельника. Я так больше не могу. Если не сделают - сменю, блин, провайдера.
Удачи. Не ругайтесь здесь, хорошо? ab

30

И вам удачи. И да, провайдеры нынче пошли не айс. В том числе, и мобильные. Впрочем, они всегда такими были, просто приходится из всех зол выбирать меньшее... А у нас, так вообще выбора нет.

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580