The chargeint always hangs up two seconds before the end of the charge
unit. isdnlog sets the length of the charge unit (i.e. Charge Interval)
according to the time of day and the date. The additional parameter for
"-h"
for isdnlog will reduce this length of time by the
given value. This additional parameter should not be used with chargeint,
otherwise chargeint will end the connection too early. This error increases
with the number of charge units. Therefore: "-h0"
to avoid
this problem.
/sbin/isdnctrl huptimeout ippp0 80
With the isdnctrl parameter "chargeset" you can set the length of a charge unit, so that it can hang up at the correct time. However, since the length of a charge unit depends on the time of day, day of week, holiday, etc., it makes no sense to use a set value. Here's where isdnlog comes in. It notices when a connection is established and calculates the length of a charge unit depending on the time of day, day of week, holiday. This is then given to isdnctrl, so it can hang up at the right time. isdnlog "tunes" isdnctrl at each connection, and also during a connection (when isdnlog is run with the "-w x" parameter). isdnlog allows isdnctrl exactly 2 seconds before the next charge unit to hang up, as long as the time entered with "huptimeout" has elapsed with no data being transferred. The transmission of a charge unit impulse is not necessary, since the times are calculated closely enough. The charge unit impulse is sent a varying intervals, so it cannot be relied upon
It's best to synchronize the clock in your own computer with that of the switching station with "isdnlog -t2". For setting the clock, see the "Miscellaneous" section, the question: "How can I set the clock of my computer with ISDN?"
If the Cisco doesn't get an answer for its keep alive packets then it will
stop routing. This normally happens after the 4. or 5. keep alive packet.
The best solution is to tell the provider not to use keep alive packets
("no keepalive"
in the Cisco configuration).
It could be that it's not the LCP packets that are keeping the connection open, but rather OSPF routing updates. The sending of these updates can only be switched off on the Cisco. You can configure "snapshot server" on the BRI interface. That means it will send out routing updates only when they are received through this interface.