• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
RTE3 Use real time ethernet as "normal" ethernet interface
#21
I was surprised as well, to see the adapter there.


Quote:Just let me ask you this. Do you use the network mode "host" when you start your container?


Yes, I am using "host" as network type.



Quote:I made tests with the new container and set the ip settings via the environment variables. I set IP_ADDRESS to 192.168.0.1 and SUB_NETMASK to 255.255.255.0 and when I jump into the container with a shell and call "ip addr show" it says 192.168.0.1/24 as it should. I don't see the subnet mask misconfigured.



When using "192.168.0.1" as IP_ADRESS, I get the expected behaviour with 255.255.255.0 as Subnetmask. But when I use "10.7.1.115" as IP-Adress, the subnetmask is setted wrongly to "255.0.0.0".
 

What happens to you, if you use my configuration?



Code:
address 10.7.1.115
network 255.255.255.0
gateway 10.7.1.1


Thanks!
Andi
  Reply
#22
Hi Andi,

the network mode "host" is not supported with this feature.
Mapping into the host system leads to conflicts between the network manager of the host and that of the container.


Excerpt from the Manual (https://github.com/HilscherAutomation/ne.../README.md):
"Limitation
...
Servicing the cifx0 interface is only possible in the container it was created. It is not available to the Docker host or to any other containers started.
…"

Best regards
Patrick
  Reply
#23
Hey Patrick,

Quote:the network mode "host" is not supported with this feature.

I have tried to use a user-defined-network using driver "bridge" and the pre-defined "bridge" network, but I get the same result as using network-type "host".
The IP-Adress shown with "ip add show" is "10.7.1.115/8".

Have you tried to use the following configuration and reached the expected behaviour?


Code:
address 10.7.1.115
network 255.255.255.0
gateway 10.7.1.1

Thanks,
Andi
  Reply
#24
I can confirm that I see the same result as you do with your settings.

It needs further investigations why this happens. We have no explanations right now.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#25
Problem has been found. The github source code project as been updated.

The DockerHub repository is triggered for an automatic update already. DockerHub will need time to build a new tag.

Monitor the repo's tag site https://cloud.docker.com/repository/dock...t-lan/tags if there is a new tag pushed. Patiently wait.

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

  Reply
#26
Thanks for the update!

When using the following configuration:

Code:
IP_ADDRESS 10.7.1.115
SUBNET_MASK 255.255.255.0
GATEWAY 10.7.1.1

I get these results now:


Quote: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: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:02:a2:49:bc:f0 brd ff:ff:ff:ff:ff:ff
    inet 10.7.1.115/24 brd 10.7.1.1 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



For me, it looks like something is still not right, cause the broadcast is "10.7.1.1" instead of "10.7.1.255"?

Also, I cannot find the route of the standard gateway, when checking "ip route show":


Quote:default via 172.18.0.1 dev eth0
10.7.1.0/24 dev cifx0 proto kernel scope link src 10.7.1.115 linkdown
172.18.0.0/16 dev eth0 proto kernel scope link src 172.18.0.2

Is this missing, or do I need to check somewhere else?

Tanks,
Andi
  Reply
#27
Andi, I see that routing is not being set in the current code and that the broadcast address is calculated wrong. Code needs one further correction.
Investigation unfortunately cannot happen before april 23. sorry
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#28
I corrected the issue with the broadcast address offline. Can’t test it. The issue with the routing and missing gateway is still present and needs further investigation
Thx
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#29
Hey Armin,

now I get the following error when trying to start up the container:
  

Quote:/etc/init.d/entrypoint.sh: line 35: unexpected EOF while looking for matching `"'

/etc/init.d/entrypoint.sh: line 49: syntax error: unexpected end of file


I found the error, therer are wrong kind of quotation marks in the bash-script in line 34:


Quote:     IFS=. read -r i1 i2 i3 i4 <<< "$IP_ADDRESS


could you please fix this?

For the standard-gateway I will than wait until after easter.

Thanks!
Andi
  Reply
#30
You are right. Have it corrected now. Dock hub is building the image right now
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Modbus TCP Connection via RTE Ethernet Ports Flo_Lo 18 476 April-15th-2019, 09:50 PM
Last Post: Armin@netPI
  [SOLVED] Use netX interface as profinet controller jromero248 2 53 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 110 June-20th-2018, 08:38 AM
Last Post: Armin@netPI
  What is needed to be a PROFINET slave (RTE3) jkohlmann 1 104 March-7th-2018, 06:31 AM
Last Post: Armin@netPI
  NTP setup (Network time protocol) zulliger@software-natives.ch 1 98 February-7th-2018, 09:05 PM
Last Post: Armin@netPI
  Web browser reports "insecure connection" when accessing netPI for the first time Armin@netPI 0 82 December-3rd-2017, 01:40 PM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 1 Guest(s)