Se questo giovedì sei al fusolab potremmo vedere insieme, sarebbe
interessante venire a capo e magari scoprire un grosso bug di openwrt
per fixarlo.
Il 01/09/2013 00.17, Saverio Proto ha scritto:
Comunque se vuoi fare delle prove a riguardo epr quanto riguarda TCP puoi
fare
MSS clamping con
Se questo giovedì sei al fusolab potremmo vedere insieme, sarebbe
interessante venire a capo e magari scoprire un grosso bug di openwrt
per fixarlo.
Considerami già lì anche perchè vorrei iniziare a mettere il naso, ma solo il
naso !, nella parte software di ninux primariamente olsr ma anche
Stavo pensando, potrebbe essere un problema di frammentazione?
La nostra rete usa un mtu di 1500, l'adsl sul cisco deve usare 1492.
Ora che ho temporaneamente tolto il traffico internet dal router non ho
più problemi.
è l'unica cosa che mi è venuta in mente.
On Saturday, August 31, 2013 07:47:43 PM Alessandro Gnagni wrote:
Stavo pensando, potrebbe essere un problema di frammentazione?
La nostra rete usa un mtu di 1500, l'adsl sul cisco deve usare 1492.
Se fosse questo il problema li creerebbe al cisco e non ad un altro router
Comunque se vuoi fare
Ma non dovrebbe essere il cisco ad informare l'openwrt che il pacchetto
e troppo grande? Se non c'è il don't fragment lo frammenta il cisco o ci
pensa l'openwrt che se ne accorge?
Onestamente non mi vengono altre idee apparte l'mtu perchè ci faccio
passare 20-40 megabit di traffico interno senza
Comunque se vuoi fare delle prove a riguardo epr quanto riguarda TCP puoi fare
MSS clamping con iptables
esatto metti la wan a MTU 1492 e poi:
iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS
--clamp-mss-to-pmtu
___
Wireless
Quindi openwrt non cancella i pezzi di pacchetto che rimangono ?
--- Messaggio originale ---
Da: Alessandro Gnagni enterprise...@gmail.com
Inviata: 31 agosto 2013 20:00
A: wireless@ml.ninux.org
Oggetto: Re: [Ninux-Wireless] Problemi con elevato traffico da/verso internet
attraverso macchine
] Problemi con elevato traffico da/verso internet
attraverso macchine openwrt
Ma non dovrebbe essere il cisco ad informare l'openwrt che il pacchetto
e troppo grande? Se non c'è il don't fragment lo frammenta il cisco o ci
pensa l'openwrt che se ne accorge?
Onestamente non mi vengono altre idee apparte
No le mie config hardware riguardo la gestione e traffico verso i gateway
sono diverse.
Il giorno 29/ago/2013 03:19, federico la morgia super_tr...@hotmail.com
ha scritto:
Se invece faccio transitare intorno a 10 megabit di traffico verso
internet dopo diversi minuti si blocca.
Fish ha
Prima nn risponde più ssh e snmpd. Dopo poco ei riavvia.
L'unica regola iptables è un nat verso riseup. Qos nn abilitato.
Col riavvio mi perdo dmesg.
Ho provato a monitorare la ram ma nn sono riuscito a ripetere di nuovo il
bug mentre controllavo, comunque oscilla fra 2 e mezzo e 6 mega liberi.
In
On Aug 29, 2013, at 9:15 AM, Alessandro Gnagni wrote:
[...]
Come posso controllare se è attivo conntrack?
Se è stato compilato come modulo e vedere se è caricato puoi eseguire un banale:
lsmod|grep conntrack
Così vedi alcuni parametri:
sysctl -a | grep conntrack
Per vedere se è caricato
On Wednesday, August 28, 2013 10:59:52 PM Alessandro Gnagni wrote:
Ho notato oggi un curioso comportamento riscontrato anche in passato, su
un 1043nd con attitude adjustment se faccio passare anche 40/80 megabit
di traffico interno su ninux non ci sono problemi.
Se invece faccio transitare
se vuoi controllare conntrack fai lsmod e vedi se è caricato il
modulo kernel nf_conntrack
quando si attiva nel dmesg ti stampa qualcosa tipo:
nf_conntrack version 0.5.0 (256 buckets, 1024 max)
Saverio
Il 29 agosto 2013 09:15, Alessandro Gnagni enterprise...@gmail.com ha scritto:
Prima nn
cmq è strano perché al Nodo Combipel ho lo stesso hardware, faccio
anche NAT, e mai avuto questo problema.
Inoltre da li ho caricato diversi video su vimeo, quindi ho usato
massivamente l'upload.
l'interfaccia del Cisco che sta davanti come è configurata ? vedi
errori sull'interfaccia ethernet
Questo apparato fa routing a terra. La tua soluzione non è attuabile.
Il giorno 29/ago/2013 10:25, Gioacchino Mazzurco g...@eigenlab.org ha
scritto:
On Wednesday, August 28, 2013 10:59:52 PM Alessandro Gnagni wrote:
Ho notato oggi un curioso comportamento riscontrato anche in passato, su
un
On Thursday, August 29, 2013 09:15:51 AM Alessandro Gnagni wrote:
Prima nn risponde più ssh e snmpd. Dopo poco ei riavvia.
Almeno a te ti si riavvia so di casi in cui si impalla e basta...
___
Wireless mailing list
Wireless@ml.ninux.org
Questo apparato fa routing a terra. La tua soluzione non è attuabile.
perche' non e' attuabile ? basta configurare una vlan untagged su una
delle porte gialle ?
Saverio
___
Wireless mailing list
Wireless@ml.ninux.org
Ho notato oggi un curioso comportamento riscontrato anche in passato, su
un 1043nd con attitude adjustment se faccio passare anche 40/80 megabit
di traffico interno su ninux non ci sono problemi.
Se invece faccio transitare intorno a 10 megabit di traffico verso
internet dopo diversi minuti si
viene nattato quel traffico verso Internet ?
Saverio
Il 28 agosto 2013 22:59, Alessandro Gnagni enterprise...@gmail.com ha scritto:
Ho notato oggi un curioso comportamento riscontrato anche in passato, su
un 1043nd con attitude adjustment se faccio passare anche 40/80 megabit
di traffico
No, il nat viene fatto dal cisco dopo di lui. Annuncia la 0 e come
gateway ha settato il cisco.
Il 28/08/2013 23.51, Saverio Proto ha scritto:
viene nattato quel traffico verso Internet ?
Saverio
Il 28 agosto 2013 22:59, Alessandro Gnagni enterprise...@gmail.com ha
scritto:
Ho notato
Che intendi per si blocca ?
dmesg e logread danno informazioni utili ?
hai qos abilitato ?
altre regole di iptables ?
se stoppi olsrd e ti metti in una situazione con molta RAM libera, il
problema persiste ?
fico questo bug, mi sono letto tutto il ticket con molto interesse :)
sembra veramente
Se invece faccio transitare intorno a 10 megabit di traffico verso
internet dopo diversi minuti si blocca.
Fish ha riscontrato lo stesso problema ?
___
Wireless mailing list
Wireless@ml.ninux.org
22 matches
Mail list logo