Newsgroup: it.comp.os.linux.sys
Titolo: "tee" sui socket

posso fare in modo che i dati ricevuti da un server ad una determinata 
porta siano inviati anche su un'altra porta?
cioč ho il server con un demone che ascola alla porta 1234, vorrei 
installare un altro demone che legga sempre gli stessi dati, ovviamente 
su una porta differente.
si puň fare?



Non mi risulta.
Max

 typed:

Ni... Dovresti mettere il primo demone in ascolto su un'altra porta, quindi
usare un programma che legga da remoto e riscriva in locale. Il problema e'
che ti perdi l'origine in questo modo.
Altrimenti ti serve una sorta di tcpdump, opportunamente filtrato, che prenda
tutti i dati in arrivo e li passi al tuo demone...
Ciaotutti,
*
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

imho nn serve a niente il tee , sniffa la porta e via.
-- 
Placebo di Peter:
        Un grammo di immagine val piu' d'un chilo di fatti.

 
Eh ? what ?

 Eh ? what ?
Il demone A ascolta sulla porta 111; voglio intercettare i suoi dati. Lo metto
in ascolto sulla 222 e metto il demone B sulla 111.
B accetta le connessioni e manda i dati ad A sulla 222, e se voglio anche a C
sulla 333, a D sulla 444 e cosi' via.


 sulla 333, a D sulla 444 e cosi' via.
Mi risulta poco fattibile in due parole.
quello che dici implica:
1) modificae il programma sulla porta originale che poi forwarda
2) oppure modificare gli altri demoni.
Quando hai un servizio che ascolta, quel servizio parla col client ed il
client risponde. Si chiama TCP/IP.
Fare quello che vuoi fare tu in maniera così semplice non è fattibile.
Gli altri servizi su porte non standard devono parlare col servizio sulla
porta standard che deve gestire le risposte del client e inviarle agli
altri, gestendo le eccezioni del caso.
E se gli N servizi su porte non standard rispondono in maniera dversa come
la metti ?
In poche parole: pessima idea.
La soluzione sporca di sniffare il traffico è più gestibile ma nemmeno essa
tanto semplice.
Ovviamente tutto questo in generale.
Per alcuni servizi particolari, magari, si può amplificare il debug per
avere i dati necessari.
Max

 Fare quello che vuoi fare tu in maniera cosě semplice non č fattibile.
L'ho fatto, quindi penso sia fattibile... Beh, io l'ho fatto per windows, ma
il concetto non cambia. Poi, alcuni servizi possono non funzionare o
funzionare in modo inatteso, ma se l'idea e' fare un tee (quindi l'unica
uscita viene dal demone principale)... A meno che il servizio usi
un'autenticazione del client, non dovrebbero esserci grossi problemi.


 si può fare?
Credo che ti stia sfuggendo qualche lievissimo dettaglio.
Ad esempio, visto che il client A sta inviando dati al server B
con indirizzo X, sulla porta Y, magari in TCP.
Mettiamo che sul server B ci sia anche un altro daemon, in ascolto
sulla porta Z.
Quando A invia il primo pacchetto SYN al server in ascolto sulla porta Y
ed anche il demone in ascolto sulla porta Z dovesse ricevere, in qualche
modo, tale SYN, cosa dovrebbe fare tale daemon?
Beh, visto che, in qualche modo, la porta destinazione e' stata cambiata
da Y a Z, il daemon dovrebbe rispondere.
E cosa farebbe allora il client A, vedendosi arrivare un pacchetto SYN ACK
con porta sorgente diversa da quella che si aspetta?
Te lo dico io: manda un bel RST.
Quel che puoi fare e', come gia' osservato in questo thread, dumpare con
tcpdump il traffico su una certa porta.
E magari anche rivedertelo e giocarci in vari modi con questo:
http://tcpreplay.sourceforge.net/
-- 
Per non dimenticare:
http://snipurl.com/SdC_ed_il_vino