Internet on the fieldbus-side

[COswald]

Good Morning Hattersheim,

my problem is, that I have a Industriel PC behind the NIOT-E-TPI51-EN-RE and this is not able to access the Internet.
This would be great for normal situation, but we have to be able to do so.

What is special here? We don't use the fieldbus side in ProfiNet-Mode, but in LAN-Mode via the LAN-Enabler Docker-Container.
I have also installed the TOSIBOX-Soft-Lock, which is working fine. Without any special routes in the Gateway.
Is where something special with this?

Here are some screenshots of the LAN and route settings in the gateway:

   

   

I'm looking forward reply.

Kind regards,

Carsten Oswald

[Armin@netPI]

Well,

my explanation why the TOSIBOX container application works without any routing setup because it is always the initiator of the local TCP/IP traffic sent to the cifx0 interface and its connected devices behind. This is just a standard communication between two local IP addresses where no routing information is needed but just the two IP addresses and no gateway firewall is blocking the access.

In your new use case now the initiator whereas is the PC sitting behind the cifX0. On this PC you need to configure a gateway first of all next to its IP address 192.168.1.x. This gateway needs to be set to the IP address of the cifx0 interface which 192.168.1.111. So all traffic of the PC outside the local network 192.168.1.x will be sent to this gateway address respectively cifx0 instead. As next you should also configure a DNS server on the PC. Usually a DNS server address 8.8.8.8 works fine. Else a simple "ping google.de" will not work on your PC since there is no name resolution configured.

Finally instead of configuring a cifx0 routing path as you did you have to configure the eth0 firewall on your Connect gateway accordingly:

   

That is all you need to do. This is not a routing problem since the default route is internally configured to eth0 anyway but a firewall problem. You have to trust the eth0 interface as NAT-trusted.

[COswald]

Hello Armin,

many thanks for your quick reply.
Yes, it was the NAT.
After enabling NAT support everything is good.
The TOSIBOX is also running.

Greetz from Haan,

Carsten

[COswald]

Hello Armin,

back  in this thread I have a incident wiht a second NetPI.

First of all: The first box is running fine. Then I have setup a second one to work as OPC UA server and TOSILOCK for CONTAINER.

• Setup three containers
  first to enable the netX Ethernet portssecond for the TOSILOCKthird for the OPC UA server in NodeJS on raspbian
     
  

• After setting up the TOSILOCK I can connect
     
  

• I can also ping the IP-address of the cifx0 via the TOSIBOX connection
     
  

• The Firewall also seams to be right
     
  

• But I'm not able to communicate with the PLC although it has the cifx0 IP-address as gateway.
     
  

I have compared all settings from 1st and 2nd box in the Portainer interface and can not see any errors.

Do you have any idea?

Kind regards for your help, stay healthy and a fine weekend!

Carsten

[Armin@netPI]

Hi Carsten,

what is the netPI system software version you are running on your new netPI? Make sure you have the version v1.2.2.0 up and running first of all.

You say you can ping 192.168.1.1 which is the address of the local cifX0 ... but how about pinging the remote IP address 192.168.1.100? Does this work also?

Also interesting is which gateway addresses you have configured for eth0 and cifx0 both. It is not allowed for example to have two gateway addresses configured at the same time cause then Linux does not know where route TCP/IP frames if they are not in the pool of local addresses.

Thx
Armin

[COswald]

Hello Armin,

I will make firmware update as first aid.
   

The device I want to reach has the IP 192.168.1.180. This works, if my Laptop is in the second port of cifx0. But not over TOSILOCK.
   

As in the NetPI that is o.k. i have not inserted a Gateway in the cifx0 setup.
   

I will come back after firmware update.

CU,

Carsten

[Armin@netPI]

Hi Carsten,

I feel the firmware update is the most important point here cause we upgraded the cifx0 behaviour specifically in the version 1.2.2.0.

If after the firmware update still no devices connected to any of the dual Ethernet ports "cifx0" are reachable, but you can ping them manually then I remember that there was something that needs to be setup in the TOSIBOX container to enable routing to the cifx0 subnet 192.1681.x ... but for this I am not the expert. It is more than half a year ago I worked with TOSIBOX.

Thx

[COswald]

Hello Armin,

the firmware update is making me crazy.I'm trying the third USB-Stick now.

• slow format as RECOVERY with FAT32
  
• unpack the "hilscher-niot-e-npi3-51-en-re-V1.2.2.0-recovery.zip" to the root of the USB-Stick
  
• shutdown the NIOT, wait until the ACT stops forever
  
• switch off
  
• plug in USB-Stick
  
• switch on
  
• wait for ACT LED to start blinking
  
• wait until ACT LED gets off forever
  
• cycle power
  

Im stuck, because the boatloader don't want to boot from the Stick.
After waiting, the old system is always coming on again.

As written, I'm getting crazy with this.

CU,

Carsten

[Armin@netPI]

Well I think your USB stick is not recognized well and hence you netPI isn't updated. From what you are describing everything is fine so far.

You can connect a HDMI cable to netPI's HDMI port an connect a monitor and watch ... there you are able to see if the device makes a normal boot and starts the netPI OS or if it says it is updating the OS while the USB stick is inserted. If the HDMI output says that the netPI is booting normal, the Raspberry Pi CPU was not able to detect the USB stick. The Raspberry CPU is very sensitive with USB sticks an their used USB contoller. It needs a USB controller chip that boot the USB stick in some milliseonds to get recognized.

Maybe you have a second USB stick.

[COswald]

Hello Armin,

yesterday afternoon, I took a closer look to the NIOT that is working and found, that this one also have v1.2.0.0 firmware. And here the TOSILOCK ist working fine.

   
   
   
   

Independent from the need to update the firmware, this didn't seam to stop working this solution. Unless, the hardware had a update in teh meanwhile and needs the firmware update to work.

CU later,

Carsten