Newsgroup: it.comp.os.linux.sys
Titolo: Re: Limitare la banda ad una applicazione

 Grazie in anticipo. A presto!     :-)
Mi sa che anche sta volta ho sbagliato ng...probabilmente. :-\
Sicuramente ICOLS sarà frequentata da utenti maggiormente ferrati
su squid o soluzioni al mio quesito. E probabilmente soprattutto
l'argomento dovrebbe essere più da sys che non da iniziare....
Almeno spero. Insomma ho preso una granchi ceffando il ng, spero
che questo crosspost non sia un problema.  ;-)
Saluti e grazie in anticipo.  :-P

> questa funzionalità di porre un limite alla banda da usare.
Ciao,
ti posso parlare solo di squid io in quando non ho mai provato altri 
prodotti "ad uso personale" (quasi da galera 'sta frase !)
Con squid riesci a fare quello che ti interessa giocando di acl e delay 
pool. E' molto versatile ed in azienda lo uso per limitare la banda 
usata da alcuni tipi di download.
L'unica menzione negativa che posso portarti e' che non sembra essere 
un'opzione contemplata in fase di creazione dei pacchetti squid di 
debian e di slack. Ho dovuto ricompilare partendo dai sorgenti su 
entrambe le distribuzioni abilitando i delay pool, pero' dopo fanno 
davvero la differenza gestiti bene via acl.
Ciao
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere...sembra 
facile a prima vista...ma la verità è che non avere nulla da perdere 
significa essere pronti a rischiare tutto ciò che si possiede.

 debian e di slack.
Io uso slack e sono abbastanza "fissato" sulla installazione di
software attraverso i pacchetti. Questo non significa comunque
che non ci si possa fare il pacchetto da soli...di solito parto
da degli slackbuild già esistenti reperiti su 
slacky.eu
 o
slackers o altro, certo immagino che swuid non sia uno dei soliti
programmini che ho provato a impacchettarmi, ma "speriamo che me
la cavo".  ;-)
Anyway, grazie per l'intervento.  :-)
Senza la pretesa di una spiegazione passo passo, i miei scopi
sono piuttosto limitati...volevo solo limitare la banda del
download manager integrato in firefox "down them all".
Ovviamente senza limitare o ponendo limiti differenti alla
navigazione con lo stesso firefox...
Con squid dici che si può fare?
Per il resto mi documenterò nella direzione indicata
concentrandomi su acl e delay. grazie di nuovo!  :-P

 concentrandomi su acl e delay. grazie di nuovo!  :-P
Qui trovi tutto quello di cui hai bisogno (e sicuramente scritto meglio 
di quanto io possa mai spiegarti ;) )
http://www.visolve.com/squid/squid30/delaypools.php
Ciao
Rizio
P.S. Potrebbe volendo essere interessante capire anche come ha fatto 
Ricciardi con il suo spettacolare ZeroShell ed eventualmente estrarre 
solo la parte relativa al traffic-shaper (se proprio non mettere su 
tutto....)
http://www.zeroshell.net/
[Cit.]
# Gestione del QoS (Quality of Service) e traffic shaping per il 
controllo del traffico su reti congestionate. Si possono imporre vincoli 
sulla banda minima garantita, sulla banda massima e sulla priorità di un 
pacchetto (utile nelle connessioni realtime come le VoIP). Tali vincoli 
potranno essere applicati sulle interfacce Ethernet, sulle VPN, sui 
point to point PPPoE, sui bridge e sui bonding (aggregati) di VPN. La 
classificazione del traffico può avvenire anche mediante i filtri Layer 
7 che permettono il Deep Packet Inspection (DPI) e quindi di regolare la 
banda e la priorità da assegnare ai flussi di applicazioni come VoIP e P2P;


 Ma il discriminante è il protocollo, tipo ftp o vari p2p?
Per il p2p, puoi pensare di usare l'estenzione ipp2p di netfilter
in tabella di mangle per il marking delle connessioni e tc di iproute2
per lo shaping.

 per lo shaping.
