Next Previous Contents

15. chargeint: Chargeint

15.1 chargeint_whatis: What does Chargeint?

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

The huptimeout can be much shorter; for example, 5 (seconds). Then I can use the last charge unit up the last 7 seconds (huptimeout + 2 seconds chargeint reserve).

15.2 chargeint_whennot: When does it not make sense to use the chargeint patch?

  1. You can only use Chargeint when isdnlog works for your card (see isdnlog).
  2. Using Chargeint only makes sense when your connections are charged per units, rather than per second.
  3. There are problems when the IP is assigned dynamically. A broken connection cannot simply be restarted (since the IP address has changed). The interrupted FTP, telnet or WWW connection must then be newly established.

15.3 chargeint_config: How does the chargeint patch work?

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

15.4 chargeint_time: How can I be sure that the chargeint patch is using the correct time?

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?"

15.5 The connection doesn't end with timeout. Possible reason: my service provider uses a Cisco router which sends a "keep alive" packetevery ten seconds.

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).

15.6 ipppd doesn't hang up.

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.


Next Previous Contents