Newsgroup: it.comp.os.linux.sys
Titolo: [ISDN] il sistema rimane connesso

salve a tutti,
per connettermi a internet utilizzo come NAT un vecchio PC P100 con 24MB
RAM, TA ISDN Asuscom (type = 35 per isnd4linux) e scheda di rete 3COM
Etherlink III, sul quale ho montato RH6.2 (kernel 2.2.19);
da un paio di giorni ho riscontrato un fastidioso (e costoso) inconveniente
cioč che una volta che la macchina si connette ad internet l'unico modo per
farla sconnettere č di intervenire manualmente (leggi: isdnctrl hangup
ippp0);
naturalmente il primo sospetto che ho avuto č stato quello di un guaio hw,
ma prima di mettere mano al cacciavite (e magari al portafoglio...) ho
voluto fare un po di prove;
ho addirittura provato a utilizzare il fil4l (minidistro su un solo floppy,
in grado di fare da router ISDN... caso mai il problema fosse dipeso da
qualche "simpaticone" che in qualche modo fosse riuscito a mettere le mani
sul mio povero NAT...) ma il problema rimaneva ancora;
ho anche provato a far andare il NAT da solo (senza macchine client) ma
niente cambia;
quindi (morale della storia) prima di smontare il tutto, qualcuno ha un
qualche vago suggerimento su come diagnosticare un eventuale guasto hw (il
TA per il resto continua a funzionar bene, anche l'orologio di sistema
funziona) ?
un ultima domanda: per evitare in futuro problemi del genere (e bollette da
capogiro) avevo anche pensato di scrivermi uno script o programmino ad hoc
che fosse in grado di monitorare l'effettivo utilizzo dell'interfaccia
ippp0, e in caso di prolungata inattivitŕ forzarne la disconnessione;
qualche dritta su come poter fare? (una prima idea era quella di
"acchiappare" l'output di ifconfig a intervalli di tempo prestabiliti e
vedere se il numero di pacchetti trasmessi/ricevuti fosse rimasto costante e
meno)
ciao

 ippp0);
per la SuSE  (non so se per la RedHatt é lo stesso)
nella dir    /etc/ppp vi é il file options .
    In questo file imposta   idle xxx
(xxx = numero secondi senza attivitá dopo i quali pppd effettuerá
la disconnessione) [ 0 (zero) ---> nessuna disconnessione].
Cordialitá
--
****************************************************
i6cey*
cost...@tin.it
sostituire asterisco con punto per email
****************************************************


grazie per il suggerimento, ma non è purtroppo un problema del genere (a
parte che per la connessione isdn e quindi per il daemon ipppd il file in
questione dovrebbe essere /etc/ppp/ioptions e non /etc/ppp/options che
dovrebbe riguardare solo pppd... mi sbaglio?)
ciao e grazie cmq

 meno)
