Hi Fotis, Besides its name the simhostroute.sh is using the bridge mode (look inside the script).
I tested today few minutes ago and it is not working, I should have documented my config and all the steps. Maybe this article could help you: https://eadalabs.com/esp32-nuttx-and-bridged-networking/ BR, Alan On 9/2/22, Fotis Panagiotopoulos <f.j.pa...@gmail.com> wrote: > 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 >> >
