Rete lan bloccata da un raspberry

[vnnngn]

Buongiorno,

 

da un cliente è stato installato un raspberry pi 4 (OS raspbian) con installato un applicativo scritto in node js per leggere delle variabili OPC-UA come client dal PLC bosch della macchina.

 

Il problema è che dopo 1 - 5 giorni massimo di esecuzione la comunicazione sulla rete ethernet della macchina si blocca e cade la comunicazione tra i dispositivi (HMI e PLC).

Scollegando il raspberry la comunicazione riprende.

Riavviando il raspberry la comunicazione riprende.

Dopo altri 1 - 5 giorni, si ripresenta il problema.

 

Come è possibile che un dispositivo collegato blocchi l'intera comunicazione nella rete macchina?

 

Dal raspberry ho eseguito un tcpdump loggando su file tracciando anche prima e dopo l'evento di blocco di comunicazione ma non sono riuscito a trarne molti suggerimenti.

 

Spoiler

Altre informazioni generali della configurazione:

 

La rete aziendale ha sottorete 192.168.0.0/24

La rete macchina ha sottorete 192.168.1.0/24

La rete macchina è collegata ad un raspberry 4 con raspbian su un adattatore ethernet-USB

La rete aziendale è collegata ad un router Teltonika RUT 300 alla porta WAN

Il raspberry è collegato ad una porta LAN del router Teltonika con sottorete 10.66.248.0/24

 

Il PLC della macchina espone delle variabili in OPC-UA sulla porta 4840.

Il raspberry legge le variabili come client OPC-UA ed espone le variabili come server OPC-UA su un'altra porta (57930).

Il router è configurato per fare portforwarding da WAN a LAN sulla porta 57930 verso l'indirizzo LAN del raspberry (10.67.248.2).

 

 

[Andrea Annoni]

Ci sono molte variabili in gioco.

ma il primo dito puntato e sui cablaggi.

una cattiva trasmissione (socket bloccati, errori FCS ecc ecc ) può generare problemi del genere.

Attenzione che il buon cablaggio non vuol dire prendere il tester della lidl e verificare la continuità…

significa utilizzare un certificatore e fare i vari test in frequenza.

 

altri indizi possono dipende da come è costituita la rete; ad esempio switch dozzinali, malagestio di Vlan.

insimma, bisognerebbe capire meglio l’architettura.

non in ultimo il raspberry stesso…. Non è che ha la SD danneggiata? 
quando la rete è “bloccata” hai provato con pcap a fare un po’ di troubleshooting?

[max.bocca]

Come ti ha consigliato @Andrea Annoni io cercherei uno switch che si possa creare una porta monitor da collegare un pc con wireshark, quindi analizzare il file catturato,  facilmente si vede chi ad un  certo punto non risponde..  io avevo uno switch che faceva i capricci dopo che gli si è abilitato un restart quotidiano mai più avuto problemi,  in questo caso si è potuto fare che nelle ore notturne non c'è attività in corso anche se il problema non è intrinseco allo switch perché se installato in altra rete non ha problemi.

[Livio Orsini]

14 ore fa, vnnngn ha scritto:

Scollegando il raspberry la comunicazione riprende.

 

Mi stupirei del contrario!

Raspberry (come arduino) è assolutamente inadatta all'ambinete industriale!

Non ha immunità ECM, ha un alimentatore che lascia passare qualsiasi disturbo, non ha separazione galvanica con il campo.

 

Soluzione del problema?

Sostituire Raspberry con un dispositivo industriale certificato.

Costa di più? Certamente perchè la sicurezza costa.

[vnnngn]

Buongiorno a tutti, intanto grazie delle risposte.

 

Applicando male i vostri suggerimenti al momento posso provare a sostituire il cavo ethernet tra raspberry e switch e inviare un nuovo raspberry (con nuova sd) per scongiugare problemi sulla scheda.

 

In attesa di capire se  è possibile analizzare il traffico tramite una porta dedicata dello switch il tcpdump fatto dal raspberry e salvato in pcap può aver registrato informazioni utili che non sono stato in grado di cogliere? Cosa dovrei cercare?
Non ho visto note a riguardo, spero di non infrangere il regolamento alleando il seguente link con un estratto dell'esito del tcpdump salvato in formato pcap (https://drive.google.com/file/d/191fNzVmcDu6iiBo9q6-kRBdkfpZxapnm/view?usp=sharing)

 

 

 

