Ethernet is not working if DHCP configured port is unplugged about meta-iot2050 HOT 22 CLOSED

@BaochengSu, @AsuraZeng, have you seen this before?

@mwanders98, there is no difference in using the original release (with an older 4.19 kernel) and the current one in master?
Next I would have asked you to try the upstream queue - but this unfortunately requires an update of the firmware which is not recommended without a programmer at hand to restore in case of problems.

from meta-iot2050.

No, haven't seen such issue before.

We will try to reproduce it.

@mwanders98, could you please share us the /opt/configurator.sh or its equivalent so that we can reproduce it from our side?

from meta-iot2050.

I put the /opt/configurator.sh and the /etc/systemd/system/configurator.service into a gist.

I just tested this scripts with a fresh copy of IOT2050_Example_Image_V1.0.2.img.
I put both files on the system and did a systemctl daemon reload and systemctl enable configurator.service.

So then I have different configurations, whether the USB stick is inserted or not and whether the DHCP port is connected or not.
After each configuration change I reboot the device and test if the static configured ethernet port is "pingable" with the configured ip and I test dhcp too, if its connected.

The resulting behaviour is pretty confusing in my opinion. Sometimes it takes an eternity till the ports are accessible. Sometimes nothing works at all.

If you want to test it yourself, I would suggest you to open two terminals with a ping to the wan and lan ip's and to play a bit with the different configurations and to reboot each time.

Tomorrow, I will try this setup again with the newest image built by Github Actions from the main branch.

from meta-iot2050.

Do your issues always correlate with that "xmit timeout" errors on the kernel console?

from meta-iot2050.

Yes. I can see them in the syslog always.

from meta-iot2050.

@mwanders98 I saw from the scripts that the networking.service is managing the network, has the NetworkManager.service been disabled? Otherwise these two would conflict with each other.

The default network config tool for headless Debian buster is ifupdown, i.e. the networking.service belongs to. For our IOT2050 example image, to simplify the wireless network configuration, we use the Network Manager as the default configuration tool.

So if you are not using any wireless network technologies, or even don't mind the complexities of the wireless configuration, feel free to just disable the NetworkManager service.

from meta-iot2050.

Sorry for my late response. I deactivated the NetworkManager but the error still exists.
I tested this on the newest Debian image from Github Actions.

Do you have an alternative idea how I can configure the network configuration dynamically at boot time? For example I could run the script before any network related systemd services are starting up. My question here is which systemd target would be correct? The network-pre.target does not exist, if I remember correctly.

from meta-iot2050.

If you install ifupdown, you can configure networking the classic way. And even if NetworkManager is enabled, it will stay away from interfaces described that way.

But are you sure you could address/work around this issue at all via scripts? The timeout error of the kernel rather points to the driver or even lower, not the way how and by whom networking is configured.

from meta-iot2050.

The configuration itself works fine via /etc/network/interfaces.

No, I am not sure at all, just a naive idea from my side for a temporary workaround. I will try the ubuntu branch tomorrow or do you have another idea how to fix this?
You mentioned a firmware update, which firmware should I update to? And how to do it? I've seen an iot2050-firmware-update script..

from meta-iot2050.

Ubuntu will mean same kernel, possibly just a different NetworkManager version, but same (default) way of configuration.

We have no new firmware image to share that you can safely install. You can build own images from source, and those may work, but if they don't, you need a programmer to reflash a working image.

from meta-iot2050.

I downloaded the newest images from Github Actions artifacts, but it seems that they are shipping with kernel 4.19 not 5.x, is this correct?
So it looks like I didn't ever had a "new" image.

Therefore I tried to build the images myself but I ran into following issues:

