Процесс, вызвавший прозвонку в режиме auto, никогда не получает затребованного соединения
Эта проблема проявлялась, когда ppp(8) в режиме auto был настроен на динамическое согласование локального IP-адреса с противоположной стороной. Это исправлено в последней версии - поищите на странице справочника слово iface.
Причиной было то, что когда эта программа использует системный вызов connect(2), для сокета назначается IP-адрес tun-интерфейса. Ядро создаёт первый исходящий пакет и записывает его в устройство tun. Затем ppp(8) читает пакет и устанавливает соединение. Если в результате согласования ppp(8) динамического IP-адреса адрес интерфейса изменится, сокет будет работать некорректно. Любые IP-пакеты, передаваемые через сокет, будут отброшены. Если даже этого не произойдёт, ответные данные не будут достигать отправителя, так как этот адрес больше ему не принадлежит.
Теоретически есть несколько способов решить эту проблему. Лучше всего, если противоположная сторона назначит интерфейсу тот же самый IP-адрес :-) Текущая версия ppp(8) именно так и поступает, более ранние реализации этого не делали.
Самым простым решением будет просто никогда не менять IP-адрес tun-интерфейса, а вместо этого изменять на лету все исходящие пакеты так, чтобы IP-адрес источника менялся с IP-адреса интерфейса на соответствующий с противоположной стороны. Это, в сущности, то же самое, что делает опция iface-alias в самой последней версии (с помощью библиотеки и ключа -nat для ppp(8)) - она отслеживает все назначенные ранее интерфейсу адреса и замещает их на последний из назначенных.
Другой возможный (и, наверное, самый надёжный) способ - это создать системный вызов, меняющий IP-адреса всем уже связанным сокетам. ppp(8) использовал бы этот вызов для модификации сокетов всех работающих программ после согласования нового IP-адреса. Этот же самый системный вызов могли бы использовать клиенты DHCP, когда они осуществляют повторную привязку к сокету.
Ещё одной возможностью является разрешение интерфейсу становиться активным без IP-адреса. Исходящим пакетам будет даваться IP адрес 255.255.255.255 до тех пор, пока не будет дан ioctl-запрос SIOCAIFADDR. приводящий к полной привязке сокета. ppp(8) нужно будет изменять IP-адрес источника и контрольную сумму пакета, только если он установлен в 255.255.255.255. Это, однако, является некоторым хаком, так как ядро будет посылать некорректные пакеты на не полностью сконфигурированный интерфейс, в предположении, что существует механизм исправления этих пакетов.
