Newsgroup: it.comp.reti.ip-admin
Titolo: collegamenti fantasma

 connessione al server.
Si, gia' notato...
E' quel porco di W95 che penso mandi dei broadcast in giro per il
mondo..
Non ti so' dire per ora come risolverlo...
Bye

On Thu, 17 Jul 1997 20:08:29 GMT, 
fr...@ulysse.it
 wrote:
Il server e' configurato in Unix.
Per chiarire che non sono stronzate lunedi' prelevero' il file
messages della dir var/adm che, "greppato" in un file chiamato pippo,
mi registra qualsiasi movimento del modem (hang up - connessione -
ecc.) e lo postero'.
Ringrazio comunque tutti e penso che la soluzione migliore sia quella
di controllare con opportuni programmi sniffer, quali pacchetti
vengono inviati.
Il dubbio e' che mamma MS ci tenga sotto continuo controllo :-).
Vi terro' informati.
Francesco Dicorato
fr...@ulysse.it

 mondo..
No. Win95 *DI SUO* non manda fouri nulla. A meno che non hai attivato
qualche servizio (netbeui? vasavei...) che produce traffico per gli affari
suoi.
Se c'e' solo il TCP/IP e non ci sono client o comunque affari vari che
tentano connessioni periodiche win95 non si muove.
Ho lasciato attivo piu' di una volta per altri motivi l'analizzatore di
traffico ethernet anche per ore sulla rete con macchine win95 accese e
incustodite e non ho mai visto traffico "inspiegabile" proveniente di li.
Piu' probabilmente ci sono altre spiegazioni.
Saluti
Lele

 Mi e' venuto subito in mente questo thread ed infatti eccomi.
Bah, la mia ignoranza in fatto di prodotti Micromolli e' abissale.
Pero' da un'ora, un'ora e mezza ho il tcpdump che analizza il traffico
della rete del mio studio, dove c'e' una sola macchina Win95, con attivo
TCP/IP e il Client per reti Microsoft e di traffico anormale *IP* non ne
vedo... l'unica cosa che passa (ero a pranzo) sono i pacchetti ARP.
Boh. 
Saluti
Lele

chiamano.
Odiare un'architettura non e' motivo sufficiente per non documentarsi:
basta che togli il bind fra TCP/IP e i servizi di rete microsoft (Client e
Condivisione file e stampanti) e risolvi il problema. Non ti dico dov'e'
perche' sono sadico e lascio che tu ti smeni un po' con il tuo odiato
sistema operativo. :-)
          /////
B/B/B/B ///     Guido Zualdi - Responsabile tecnico
/y/y/y ///          Netanday Lignano Sabbiadoro
e/e/e ///  ///            (Udine) Italy
      //////uido       

 TENETENE CONTO ANCHE PER EVENTUALI BOLLETTE SALATE DELLA TELECOM.
Beh, esiste anche il modo per ignorare taluni pacchetti, a dir la
verita' non ho mai avuto occasione di provarlo, ma sono certo che sia
possibile.
Se ben configurato, un dialer apre la connessione *solo* quando ce n'e'
l'effettiva necessita'.
Ciao!
-- 
 Daniele
------------------------ Fuck The Monopoly ! -----------------------
             ______                           ____                  
            /_  __/                          / __/                  
             / /__     __  __  __           / /_                    
            / //_  /  /_  /   / / /\/\     /_  / /  / \/ \/     
           / //__ /_ /__ /__ /_/ /   /    __/ / /__/  /\ /\       
          /_/ Italia                     /___/                      
 
  -> 161 <- days and telecom's monopoly will be fucked forever !    
 
--------------------------------------------------------------------
 Daniele Orlandi - Utility Line Italia - 
http://www.xt.net
 
 Via Mezzera 29/A - 20030 Seveso (MI) - Italy - FAX: 
++39(362)540153
--------------------------------------------------------------------

 tuo odiato sistema operativo. :-)
