Network failure running nmap against board

Libraries
1

I am running version 2.4.0 of FreeRTOS+TCP on a Renesas EK-RA6M5.
I’m using the quickstart demo with static ip.
The phy I’m using is the ksz8091.

Testing the stability of the FreeRTOS plus TCP stack:
When I run nmap against my static ip, if there’s no listening socket, it completes as expected.
(And my UUT responds to ping packets)

When I start a thread that starts a listening socket and run nmap, the unit won’t
respond to pings.
In the debugger the mac appears to have stopped generating interrupts.
(consequently, won’t respond to ping)

If I pull and re-seat the ethernet cable, the mac starts generating interrupts again.
(responds to ping again)
Is this a known issue?

I don’t know the problem is with SYN packets necessarily; since it appears to be the mac has
stopped generating interrupts and can be reinitialized. But so far, the problem only appears
to happen when I run nmap against the ip address with an open socket.

2

Where did the MAC driver come from?

3

It is integrated into the RA6M5 chip.

I tried to paste the link to Renesas, but links aren’t allowed.

4

Richard means the MAC software driver, the custom part of the network stack below FreeRTOS+TCP controlling the MAC peripheral of the MCU.

5

My bad.

I’m not sure I know how to identify where the MAC software driver is.
All the code came from e2 studio running FSP 4.4.0.
(The PHY driver is r_ether_phy_target_ksz8091rnb.c, maybe from FreeRTOS, or Renesas)

My original statement is based off line 217 of vEtherISRCallback in NetworkInterface.c.
if (p_args->status_eesr & ETHER_EDMAC_INTERRUPT_FACTOR_RECEPTION)

In a fault state, I stop hitting my break-point here.

6

is custom/provided by 3rd party and also the MCU specific NetworkInterface.c.
My guess: The MAC driver (implemented in NetworkInterface.c) has a problem resp. is buggy.
nmap might cause high packet load on the device revealing some corner case problems of the driver.

7

Makes sense.

It appears that xNetworkInterfaceInitialise sets up an interface provided by Renesas.

So it sounds like this hasn’t been seen yet and may be in their mac driver?

I have already found that by commenting “vTCPStateChange( pxReturn, eSYN_FIRST );”
in FreeRTOS_TCP_IP.c, it won’t break, but that just means something downstream isn’t
working.

Any recommendations how I should debug something as dynamic as this?

And thanks for taking your time for all your answers.

8

[I just updated your forum status to enable you to post links]

9

Thanks,

the link was:

But you were talking about the MAC driver anyway, not hardware.

10

Hi @ddeyo,
Could you help to enable ipconfigHAS_PRINTF and configPRINTF to see if we can get any info from log?
Besides that, there is a discussion in Renesas forum about RA6M5 network interface. Could you help to try with the solution of it?

Thanks.

11

Hi @ddeyo ,
2 things can be done here:

  1. Capture the ethernet frames using wireshark and see what is exactly happening when the issue occurs.
  2. Take a dump of MAC registers when everything is running fine and in issue state and compare the same.
    These mostly likely will give some good pointers.

Thanks,
Shub

12

Hello ActoryOu,

The link you provided definitely prevents the problem I am seeing, thank you.

Do you mean you want me to help with ipconfigHAS_PRINTF? Or were just suggesting
that I enable ipconfigHAS_PRINTF to get more information?

And would you have me to help with the problem in the link,
or were you asking me to try it out?

13

Hello Shub,

I have done a wireshark captures on a simple nmap using one port (succeeded) and on
a sequence of ports (failed).

It looks like there may be a problem with multiple threads/sockets. The problem
happens when an open port is found. The SYN-ACK packet never gets sent back and
consequently the side that started the SYN never sends an RST packet.

The link sent by ActoryOu provided a way to prevent the problem.

thanks,

-dwd

14

@Shub Please ensure the fix gets merged into the mainline - thanks.

1 Like
15

It’s great to know you’ve tried the solution from the link, and it works!
We’ll merge the patch back to FreeRTOS-Plus-TCP repo.

Thanks.

Update: We don’t have NetworkInterface.c for RA6M5 in FreeRTOS-Plus-TCP.
@ddeyo Where do you get that file? Is it generated by FSP?

16

Sure @rtel, we will.

@ddeyo Thanks for confirming the fix.

17

Not a problem, I thank everyone for their help.