- Questo topic ha 3 risposte, 2 partecipanti ed è stato aggiornato l'ultima volta 9 anni, 5 mesi fa da
.
-
Post
-
Attualmente sto tentando di mettere in piedi un meccanismo di trasferimento dati tra un controllore SlimLine CPU ARM7 IEC61131-3 (Versione Full RS485) ed un PC che funge da server, utilizzando l’UDP, lavorando su una LAN il tutto funziona correttamente. Se il controllore viene invece connesso mediante un modem/router UMTS succede quanto segue:
– I messaggi UDP non vengono inviati a meno che non venga effettuato un ping periodico verso il server con la function block SysIPReach;
– Utilizzando SysIPReach i messaggi vengono recapitati correttamente al server ma le risposte del server non riescono a superare il modem/router;
– Se al posto del controllore utilizzo un PC anche le risposte del server vengono ricevute correttamente. In pratica connettendo il controllore al server mediante un modem/router non sono in grado di ricevere le risposte del server (ho verificato con Wireshark che effettivamente il modem non le fa passare).
Qualche idea in merito ?
Abbiamo applicazioni presso alcuni clienti che utilizzano lo scambio dati in UDP tra sistemi SlimLine (Viene utilizzato l’FB UDPDataTxfer, UDP data transfer), ed in alcune applicazioni questo scambio avviene mediante utilizzo di routers (ADSL, UMTS, Satellitari). Vediamo allora di elencare i possibili tests da effettuare.
L’utilizzo del ping (FB SysIPReach) è indispensabile, perchè è solo con il ping che viene inserita la voce ARP nella ARPTable (IP destinatario su LAN, IP del gateway su WAN, verificare con comando ARPTable da telnet). Lo scambio funziona anche senza il ping solo se si accede al sistema (Telnet, Modbus o WEB) dall’IP del destinatario pacchetti UDP su rete LAN o da Internet su rete WAN e non si lascia più scadere il tempo di vita.
Utilizzando un router è possibile creare un VPN tra le parti, ed in tal caso non vi sono problemi il tutto agisce come una rete LAN veicolata su rete WAN.
Se non usi la VPN dal dispositivo connesso alla rete LAN del router puoi raggiungere l’IP pubblico (La connessione viene iniziata dal dispositivo). Ma per permettere all’IP pubblico di raggiungere il dispositivo devi configurare il NAT (O port forwarding) del router. Dal tuo post non si evince se questa configurazione è stata fatta.
Aggiungo un post separato per rispondere all’ultimo punto della tua domanda, dove dici Se al posto del controllore utilizzo un PC anche le risposte del server vengono ricevute correttamente.
Qui bisogna ricondursi alla tecnica del IP masquerading o NAT dinamico (Cito testalmente Wikipedia). Ciascuna connessione TCP o UDP viene gestita individualmente, quando la connessione viene iniziata, il router NAT mantiene una tabella di corrispondenze tra porte sull’indirizzo esterno e corrispondenti porte e indirizzi IP privati. Quando riceve un pacchetto TCP o UDP sull’indirizzo IP esterno, consulta la tabella per sapere a quale host interno e su quale porta inviarlo. Il router NAT deve quindi tenere traccia di tutte le connessioni TCP e UDP attive tra la rete interna e quella esterna (e preoccuparsi di eliminare le voci inutilizzate da questa tabella mediante un meccanismo di scadenza).
Quindi se non hai configurato il NAT del router, se la comunicazione inizia dal dispositivo sotto il router vero il dispositivo su IP pubblico dovrebbe essere possibile per il dispositivo dall’IP publico reinviare i dati indietro al dispositivo su IP privato. Certo devi essere certo di utilizzare sempre le stesse porte perchè se rispondi verso una porta diversa da quella da cui è partita la comunicazione il pacchetto è bloccato dal router.
Il fatto che con il PC funzioni potrebbe essere legato a chi inizia per primo la comunicazione durante i test che hai eseguito è possibile ?
Per capire dove stesse realmente il problema ho implementato sullo SlimLine un semplice client NTP che si connette al server dell’INRIM e tutto pare funzionare bene.
Alla fine sembra più un problema di protocollo, probabilmente qualche dispositivo lungo il cammino del pacchetto ne provoca l’eliminazione in virtù di qualche controllo. Il server che stavo utilizzando per i test al momento non faceva altro che rispedire la richiesta inviata dal controllore; è bastato modificare un byte del messaggio ed il recapito è avvenuto correttamente.
- Devi essere connesso per rispondere a questo topic.