Mi spiace... so dove sono.... non ti do' soddisfazione :^)
Comunque, la tua non e' una soluzione... prova a pensare a chi si trova
in una rete solo IP, cosi' facendo, gli impedisci di utilizzare SMB!
Il problema va risolto a livello del dialer, non dei clients. Non sono i
clients che devono smetterla di trasmettere i broadcast (ne hanno il
sacrosanto diritto anche se, forse il loro utilizzo tanto massiccio puo'
essere opinabile), piuttosto il dialer non deve chiamare se riceve un
broadcast... sempre che sia questo il motivo... io ho ipotizzato.
Magari, si tratta di qualche broadcast DHCP... boh...


broadcast... sempre che sia questo il motivo... io ho ipotizzato.
Be', non credo che un accesso ogni 11 minuti sia una cosa cosi' massiccia. 
A proposito, sono 3 giorni che tengo la rete sotto controllo per vedere se
c'e' qualche broadcast che va all'esterno, ma di accessi a 255.255.255.255
neanche l'ombra. Siamo sicuri che 255.255.255.255 sia un indirizzo di
broadcast 'generale'? A parte la pericolosita' della cosa, a me risultava
che gli IP dal 224.x.x.x in su fossero riservati, e infatti un traceroute
su uno di quelli non mi va da nessuna parte. Visto cosi' un accesso al
255.255.255.255 sembrerebbe piu' una mattana da client impallato che
altro. 


 udp 68
Io non ne vedo. Puo darsi che cambi qualcosa nei bindings, ma io vedo
traffico netbios-ns solo se mi metto a sfogliare le "risorse di rete"
Windows95 osr2 installato e non piu toccato. Solo TCP/IP. purtoppo ho una
macchina sola con 95. (questa!)
Con le macchine NT il traffico e', comunque, ben diverso.
Saluti 
Lele
 

disabilitare anche la rete e i servizi di condivisione.
Qui non mi e' chiaro, ma invece di voler intervenire sui client, e'
proprio cosi' difficile intervenire sul diald? Il log delle connessioni
non e' sufficiente perche' non indica che tipo di pacchetti ha generato le
chiamate.  Se puoi intervenire sul diald risolvi il problema alla radice
se gli dici di ignorare qualsiasi pacchetto di tipo netbios-x (138 e 139).
In ogni caso, a me non risulta che un sistema ben configurato abbia
bisogno di fare broadcast all'esterno, a meno che, come ho gia' scritto,
non usi un server Wins messo fuori, oppure che qualche macchina abbia le
netmask malmesse.  Quanti IP avete a disposizione? Che netmask e' messa
sulle macchine? E sul server? A sistema appena acceso, riesci a fare un
ping da una macchina all'altra (usando gli IP numerici), oppure anche
questo genera una chiamata? 


 esterna!  Sono broadcast sulla sottorete, non dovrebbero mica uscire.
Certo, hai perfettamente ragione, io ho solo fatto vedere che anche una
macchina NT ferma puo' generare del traffico IP e, se il router/dialer
non lo ignora come dovrebbe, questo risulta in collegamenti continui...
Ciao!
-- 
 Daniele


 impallato che altro.
No.. no... e' proprio il broadcast.
Viene utilizzato quando non si ha conoscenza del proprio network
address, specialmente per BOOTP, DHCP, ARP etc....
Ciao!
-- 
 Daniele
------------------------ Fuck The Monopoly ! -----------------------
             ______                           ____                  
            /_  __/                          / __/                  
             / /__     __  __  __           / /_                    
            / //_  /  /_  /   / / /\/\     /_  / /  / \/ \/     
           / //__ /_ /__ /__ /_/ /   /    __/ / /__/  /\ /\       
          /_/ Italia                     /___/                      
 
  -> 159 <- days and telecom's monopoly will be fucked forever !    


 disabilitare anche la rete e i servizi di condivisione.
Nella peggiore, attiva i servizi di rete su NetBeui.. Se pure questo ti
attiva la connessione, prender=F2 in seria considerazione l'idea di
prendere un po' di ferie..
-- =
			Luca Amicone
--
	Il pericolo =E8 il mio mestiere,
	farsi del male no.
		-- Kipli

