10.7.19. Процесс, вызвавший прозвонку в режиме auto, никогда не получает затребованного соединения

Эта проблема проявлялась, когда ppp в режиме auto был настроен на динамическое согласование локального IP-адреса с противоположной стороной. Это исправлено в последней версии - поищите на странице справочника слово iface.

Причиной было то, что когда эта программа использует системный вызов connect(2), для сокета назначается IP-адрес tun-интерфейса. Ядро создаЃт первый исходящий пакет и записывает его в устройство tun. Затем ppp читает пакет и устанавливает соединение. Если в результате согласования ppp динамического IP-адреса, адрес интерфейса менется, сокет будет работать некорректно. Любые IP-пакеты, передаваемые через сокет, будут отброшены. Если даже этого не произойдЃт, ответные данные не будут достигать отправителя, так как этот адрес больше ему не принадлежит.

Теоретически есть несколько способов решить эту проблему. Лучше всего, если противоположная сторона назначит интерфейсу тот же самый IP-адрес :-) Текущая версия ppp именно так и поступает, более ранние реализации этого не делали.

Самым простым решением будет просто никогда не менять IP-адрес tun-интерфейса, а вместо этого изменять на лету все исходящие пакеты так, чтобы IP-адрес источника менялся с IP-адреса интерфейса на согласованный с противоположной стороной. Это, в сущности, то же самое, что делает опция iface-alias в последней версии ppp (с помощью библиотеки libalias(3) и ключа -alias для ppp) - она отслеживает все назначенные ранее интерфейсу адреса и замещает их на последний из назначенных.

Другой возможный (и наверное, самый надЃжный) способ - это создать системный вызов, меняющий IP-адреса всем уже связанным сокетам. Ppp использовал бы этот вызов для модификации сокетов всех работающих программ после согласования нового IP-адреса. Этот же самый системный вызов могли бы использовать клиенты DHCP, когда они осуществляют повторную привязку к сокету.

ЕщЃ одной возможностью является резрешение интерфейсу становиться активным без IP-адреса. Исходящим пакетам будет даваться IP адрес 255.255.255.255 до тех пор, пока не будет дан ioctl-запрос SIOCAIFADDR. приводящий к полной привязке сокета. Ppp нужно будет изменять IP-адрес источника и контрольную сумму пакета, только если он установлен в 255.255.255.255. Это, однако, является некоторым хаком, так как ядро будет посылать некорректные пакеты на не полностью сконфигурированный интрерфейс, в предположении, что существует механизм исправления этих пакетов.