Alan, is this guide for CONFIG_SIM_NET_HOST_ROUTE or CONFIG_SIM_NET_BRIDGE? I suppose it is the former. But according to the documentation, NuttX will not access the internet with CONFIG_SIM_NET_HOST_ROUTE, right?
Anyway, I tried with both configurations, but no, it is not working. I can ping the simulator, but it cannot send messages to the LAN or internet. Nathan, I tried to use TAPDEV_DEBUG, but it is not working. Syslog prints nothing within this driver. I mean, I can see with the debugger that the code there is executed. Syslog in itself is not working in this context. Anyway, I stopped spending time in the driver, because I think I have an idea of the issue. I used wireshark both on the bridge and the network interface. I can see the simulator sending packets to the bridge, but these packets do not appear on the netif! It seems that the bridge does not want to forward the traffic between tap and ethernet. I have spend hours on this, but I haven't managed to make this work. On Wed, Aug 31, 2022 at 4:38 PM Nathan Hartman <hartman.nat...@gmail.com> wrote: > On Wed, Aug 31, 2022 at 5:12 AM Fotis Panagiotopoulos > <f.j.pa...@gmail.com> wrote: > > I enabled all network prints. > > > > I can see some ARP packets being sent and received, but nothing else. > > I get a bunch of warnings like the following: > > > > netdriver_recv_work: WARNING: Unsupported Ethernet type 3465 > > > > (where the Ethernet type number is a different number every time) > > This warning is printed from netdriver_recv_work() in > arch/sim/src/sim/up_netdriver.c. > > The call to netdev_read() fills dev->d_buf, which is typecast to eth; > then, eth->type is a 2-byte code located in bytes 12 and 13 of > dev->d_buf. (See struct eth_hdr_s in include/nuttx/net/ethernet.h.) > > Since you're saying that the WARNING is printing a different number > every time, I wonder whether the read in tapdev_read() is filling the > buffer with random garbage. (Note: netdev_read() is a macro that > translates to tapdev_read() under your Kconfig settings.) > > Following this line of thought... There is a symbol that isn't defined > anywhere: TAPDEV_DEBUG. If this symbol is defined, then a function > dump_ethhdr() will be called in tapdev_read(). (If not defined, which > is the case now, then dump_ethhdr() is an empty macro.) It may be a > good idea to define this symbol to help track down this problem by > logging the received headers. The easiest way may be to temporarily > add -DTAPDEV_DEBUG to CFLAGS in the board's Make.defs, but it might be > better to rename this symbol to CONFIG_SIM_NETDEV_TAP_DEBUG and add it > to arch/sim/Kconfig, so that other developers can turn it on and off > easily. > > Now, in continuing to analyze where the data is coming from, I don't > understand the implementation of tun_read() in drivers/net/tun.c. It > looks like it will read data from the write buffer, or from the read > buffer, whichever it finds first. Isn't that a little bit strange? > Perhaps someone can explain how this implementation works. > > Without a setup to single-step through this logic, it's hard to > continue analyzing by reading code. Perhaps you could share more > details about your setup (and the defconfig produced by 'make > savedefconfig')? > > Cheers, > Nathan >