minuto.
Mah, a me tutti gli strumenti indicano come indirizzo di broadcast
x.x.x.255, perlomeno su una rete con netmask 255.255.255.0, sia tcpdump
che netwatch indicano quell'indirizzo e non 255.255.255.255, e da sempre
la doc di Linux mi parla dell'indirizzo di broadcast come dell'ultimo
disponibile nella sottorete, non come l'ultimo disponibile
nell'indirizzamento a 32 bit.
Puo' essere solo un problema di notazione, e forse (dico forse) i messaggi
broadcast non sono neanche legati ad un IP, tanto c'e' qualcos'altro che
deve identificarli come broadcast, non certo l'IP, ma allora il metodo
che uso io mi pare piu' logico...
A meno che ovviamente tu non abbia una rete non connessa a Internet con
netmask 0.0.0.0 :-))


 con netmask 0.0.0.0 :-))
No, purtroppo non ho cosi' tanti indirizzi, e la rete e' connessa ad
Internet.
Ciao!
-- 
 Daniele
------------------------ Fuck The Monopoly ! -----------------------
             ______                           ____                  
            /_  __/                          / __/                  
             / /__     __  __  __           / /_                    
            / //_  /  /_  /   / / /\/\     /_  / /  / \/ \/     
           / //__ /_ /__ /__ /_/ /   /    __/ / /__/  /\ /\       
          /_/ Italia                     /___/                      
 
  -> 157 <- days and telecom's monopoly will be fucked forever !    


layer 2, altrimenti non lo riceveresti neanche.
Io so molto poco dei layer, ho ipotizzato che per passare su una rete
Ethernet dovesse essere classificabile come broadcast senza bisogno di
leggere l'IP, altrimenti occorrerebbe tenere le periferiche di rete ad
esaminare tutti i pacchetti che passano, cosa poco pratica.


 esaminare tutti i pacchetti che passano, cosa poco pratica.
E invece no... le schede ethernet esaminano tutti i pacchetti che
arrivano, ma non li passano al layer superiore a meno che:
- Le schede non siano in promiscuous mode.
- Il pacchetto non abbia l'indirizzo MAC della scheda.
- Il pacchetto non sia un broadcast.
Pertanto non disturbano il processore a meno che non sia effettivamente
necessario.
Quindi, quando invii un broadcast IP, se il pacchetto e' destinato alla
rete direttamente collegata all'host viene mandato con un pacchetto
ehernet broadcast, altrimenti viaggia in unicast verso i vari routers e
quando raggiunge quello collegato alla rete di destinazione viene
inviato come broadcast ethernet. I pacchetti 255.255.255.255 di solito
vengono ignorati dai routers.
Se pero', mandi un pacchetto con indirizzo IP unicast in un pacchetto
ethernet broadcast, questo viene ricevuto da tutte le schede ethernet e
inviato al layer 3 che pero', vedendo che non e' destinato a lui, lo
scarta.
Concludendo, per poter ricevere un broadcast IP, sia l'indirizzo IP, sia
l'indirizzo MAC devono essere dei broadcast.


 ma non per NetBIOS.
