ОС FreeBSD 5.3По расписанию осуществляется дозвон по PPPoE. по умолчанию используется
интерфейс tun0. Но иногда случается достаточно редкая ситуация, когда соединение не отключено, а поступает команда на подключение. При этом ppp звонит по tun1- интерфейсу, который - есссно - не подключается... ибо
одно соединения уже есть и роутер, разумеется, не пускает. Вот и стоит ppp c двумя up интерфейсами - tun0 и tun1. Другого лечения, кроме shutdown -r now я не знаю. Отсюда вопросы :1. Как сделать так, чтобы ppp работал ТОЛЬКО с tun0 и других интерфейсов, в случае чего создавать не пытался ?
2. Если все же лишний tun - интерфейс создан, то как его прибить без перезагрузки ?Заранее спасибо.
>ОС FreeBSD 5.3
>
>2. Если все же лишний tun - интерфейс создан, то как его
>прибить без перезагрузки ?
>
>Заранее спасибо.Не знаю, есть ли во Free ifconfig, но под линем нет проблем:
ifconfig tun0 down
>Не знаю, есть ли во Free ifconfig, но под линем нет проблем:
>
>ifconfig tun0 down
Как ни странно есть... Работает анологично :)
>>Не знаю, есть ли во Free ifconfig, но под линем нет проблем:
>>
>>ifconfig tun0 down
>Как ни странно есть... Работает анологично :)Естествено есть, не настолькоя даун. Речь идет не об up/down операциях, а об уничтожении интерфейса, т.к. если в описанной ситуации сделать ifconfig tun1 down, то на работу ppp это не повлияет, он зараза, будет все равно звонить по tun1, а не по tun0. Вот собсна в чем проблема.
я сталкивался. твой ппп снова "зазвонит" по tun0 без shutdown
если ты предварительно сделаеш killall -9 ppp или чтото подобное чере kill
(бывает этот трабл когда ппп тупо зависает в ожидании чегото от модема или pptp потока - восновном изза нестабильной линии)
Еще вариант: рестартовать все сетевые сервисы. Т.е. pppd, VPN, network.
А вообще нужно разбираться с тем, что именно происходит. Почему вообще "дозвон по расписанию"? Почему, наконец, при разрыве PPPoE не отключается tun0?
Может быть что-то нужно в inittab засунуть (или в его фришный аналог), для чего-то может быть нужно дополнительные параметры указать, чтобы отслеживать состояние/работоспособность.
Да собственно достаточно стартап скрипт написать в котором анализировать наличие/отсутствие tun0 и соответственно прекращать/продолжать работу.Но идеологически правильно, ИМХО, все же действительно разобраться, что происходит и почему возникает подобная ситуация.
Профилактика, знаете ли, всегда эффективней лечения...
Ситация дана "как есть".Поясню подробнее:
Даны два тарифных плана, для разного времени суток, соответственно по расписанию, кроном выполняются простые действия, типа:
killall -HUP ppp
ppp -ddial ..........
а также запись логов брандмауэра и т.д.Допустим: Исправить ситуацию в корне нереально.
Интересует как решить две проблемы:
1. Как ЗАСТАВИТЬ ppp работать ТОЛЬКО c tun0 и не создавать других интерфейсов в случае непоняток ?
2. Как УНИЧТОЖИТЬ интерфейс сам по себе ?
в man ifconfig нашел ключик параметр destroy, но видимо /dev/hands у меня пока не на уровне а примеров использования чего-то вроде:
ifconfig tun1 destroy я не нашел.Эти вопросы меня интересуют, кроме всего прочего и как чисто теоретические.
Помогите, пожалуйста.
Нужно правильно написать скрипт подключения.
>Нужно правильно написать скрипт подключения.
Понял. Углублюсь в чтение man`ов.
>>Нужно правильно написать скрипт подключения.
>
>
>Понял. Углублюсь в чтение man`ов.
если используешь 4-ку там можно забить руками сколько tun может быть в
системе, если 5-ку и выше - увы, сей финт не прокатит
с остальным проблема, впрочем:[man ppp]
................
The -unit flag tells ppp to only attempt to open /dev/tunN. Normally,
ppp will start with a value of 0 for N, and keep trying to open a tunnel
device by incrementing the value of N by one each time until it succeeds.
If it fails three times in a row because the device file is missing, it
gives up.The following modes are understood by ppp:
сам за себя говорит. Если система по каким либо причинам в идит, что tunN
занят, она автоматом создает tunN+1
Skif,спасибо, что ткнул носом.
проблема устранена.