se e` vero quello che penso NON servirebbe a nulla in quanto il traffico
c'e` davvero (anche se magari e` poco)!
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

ippp0);
prova a postare la risposta di un "isdnctrl list ippp0" per verificare
i tuoi settaggi...
puo' comunque darsi che sia il solito pacchetto in uscita da qualche
macchina windows (o da qualche servizio che tenta periodicamente di
uscire dalla rete locale) a tenere "su" ippp0.
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

 c'e` davvero (anche se magari e` poco)!
vero, infatti con tcpdump ho notato del traffico 'fantasma' (?)
ammetto di non capirci molto (sic!) cmq ho notato uno strano traffico piů o
meno continuo a livello di DNS (ho configurato un DNS cache); stoppando il
daemon named, (e per prudenza o tirato giů amche lo squid.... non si sa mai)
ho notato che con cadenza di circa 30 secondi vengo bersagliato da igmp
query (!)
ecco cosa dice tcpdump a riguardo
# tcpdump -i ippp0
Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on ippp0
19:05:58.056789 < 195.31.66.214 > 
224.0.0.1
: igmp query [ttl 1]
19:06:28.158155 < 195.31.66.214 > 
224.0.0.1
: igmp query [ttl 1]
19:06:58.270400 < 195.31.66.214 > 
224.0.0.1
: igmp query [ttl 1]
19:07:28.382265 < 195.31.66.214 > 
224.0.0.1
: igmp query [ttl 1]
4 packets received by filter
le impostazioni dell'interfaccia ippp0 sono le seguenti:
# ifconfig -i ippp0
ippp0     Link encap:Point-to-Point Protocol
          inet addr:212.171.175.237  P-t-P:195.31.66.214  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:530 errors:0 dropped:0 overruns:0 frame:0
          TX packets:516 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:30
a qusto punto le domande sono 2:
1) č normale un comportamento del genere (il gateway mi 'pinga' di
continuo???)
2) esiste un modo per far ignorere a ipppd questi ping (ipchains sembra non
funzionare)
ammetto che sono perplesso...
un ultima cosa: ultimamente ho notato in /var/log/messages* svariati
tentativi di accesso (ovviamente falliti) verso la porta 80 del mio NAT...
cos'č, code-red? o che altro?
grazie per l'aiuto
ciao

 uscire dalla rete locale) a tenere "su" ippp0.
dalle prove che ho fatto lo escluderei, ed escluderei anche la presenza di
qlc ospite indesiderato (leggi: worm) dalo momento che il problema si
manifesta sia utilizzando la RH6.2 da hd, sia utilizzando fli4l interamente
da floppy;



a dire la verità l'oggetto del messaggio è forse un po troppo ottimistico...
diciamo che ho capito da cosa dipende...
in altre parole, provando con un po di provider free mi sono accorto che
Tiscali
ClubNet
Infinito (Genie)
'pingano' di continuo (una volta ogni 30 secondi) la mia macchina, con lo
spiacevole risultato di mantenere attiva la mia connessione; tcpdump parla
chiaro (riporto da post precedente)
19:05:58.056789 < 195.31.66.214 > 
224.0.0.1
: igmp query [ttl 1]
connettendosi invece a
Galactica
Libero
tale comportamento non si manifesta;
qualche idea?
ciao

 cos'č, code-red? o che altro?
si, molto probabilmente si tratta di code-red o di qualche suo stretto
parente (e` normale che una macchina collegata ad internet riceva qualche
decina di tentativi al giorno di tentati attacchi dal worm in oggetto)


 caso di approntare qualche filtro
ho mandato yna mail a tiscali, una a ciaoweb e una a genie;
ciaoweb non ha ancora risposto, genie - o meglio, il mail robot di genie -
ha inviato una risposta pescata a caso da quelle precompilate (un ottimo
esempio di serietà...) mentre tiscali mi ha risposto (anche con una buona
sollecitudine); di seguito ecco la risposta di tiscalinet:
- Buongiorno,
-
- l'inconveniente che Lei sta riscontrando è dovuto al continuo invio di
- pacchetti dati da parte dei server Tiscali,
- anche se non si sta utilizzando la connessione:
- questa continua ricezione fa si che venga a mancare la disconnessione per
- inattività.
-
- Si tratta di pacchetti di multicasting di questo formato
-
- 02:10:54   IP.011: unsup mcst 195.130.22x.xxx -> 224.0.0.10
- 02:10:58   IP.011: unsup mcst 195.130.22x.xxx -> 224.0.0.10
- 02:11:03   IP.011: unsup mcst 195.130.22x.xxx -> 224.0.0.10
-
- E' possibile bloccarli con un Firewall bloccando i pacchetti inviati
- all'indirizzo di rete 224.0.0.x, e  l'unica controindicazione sarà la
- difficoltà nel vedere i filmati.
non voglio neanche entrare nel merito se 'pingare' un utente sia una cosa
corretta o meno, in ogni caso ecco confermati i miei sospetti;
onestamente non ho capito a che cosa servano tutti 'sti ping (si parla di
'vedere filmati'.... bah, sono perplesso...molto perplesso: che razza di
protocollo di streaming è così fesso da dipendere da una sfilza di ping per
funzionare?);
inoltre pur provando a filtrare tale pacchetti con ipchains (ho addirittura
provato un rifiuto totale in ingresso da 
224.0.0.0/8
) questo fastidioso ping
continua a mantenermi attiva la connessione;
quindi le alternative che mi restano sono 2:
1) trovare il modo per far ignorare a ipppd determinati pacchetti
'fastidiosi' (la vedo dura....)
2) lasciar perdere la gestione di dialmode auto di ipppd e affidarmi a diald
che sicuramente prevede delle logiche di filtro per determinare l'autodial
(e di conseguenza anche il conseguente hangup... spero!)
ok, grazie per il prezioso supporto, farò delle prove e casomai vi farò
sapere;
ciao

 (e di conseguenza anche il conseguente hangup... spero!)
Un po' di fruga su google pare confermare.  Ad esempio
http://groups.google.com/groups?q=igmp+group:comp.os.linux.*&hl=en&safe=off&
rnum=10&selm=7bn67g%24400%241%
40news-2.news.gte.net
é un tizio che aveva lo stesso problema nel '99 con il suo
provider (GTE) -- pacchetti igmp ogni 30 secondi diretti
a 224.0.0.1 -- prova a filtrarli con ipfwadm (2 anni e 1/2
fa) ma senza successo.  Alla fine "usa una regola in diald
per ignorare i pacchetti con ip.protocol=2 e sembra
funzionare" ma resta scocciato di non esserci riuscito
con ipmasq.  Ma di hit su igmp e ipppd ce ne sono
pochissimi e non su comp.os.linux.*...
Alex


ho visto, avevo letto anche io il posto di cui parli;
cmq ho postato su de.comp.os.unix.linux.isdn e un certo Leopold Toetsch mi
ha mandato una mail ben dettagliata su come patchare il modulo isdn.o (non
ipppd) per risolvere il mio problema;
gli ho chiesto un chiarimento riguardo una riga di sorgente C che non ho ben
capito se vada tolta o se semplicemente si sia scordato di trascriverla e
poi proverò il tutto;
se la cosa funziona, e se può interessare qualcuno, non ho alcun problema (e
ci mancherebbe...) a postare la patch;
ciao

 'fastidiosi' (la vedo dura....)
controlla...
D

tale comportamento non si manifesta;
Ergo, il tuo TA si disconnette regolarmente?
-- 
BlueRaven
Prima di parlare, ricorda:
mount -t auto /dev/brain /mnt/mouth


ovvio, funziona come un orologio svizzero ;))
ciao