NetBIOS  e`  solo  il  nome delle  API:  se  intendi   NETBEUI, questo   usa
direttamente le  trame MAC/LLC, per  cui l'indirizzo  di broadcast usato  e`
quello di livello 2 (per ethernet e  token ring: ff:ff:ff:ff:ff:ff), che poi
e` l'indirizzo usato  per mappare il limited  broadcast IP (livello 3  ) sul
broadcast di livello 2.
TCPBEUI, invece... be',  dipende da come e`  stato configurato: se  si usano
WINS e/o   il file LMHOSTS   si evitano  un   sacco di  broadcast;  inoltre,
dovrebbero essere broadcast diretti  alla  subnet (purtroppo: gia`,  perche'
basta una  netmask sballata  o un  router troppo  permissivo  e i  broadcast
viaggiano, viaggiano...).
Purtroppo, nel caso che   ha dato il  via al  thread, il  router e` un  host
"multihomed"  (dotato  di piu` interfacce  di rete,  cioe`),  e le RFC sopra
citate *non* dicono come deve comportarsi  un computer siffatto quando e` il
momento  di mandare   dei limited  broadcast:  li manda  su  *tutte*  le sue
interfacce, o solo su quella primaria, o  su una eventualmente specificabile
dall'utente ? A seconda delle scelte di programmazione, possiamo trovare uno
qualsiasi di  questi comportamenti (il primo, in   particolare, non e` molto
"risparmioso" per chi e` collegato in "dial-up"...).
Saluti,
Luca Polo.
-- 
 / Luca Polo : 
Luca...@gest.unipd.it
 || System administrator          \
| (
http://www.gest.unipd.it/~jake
 for  || Ist. di Ingegneria Gestionale  |
 \ address and phone numbers)          || Universita` di Padova, Italy  /

Sar=E0 anche poco pratico, ma per quanto ne so io tutte le schede di =
rete
di una ethernet esaminano tutti i pacchetti.=20
Andrea
	-----Original Message-----
	From:	Guido Zualdi [
SMTP:gui...@scratch.netanday.it
]
	Posted At:	Sunday, July 27, 1997 11:49 PM
	Posted To:	ip-admin
	Conversation:	collegamenti fantasma
	Subject:	Re: collegamenti fantasma
	=85
	Io so molto poco dei layer, ho ipotizzato che per passare su una
rete
	Ethernet dovesse essere classificabile come broadcast senza
bisogno di
	leggere l'IP, altrimenti occorrerebbe tenere le periferiche di
rete ad
	esaminare tutti i pacchetti che passano, cosa poco pratica.
	=85


Lo so, mi sono espresso male, per periferica di rete volevo intendere
qualcosa a livello un po' piu' alto dell'hardware che, per l'appunto,
esamina tutti i pacchetti in entrata.
          /////
B/B/B/B ///     Guido Zualdi - Responsabile tecnico
/y/y/y ///          Netanday Lignano Sabbiadoro
e/e/e ///  ///            (Udine) Italy
      //////uido      =20

 writes:
   Entrambi sono indirizzi di broadcast, solo che 255.255.255.255
   indica la volonta' che venga propagato al maggior numero di reti
   possibile
!!!  No!  Quello e` un indirizzo (detto limited broadcast) che va
distribuito alla sottorete locale e che non deve essere inoltrato dai
router.  E` completamente equivalente a un directed broadcast alla
sottorete locale.  Per comodita` di riferimento, cito il paragrafo
relativo di RFC 1122, tagliando le parti obsolete, deprecated o
irrilevanti.  Per una discussione piu` approfondita, vedere il
paragrafo 5.3.5 di RFC 1812.
      3.3.6  Broadcasts
         Section 3.2.1.3 defined the four standard IP broadcast address
         forms:
           Limited Broadcast:  {-1, -1}
           Directed Broadcast:  {<Network-number>,-1}
	[taglio]
         A host MUST recognize any of these forms in the destination
         address of an incoming datagram.
	[taglio]
         Hosts SHOULD use the Limited Broadcast address to broadcast to
         a connected network.
         DISCUSSION:
              Using the Limited Broadcast address instead of a Directed
              Broadcast address may improve system robustness.  Problems
              are often caused by machines that do not understand the
              plethora of broadcast addresses (see Section 3.2.1.3), or
              that may have different ideas about which broadcast
              addresses are in use.  The prime example of the latter is
              machines that do not understand subnetting but are
              attached to a subnetted net.  Sending a Subnet Broadcast
              for the connected network will confuse those machines,
              which will see it as a message to some other host.


Se ti riferisci a rimuovere i bindig sulle proprieta' del TCP/IP,
faccio notare che, oltre a non accettare la mancanza di driver, alla
prossima connessione, i suddetti servizi vengono eliminati e non e'
piu' possibile utilizzare la rete :-)
Comunque ormai e' certo che i pacchetti di chiamata al server remoto
collegato via isdn che abilitano la chiamata, derivano dal netbios.
Basterebbe solo vedere come disabilitare tale opzione senza
disabilitare anche la rete e i servizi di condivisione.
Comunque ne approfitto per in viare uno stralcio di una sola giornata
con le connessioni e le chiamate "fantasma".:
Jun 11 10:44:08 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 10:44:09 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 10:53:23 shangri-la kernel: isdn_net: local hangup ippp0
Jun 11 10:53:23 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 10:54:31 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 10:54:32 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 10:58:28 shangri-la kernel: isdn_net: local hangup ippp0
Jun 11 10:58:28 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 10:59:33 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 10:59:34 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 11:03:28 shangri-la kernel: ippp0: remote hangup
Jun 11 11:03:28 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 11:04:34 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 11:04:35 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 11:08:28 shangri-la kernel: ippp0: remote hangup
Jun 11 11:08:28 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 11:09:34 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 11:09:35 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 11:13:31 shangri-la kernel: isdn_net: local hangup ippp0
Jun 11 11:13:31 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 11:14:35 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 11:14:36 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 11:18:29 shangri-la kernel: ippp0: remote hangup
Jun 11 11:18:29 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 11:19:35 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 11:19:36 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 11:23:30 shangri-la kernel: ippp0: remote hangup
Jun 11 11:23:30 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 11:24:36 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 11:24:37 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 11:28:39 shangri-la kernel: isdn_net: local hangup ippp0
Jun 11 11:28:39 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 11:34:36 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 11:34:37 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 11:38:30 shangri-la kernel: ippp0: remote hangup
Jun 11 11:38:30 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 11:49:35 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 11:49:36 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 11:53:31 shangri-la kernel: ippp0: remote hangup
Jun 11 11:53:31 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 12:04:35 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 12:04:36 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 12:08:31 shangri-la kernel: ippp0: remote hangup
Jun 11 12:08:31 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 12:19:35 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 12:19:36 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 12:23:31 shangri-la kernel: ippp0: remote hangup
Jun 11 12:23:31 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 15:27:02 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 15:27:03 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 15:36:27 shangri-la kernel: ippp0: remote hangup
Jun 11 15:36:27 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 15:37:34 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 15:37:35 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 15:41:30 shangri-la kernel: ippp0: remote hangup
Jun 11 15:41:30 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 15:42:36 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 15:42:37 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 15:46:30 shangri-la kernel: ippp0: remote hangup
Jun 11 15:46:30 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 15:47:36 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 15:47:37 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 15:51:32 shangri-la kernel: ippp0: remote hangup
Jun 11 15:51:32 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 15:52:37 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 15:52:38 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 15:56:31 shangri-la kernel: ippp0: remote hangup
Jun 11 15:56:31 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 15:57:41 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 15:57:42 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 16:01:37 shangri-la kernel: ippp0: remote hangup
Jun 11 16:01:37 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 16:02:42 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 16:02:43 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 16:06:36 shangri-la kernel: ippp0: remote hangup
Jun 11 16:06:36 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 16:07:43 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 16:07:43 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 16:11:37 shangri-la kernel: ippp0: remote hangup
Jun 11 16:11:37 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 16:15:59 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 16:16:00 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 16:20:53 shangri-la kernel: isdn_net: local hangup ippp0
Jun 11 16:20:53 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 16:32:01 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 16:32:01 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 16:35:59 shangri-la kernel: ippp0: remote hangup
Jun 11 16:35:59 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 16:47:01 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 16:47:01 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 16:50:58 shangri-la kernel: ippp0: remote hangup
Jun 11 16:50:58 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 17:02:01 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 17:02:02 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 17:05:56 shangri-la kernel: ippp0: remote hangup
Jun 11 17:05:56 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 17:17:01 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 17:17:02 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 17:20:57 shangri-la kernel: ippp0: remote hangup
Jun 11 17:20:57 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 17:32:01 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 17:32:02 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 18:20:54 shangri-la kernel: isdn_net: local hangup ippp0
Jun 11 18:20:54 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 18:32:00 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 18:32:01 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 18:35:56 shangri-la kernel: ippp0: remote hangup
Jun 11 18:35:56 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 18:37:21 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 18:37:21 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 19:16:11 shangri-la kernel: isdn_net: local hangup ippp0
Jun 11 19:16:11 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 19:22:20 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 19:22:21 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 19:56:45 shangri-la kernel: isdn_net: local hangup ippp0
Jun 11 19:56:45 shangri-la kernel: ippp0: Chargesum is 0
Jun 11 19:57:45 shangri-la kernel: ippp0: dialing 0 333996...
Jun 11 19:57:46 shangri-la kernel: isdn_net: ippp0 connected
Jun 11 22:58:47 shangri-la kernel: isdn_net: local hangup ippp0
Jun 11 22:58:47 shangri-la kernel: ippp0: Chargesum is 0