18.03.1997


   This file contains a description of how to setup 
   a leased line using i4l on Linux and ICN4B
   ISDN cards on both sites of the line. Below follows
   a description on the setup and script files in 
   both, German and English. 

   Thanks to Marcus Faure for his support.

 
     Werner Becker

 ======================================================================

  From:     Marcus Faure <faure@voerde.globvill.de>
  Subject:  ICN4B <-- D64S2 --> ICN4B

 
  Hallo,

  ich wollte Euch an meinen Erfahren bezueglich Vernetzung zweier LinuX-
  Boxen ueber eine 128k-Standleitung teilhaben lassen. In beiden Rechnern
  kommt eine ICN4B zum Einsatz. Das Startskript sieht auf beiden Seiten 
  folgendermassen aus:

  #Initialisierung der ICN-Hardware
  /sbin/insmod icn icn_id=NT1t0 icn_id2=NTld0
  /sbin/icnctrl load /sbin/download/loadpg.bin /sbin/download/pc_1t_ca.bin /sbin/download/pc_1t_ca.bin 

  #Den S0 der ICN auf Leased Line stellen
  /sbin/icnctrl -d NTld0 leased on

  #Ein Workaround fuer Kernel < 2.0.29pl4, s.u.
  /bin/echo "02;EAZ2" > /dev/isdnctrl2

  #Ersten Standleitungskanal konfigurieren
  /sbin/isdnctrl addif isdnl0
  /sbin/isdnctrl eaz isdnl0 1
  /sbin/isdnctrl l2_prot isdnl0 hdlc
  /sbin/isdnctrl addphone isdnl0 in LEASED1
  /sbin/isdnctrl secure isdnl0 on
  /sbin/isdnctrl huptimeout isdnl0 0
  /sbin/isdnctrl ihup isdnl0 off
  /sbin/isdnctrl chargehup isdnl0 off
  /sbin/isdnctrl bind isdnl0 NTld0,0 exclusive

  #Zweiten Standleitungskanal konfigurieren
  /sbin/isdnctrl addslave isdnl0 isdnl1
  /sbin/isdnctrl eaz isdnl1 2
  /sbin/isdnctrl l2_prot isdnl1 hdlc
  /sbin/isdnctrl addphone isdnl1 in LEASED1
  /sbin/isdnctrl secure isdnl1 on
  /sbin/isdnctrl huptimeout isdnl1 0
  /sbin/isdnctrl ihup isdnl1 off
  /sbin/isdnctrl chargehup isdnl1 off
  /sbin/isdnctrl bind isdnl1 NTld0,1 exclusive

  #Und der Netzwerkkram
  /sbin/ifconfig isdnl0 <my-ip> pointopoint <remote-ip>
  /sbin/route add <remote-ip> isdnl0

  Das ganze war eine ziemlich schwere Geburt. Das erste Problem war, das auf
  den (2.0.27er) Rechnern der zweite Kanal nicht aktiviert wurde. Im Syslog 
  stand eine Meldung, das der Call ignoriert wird. Hierbei handelt es sich
  um einen Bug im icn-Treiber, der die eigene Rufnummer fuer den 2. Kanal
  nicht richtig gesetzt hat, daher musste die EAZ manuell mit echo in das
  Interface gedrueckt werden. Dies soll seit 2.0.29 mit Isdnpatchlevel 4
  behoben sein. 

  Danach wurde der 2. Kanal zwar aktiviert, aber nach einem isdnctrl verbose 4
  konnte man sehen, dass die Pakete auch bei Vollast nur ueber den 1. flossen.
  Der Kanal selbst war aber in Ordnung, da man durchaus 2 unabhaengige PtP-
  Devices konfigurieren und diese ueber EQL zusammenschliessen konnte. Diverse
  Experimente und eMails an den Support von Thinking Objects (der ICN-
  Distributor) spaeter wurde mir empfohlen, den Kernel auf 2.0.29 mit den 
  Patches von ftp.franken.de aufzuruesten.

  Bereits die Umruestung einer Seite fuehrte dazu, dass beim Senden ein hoeherer
  Datendurchsatz zu bemerken war, es scheint in < 2.0.29 also noch einen Bug
  in der Verteilung der Pakete auf die Kanaele beim Verschicken zu geben.
  Die Aufruestung der zweiten Seite fuehrte dann erwartungsgemaess zu einem
  maximalen Durchsatz von 15.xk in beide Richtungen. Einschraenkend muss ich
  anmerken, dass dies nur mit mehreren geoeffneten Verbindungen moeglich ist,
  lokale FTP-Sitzungen kommen nur auf ca. 11k Durchsatz. Aus dem Syslog geht 
  hervor, dass auf dem 2. Kanal auch bei einem tcpblast fast immer weniger 
  Pakete verschickt werden als auf dem 1. . Falls noch jemand eine Optimierungs-
  moeglichkeit kennt, moege er mich bitte anmailen (faure@globvill.de)
  Jedenfalls laeuft die Loesung jetzt seit 3 Wochen stabil.

  Zur Uebersicht hier der Output von isdnctrl list:

  Current setup of interface 'isdnl0':
  EAZ/MSN:                1
  Phone number(s):
    Outgoing:
    Incoming:             LEASED1
  Secure:                 on
  Callback:               off
  Reject before Callback: on
  Callback-delay:         5
  Dialmax:                1
  Hangup-Timeout:         0
  Incoming-Hangup:        off
  ChargeHangup:           off
  Charge-Units:           0
  Layer-2-Protocol:       hdlc 
  Layer-3-Protocol:       trans
  Encapsulation:          rawip
  Slave Interface:        isdnl1
  Slave delay:            10
  Master Interface:       None
  Pre-Bound to:           NTld0, Channel 0, exclusive


  Current setup of interface 'isdnl1':
  EAZ/MSN:                2
  Phone number(s):
    Outgoing:
    Incoming:             LEASED1
  Secure:                 on
  Callback:               off
  Reject before Callback: on
  Callback-delay:         5
  Dialmax:                1
  Hangup-Timeout:         0
  Incoming-Hangup:        off
  ChargeHangup:           off
  Charge-Units:           0
  Layer-2-Protocol:       hdlc
  Layer-3-Protocol:       trans
  Encapsulation:          rawip
  Slave Interface:        None
  Slave delay:            10
  Master Interface:       isdnl0
  Pre-Bound to:           NTld0, Channel 1, exclusive

  An dieser Stelle moechte ich noch meinen Dank an Markus Klingspor von
  Thinking Objects ausrichten, der tagsueber in einer etwa 45minuetigen
  Telnet- und Telefonsession (Ferngespraech) nach dem Fehler gesucht hat.

  Marcus


 =================  The english version ======================================


  Hi,

  I wanted to let you participate in my experiences regarding connecting 2
  LinuX-boxes via a 128k leased line. An ICN4B was used in both computers.
  The startup script on both sides looks as follows:

 #Initialisation of the ICN hardware
 /sbin/insmod icn icn_id=NT1t0 icn_id2=NTld0
 /sbin/icnctrl load /sbin/download/loadpg.bin /sbin/download/pc_1t_ca.bin /sbin/download/pc_1t_ca.bin 

 #Switch S0 to leased mode
 /sbin/icnctrl -d NTld0 leased on

 #a workaround for kernels < 2.0.29pl4, see below
 /bin/echo "02;EAZ2" > /dev/isdnctrl2

 #Configure 1st channel
 /sbin/isdnctrl addif isdnl0
 /sbin/isdnctrl eaz isdnl0 1
 /sbin/isdnctrl l2_prot isdnl0 hdlc
 /sbin/isdnctrl addphone isdnl0 in LEASED1
 /sbin/isdnctrl secure isdnl0 on
 /sbin/isdnctrl huptimeout isdnl0 0
 /sbin/isdnctrl ihup isdnl0 off
 /sbin/isdnctrl chargehup isdnl0 off
 /sbin/isdnctrl bind isdnl0 NTld0,0 exclusive

 #Configure 2nd channel
 /sbin/isdnctrl addslave isdnl0 isdnl1
 /sbin/isdnctrl eaz isdnl1 2
 /sbin/isdnctrl l2_prot isdnl1 hdlc
 /sbin/isdnctrl addphone isdnl1 in LEASED1
 /sbin/isdnctrl secure isdnl1 on
 /sbin/isdnctrl huptimeout isdnl1 0
 /sbin/isdnctrl ihup isdnl1 off
 /sbin/isdnctrl chargehup isdnl1 off
 /sbin/isdnctrl bind isdnl1 NTld0,1 exclusive

 #Now for the networking stuff..
 /sbin/ifconfig isdnl0 <my-ip> pointopoint <remote-ip>
 /sbin/route add <remote-ip> isdnl0


   The configuration was quite a pain. The first problem was that the 2nd channel
   was not activated on the 2.0.27 boxes. A message in the syslog read that
   the call got ignored. This was a bug in the icn driver, which did not set
   the local number for the 2nd channel correctly, hence the number had to be set
   manually via an echo. This is said to be fixed since 2.0.29pl4.
   After that the 2nd channel got activated, but after an isdnctrl verbose 4
   it became clear that all packets were transferred on the 1st channel, even
   with full load. The channel itself was OK, because it was possible to
   configure 2 independent PtP-devices and bundle them with EQL. Several 
   experiments and emails to Thinking Objects (German ICN-distributor) later
   I got the recommendation to upgrade to 2.0.29 with the patches from
   ftp.franken.de.

   The upgrade of only 1 side lead to a higher throughput sending packets,
   there seems to be a bug in kernels < 2.0.29 distributing the packets to
   the channels. As expected, upgrading both sides lead to a maximum throughput
   15.xk in both directions. I have to admit this is only possible with multiple
   connections, local FTP is limited to ~11k. Regarding to the syslog the 2nd
   channel transports almost always less packets than the 1st, even with a 
   tcpblast. If somebody knows a chance to optimize this, feel free to
   email me (faure@globvill.de).
   
   This configurations is stable for 3 weeks now.


  As an overview, here comes the output of isdnctrl list:

   Current setup of interface 'isdnl0':
   EAZ/MSN:                1
   Phone number(s):
     Outgoing:
     Incoming:             LEASED1
   Secure:                 on
   Callback:               off
   Reject before Callback: on
   Callback-delay:         5
   Dialmax:                1
   Hangup-Timeout:         0
   Incoming-Hangup:        off
   ChargeHangup:           off
   Charge-Units:           0
   Layer-2-Protocol:       hdlc 
   Layer-3-Protocol:       trans
   Encapsulation:          rawip
   Slave Interface:        isdnl1
   Slave delay:            10
   Master Interface:       None
   Pre-Bound to:           NTld0, Channel 0, exclusive

   Current setup of interface 'isdnl1':
   EAZ/MSN:                2
   Phone number(s):
     Outgoing:
     Incoming:             LEASED1
   Secure:                 on
   Callback:               off
   Reject before Callback: on
   Callback-delay:         5
   Dialmax:                1
   Hangup-Timeout:         0
   Incoming-Hangup:        off
   ChargeHangup:           off
   Charge-Units:           0
   Layer-2-Protocol:       hdlc
   Layer-3-Protocol:       trans
   Encapsulation:          rawip
   Slave Interface:        None
   Slave delay:            10
   Master Interface:       isdnl0
   Pre-Bound to:           NTld0, Channel 1, exclusive

   I'd like to thank Markus Klingspor of Thinking Objects, who supported
   me searching for the bug via telnet and phone (distance call) for about 
   45 minutes.

 Marcus