Ok, non ho capito moltissimo, lo ammetto, ma perchč in questo
capo sono parecchio indietro.
Il fatto č che sono anni che viaggio senza firewall e non ve ne
ho mai messo mano....disabilitando i servizi accessibili
dall'esterno ecc non ho mai avuto problemi o non mi sono accorto
di rootkit, o altri attacchi...solo qualche tentativo di
bruteforce, mai piů visti da quando ho  disabilitato i tentativi
di accesso verso sshd dall'esterno.
Resta il fatto che ipfilter o netfilter non li conosco e anchelě
dovrei documentarmi...ma questa di solito č la via per
raggiungere parecchi obiettivi no?
Vi ringrazio ancora sia whipalsh che Rizio. Saluti!  :-)

 obiettivi no?
Direi di sì.

 per impostare policy di traffic shaping e simili.
Capisco...ma in questo caso com fare a marcare i pacchetti
generati da "down tham all". Il protocollo penso sia sempre http
no? quindi la vedo dura...

 no? quindi la vedo dura...
Ethereal... hemmm, scusa, Wireshark.


 dura...
Su http puoi usare squid, come detto, costruendo una adeguata acl
(sullo user agent) e i delay pool.
Ma puoi anche sbizzarrirti con iptables: ad esempio, usi l'estensione
l7 per individuare le sessioni http, per poi individuare lo User-Agent
di Down Them All con l'estensione string, per dire la prima cosa che mi
viene in mente.

 viene in mente.
Rispondo a te per rispondere ad entrambi.
Gente io non vi ho capito quasi nulla...nello specifico.
In termini generali, invece penso di aver capito che si può fare
ma non prima di aver messo mano alla documentazione.
Quindi inutile per me proseguire la discussione, meglio fermarmi
qui e procedere alla lettura dei manuali. Quando e se arrivo ad
una conclusione, nel caso avessi problemi, mi rifaccio vivo.
A proposito, se voleste aggiungere qualche altro link anche per
iptables e compagnia...  ;-)
Magari con qualche esempio inerente all'obiettivo.
Saluti e grazie ancora per la disponibilità  :-)

 viene in mente.
Dunque, riprenderi un attimo l'argomento...
lasciamo perdere per il momento squid, vorrei concentrarmi su
iptables/netfilter, anche perchè mettere in piedi un firewall
credo sia un'operazione interessante nonchè utile, soprattutto
visto che il mio sistema viaggia scoperto da quel punto di vista.
Allora, devo premmettere che il mio sistema è basato su
slackware-12.1, ma l'ho messo in piedi pertendo da pochi pacchetti
e aggiungendo man mano ciò che mi serviva.
In pratica il pachetto iptables non è presente (anzi era). Ora
l'ho installato...non so se ci sono dei pacchetti da cui dipende,
ma va bè eventualmente il programma mi avvertirà.
Ho anche dato un'occhiata alle estensioni consigliate cercando
informazioni in rete.
Mi piacerebbe avere seppur sinteticamente una visione d'insieme
dell'operazione:
abbiamo detto che bisogna in primo luogo intercettare i pacchetti
generati (o richiesti, non so...) da "down them all". Questo
significa in prima battuta estrarre in qualche modo lo "user agent"
che da qualche parte i pacchetti dovrebbero contenere. giusto?
Fermiamoci un attimo:
Per ottenere quella informazione si può usare uno sniffer (dico
bene? non ne ho mai usati e devo capire come fare a farlo
funzionare) e come consigliava Ritzio si potrebbe usare
wireshark che ho installato.
È un buon punto di partenza per poi dedicarsi con più
informazioni ad iptables?
Altra cosa...leggevo che le estensioni di iptables/netfilter sono
in realtà delle patch...però poi mi sono accorto che quei
documenti erano riferiti al kernel 2.4.
Mi vedo un attimo confuso da questo punto di vista:
le estensioni consigliate sono già comprese in iptables
netfilter? oppure devo ricompilare qualcosa?
il kernel è 2.6.24.5 stiamo parlando di slackware quindi si
tratta di un vanilla, visto che di patch io non ne ho applicato
se non ricordo male.
iptables è 1.4.0
Spero non siano domande campate in aria...grazie in anticipo!
:-)

 iptables è 1.4.0
Come sopra, netfilter e' comunque inserito in tutti e due i branch 
percio' vai tranquillo e dalla via che ci sei ti conviene anche fare un 
bel boot con un kernel 2.6 nuovo fiammante.... AFAIK e' sempre una cosa 
emozionante vedere il boot della macchina sgombro da cavolate e reattivo 
secondo i tuoi dettami e le tue scelte !!
Rizio (no Ritzio !)


 wireshark che ho installato.