| I: Extracting fdisk...
........
| I: Extracting liblzma5...
| I: Extracting zlib1g...
| I: Running command: chroot /work/build/tmp/work/iot2050-debian-arm64/isar-bootstrap-target/1.0-r0/rootfs /debootstrap/debootstrap --second-stage
| W: Failure trying to run:  mount -t proc proc /proc
| W: See //debootstrap/debootstrap.log for details
| W: Failure trying to run:  /sbin/ldconfig
| W: See //debootstrap/debootstrap.log for details
| WARNING: exit code 1 from a shell command.
| ERROR: Execution of '/work/build/tmp/work/iot2050-debian-arm64/isar-bootstrap-target/1.0-r0/temp/run.do_bootstrap.71' failed with exit code 1:
| I: Running command: debootstrap --arch arm64 --foreign --verbose --variant=minbase --include=locales,gnupg --components=main,contrib,non-free buster /work/build/tmp/work/iot2050-debian-arm64/isar-bootstrap-target/1.0-r0/rootfs http://deb.debian.org/debian
| I: Retrieving InRelease
| I: Checking Release signature
| I: Valid Release signature (key id 6D33866EDD8FFA41C0143AEDDCC9EFBF77E11517)
| I: Retrieving Packages
......
| I: Validating Packages
| I: Resolving dependencies of required packages...
| I: Resolving dependencies of base packages...
| I: Checking component main on http://deb.debian.org/debian...
| I: Retrieving libacl1 2.2.53-4
| I: Validating libacl1 2.2.53-4
........
| I: Extracting liblzma5...
| I: Extracting zlib1g...
| I: Running command: chroot /work/build/tmp/work/iot2050-debian-arm64/isar-bootstrap-target/1.0-r0/rootfs /debootstrap/debootstrap --second-stage
| W: Failure trying to run:  mount -t proc proc /proc
| W: See //debootstrap/debootstrap.log for details
| W: Failure trying to run:  /sbin/ldconfig
| W: See //debootstrap/debootstrap.log for details
| WARNING: exit code 1 from a shell command.
| 
ERROR: Task (/work/isar/meta/recipes-core/isar-bootstrap/isar-bootstrap-target.bb:do_bootstrap) failed with exit code '1'
NOTE: Tasks Summary: Attempted 154 tasks of which 80 didn't need to be rerun and 1 failed.

I tried the different build commands mentioned in the README, but neither works.
My build host is a Ubuntu vmware vm which is completely empty but was upgraded from 18.04 to 20.04.2 today.

Linux build 5.4.0-70-generic #78-Ubuntu SMP Fri Mar 19 13:29:52 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

What could fix this build error?

from meta-iot2050.

When sharing build issues, please make sure to also share the exact command line used to start the build.

Regarding 5.x kernels (upstream): You can build that already by appending :kas/opt/upstream.yml to the main yaml. However, it takes a newer firmware as well, and installing that my leave your device broken (see https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/README.md).

from meta-iot2050.

Hi, I'm also have the same issue with IOT2050 Basic.
If I connect the ethernet cable after the equipment boots. The ethernet port (configure as dhcp) don't get IP address.

Log:

root@iot2050-debian:~# tail -f /var/log/syslog
Feb 14 10:20:03 iot2050-debian ntpd[456]: error resolving pool 0.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Feb 14 10:20:04 iot2050-debian ntpd[456]: error resolving pool 1.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Feb 14 10:20:06 iot2050-debian ntpd[456]: error resolving pool 3.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Feb 14 10:20:07 iot2050-debian ntpd[456]: error resolving pool 2.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Feb 14 10:20:18 iot2050-debian kernel: [ 506.069328] icssg-prueth pruss0_eth eth1: Link is Up - 100Mbps/Full - flow control off
Feb 14 10:20:18 iot2050-debian kernel: [ 506.077327] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Feb 14 10:20:18 iot2050-debian NetworkManager[227]: [1550139618.4864] device (eth1): carrier: link connected
Feb 14 10:20:18 iot2050-debian kernel: [ 506.184856] icssg-prueth pruss0_eth eth1: cmd 8102000a: completion timeout
Feb 14 10:20:21 iot2050-debian ntpd[456]: Listen normally on 18 eth1 [fe80::8ef3:19ff:fe0a:e827%2]:123
Feb 14 10:20:21 iot2050-debian ntpd[456]: new interface(s) found: waking up resolver

from meta-iot2050.

But that works if the cable was plugged before booting?

Did you try with the latest image from CI here? Or with the released one? Any differences in behavior?

from meta-iot2050.

It works well if the cable is plugged before booting.
The image was build from the github commit from the date 2021-03-05.
I did not try with other image.

Update:
To mitigate this problem on the iot2050 that are already install. We change from dhcp to static ip address.

from meta-iot2050.

Problem still applies to V01.01.01 release?

from meta-iot2050.

Sorry for the late reply.
I download the V01.01.01 release from the siemens forum and I got the same issue.

from meta-iot2050.

I also have the same issue even with the recent release. Is there any resolution to this issue ?

from meta-iot2050.

@Vishal8523 Do you have the dmesg | grep pru log?

from meta-iot2050.

@BaochengSu

from meta-iot2050.

I've integrated the newer TI firmware that may fix this but not yet tested the outcome. Any feedback highly welcome!

from meta-iot2050.

According to our tests, the issue is resolved with the latest master version. Please reopen if that should not be the case.

from meta-iot2050.