PYNQ-Z1 point-to-point network connection failure

Support
1

Hello,

I’m experiencing some odd behavior with my PYNQ-Z1 board. After following the Getting Started guide as closely as I could, I am not able to establish an ethernet connection between the board and my host PC to access the Jupyter notebook.

My setup is as follows. Currently using Windows 10 after trying with Ubuntu 18.04 with no success. The PYNQ SD card image is the one that came with the board, I am not sure of the exact version. I have an Ethernet cable connected (I verified that it is actually connected), to the motherboard’s RJ45 slot of my PC. I have a USB cable connected to the board from my PC. I am able to successfully pull data over serial into PuTTY. The hardware jumpers, USB connection, and ethernet connection are consistent with the diagram provided in the setup guide. My browsers are OperaGX, Edge, or Firefox

The steps to reproduce are as follows. I ensure my machine is using a specified ipv4 address, as per the Windows instructions on the getting started guide. (The screenshot shows the address 192.168.2.13, I initially tried 192.168.2.1, but got curious to see if it would work with another address within the subnet. It did not)

image_2023-08-31_221053306
image_2023-08-31_2210533061173×677 45.6 KB

My advanced sharing settings are entirely open, all options under Private, Guest or Public, and All Networks are all set to “Turn on x”.

Network Discovery is given full permissions in Windows Defender Firewall. Public and Private boxes are checked.

I am able to pull data over serial using PuTTY. Invoking ip a and ifconfig throws the following:

xilinx@pynq:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group defaul                                                                                                                                                             t qlen 1000
    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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1                                                                                                                                                             000
    link/ether 82:80:46:67:0e:99 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP gr                                                                                                                                                             oup default qlen 1000
    link/ether 00:18:3e:04:5a:19 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:3eff:fe04:5a19/64 scope link
       valid_lft forever preferred_lft forever
