• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
RTE3 Use real time ethernet as "normal" ethernet interface
#31
When I am back to the office and able to test I will add the following three lines to support the routing as well:
Code:
NETWORK=$((i1 & m1)).$((i2 & m2)).$((i3 & m3)).$((i4 & m4))
ip route add $GATEWAY dev cifx0
ip route add $NETWORK/$SUBNET_MASK via $GATEWAY dev cifx0
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#32
Thanks, now the IP-Adress and Subnet-Mask are working correctly with the posted configuration.

BR,
Andi
  Reply
#33
Hey Armin,


have you tried to add the routing already?

Thanks,
Andi
  Reply
#34
No, will do it after my vacation next week. I have no test system with me and don’t want to hack in untested stuff.
Have you tried the three commands I sent as code extract and can you share your experiences with it? Then the implementation has been verified by an independent person
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#35
Routing is now implemented.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#36
Hey Armin,

sorry for the late response, haven't been in office.

The routing talbe still looks the same as before:

Code:
root@2fc071664fb9:/# ip route
default via 172.17.0.1 dev eth0
10.7.1.0/24 dev cifx0 proto kernel scope link src 10.7.1.115
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2

Maybe it's because of the errors in the log-file:


Code:
starting ssh ...,
Starting OpenBSD Secure Shell server: sshd.,
Waiting for added 'cifx0' network interface ... ,
'cifx0' network interface is now ready,
cifx0 ip address/subnet mask set to 10.7.1.115/255.255.255.0,
RTNETLINK answers: Network is down,
RTNETLINK answers: Network is unreachable,


Any idea what went wrong? Still using the same configuration as written before.

Thanks,
Andi
  Reply
#37
Hello Andi,

I see the same effect like you do. I tried to understand the root cause of the error "RTNETLINK answers: Network is down" and I have learned that using an "ip route" command on any interface needs to have it in "up" state before the command can be used. This is not how it is realized today. I never saw this problem cause my interface was "up" always and hence all "ip route" commands worked right away.

Meanwhile I am getting this in my container when I am using your IP setup

Code:
root@b8e92e0e5baf:/# ip route
default via 172.17.0.1 dev eth0
10.7.1.0/24 via 10.7.1.1 dev cifx0
10.7.1.1 dev cifx0 scope link
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2

Is it how it shall look like?
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#38
Container updated

Getting this output now
Code:
root@e7dec71e8429:/# ip route
default via 172.17.0.1 dev eth0
10.7.1.0/24 via 10.7.1.1 dev cifx0 src 10.7.1.115 linkdown
10.7.1.1 dev cifx0 scope link linkdown
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#39
Hey,

I get the same output now. The Problem that now occurs is that the "bridged" network mode is not working.

the IP-Adresses look like this:


Code:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: cifx0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:02:a2:49:bb:d0 brd ff:ff:ff:ff:ff:ff
    inet 10.7.1.115/24 brd 10.7.1.255 scope global cifx0
       valid_lft forever preferred_lft forever
8: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:12:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.18.0.2/16 brd 172.18.255.255 scope global eth0
       valid_lft forever preferred_lft forever


As you can see, the eth0 is using an IP-Adress, which is located within the subnet of the Network-Bridge. The docker-network-bridge than connects this IP-Adress to the host's IP-Adress of this adapter.

The cifx0 adapter directly gets the IP-Adress, which shall be used for remote communication and not that of the internal Network-Bridge, which is right?

If I connect the netPi over a switch with another device within the same subnet, I cannot ping either the device from within netPi's container, nor the netPi from the device, using 10.7.1.115 as IP-Adress. Could it be that docker is somehow prohibiting the communication or that it gets stuck within the container?

Have you been able to ping another device using the cifx0-adapter?


Thanks,
Andi
  Reply
#40
Well Andi,

you configured the gateway 10.7.1.1 and this is how it is configured now.

So once you call just "ping 10.7.1.20" for example within the container, the ethernet protocol will send an ARP telegram from 10.7.1.115 to the IP address 10.7.1.1 to ask for the MAC address of 10.7.1.1 first of all. And if the 10.7.1.1 device does not exits, then the ping command will not get back any response and hence will fail.

Are you sure you have a gatewas running at 10.7.1.1?

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  normal ethernet port using for Profinet MGharat 4 28 August-7th-2019, 10:39 AM
Last Post: hannes
  Launching multi-containers at a time - Docker stacks Armin@netPI 0 21 June-4th-2019, 04:11 PM
Last Post: Armin@netPI
  niot-e-npi3-51-en (RS485 <-> Industrial Ethernet) merklethomas 6 55 April-26th-2019, 01:38 PM
Last Post: Armin@netPI
  Modbus TCP Connection via RTE Ethernet Ports Flo_Lo 18 478 April-15th-2019, 09:50 PM
Last Post: Armin@netPI
  USB/Ethernet adapter slos 4 51 April-8th-2019, 09:11 AM
Last Post: slos
  [SOLVED] Use netX interface as profinet controller jromero248 2 60 January-10th-2019, 12:30 PM
Last Post: jromero248
  IP Realtime Ethernet michu252 7 323 August-21st-2018, 10:41 AM
Last Post: Armin@netPI
  EtherCAT Slave OP mode (netPI RTE3) mauroriva 1 112 June-20th-2018, 08:38 AM
Last Post: Armin@netPI
  usage of hilschernetpi/netpi-netx-ethernet-lan is working but costs 25% cpu power Michael_d 7 158 March-9th-2018, 10:52 AM
Last Post: Michael_d
  What is needed to be a PROFINET slave (RTE3) jkohlmann 1 105 March-7th-2018, 06:31 AM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 1 Guest(s)