Pppd dns что это
Итак, getty в качестве шелла вызывает /usr/sbin/pppd, поэтому мы не можем задать параметры pppd из командной строки, и зададим все необходимые параметры в файлах /etc/ppp/options и /etc/ppp/options.ttyd0. Напомню, что в первом у нас записано:
Во второй же мы поместим следующее:
Рассмотрим параметры подробнее:
passive При запуске pppd пытается несколько раз установить PPP-соединение, если же все попытки оказались неудачными, pppd завершает работу. Этот параметр указывает pppd не завершать работу, а пассивно ожидать попытки установления соединения, исходящие с удалённой стороны.
192.168.1.1:192.168.1.200 Этот параметр задает соответственно локальный и удалённый адреса для данного соединения, то есть локальный адрес равен 192.168.1.1, а адрес удалённой стороны - 192.168.1.200. В принципе, адреса могут быть выбраны совершенно от балды, например, 192.168.100.1:10.0.0.1 - между нашим и удалённым компьютером будет работать PPP-соединение. Проблемы начнутся, когда удалённый компьютер будет использовать наш в качестве маршрутизатора для доступа к другим компьютерам. Тут нам придется попотеть с таблицей маршрутизации. Но если удалённой стороне нужно выделить только один адрес без всяких сетей, то существует способ избежать этого. Для этого удалённой стороне нужно назначить адрес, входящий в нашу локальную сеть, и указать pppd параметр proxyarp, описанный чуть ниже. Кстати, адрес локальной стороны может совпадать с адресом одной из сетевых карт на этом же компьютере.
После того, как к нам позвонят и pppd установит соединение, выполним команду
Мы увидим, что сетевому интерфейсу ppp1 назначен адрес 192.168.1.1:
А выполнив команду
мы удостоверимся, что удалённой стороне назначен адрес 192.168.1.200:
proxyarp Каждый компьютер в сети хранит таблицу соответствия локальных IP-адресов и физических адресов, например, ethernet'овских. Исходя из этой таблицы, сетевой драйвер определяет по какому физический адресу нужно послать пакет с заданным IP-адресом. Эта таблица динамически обновляется с помощью протокола ARP.
Если мы выбрали для удалённой стороны адреса, которые входят в нашу локальную сеть, то имеет смысл использовать параметр proxyarp. Этот параметр указывает pppd создать запись в этой таблице для адреса удалённой стороны (в нашем примере - 192.168.1.200) и поставить ему в соответствие физический адрес одной из сетевых карт, установленных на локальном компьютере. В результате, все компьютеры в нашей локальной сети (кроме того, на который позвонили) будут считать, что адрес 192.168.1.200 находится на этом компьютере и, таким образом, проблемы с маршрутизацией с нашей стороны не возникает.
После успешного соединения выполним команду
и увидим, что pppd создал для удалённой стороны с адресом 192.168.1.200 запись в нашей таблице с физическим адресом "0:40:c7:95:38:72":
Выполнив на соседнем компьютере ту же команду
мы увидим, что для него наши два адреса вообще никак не отличаются:
ms-dns 192.168.1.2 и ms-dns 192.168.1.4 Windows 95 и NT 4.0 при установлении PPP-соединения запрашивает адреса двух DNS серверов. Первый параметр задает адрес первого DNS сервера, а второй, понятно, второго. Если у Вас только один DNS сервер, то укажите параметр только один раз.
Этот параметр никак не влияет на адреса DNS клиента, если клиентом выступает pppd. В старых версиях pppd этому параметру соответствовали два других - dns1 и dns2, но, очевидно, эти названия неоднократно вводили публику в заблуждение относительно их применения и параметр переименовали.
debug Это параметр указывает pppd вести подробный протокол соединения.
В два других файла /etc/ppp/options.ttyd2 и /etc/ppp/options.ttyd3 мы запишем то же самое, за исключением адреса удалённой стороны - он будет другой - соответственно 192.168.1.1:192.168.1.201 и 192.168.1.1:192.168.1.202. Локальный же адрес во всех соединениях мы будем использовать один и тот же.
В принципе, адреса для соединения pppd, как все остальные параметры, определяет в следующем порядке:
Из файла /etc/ppp/options.
Записывать что-то сюда - занятие достаточно бессмысленное. Правда, сюда можно поместить адрес локальной стороны - 192.168.1.1:, так как он у нас одинаков для всех входящих соединений. Но поскольку у нас есть одно исходящее соединение к нашему провайдеру, лучше этого не делать.
Из файла ~/.ppprc, находящегося в домашнем каталоге пользователя, который запустил pppd.
От этого файла тоже мало пользы. Поскольку, либо нам придется каждому пользователю выделять по отдельному адресу, либо эти адреса всё равно будут переопределены следующим файлом. Кроме того, если мы будем использовать PAP или CHAP аутентификацию, то pppd будет всегда запускаться от root'а. В этом случае, лучше назначать адреса с помощью secrets-файлов.
Из файла /etc/ppp/options.ttyd0.
Наиболее действенный способ, которым мы и вспользовались. Каждому порту выделяется свой адрес.
Из командной строки pppd.
Для этого нам нужно записать pppd с нужными нам параметрами в файл:
назовем этот файл ppplogin.sh, поместим его в домашний каталог пользователя и установим его в качестве шелла для этого пользователя. Этот метод позволяет некоторым пользователям выделить отдельный адрес.
linux samba mail postfix FreeBSD Unix doc linux howto ALTLinux PHP faq bind sendmail apache iptables firewall kernel rpm apt-get Slackware openssh Cisco debian vmware GNU oracle sun awk /etc/ passwd linux установка учебник книга скачать
Состояние перевода: На этой странице представлен перевод статьи Ppp. Дата последней синхронизации: 24 января 2022. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.
ppp (Paul's PPP Package) — пакет с открытым исходным кодом, который реализует протокол соединения точка-точка (PPP) для систем Linux и Solaris. Пакет предоставляет демон pppd, который может быть использован вместе с xl2tpd , pptpd и netctl.
Протоколы 3G, L2TP и PPPoE работают на основе PPP, поэтому они также могут контролироваться ppp.
Troubleshooting
ФОРМАТ ФАЙЛА
Секция global
Секция server
Секция rr
Каждая секция rr указывает ресурсную запись DNS, которая хранится локально. Это позволяет указывать собственные записи DNS, которые обслуживаются pdnsd ограниченным образом. Реализованы только записи A, PTR, CNAME, MX, NS и SOA.
Эта опция позволяет определять ресурсные записи для 1.0.0.127.in-addr.arpa. и localhost. (и возможно даже одного или двух узлов) без запуска дополнительного сервера имён, если кэширующие серверы имён не обслуживают эти записи. Предполагается, что pdnsd НЕ способен работать в качестве полноценного сервера имён.
name=строка; Описывает доменное имя ресурсной записи . Эту опцию необходимо указывать перед записей любого типа: A, PTR, CNAME, MX, NS или SOA. Имена интерпретируются как абсолютные доменные имена (то есть pdnsd подразумевает, что они оканчиваются корневым доменом). Для этих и всех последующих аргументов, которые требуют доменные имена, нужно указывать доменные имена в точечной нотации (например venera.isi.edu.).
Предыдущая версия pdnsd требовала, чтобы доменные имена, заданные в конфигурационном файле, оканчивались точкой. Но начиная с версии 1.1.8b1-par8, pdnsd автоматически добавляет точку в конце, если она пропущена.
Новое в версии 1.2: Также возможно указать имя, начинающееся с метки *. Такие имена называются шаблонами. Со * в шаблоне может совпадать одна или более меток в запрашиваемом имени, но только метки целиком. Любые другие, не начальнеы символы * в шаблоне, совпадают со * только буквально.
Например, *.mydomain совпадёт с a.mydomain или www.a.mydomain, но не с mydomain. *.a*.mydomain совпадёт только с www.a*.mydomain, но не с www.ab.mydomain. *a.mydomain совпадёт только с самим собой.
Перед указанием секции rr с name=*.mydomain, нужно определить несколько записей для mydomain, обычно это NS и/или SOA записи. Например:rr name = mydomain;
ns = localhost;
soa = localhost, root.localhost, 42, 86400, 900, 86400, 86400;
>
rr name = *.mydomain;
a = 192.168.1.10;
>В этом примере, www.mydomain и ftp.mydomain будут решаться в числовой адрес 192.168.1.10 (если нет секций rr, явно указывающих адреса для www.mydomain или ftp.mydomain). Если нужно, чтобы mydomain тоже решался в числовой адрес, добавьте запись A в первой секции rr.
ttl=время; Указывает ttl (время жизни) для всех ресурсных записей в этой секции после этой опции. По умолчанию это 86400 секунд (=1 день). authrec=(on|off); Если эта опция включена, то pdnsd будет создавать полномочные локальные записи для этой секции rr. Это означает, что pdnsd помечает доменную запись, так что записи этого домена, не представленые в кэше, будут обрабатываться как несуществующие. То есть pdnsd будет считать, что нет других серверов, у которых может быть запрошена запись этого типа. При этом возвращается ответ, не содержащий записей запрошенного типа. Это чаще всего то, что нужно: если вы добавили запись A для узла, и он не имеет записи AAAA (и нет адресов IPv6), обычно не нужно, чтобы для решения записи этого типа запрашивались другие серверы имён.
Эта опция включена по умолчанию.
Помните, что эта опция имеет эффект, только если ей предшествует опция name!reverse=(on|off); Новое в версии 1.2: Если нужно, чтобы локально определённые имена решались в числовой адрес и наоборот, это можно сделать установив reverse=on до определения записи A (смотрите ниже). Другой способ достичь того же эффекта - определить отдельную запись PTR, но эта опция чаще бывает намного более удобной.
По умолчанию выключено.a=строка; Определяет запись A (адрес узла). Аргумент - IP-адрес в точечной нотации. pdnsd будет обслуживать этот адрес, как соответствующий имени узла, указанному в опции name.
Для указанного здесь достаточно поддержки в библиотеках C и чтобы при компиляции не использовалась опция --disable-new-rss, строка-аргумент может быть также адресом IPv6, в этом случае должна быть определена запись AAAA.
Эта опция может использоваться несколько раз внутри секции rr, таким образом для имени можно определить несколько адресов. Однако, если вы поместите разные адреса в разные секции rr под тем же именем, определение в последней секции rr отменит определения в предыдущих секциях.ptr=строка; Определяет запись PTR (указатель доменного имени). Аргумент - имя узла в точечной нотации (смотрите описание опции name). Запись PTR используется для решения адресов в имена. Например, если вы хотите, чтобы адрес 127.0.0.1 решался в localhost, и localhost в 127.0.0.1, вам нужно нечто подобное следующим секциям: rr name = localhost;
a = 127.0.0.1;
owner = localhost;
soa = localhost, root.localhost, 42, 86400, 900, 86400, 86400;
>
rr name = 1.0.0.127.in-addr.arpa;
ptr = localhost;
owner = localhost;
soa = localhost, root.localhost, 42, 86400, 900, 86400, 86400;
>Вторая секция предназначена для обратного решения и использует опцию ptr. Отметим, что можно достичь того же эффекта, указав только первую секцию с reverse=on.
У имени во второй секции есть особенность: когда решатель хочет получить имя узла по интернет-адресу, он формирует адрес, который будет построен из байтов IP-адреса в обратном порядке (1.0.0.127 вместо 127.0.0.1), где каждый байт адреса записывается как число, составляющее поддомен домена in-addr.arpa.
Так что, если вы хотите сформировать адрес для обратного решения, возьмите IP в точечной нотации (например 1.2.3.4), обратите порядок байтов (4.3.2.1) и дополните in-addr.arpa. (4.3.2.1.in-addr.arpa.). Теперь, определите секцию rr, задающую в опции ptr этот адрес в виде имени и укажите доменное имя соответствующее этому IP-адресу.cname=строка; Определяет запись CNAME (каноническое имя). Аргумент должен быть полностью определённым именем узла в точечной нотации (смотрите описание опции name). CNAME - это DNS-эквивалент псевдонима или символической ссылки.
Полезное применение для CNAME - задание коротких, легко запоминающихся имён для узлов со сложными именами. Например, можно создать имя "news", ссылающееся на сервер новостей "nntp2.myisp.com" вашего провайдера. Вместо добавления записи A для "news" с тем же адресом, что у "nntp2.myisp.com", можно задать CNAME указывющий на "nntp2.myisp.com", так что если IP-адрес сервера новостей вдруг изменится, не нужно будет обновлять запись для "news".
Чтобы осуществить это в pdnsd, можно добавить следующую секцию в файл конфигурации:rr name = news;
cname = nntp2.myisp.com;
owner = localhost;
>mx=строка,число; Определяет запись MX (почтовый обмен). Строка - это имя узла почтового сервера в точечной нотации (обратитесь к описанию опции name). Число указывает уровень предпочтения.
Когда вы кому-либо отправляете письмо, письмо обычно идёт от вашего клиента электронной почты к вашему SMTP-серверу. Ваш SMTP-сервер проверяет MX-запись домена в почтовом адресе. Например, для joe@example.com, будет просматриваться запись MX для example.com и будет найдено имя почтового сервера для этого домена, скажем, mail.example.com. Затем ваш SMTP-сервер получит A-запись для mail.example.com, и соединится с почтовым сервером адресата.
Если имеется несколько MX-записей, ваш SMTP-сервер будет выбирать одну из них, основываясь на уровнях предпочтений (начиная с наименьшего уровня предпочтения с учётом работоспособности).
Не определяйте записи MX в pdnsd если вы не уверены в том, что вы делаете.owner=строка; или ns=строка; Определяет запись NS (сервер имён). Указывает имя узла, который должен быть полномочным для записей, определённых в секции rr. Обычно это узел, на котором запущен pdnsd.
Замечание: В предыдущих версиях pdnsd эта опция должна была указываться перед любой записью A, PTR, CNAME, MX или SOA. В версии 1.2, ограничения на эту опцию такие же, как у только что упомянутых опций, она должна быть указана после опции name=. Это может быть неприятно, если вы используете старый конфигурационный файл, в котором указывается owner= перед name= (приносим свои извинения). Кроме большей согласованности, преимущество также состоит в том, что теперь можно указать столько записей NS, сколько необходимо (включая ноль).soa=строка,строка,число,время,время,время,время; Определяет запись SOA (начало полномочий). Первая строка - это доменное имя сервера, оно должно совпадать с именем, которое вы указали в качестве владельца.
Вторая строка указывает почтовый адрес администратора сервера имён. Он тоже указывается как доменное имя, так что нужно заменить знак @ в имени на точку (.) чтобы получить имя, которое нужно здесь указать. Следующий параметр (первое число) - это серийный номер записи. Вы должны увеличивать это число при изменении записи.
Четвёртый параметр - это период обновления. Он указывает время, по прошествии которого кэширующий сервер должен попытаться обновить кэшированную запись.
Пятый параметр указывает время, через которое кэширующий сервер должен попытатья обновить запись после ошибки обновления.
Шестой параметр определяет тайм-аут, после которого кэшированная запись устареет, если она не была обновлена.
Седьмой параметр - это время жизни, которое указывается в каждой ресурсной записи и должно быть таким же, как заданное с помощью опции ttl (если ttl не указан, воспользуйтесь значением по умолчанию - 86400).
Секция neg
Секция source
Не удается загрузить модуль ядра ppp_generic
Проблема выражается в том, что при запуске процесс pppd не может найти соответствующий модуль:
Решается исправлением /etc/modprobe.d/modules.conf : замените в файле строку
ppp (Paul's PPP Package) is an open source package which implements the point-to-point protocol (PPP) on Linux and Solaris systems. It is implemented as single pppd daemon and acts as backend for xl2tpd , pptpd and netctl. 3G, L2TP and PPPoE connections are internally based on PPP protocol and therefore can be managed by ppp.
Prerequisites and tested hardware
The only requirement is the ppp package (2.4.5-1 tested). The method described supports easy switching between several carriers and 3G and GPRS modes. It has been tested and directly works with no modifications (except for the device name) with:
- Huawei EM770 MiniPCIe modem (Asus Eee PC 1000H Go internal integrated modem).
- Huawei E220 and E1552 external USB dongles.
- Nokia N73 (USB tethering; select "PC Suite" when the phone asks).
- Nokia CS-15 (lsusb says 0421:0612 Nokia Mobile Phones)
- Alcatel x310e (carrier: Wind IT)
This guide assumes that your modem hardware is properly detected and working. You simply may look at /var/log/messages to discover the device names appeared when the modem is plugged in. Alternatively:
In this computer there are 2 devices available: a internal 3G modem (ttyUSB0) and a external 3G dongle (ttyUSB3). The Nokia phones use other device names, like ttyACM0. The extra devices created are useful to get and query the internal modem state while the main one is in use (you may try the cat command on them).
To enable some modems you may need the usb_modeswitch package (see the USB 3G Modem wiki for more information).
/etc/ppp/options-mobile
Create this file:
The first line is the modem device (ttyUSB0 in the example) and it will be a permanent option while your hardware does not change. You may want to modify some options (see man pppd). The proposed setup tries to keep the connection permanently established, reconnecting when necessary.
^SRVST
Reports the type of service the network your currently registered to is providing (it seems normal to first report 1 and then switch to 2). Depending on the device there might be more types.
Reports the mode you are currently transmitting in. Depending on the device there might be more modes. Note: It seems normal for the device to only go to 5,5/5,6/5,7 when transmitting and fall back to 5,4 when idle.
Reports strength of the mobile signal in form of $rssi,[$ber]. This info can also be optained by issuing AT+CSQ but unless you are registered to a network it seems this just returns the value for the strongest network whenever you are able to use it or not. To give some meaning to this you can convert it to percent by RSSI / 31 * 100. RSSI of 3/4 (about 10% reception) seems to be the absolute minimum to get a (rather flaky) HDSPA connection.
Маршрут по умолчанию
При запуске pppd пытается добавить свой системный маршрут по умолчанию (default route). Если перед запуском уже был установлен такой маршрут, pppd не станет его обновлять, и новые соединения во внешнюю сеть направляться не будут. При этом в /var/log/errors.log вы увидите что-то наподобие:
Если это поведение нежелательно, и xxx.xxx.xxx.xxx — совсем не то, что вам нужно, вы можете создать простой скрипт в /etc/ppp/ip-pre-up.d/ с таким содержимым:
Не забудьте дать скрипту права на запуск. Также убедитесь, что есть скрипт с названием 'ip-pre-up', который запускает *.sh файлы из каталога 'ip-pre-up.d'.
PPPoE
Создайте файл настроек соединения:
Если задана опция usepeerdns , при соединении pppd создаст файл /etc/ppp/resolv.conf с полученными адресами DNS-серверов. По умолчанию скрипт /etc/ppp/ip-up.d/00-dns.sh перемещает этот файл в /etc/resolv.conf , чтобы система могла использовать эти DNS-серверы. Если это поведение является нежелательным (например, установлен локальный кэширующий DNS), отредактируйте /etc/ppp/ip-up.d/00-dns.sh под ваши нужды.
Добавьте запись с паролем соединения в /etc/ppp/pap-secrets или /etc/ppp/chap-secrets , в зависимости от типа аутентификации, используемого вашим провайдером.
По возможности используйте chap, так как он безопаснее (здесь можно почитать о том, как работает chap). Однако, если вы не уверены, можно добавить запись в оба файла, pppd выберет нужный самостоятельно. Запись выглядит следующим образом:
Имя пользователя должно совпадать с именем, указанным в опции name . Оно также используется для аутентификации, если не переопределено другим значением с помощью опции user .
Теперь вы можете попробовать установить соединение командой:
где имя_соединения — имя файла настроек, созданного в /etc/ppp/peers .
Чтобы убедиться, что соединение PPPoE установлено, проверьте вывод pppd в системном логе:
При успешном соединении вы увидите что-то наподобие следующих строк:
Файл настроек /etc/ppp/peers/provider используется по умолчанию, если при вызове pppd не было указано имя файла. Вместо явного указания имени файла настроек программе pppd вы также можете просто добавить символическую ссылку на свой файл:
Теперь можно устанавливать соединение одной командой
Чтобы разорвать соединение, выполните
Automatic PPP
and it will connect ppp as soon as you plug in the device. You can probably do something similar for the other modems.
Простой мастер настройки
pppconfig AUR предоставляет текстовый интерфейс, основанный на dialog, для лёгкой конфигурации pppd. Для использования просто запустите команду pppconfig от имени root и следуйте дальнейшим инструкциям.
Полученную конфигурацию можно подключать и отключать с помощью команд pon и poff как описано выше.
Default route
If you have a preconfigured default route before the pppd is started, the default route is kept, so take a look in /var/log/errors.log and if you have something like:
and xxx.xxx.xxx.xxx is not the correct route for you
- Create a new script in /etc/ppp/ip-pre-up.d with this content:
Note: Make sure you have a script named 'ip-pre-up' which launches *.sh in 'ip-pre-up.d' like other launch scripts do.
Configuration
network hook
Users of traditional network setup (instead of netcfg) can use the following trick to launch the wait-dialup-hardware script from the standard /etc/rc.d/ppp service. The example is intended to run the mobile-noauth profile:
Updating the default provider symlink to point to the new intermediate (fake) mobile-noauth.wait profile, it will simply run the wait-dialup-hardware script from within pppd and, in turn, will restart pppd with the final (non fake) mobile-noauth profile once the hardware is ready. Note that the noauth option in the first line of the fake profile is necessary (even if the final profile does requires authentication).
Tips and tricks
Start the pppd
To start the pppd daemon, either run pon/poff or /etc/rc.d/ppp start|stop. In Arch this can be automated to occur at system boot by adding "@ppp" after "network" in the DAEMONS line of /etc/rc.conf (the "@" places it in background, since pppd start may be a bit slow).
The log is stored in /var/log/messages.
With the above proposed setup, while the new ppp0 interface is up, pppd will automatically set your default route (if none previously existing) as well as the /etc/resolv.conf contents. It seems very reliable handling DNS switchings (the backup is kept in resolv.conf.backup.ppp0, but I never had to manually restore it, even after a power failure).
Установка
Убедитесь, что ядро вашей системы скомпилировано с поддержкой PPPoE (верно для стандартной сборки):
ВЕРСИЯ
Эта страница руководства корректна для версии 1.2.6-par pdnsd.
AT^SYSCFG Huawei command reference
To see the supported values, you can query your own modem sending the "AT^SYSCFG=?" command.
AT^SYSCFG=? command output on Huawei EM770:
Masquerading seems to be working fine but some sites do not work
The MTU under pppoe is 1492 bytes. Most sites use an MTU of 1500. So your connection sends an ICMP 3:4 (fragmentation needed) packet, asking for a smaller MTU, but some sites have their firewall blocking that.
Enabling the PMTU clamping in iptables can solve that:
Now, for some reason, just trying to save the resulting iptables configuration with iptables-save and restoring it later, does not work. It has to be executed after the other iptables configuration had been loaded. So, here is a systemd unit to solve it:
Listing
AT+COPS=? returns a list of all available networks in the format of $state,$longname,$shortname,$id,$tech.
Автодозвон
Если pppd запущен, вы можете выполнить сброс соединения, отправив процессу сигнал SIGHUP :
После разрыва соединение будет вновь установлено.
Примечание: Убедитесь, что опция persist включена в ваш файл конфигурации /etc/ppp/peers/provider . Также вы можете добавить параметр holdoff 0 для переподключения без тайм-аута.
Используя cron
Примечание: Есть много разных реализаций cron, но ни одна из них не установлена по умолчанию; вместо него базовая система использует таймеры systemd.
Выполните следующие шаги от имени суперпользователя.
Создайте файл скрипта (например, pppd_redial.sh ) со следующим содержимым:
Сохраните файл и сделайте его исполняемым.
Теперь создайте задачу для cron, используя команду crontab -e . Если появляется ошибка, убедитесь, что установлена переменная окружения EDITOR . По команде откроется редактор — добавьте в него строку, указав правильный путь до вашего скрипта перезапуска соединения:
Сохраните файл и убедитесь, что служба cronie работает. Если это не так, включите и запустите службу cronie .
Теперь ваше соединение будет перезапускаться каждый день в 4 утра.
Используя таймер systemd
Также вы можете настроить таймер systemd для выполнения ежедневного перезапуска соединения. Просто создайте файлы .service и .timer с одинаковыми именами:
Теперь просто включите и запустите таймер, и systemd будет выполнять сброс соединения каждый день в указанное время.
Contents
Huawei unsolicited report command reference
These appear on the second ttyUSB.
netcfg hook
To use the above script, netcfg users could add the following profile:
Do an auto redial
If pppd is running, you can force a connection reset by sending the SIGHUP signal to the process:
And you have redialed the connection.
Note: Make sure you have persist option enabled in your /etc/ppp/peers/provider tab. Additionally you might want to set holdoff 0 to reconnect without waiting.
Using cron
Note: There are many cron implementations, but none of them are installed by default as the base system uses systemd/Timers instead.
As root, do the following:
Create a bash script similar to this and give it a name (e.g. pppd_redial.sh ):
Give it execute permissions and put it on a path visible to root.
Then create a cron job using crontab -e . Check that your EDITOR env variable is set if the command fails. So add anywhere in the file,
Confirm that cronie service is up and running. If this is not the case, just enable and start it.
Save and exit. Your PPPoE connection will now restart every day at 4AM.
Using a systemd timer
An alternative way to force a reconnect is using a systemd timer and the poff script (in particular its -r option). Simply create a .service and .timer files with the same name:
Now just enable and start the timer and systemd will cause a restart at the specified time.
Troubleshooting
In case of using a wrong PIN, my modem consistently rejects the APN setting phase (no error in the steps before). This is how /var/log/messages looks like:
It would be a long story, but I will simply abbreviate it: if you have just set or changed the PIN in a phone, please reboot the phone and try it in the phone before placing the SIM card in the modem (I'm not sure if the PIN updates take effect just at the moment they are done in the phone menus).
In case of frequent manual pppd restarts, as for example when testing configuration options, the EM770 (firmware upgraded to 11.104.16.12.00) sometimes becomes confused. Despite it responds to the AT commands, it gets stuck in a "NO CARRIER" reply (while the 3G network is ok, as a mobile phone may report). This not occurs with the proposed scripts (in case of connection lost, they wait enough time before retrying). With the modem stuck, powering OFF and then ON the computer solves the problem. This is perhaps a firmware bug. Also, when using a PIN, this modem returns a NO CARRIER reply in the first connection try (it seems that a huge wait after setting the PIN helps; anyway the same effect is achieved by the ordinary connection retry). While running, the EM770 is stable, but the E220 or the Nokia phones are far more reliable in the connection phase. Your mileage may vary depending on your hardware.
At least for Huawei E870 issuing AT+CFUN=1,1 (meaning restart and go to online mode) seems to fix being stuck with no NO CARRIER without having to reboot. This might be related to network registration being done after restart. You can check AT+COPS? to see if you are actually registered but note you also want a service state of 2 (meaning "valid service" - this is automatically reported by the card as ^SRVST:X on the second ttyUSB) otherwise trying to dial out is hopeless. In the rare case of the card becoming completely stuck (doesnt respond to AT commands anymore) this can be fixed by using pccardctl (pccardctl eject [slot-number]; pccardctl insert [slot-number]). Of course this only works for pcmcia cards but maybe there is a similar trick for USB dongles.
Маскарадинг работает, но некоторые сайты не открываются
Проблема решается добавлением правила с PMTU clamping в iptables:
Однако, по некоторой причине, это правило может не попадать в вывод iptables-save. Если у вас тот случай, когда iptables-restore не восстанавливает правило после перезапуска, попробуйте следующее решение.
Создайте файл службы systemd:
Contents
Easy wizard configuration
pppconfig AUR provides a dialog interface to create pppd configuration easily. The usage is as simple as running pppconfig as root and it will guide the configuration creation.
The resulting configuration can be called using pon and discarded using poff as mentioned before.
Starting pppd on boot
Manual selection
You can lock the device to only connect to a specific operator by issuing AT+COPS=1,$format,$operator command. Note: Even the numeric id needs to be quoted.
Эта страница руководства описывает структуру файла конфигурации pdnsd8 и доступные опции настройки. По умолчанию файл находится в /etc/pdnsd.conf, но это можно изменить с помощью опции -c командной строки. Пример файла pdnsd.conf имеется в составе дистрибутива pdnsd в каталоге с документацией или в файле /etc/pdnsd.conf.sample.
Советы и рекомендации
PPPoE
Create the connection configuration file:
If usepeerdns option is used, pppd will create the /etc/ppp/resolv.conf file with obtained DNS addresses while establishing a connection. By default, the /etc/ppp/ip-up.d/00-dns.sh hook script moves this file to /etc/resolv.conf , allowing the system to use these name servers. If this is undesirable (e.g. you are using a local caching DNS), edit the /etc/ppp/ip-up.d/00-dns.sh as you need.
Put a line like this in /etc/ppp/pap-secrets or /etc/ppp/chap-secrets as required by the authentication method used by your ISP.
Chap should always be preferred, when possible, if aiming at security (to understand how chap works see this), however it is OK to write these two files at the same time, pppd will automatically use the appropriate one:
You can now start the link using the command:
Alternatively, you can use this
where your_provider is the exact name of your options file in /etc/ppp/peers .
To see whether your PPPoE connection is started correctly, check the pppd output in system logs:
On a successful connection, you will see something like the following:
By default the configuration in /etc/ppp/peers/provider is treated as the default, so if you want to make "your_provider" the default, you can create a link like this
Now you can start the link by simply running:
To close a connection, use this
Operator selection
Configuration
/etc/ppp/peers
Add these files:
The provider symlink defines the default peer for pppd, and as you see it points to the mobile-noauth file. It is possible to setup a different file with user/password for each carrier (with mobile-auth being a example) but it seems that this is not necessary (at least, not for Vodafone or Simyo in Spain).
Patch for modem availability after booting
This article or section is out of date.
If you automate the pppd start, it may occur that the modem device does not exists at the moment of the pppd launch during the computer boot. This may occur even when the USB modem module load is manually setup in rc.conf: that helps, but the device may be still not always available when pppd comes into scene. The pppd daemon rejects to start when the configured device does not exists, and it does not seems to have an option to force it to start (note that in case the device disappears once pppd is already running, for example by momentarily disconnecting the external 3G USB modem, pppd will continue running and will reconnect once it appears again).
The following script may be useful to wait until the hardware is ready. It will typically wait for 0-2 seconds. The modem device is assumed to be the first line on /etc/ppp/options-mobile. It takes an argument with the maximum wait (in seconds). Optionally admits a second argument with a profile name (from /etc/ppp/peers) which will be used to re-run pppd. Do not forget to make the script executable:
The script will add a line to /var/log/messages :
Запуск pppd при старте системы
Решение проблем
Contents
/etc/ppp/chatscripts
The core script is mobile-modem.chat, which dialogues with the modem and properly inserts another tiny scripts for selecting the APN, GPRS/3G and the PIN code. You probably will not need to modify it. This script is interpreted by the limited (but powerful enough) chat tool, included in the standard ppp package. With the proposed method, you will keep a little personal file-based "database" of settings.
If you exchange the SIM card, to select the new carrier you only need to update the apn symlink to point to the correct apn file and restart the ppp network (for example with killall -HUP pppd). The same for changing between 3G/GPRS forced modes (mode symlink).
The other files consist in a single line, which in some cases you may need to modify in order to customize it.
(of course, you will have to create your own apn files, replacing "ac.vodafone.es" or "gprs-service.com" by your own APN strings on them).
For Telenor, use your mobile phone number (without country code) for both user and password in /etc/ppp/peers/mobile-noauth.
If your SIM card has the PIN code disabled, you should symlink pin to pin.NONE to avoid sending it. When a SIM card has the PIN code enabled, it is only required to be sent the first time after power on. There is a modem command to query about this, but since I did not find a reliable way to use it in the chat script, the PIN, when enabled, is always sent. This has no drawbacks, other than a little additional delay also due to the chat script limitations while recovering from the modem error response (if the PIN was no longer required).
The SYSCFG line in the mode.* files is device-dependent, and likely Huawei-specific. It does not works in Nokia phones (you may symlink mode to mode.NONE, which only sends the AT command with no effect). I had to investigate before achieving success with both EM770 and E220 modems. Despite many forums reporting a "4" trailing code, it seems that the trailing 0/1 number, while optional in E220, becomes mandatory in EM770 for truly switching the mode. At the end of this guide there are explained the available options for this command. As previously said, you may simply link to mode.NONE and use your modem defaults in case of problems.
Easy wizard configuration
Instead of manually creating pppd configuration, pppconfig AUR can be used to create pppd configuration and chatscripts easily. Editing chatscript is needed to provide APN name, e.g. adding AT+CDGCONT=1,"IP","apnname" on specific chatscript profile, e.g. /etc/chatscripts/mobile .
pppd cannot load kernel module ppp_generic
When starting PPTP client, the pppd process cannot locate the appropriate module:
Why not to use a pppd wrapper (like wvdial or similar)?. I particularly switched to direct pppd because my previous software sometimes silently exited instead of reconnecting, as it was configured to do, requiring me to travel to manually perform the reconnection.
You may be reading this page by the same reason it was written for: you may have finally concluded that the lesser the layers, the less likely the troubles.
Installation
Make sure that your kernel is compiled with PPPoE support (present in default kernel):
Настройка
Читайте также: