Technical data

B. Appendixes to optional packages

• remote IP will be set to 0.0.0.0 if nothing else is speciﬁed. Hence the routes conﬁgured

by the kernel while initializing the interface will vanish.

• additionally set routes will be saved in a ﬁle

• if a netmask is given for the circuit it will be transferred to the ipppd in order to use it

for the conﬁguration of the interface (and therefore route generation) after negotiation

of an IP.

• after dial-in the saved routes of the circuit will be reloaded from the ﬁle and set again

(they were deleted by the kernel while ipppd was reconﬁguring the interface)

• after hangup the interface will be reconﬁgured and routes are set anew to restore the

initial situation.

Conﬁguration of a circuits looks like this in that case:

• item default route

ISDN_CIRC_%_ROUTE='0.0.0.0'

If the circuit is a lcr circuit and “active” in the moment a default route will be set

towards the circuit (res. the according interface). After dial-in a host-route to the

provider appears that vanishes after hanging up.

• special routes

ISDN_CIRC_%_ROUTE='network/netmaskbits'

The given routes for the circuit (res. the according interface) will be set. After dial-in

the routes deleted by the kernel will be restored and a host-route to the dial-in node

exists. After hangup the initial state will be restored.

• remote ip

ISDN_CIRC_%_REMOTE='ip address/netmaskbits'

ISDN_CIRC_%_ROUTE='network/netmaskbits'

While conﬁgurating the interface routes to the target net appear (according to IP address

AND netmask). If the speciﬁed IP is kept after dial-in (meaning no other IP is negotiated

during connection establishment) the route will be kept as well.

If another IP was negotiated during dial-in the route will change accordingly (new IP

AND netmask).

For additional routes see above.

This will hopefully solve all problems raised by special routes. The way of correction may

change in the future but the principle won’t.

367