propeller
написал 8 июня 2005 года в 09:05 (654 просмотра)
Ведет себя
как мужчина; открыл 53 темы в форуме, оставил 158 комментариев на сайте.
У меня соединеник с интернетом по vpn. Так что приходитсяпользоваться pptp. и вот что с ним замечено. Соединение с интернетом может просто так взять, да пропасть. Это не HUP, соединение не считается разорваным. я обчыно на это отвачл просто новыи подключением и все. но не хочется ведь каждый раз ручками делать. как бы это автоматизировать?
Последние комментарии
- OlegL, 17 декабря 2023 года в 15:00 → Перекличка 21
- REDkiy, 8 июня 2023 года в 9:09 → Как «замокать» файл для юниттеста в Python? 2
- fhunter, 29 ноября 2022 года в 2:09 → Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt? 6
- Иванн, 9 апреля 2022 года в 8:31 → Ассоциация РАСПО провела первое учредительное собрание 1
- Kiri11.ADV1, 7 марта 2021 года в 12:01 → Логи catalina.out в TomCat 9 в формате JSON 1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
#echo «persist» >> /etc/ppp/peers/$PROVIDER
не понял.
и что это такое и что это значит?
ping -> reconnect.
Это следствие того, что ты не написал, что у тебя за ОС.
Fedora 2.
и в чем же дело?
Для того, чтобы ты мог соединиться с pptp сервером, тебе надо сначала настроить тунель. При настройке тунеля также указывается и его имя. В директории /etc/ppp/peers появится файл, именем которого будет, как раз, то самое имя тунеля. a110c в своей подсказке указал в качестве имени: «$PROVIDER» — видимо, считает, что ты назвал тунель в честь своего провайдера (если это не так, то укажи то имя, которое придумал при настройке). В этом файле, как ты уже понял, хранятся настройки твоего PPTP-тунеля. Команда: «echo „persist“ >> /etc/ppp/peers/$PROVIDER» — добавляет в конец данного конфигурационного файла строчку «persist». Это некая опция для тунеля. Что именно делает эта опция, поищи в мануале или в интернете.
Спасибо fly4life за верный перевод! :)
Я исходил из того, что ты пользуешься pptp клиентом с sourceforge.net. Также ты написал, что линк у тебя поднимается, значит, и конфиг должен быть. Раз он там есть, то у меня зародилась надежда на то, что увидев
#echo «persist» >> /etc/ppp/peers/$PROVIDER ты как минимум сделаешь ls /etc/ppp/peers, увидишь, что там лежит файли с опциями и добавишь к опциям еще одну…
Нет, мужики, спасибо большое за этот ликбез, но … /etc/ppp/peers/ я настроил уже давно и ручками (почему-то автоматом ничего не работало). брали именно что с sourceforge.
ну а интересно как раз, что значит этот «persist» (ну я все-таки понимаю, что та команда всего лишь приписывала в конец файла).
все-таки не хочется что-то там приписывать в настройки соединения не понимая, что это такое есть.
Вам же redbeard написал:
Если не верите, то вот отрывок из man pppd:
Теперь поняли или вам перевести?
Странный ты. Я же тебе подсказал, где тебе читать про значение указанной опции. Ты почему-то проигнорировал.
Ты имел в виду вот это?
Прошу простить, ping->reconnect не заметил.
Нет, я про «persist». Забей уже ;). Просто скажи, решилась ли проблема?
в принципе есть такая же проблема на pptp. Соединение не теряется сервер удаленный Пингуется а фактически коннекта нет. У меня стоит reconnect if connection lost но он не видит что оно потерялось — в моем случае это gui pptpconfig
видимо та же ситуация.
не часто но случается. pptp 1.4 и 1.5 был роли не играет
вот лог в тот момент когда соединение потяряно
Using interface ppp0pptpconfig: monitoring interface ppp0
Connect: ppp0 <--> /dev/pts/3
MPPE 40-bit stateless compression enabled
local IP address 83.217.204.30
remote IP address 83.217.200.3
primary DNS address 83.217.193.2
secondary DNS address 83.217.192.2
pptpconfig: pppd process exit status 0 (started)
ip route add 10.0.0.10 via 10.8.112.1 dev eth0 src 10.8.117.254
pptpconfig: routes added to remote networks
ip route replace default dev 'ppp0\′
pptpconfig: default route changed to use tunnel
pptpconfig: DNS changes made to /etc/resolv.conf
pptpconfig: connected
ping -c 5 83.217.200.3
PING 83.217.200.3 (83.217.200.3) 56(84) bytes of data.
64 bytes from 83.217.200.3: icmp_seq=1 ttl=128 time=7.36 ms
64 bytes from 83.217.200.3: icmp_seq=2 ttl=128 time=7.28 ms
64 bytes from 83.217.200.3: icmp_seq=3 ttl=128 time=6.77 ms
64 bytes from 83.217.200.3: icmp_seq=4 ttl=128 time=7.01 ms
64 bytes from 83.217.200.3: icmp_seq=5 ttl=128 time=6.75 ms
— 83.217.200.3 ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 6.753/7.038/7.366/0.254 ms
Работает, или нет проверить не могу. дело в том, что эту ситуацию я спровоцировать не умею. более того, я просто даже не понимаю, откуда она возникает. у меня та же ситуация, что и у daemonBSD — ничего особенно в логах нет.
Звонил провайдеру — ничего не знают.
но с ними было и смешнее — в середине дня впн хорошо покдлючался. вечером стал ругаться на chap authentication failed (кстати, благодаря персисту тут же пробовал снова и снова). сам ничего не менял. проверил на всякий пожарный. звонок провайдеру — они ничего не далали. все, замкнутый круг. сегодня утром бац — все работает. прямо видовс какой-то — система живет своей жизнью (только неясно у кого, у меня, или у них; скорее у них все-таки).
chap authentication failed это могла сессия твоя подвиснуть если ругается E=691 (это вроде на пароль) то скорее всеего точно.
слушай, а у тебя какой провайдер?
у меня инфолайн.
Что значит подвиснуть? подвиснуть можно только если есть чему — у меня даж соединения не происходило. Да и по логам все шло ровно.
Что значит Е=691?
У меня домоком.
нет у меня когда еще бывает по вине прова сессия подвисает на их сервере и выдает ашибку аутентификации потому что сервер думает что я еще подключен в то время как давно соединения нет.
у меня бывает как описанный мной выше лог — то есть признаки здоровья pptp соединения при его фактическом отсутсткии,
так и ошибка аутентификации, то есть 691 вроде как пароль неверен но тут уж провайдер виноват
Эта 691ая ошибка у тебя выпрыгивает в логах?
так не знаешь, отчего может быть вот эта красота с неожиданным разрывом втихомолку?
нет не знаю но у меня таже проблема
+
а у тебя АДСЛ или выделенка?
у меня адсл
в данных случаях рекомендуется использовать traceroute или mtr для анализа, что и как….
а так же смотреть таблицу маршрутизации как локально, так и на удалённой стороне…
по поводу 691 ошибки — ну спросите же гугль://adsl+pptp+"error 691»
он добрый, много расскажет. ;)
Таблицу могу смотерть только у себя, на сервере никак. ну а причем она здесь вообще? как может быть связано CHAP authentication с таблицей? более того, скажу, что у меня запись об ppp делается в таблицу после создания соединения. до того система матерится и говорит, что о таких ничего не знает.
про гугль — у меня вовсе не адсл, ну и я еще ни разу не видел, чтобы в логах писался номер ошибки, а не сама суть, стоящая за этим номером. потому и удивился. но равно ничего подобного в лине еще не видел.
разумеется материться потому как она фактически начинает действовать маршрутизация после того как произошло соединение.
потому до того нет даже и устройства ppp