Fermo restando i dubbi espressi nel post precedente, vorrei dire
due parole su wireshark:
l'ho lanciato ed è saltata fuori una gui piuttosto amichevole
(sono sempre punti di vista...), io credevo fosse roba testuale,
va bè...probabilmente ci sarà il modo diusarlo anche da console.
In pratica dopo una sbirciata ad un po' di documentazione in rete
e al man ho realizzato che mi occorreva "posizionare" lo sniffer
in modo da catturare ciò che passa da una certa interfaccia.
Stiamo parlando di connessione dialuo ad internet e quindi ho
immagginato che ppp0 fosse l'interfaccia da considerare...giusto?
Iniziando ad analizzare ppp0 compaiono parecchie righe di
richieste da me (mio ip) verso altri ip e risposte...
Poi ho filtrato le righe in modo da vedere unicamente le
trasmissioni via protocollo http e ho lanciato downthemall
iniziando a scaricare un file.
Nella penultima sezione in basso di wireshark si possono vedere i
dettagli riguardanti una riga precedentemente selezionata.
Così, dopo aver selezionato la riga riguardante la mia richiesta
verso il sito dove stava il file in download ho guardato i
dettagli...in cerca dello user-agent che dovrebbe contraddistinguere
down-them-all.
ci sono 5 voci: frame, linux cooked captured, internet protocol,
transmission control protocol, hypertext transfer protocol.
Bene, andando a espandere i dettagli di hypertext transfer
protocol ottengo i dettagli circa la mia richiesta al server
"GET indirizzo.file/nomefile" e altri dettagli tra cui vedo anche
la voce User-Agent...sembra fatta...
Invece no! dice:
              gecko/2008...  Firefox/
2.0.0.16
\r\n
Insomma di down-them-all non vi è traccia...
Allora il mio ragionameto è il seguente:
se io lavorassi con netfilter sul layer7 attraverso l'estensione
l7 e cercassi di "filtrare" i pacchetti con l'estensione string sulla
base dello user-agent corrispondente a down-them-all,
probabilmente non riuscirei ad intercettare alcun pacchetto ne
tantomeno a limitare la banda ipegnata dall'applicazione in
esame.
Il problema è che down-them-all non è un'applicazione autonoma,
ma un plugin di firefox e questo complica le cose...anche
semplicemente trovare il processo corrispondente a downthemall
non saprei come farlo tanto per dire.
Voi avete in mente qualcosa viste queste informazioni?
Scusate la lunghezza. Spero di essere stato chiaro almeno.

 Rizio (no Ritzio !)
ooopss, chiedo scusa  :-D

 piacere). Sbaglio?
Sì.
Un po' d'acqua è passata sotto ai ponti dai tempi di patch-o-matic.
xtables consente l'aggiunta di estensioni senza necessità di patch
e ricompilazione del kernel; basta, appunto, compilare ed installare
le sole estensioni.
Vedi
http://jengelh.medozas.de/projects/xtables/

 
http://jengelh.medozas.de/projects/xtables/
Appena riesco ci metto mano. Grazie!  :-)

 Quindi, netfilter di suo, nel vanilla, non comprende le estensioni
Bisogna capire cosa tu intenda per "estensioni".
Un tempo, tutto ciò che riguardava netfilter e non era 
ancora nel kernel tree ufficiale era in patch-o-matic.
Attualmente, ciò che non è nel tree ufficiale è in xtables-addons.
Cerca di capire cosa ti serve esattamente: magari è già in netfilter.

 Di java non so nulla... si può sempre dare un'occhiata comunque.
Ho paura che sia l'unica via di fuga...in un certo senso
almeno...
Mi spiego.
Se non si riesce a distingure downthemall da firefox, nè con l'id
del processo perchè avviando downthemall, non si avvia o almeno non
mi pare, alcun nuovo processo identificabile in qualche modo. Nè
si riesce basandosi sullo user-agent perchè a quanto pare, è lo
stesso di firefox.
Se quanto sopra è corretto, e potrebbe anche essere da
approfondire per capire meglio, ma se fosse corretto, allora
l'alternativa è agire da dentro firefox.
Guarda caso esiste in effetti una possibile soluzione, lameno
potenzialmente visto che non l'ho provata:
c'è un'estensione di firefox, chiamata firefox throttle:
lifehacker.com/362512/cap-your-browsing-bandwidth-with-firefox-throttle
https://addons.mozilla.org/it/firefox/search?q=+Firefox+Throttle&cat=all
Ma a quanto pare fortuna vuole che sia solo per windows...  :-\
Cosa ne pensate? esiste qualcosa di simile anche per il pinguino?

 Cerca di capire cosa ti serve esattamente: magari è già in netfilter.