@max.bocca  Lo switch è un IP-COM F1024 (https://down.ip-com.com.cn/en/F1024/F1024 Datasheet.pdf)

Non mi sembra dia la possibilità di creare una porta monitor.

Aggiungo poi che la macchina viene spenta ogni sera e così anche raspberry e Router Teltonika.

 

@Andrea Annoni E' possibile che il problema sia nel cavo ethernet tra raspberry e switch o potrebbe essere anche che la qualità di trasmissione PLC-HMI sia sufficiente per la loro comunicazione ma quando viene sottoposta anche al traffico con il raspberry questo causi errori e congestione?
Al momento ho eseguito un test di velocità sulla SD e non sono stati riscontrati problemi.

 

@Livio Orsini  Fosse un problema di interferenze come posso verificarlo? Se alimentassi il raspberry con uno stepdown 24v-5v prendendo la 24v dalla macchina potrebbe essere un modo per escludere il problema almeno in fase di ricerca del problema?

 

 

 

 

Lo schema della rete è illustrato di seguito.

Spoiler

 

 

[Andrea Annoni]

Non hai risposto alle domande, per cui resta sempre un incongnita risponderti.

 

Diciamo che dopo aver letto la rispost di @Livio Orsini condivido al 100% il dubbio. Una possibile soluzione NON è prelevare alimentazione dalla macchina, ma alimentare temporaneamente il raspberry a batteria (per esempio).

[Livio Orsini]

10 ore fa, Andrea Annoni ha scritto:

ma alimentare temporaneamente il raspberry a batteria (per esempio).

 

Condivido perchè così si eliminano almeno i disturbi condotti dall'alimentazione.

Rimangono ancora come fonte di possiibli blocchi i disturbi irradiati e quelli condotti dai collegamenti.

In genere la fonte della maggior parte dei disturbi è l'alimentazione.

Però torno a ripetere che schede come raspberry ed arduino devono essere impiegate solo per gli scopi per cui sono state progettate.

L'ambiente industriale non è assolutamente il loro ambiente: non potrebbero mai superare alcun test ECM, anche quello minimo.

[vnnngn]

12 ore fa, Andrea Annoni ha scritto:

Non hai risposto alle domande, per cui resta sempre un incongnita risponderti.

 

Diciamo che dopo aver letto la rispost di @Livio Orsini condivido al 100% il dubbio. Una possibile soluzione NON è prelevare alimentazione dalla macchina, ma alimentare temporaneamente il raspberry a batteria (per esempio).

 

Ottimo, grazie dell'indicazione per l'alimentazione proverò subito.

 

Per quanto riguarda l'SD è nuova ma questo non esclude che non sia danneggiata, al momento non ho fatto nessun test specifico.Intanto lo farò preventivamente su quella sostitutiva che invierò.

 

Per quanto riguarda il pcap quando mi sono connesso con un computer alla rete non riuscivo a pingare nessun dispositivo. Ho fatto riavviare il raspberry prima eseguire wireshark.

Successivamente ho lanciato il tcpdump a registrazione continua con log su file per intercettare l'evento futuro.

 

 

[vnnngn]

2 ore fa, Livio Orsini ha scritto:

 

Condivido perchè così si eliminano almeno i disturbi condotti dall'alimentazione.

Rimangono ancora come fonte di possiibli blocchi i disturbi irradiati e quelli condotti dai collegamenti.

In genere la fonte della maggior parte dei disturbi è l'alimentazione.

Però torno a ripetere che schede come raspberry ed arduino devono essere impiegate solo per gli scopi per cui sono state progettate.

L'ambiente industriale non è assolutamente il loro ambiente: non potrebbero mai superare alcun test ECM, anche quello minimo.

 

Mi rendo conto che il raspberry in questo caso è usato in modo impropio ma si potrebbe dargli un contorno più dignitoso ad esempio installando un filtro EMI sull'alimentazione?

[Livio Orsini]

Prova con alimentazione a batteria.

Se c'è qualche risultato significativo allora si può cercare di miglioare le cose usando un buon alimentatore a 12V precedujto da un filtro di rete; a questo alimentatore fai seguire un filtro a doppio pi greco C-L-C-L-C ed un regolatore serie per ottenere i 5V.

Poi separi gli zero volt di raspberry da tutto il resto usando separatori galvanici per tutto entra ed esce dalla scheda. Il tutto racchiuso in un contenitore metallico, con funzioni di schermo, collegato ad un'ottima linea di terra.

Alla fine il costo sarà simile a quello di un apparato industriale che svolge le medesime funzioni, con molta complicazione in più.

Altrimenti ti puoi limitare ad un alimentatore sero per dare i 5V alla scheda, facendolo precedere da un filtro di rete Shaffner o equivalente.

Poi, se sei devoto a qualche santo, lo preghi e gli accendi un grosso cero, sperando che tutto questo basti.😉

[Dumah Brazorf]

Come mai lo switch non è indiziato?

Almeno è uno di quelli "professionali" con la carcassa in metallo collegata a terra?

[Livio Orsini]

16 ore fa, Dumah Brazorf ha scritto:

Come mai lo switch non è indiziato?

 

Perchè:

 

Il 15/7/2022 alle 21:29 , vnnngn ha scritto:

Scollegando il raspberry la comunicazione riprende.

Riavviando il raspberry la comunicazione riprende.

 

Inoltre, se conosci almeno un po' raspberry, sai che al 99,99% è sicuramente questo dispositivo il responsabile delle cadute di comunicazione.

Addirittura basterebbe mettere un reset automatico al dispositivo, che viene attivato sulla caduta di comunicazione, per mascherare il problema.

 

[Dumah Brazorf]

Quindi un client si collega ed ha accesso esclusivo finchè non rilascia il collegamento?

Comunque se basta scollegare e ricollegare (spero intenda il cavo di rete) il raspberry scommettiamo che funziona anche spegnendo e riaccendendo lo switch?

[Livio Orsini]

2 ore fa, Dumah Brazorf ha scritto:

scommettiamo che funziona anche spegnendo e riaccendendo lo switch?

 

Non credo, perchè la parola chiave è: "Riavviando il raspberry la comunicazione riprende." Altrimenti avrebbe scritto "ricollegando a raspberry.

 

Son cose che mison capitate altre volte, molti anni fa. Si blocca la comunicazione, spegni il dispositivo che sai da problemi, scolleghi il cavo di comunicazione, resetti o spegne e riaccendi, il dispositivo, ricolleghie e tutto funziona sino al prossimo blcocco.

Questo succede quando hai dispositivi con immunità ECM inesistente.

 

Queste sono considerazioni sulla base di quanto riportato. Per avere certezze è necessario poter avere "in mano" l'impianto.

[vnnngn]

Il 19/7/2022 alle 11:36 , Livio Orsini ha scritto:

Prova con alimentazione a batteria.

Se c'è qualche risultato significativo allora si può cercare di miglioare le cose usando un buon alimentatore a 12V precedujto da un filtro di rete; a questo alimentatore fai seguire un filtro a doppio pi greco C-L-C-L-C ed un regolatore serie per ottenere i 5V.

Poi separi gli zero volt di raspberry da tutto il resto usando separatori galvanici per tutto entra ed esce dalla scheda. Il tutto racchiuso in un contenitore metallico, con funzioni di schermo, collegato ad un'ottima linea di terra.

Alla fine il costo sarà simile a quello di un apparato industriale che svolge le medesime funzioni, con molta complicazione in più.

Altrimenti ti puoi limitare ad un alimentatore sero per dare i 5V alla scheda, facendolo precedere da un filtro di rete Shaffner o equivalente.

Poi, se sei devoto a qualche santo, lo preghi e gli accendi un grosso cero, sperando che tutto questo basti.😉

 

Tanti ceri, rigorosamente a stoppino di cotone, non led.

 

Grazie delle indicazioni. Presentandosi il problema ogni 1-5 giorni, non sarà semplice alimentare il raspberry a batteria, valuto eventualmente la strada dell'alimentatore + filtro e vediamo.

 

 

3 ore fa, Dumah Brazorf ha scritto:

Quindi un client si collega ed ha accesso esclusivo finchè non rilascia il collegamento?

Comunque se basta scollegare e ricollegare (spero intenda il cavo di rete) il raspberry scommettiamo che funziona anche spegnendo e riaccendendo lo switch?

Scollegando il cavo ethernet che collega il raspberry allo switch la comunicazione tra gli altri dispositivi è ripresa.

 

[Livio Orsini]

18 ore fa, vnnngn ha scritto:

Scollegando il cavo ethernet che collega il raspberry allo switch la comunicazione tra gli altri dispositivi è ripresa.

 

 

Ovvio perchè è stato eliminato il dispositivo che blocca la comunicazione.

 

18 ore fa, vnnngn ha scritto:

non sarà semplice alimentare il raspberry a batteria,

 

Raspberry dovrebbe consumare circa 50mA, con una batteria da qualche Ah perfettamente carica, dovresti farcela. Comunque con un buon alimentatore, pesantemente filtrato, dovresti avere qualche miglioramento.

Se puoi ricavare un out da PLC,che segnala comunicazione bloccata, potresti comandare un relè che fa il reset Hw di raspberry. Come ho scritto prima è una vera porcata ma funziona.

[Dumah Brazorf]

Occhio che al raspberry non puoi togliere la corrente così alla bersagliera, si sputtana l'sd.

[ilguargua]

2 ore fa, Livio Orsini ha scritto:

Raspberry dovrebbe consumare circa 50mA

Ottimista! Minimo sono 10 volte tanto, facilmente anche di più.

 

Ciao, Ale.

[Livio Orsini]

2 ore fa, Dumah Brazorf ha scritto:

Occhio che al raspberry non puoi togliere la corrente così alla bersagliera, si sputtana l'sd.

 

Ho scritto "resettare", non "togliere l'alimentazione"! Reaspberry ha un pin dedicato al reset HW ESTERNO.

 

2 ore fa, ilguargua ha scritto:

Ottimista! Minimo sono 10 volte tanto, facilmente anche di più.

 

 

Dipende dal tipo, da cosa hai attaccato e dalla velocitàdi clock

Ne ho una che lavora "nuda" e consuma <50mA. Questa da come è descritta dovrebbe avere solo la connessione di rete.

[ilguargua]

11 minuti fa, Livio Orsini ha scritto:

Ne ho una che lavora "nuda" e consuma <50mA

Ho appena fatto una prova con un raspberry PI zero che ho sottomano, alimentandolo senza l'SD (e quindi sostanzialmente non sta facendo niente), consuma 53 mA. Ma è un mono core e con poca ram, il PI 4 è un dual core, con clock anche più elevato, temo che 50 mA siano davvero pochi...

 

Ciao, Ale.

[ilguargua]

Qui ci sono i consumi indicativi di vari modelli di raspberry PI, come del resto è ragionevole aspettarsi il 4 è quello che consuma di più.

 

Ciao, Ale.

[Livio Orsini]

Io il consumo, citato a memoria, lo riferivo ad una monocore che ho usato per un lavoretto domotico. Ricordo che avevo cercato di contenere i consumi quindi l'ordine di grandezza dovrebbe essere quello.

Poi so benissimo che i quad core hanno cosumi molto maggiori. Per le applicazioni con quand core si consiglia un alimentatore che eroghi almeno di 1A. Io addirittura uso un 5A perchè ho anche altra roba da alimentare.

 

Comunque il problema non credo sia il consumo, ma i blocchi di comunicazione. Nell'applicazione in oggetto non so cosa abbiano usato, vista la funzione io avrei usato la più semplice a singolo core. (in effetti non avrei mai usato una raspberry, ma questo mi sembra pacifico, visto quelle che ho scritto subito).

[vnnngn]

Buongiorno a tutti,

 

un chiarimento:

sia @Livio Orsini che @Andrea Annoni per ridurre i disturbi avete escluso l'alimentare il raspberry direttamente dalla 24v della macchina con opportuno convertitore dc-dc (es: https://www.meanwell.com/upload/pdf/DDR-30/DDR-30-spec.pdf)

 

Posso chiedervi come mai? Era il primo intervento venutomi in mente pensando che essendo tutti i dispositivi in comunicazione alimentati allo stesso modo con anche gli zeri in comune sarebbe potuto essere risolutivo o quasi.

 

 

[Livio Orsini]

22 minuti fa, vnnngn ha scritto:

avete escluso l'alimentare il raspberry direttamente dalla 24v della macchina con opportuno convertitore dc-dc

 

Perchè, in genere questi alimentatori,non hanno una buona reiezione ai disturbi e, soprattutto, perchè l'alimentazione a 24V dei servizi di macchina, è una vera autostrada che veicola una quantità elevata di disturbi. In pratica si questi conduttori viaggiano tutti i disturbi condotti ed irradiati della macchina e magari anche quelli raccolti in campo, visto che spesso questa tensione serve anche sensori, pulsanti, commutatori e sgnalaioni sul campo.

[vnnngn]

Capito, grazie.

 

Aggiornerò il thread quando ci saranno novità / conferme e speriamo soluzioni.