I'm having a bit of an issue when it comes to exchanging network packets with QEMU via the TAP interface "zeth" as set up by net-setup.sh.
When building the TCP socket echo server demo for the qemu_x86 target with the e1000 driver enabled within Zephyr and -nic tap,model=e1000 passed to QEMU (Ethernet mode, SLIP driver disabled), the TAP interface works as expected while QEMU is running. When building the same application for the qemu_cortex_r5 target (which simulates the UltraScale RPU on the Xilinx ZCU102 board) using my Xilinx GEM network driver, in this case the QEMU networking parameter is -nic tap,model=cadence_gem, there's an odd effect I can't really make any sense of. When I ping the IP address used by Zephyr, an ARP request is sent, an ARP reply is received, "arp -i zeth" on the host side shows the correct MAC/IP tuple. These packets show up in Wireshark which is running at the same time acquiring all traffic on the zeth interface.
Afterwards, the ICMP echo request is sent by the Linux host, Zephyr receives it and generates a reply (visible both as hexdump on the Zephyr console and within Wireshark). As more requests and replies are sent, the seq number in the ICMP packets increases, each reply packet's seq matches that of the previous request. Yet, the ping command on the Linux host doesn't receive this data. The output generated by ping is always "x packets transmitted, 0 received, 100% loss". Yet, when calling ifconfig, a non-zero packet count is shown for both RX and TX, and those numbers match the packets logged by Wireshark. Ifconfig also shows that for both RX and TX, there were no errors, no overruns, no packets dropped and no collisions. The same phenomenon can be observed when trying to connect to the port opened by the echo server using PUTTY: the SYN packet is sent by the host, Zephyr generates the SYN/ACK reply, again visible in Wireshark, the calling application doesn't receive the data and sends another SYN packet multiple times, to which Zephyr replies with RST/ACK each time. PUTTY eventually indicates a timeout.
I'm at a loss as to why all packets are visible within Wireshark, so therefore, the zeth interface seems to work as expected, but the data in the Zephyr->host direction isn't handed over to the calling application, which works fine on the x86 target. I eventually suspected a bug within QEMU itself and built the latest version (both from the main repo and the Xilinx branch) from source, unfortunately, this didn't solve the problem. Has anyone ever observed this problem before when running a networking-enabled Zephyr application within QEMU?