Newsgroup: it.comp.os.linux.sys
Titolo: gratuitous arp conto terzi

ovvero il problema della stampante multifunzione.
 
Scusate, ci riprovo qui dato che su it.comp.reti.ip-admin non
ho avuto fortuna.
 
 
Il problema è che si vuole piazzare una stampante multifunzione
in un punto dove proprio non si può far arrivare un cavo di rete.
 
Visto che l'ufficio ha una copertura wifi data da questi access point:
 
http://www.arubanetworks.com/it/prodotti/prodotti-per-il-networking/access-point/serie-103/
 
 
ho collegato alla stampante questo simpatico aggeggio:
 
http://www.tp-link.it/products/details/TL-WR802N.html
 
 
che configurato in modalità client assolve egregiamente al suo compito.
 
Quindi ho:
 
il server linux            con indirizzo   192.168.1.101
l'access-point aruba       con indirizzo   192.168.1.254
l'access-point TP-Link     con indirizzo   192.168.1.244
la stampante multifunzione con indirizzo   192.168.1.218 
 
 
Vado sulla stampante, eseguo una scansione e quella mi deposita
il file relativo sulla direttiva condivisa da Samba del server
Linux.
 
Lancio una stampa dal server Linux e la stampante, tutta giuliva,
mi sputa fuori le paginette A4 ottimamente stampate. 
 
Tutto OK ?
 
Quasi.
 
Il fatto è che se lascio la stampante inattiva per un po'
questa smette di eseguire ulteriori stampe a meno che non
esegua una scansione, subito dopo la quale riprende a stampare.
 
Per farla breve il problema è al livello del TCP-IP, quando
faccio una scansione la stampante raggiunge senza problemi
il server che si ritrova nella sua arp-table il mac address
dell'indirizzo IP 192.168.1.218 (che in realtà è quello del
TP-Link)
 
Grazie a ciò le stampe eseguite immediatamente dopo funzionano.
 
Ma dopo un periodo di inutilizzo la riga relativa nella tabella
arp del server scade e viene rimossa.
 
Se a questo punto il server tenta di raggiungere la stampante,
non ci riesce, anche un normale ping dal server non la raggiunge
in quanto le richieste arp per l'indirizzo 192.168.1.218
non vengono propagate, credo, dal TP-LINK.
 
Allo stesso modo il server Linux, dopo un po', non raggiunge
più il TP-Link.
 
 
Per quanto riguarda il server Linux ho risolto facilmente
aggiungendo queste due righe nello shell /etc/rc.local:
 
arp -s 192.168.1.218 18:d6:c7:ce:3c:3c
arp -s 192.168.1.244 18:d6:c7:ce:3c:3c
 
 
Così facendo raggiungo senza problemi sia la stampante che
il TP-LINK, ma il problema sono tutti i PC sulla rete locale
che non riescono a raggiungere la stampante.
 
Pensavo che potrei risolvere se potessi far spedire dal server
Linux dei gratuitous arp per conto della stampante ma non so
se si può, e come fare.
 
Ho dato uno sguardo a ettercap ma non mi pare che mi consenta
di fare quello che mi serve.
 
Qualche dritta per questa o altre soluzioni ? 
 
 
-- 
Stefano L.

esegua una scansione, subito dopo la quale riprende a stampare.
 
E provare a pingare una volta ogni 30 secondi la stampante?
 
Leonardo
-- 
 
A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

 E provare a pingare una volta ogni 30 secondi la stampante?
 
Come ho scritto, il problema non è sul server Linux, dove ho risolto 
banalmente inserendo una entry statica nella arp table.
 
Il problema è su tutti i pc windows che non riescono a raggiungere
la stampante perché le loro richieste arp non ricevono risposta.
 
Vorrei evitare di fare la stessa cosa su ogni singolo pc, prima di tutto
perché sarebbe una rogna, secondo perché non so se windows me lo consente.
 
La mia idea sarebbe quella di far spedire dal server Linux dei gratuitous 
arp facendo finta di essere la stampante (quindi col suo mac-address)
in modo che i vari pc windows si ritrovino nelle loro arp-table
la riga necessaria.
 
Il punto è che non so se è possibile far fare questo al server Linux.
 
Come ho scritto, ho dato uno sguardo a ettercap ma non l'ho mai
usato e non riesco a capire se può fare quello che mi serve.
 
 
-- 
Stefano L.

Come ho scritto, il problema non è sul server Linux
 
Non ho detto che lo fosse :-)
 
Sembra che il tuo WLAN client abbia qualcosa di simile ad un inactivity drop
(idle drop), per cui la stampante ha un indirizzo e sa di averlo, mentre per
qualche motivo il WLAN client decide di no.
 
Chiaramente, appena la stampante (lato "client" per il WLAN coso) attiva una
connessione per fare la scansione, le cose tornano a posto.
 
Il ping continuo dal server avrebbe l'unica funzione di far vedere il "pong"
di risposta al WLAN client.
 
Io **credo** che forse si possa settare il coso per non fare scemenze (prova
a inserire "0" nel campo "Max Idle Time" impostando "Connect on Demand"). Ma
altrimenti, il ping-pong è un sistema come un altro per avere un keep-alive.
 
Tanto, qualcosa periodicamente sul server devi eseguirla comunque. A meno di
impostare delle ARP route fisse sui terminali Windows:
 
    netsh interface ipv4 add neighbors "Nome Connessione LAN" 
       192.168.1.218 18-d6-c7-ce-3c-3c
 
...prima di usare netsh, aka l'opziuone nucleuare fine di muondo, prova se i
finti ARP funzionano da Windows. Si sa mai.
 
    arp -s 192.168.1.218 18-d6-c7-ce-3c-3c


 in un punto dove proprio non si può far arrivare un cavo di rete.
 
Metti uno di quegli aggeggi a onde convogliate , se ci arriva il wifi ci arriva sicurmanete anche quello.
 
Una mia opinione, il wifi non e' la soluzione migliore in tutte le circostanze.
 
Giulia
PS: se non vole spendere 30 euro per una soluzione rocksolid lascia perdere quel cliente.
 
 
 
 

 mentre per qualche motivo il WLAN client decide di no.
 
Ci hai quasi preso.
 
Il problema non era il WLAN client, ma l'access point Aruba !
 
Nelle impostazioni avanzate, che fino ad adesso avevo trascurato,
c'è un opzione "filtraggio broadcast" attiva di default,
disabilitandola tutto è diventato normale.
 
Credo che serva per poter evitare di inondare rete wifi con dei broadcast
che normalmente non servono a nulla dato che difficilmente sulla rete wifi
ci sono apparati con dei servizi attivi, cosa che invece è vera nel mio 
caso.
 
Quindi, dal punto di vista dell'access point, è certamente indispensabile
propagare i broadcast delle arp-request dalla rete wifi verso la cablata,
mentre è, quasi sempre, uno spreco di banda wifi fare l'opposto.
 
 
-- 
Stefano L.

 perdere quel cliente.
Non ci penso neanche ! E uno dei clienti migliori e non si fa scrupoli
a spendere quando serve.
 
A parte questo, per me era ormai più che un problema una curiosità,
una sfida tecnica.
 
Il tarlo di capire se era possibile risolvere con ettercap mi è rimasto,
prima o poi me lo studierò :-)
 
 
 
-- 
Stefano L.