Si il problema almeno per quanto riguarda downthemall è proprio
quello. Intanto guardando sul suo sito i commenti pare che la
funzione mancante di bandwidth-limit sia molto gettonata.  ;-)
Vorrei ora acccantonare un attimo downthemall e porre un altro
esempio, in modo da fare una prova rapida.
Diciamo che sto scaricando un file da un sito via http, con una
richiesta GET...ma non importa poi molto. Ciò che importa è che
sto scaricando da quel sito con un tool scritto in python...non
da me beato ignorante, per carità...si tratta di un proxy per
scaricare video in streaming da "veoh" o siti simili.
Quindi conosco il sito da cui proviene il malloppo.
Come posso fare a limitarne la banda con iptables?
Avevo pensato ad una regola capace di limitare la banda in
ingresso per i pacchetti provenienti da quel sito.
Chiedo la cena pronta...direte voi, ma non è che potreste
azzardare il comando da passare per istruire iptables?
Penso che in questo caso non servano estensioni esterne o
sbaglio?

 limitarne la banda con iptables?
Iptables non limita la banda.
Può essere usato per marcare pacchetti identificati sulla
base di criteri che possono essere i più vari.
Il marking applicato da iptables può poi essere usato da tc, strumento
della suite iproute, per fare traffic shaping.

 della suite iproute, per fare traffic shaping.
Visto che la risposta, benchè chiara è un po' poco...pratica a
livello immediato (speravo in 4 righe di comandi...), mi sono
messo a leggere un po di howto-s.
Per esempio ve n'è uno chiamato adsl abndwidth limiting howto o
roba simile, in cui viene spiegato come ottimizzare la gestione
di banda col fine di minimizzare la latenza ecc ecc...insomma per
me è roba un po' complessa, comunnque si legge.
Bene, ad un certo punto viene detto però che non è possibile
limitare la banda in entrata, ma solo quella in uscita.
Mi chiedevo, ma allora quando lancio wget con l'opzione
--limit-rate, cosa accade?
lui scarica a velocità molto più bassa e la mia connessione
resta "spesso" utilzzabile anche per navigare.
Che ne dite?  :-?
Cioè in qualche modo wget cerca di dare istruzioni al server in
modo che già all'origine i pacchetti vengano inviati a velocità
ridotta oppure agisce in qualche altro modo sui pacchetti in
arrivo?
Non so se sono riuscito ad esprimermi troppo bene... :-|

 della suite iproute, per fare traffic shaping.
Volevo segnalare questo link che penso possa essere interessante:
http://www.sistemistiindipendenti.org/pdf/shaping.pdf
Devo ancora leggerlo a dire il vero, ma da una scorsa veloce mi
pare faccia al caso mio (e di altri che magari si sono posti le
stesse domande).

Vorrei proporvi un esempio:
mettiamo in conto di voler limitare la banda in download per quei
pacchetti che provengono da un certo sito.
Ho trovato uno script che ho deciso di provare al volo:
http://www.topwebhosts.org/tools/traffic-control.php
Da questo ho ricavato il seguente:
#!/bin/bash
TC=/sbin/tc
IF=ppp0
U32="$TC filter add dev $IF protocol ip parent 1:0 prio 1 u32"
IP=
ip.di.pro.va
UPLD=5kbps
DNLD=5kbps
$TC qdisc add dev $IF root handle 1: htb default 30
$TC class add dev $IF parent 1: classid 1:1 htb rate $DNLD
$TC class add dev $IF parent 1: classid 1:2 htb rate $UPLD
$U32 match ip dst $IP/32 flowid 1:1
$U32 match ip src $IP/32 flowid 1:2
----
Ad ip di prova ho fatto corrispondere l'ip del sito da cui volevo
provare a scaricare ed ottenere una velocità limitata in questo
caso a 5 KB/s.
Dovrebbe funzionare secondo voi?
Scaricando da quel sito la banda mi risulta libera di superare i
5 KB/s...
Spero possiate darmi una mano perchè da tutta la documenntazione
in rete penso di non saltarci fuori. Grazie in anticipo  :-)