4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
xilinx@pynq:~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.137.158  netmask 255.255.255.0  broadcast 192.168.137.255
        inet6 fe80::218:3eff:fe04:5a19  prefixlen 64  scopeid 0x20<link>
        ether 00:18:3e:04:5a:19  txqueuelen 1000  (Ethernet)
        RX packets 57  bytes 6388 (6.3 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 58  bytes 8576 (8.5 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 34  base 0xb000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 489  bytes 42434 (42.4 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 489  bytes 42434 (42.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

xilinx@pynq:~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.137.158  netmask 255.255.255.0  broadcast 192.168.137.255
        inet6 fe80::218:3eff:fe04:5a19  prefixlen 64  scopeid 0x20<link>
        ether 00:18:3e:04:5a:19  txqueuelen 1000  (Ethernet)
        RX packets 95  bytes 8518 (8.5 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 111  bytes 17950 (17.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 34  base 0xb000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 975  bytes 77186 (77.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 975  bytes 77186 (77.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Which is incredibly interesting. At first, eth0 is not assigned an ipv4 address, then it magically generates an ipv4 address inconsistent with the default 192.168.2.99. Recalling either ip a or ifconfig will either display the eth0 interface with or without an ipv4 address. Sometimes, the correct default address is displayed, 192.168.2.99. Other times, the incorrect address or no address at all is displayed. Attempting to connect to the 192.168.137.158 address via a browser yields a connection failed error, much like any attempt to connect to the default address 192.168.2.99.

Pinging the board from the host gives the following:

Microsoft Windows [Version 10.0.19045.3324]
(c) Microsoft Corporation. All rights reserved.

C:\Users\davwa>ping 192.168.2.99

Pinging 192.168.2.99 with 32 bytes of data:
Reply from 10.199.4.100: TTL expired in transit.
Reply from 10.199.4.100: TTL expired in transit.
Reply from 10.199.4.100: TTL expired in transit.
Reply from 10.199.4.100: TTL expired in transit.

Ping statistics for 192.168.2.99:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:\Users\davwa>

Which suggests the host PC can successfully communicate with the board in some respect.

Pinging the host from the board gives the following (with 192.168.2.13 set as the machine’s static address):

xilinx@pynq:~$ ping 192.168.2.13
ping: connect: Network is unreachable

I began to think it was a jupyter issue. Calling jupyter lab list from the board gives the following:

xilinx@pynq:~$ jupyter lab list
Currently running servers:

Calling systemctl status jupyter.service from the board gives the following:

xilinx@pynq:~$ systemctl status jupyter.service
● jupyter.service - Jupyter Notebook Server
     Loaded: loaded (/lib/systemd/system/jupyter.service; enabled; vendor prese>
     Active: active (running) since Mon 2023-06-05 21:37:03 UTC; 30min ago
    Process: 278 ExecStart=/usr/local/bin/start_jupyter.sh (code=exited, status>
      Tasks: 2 (limit: 874)
     Memory: 105.9M
4 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 489  bytes 42434 (42.4 KB)/bin/python3 /usr/local/share/pynq>
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I’m honestly not too sure how jupyter works, but I saw these two commands in another forum post similar to this problem and figured it would be information worth sharing. I assume this return means the jupyter server is running as expected.

I am not sure how to interpret this issue. Please let me know if there is anything I did wrong or any further information I can provide. Thank you very much for reading.

David

1 Like
2

Hi @davwamai,

Welcome to the PYNQ community.

First, I would suggest you to update to get the latest SD Card of PYNQ. PYNQ - Python productivity for Zynq - Board

It is odd, because eth0 in the PYNQ-Z1 board is 192.168.137.158, which is outside the subnetwork you setup on Windows. You could update the IP in Windows to something like this 192.168.137.2 and hopefully this should work. Note, that you need to access the PYNQ-Z1 with the IP 192.168.137.158

Mario

1 Like
3

Mario,

Connecting to the board with the 192.168.137.2 static ip ended up working. I was so tired when writing the forum post that I completely forgot to change the static IP on my PC to match the IP subnet assigned to the board.

There are other odd things happening, however. I can successfully connect to the board with no problems around 30s to 2 minutes after the boards boot process has finished and the DONE light is turned on. A few minutes into messing around in the Jupyter notebook, I get a netwrok error in my browser saying something along the lines of “The Jupyter notebook has lost connection, it will continue to try to re-establish the connection in the meantime.”

To investigate, I accessed the board through PuTTY and called ifconfig:

Welcome to PYNQ Linux, based on Ubuntu 22.04 (GNU/Linux 5.15.19-xilinx-v2022.1 armv7l)

Last login: Mon Jun  5 21:36:39 UTC 2023 on ttyPS0
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

xilinx@pynq:~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.137.158  netmask 255.255.255.0  broadcast 192.168.137.255
        inet6 fe80::218:3eff:fe04:5a19  prefixlen 64  scopeid 0x20<link>
        ether 00:18:3e:04:5a:19  txqueuelen 1000  (Ethernet)
        RX packets 58  bytes 6710 (6.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 63  bytes 9488 (9.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 34  base 0xb000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 488  bytes 42446 (42.4 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 488  bytes 42446 (42.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

xilinx@pynq:~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::218:3eff:fe04:5a19  prefixlen 64  scopeid 0x20<link>
        ether 00:18:3e:04:5a:19  txqueuelen 1000  (Ethernet)
        RX packets 3191  bytes 291797 (291.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5922  bytes 8265399 (8.2 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 34  base 0xb000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 3487  bytes 297753 (297.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3487  bytes 297753 (297.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The first call to ifconfig was made very soon after I connected the board to the PC and successfully accessed the Jupyter notebook. The second call to ifconfig was made after the error saying the Jupyter notebook lost connection was thrown. You’ll notice in the first ifconfig call that the ipv4 address is present, and in the second the address is not there.

After a few minutes the connection was reestablished, so I am assuming this is normal. If this is not the case, then I will go ahead and re-etch an update PYNQ image onto the SD card.

Thank you very much for your reply,
David

1 Like
4

The connection shouldn’t drop.

I suggest you reflash the SD card with the latest image.

Mario