ARP frames are never set unreachable about picotcp HOT 5 OPEN

@jelledevleeschouwer Is this something you can take a look at?

from picotcp.

Seems like it has something to do with DNS:
[Wed Oct 23 10:54:10.352 2019] DNS: sending query to 08080808
[Wed Oct 23 10:54:10.352 2019] Allocated buffer @200104b8, len= 93 caller: 00000000
[Wed Oct 23 10:54:10.352 2019] DEBUG MEMORY: 15 frames in use.
[Wed Oct 23 10:54:10.352 2019] ================= ARP REQUIRED: 1 =============
[Wed Oct 23 10:54:10.372 2019]
[Wed Oct 23 10:54:10.372 2019] Allocated buffer @200105b0, len= 42 caller: 00000000
[Wed Oct 23 10:54:10.372 2019] DEBUG MEMORY: 16 frames in use.
[Wed Oct 23 10:54:10.372 2019] QUERY: 0300000a
[Wed Oct 23 10:54:10.372 2019] Sending arp request.
[Wed Oct 23 10:54:10.372 2019] Discarded buffer @200105b0, caller: 00000000
[Wed Oct 23 10:54:10.388 2019] DEBUG MEMORY: 15 frames in use.
[Wed Oct 23 10:54:10.784 2019] Allocated buffer @200105b0, len= 342 caller: 00000000
[Wed Oct 23 10:54:10.803 2019] DEBUG MEMORY: 16 frames in use.
[Wed Oct 23 10:54:10.803 2019] No such port 67
[Wed Oct 23 10:54:10.803 2019] Discarded buffer @200105b0, caller: 00000000
[Wed Oct 23 10:54:10.803 2019] DEBUG MEMORY: 15 frames in use.

from picotcp.

@jelledevleeschouwer @danielinux
Seems like the problem is that 'pico_arp_queued_trigger' isn't called besides in 'pico_arp_add_entry'.

DNS query causes an ARP requirement, but when there is no incoming ARP communication, the frame and allocated buffer isn't discarded (as the ARP has been postponed, but the 'pico_arp_queued_trigger' is never called). I keep trying the DNS query, so the memory is 'empty' very fast.
Where should we call 'pico_arp_queued_trigger', or how should we solve this?

from picotcp.

@ThomasNauwelaerts, are you really sure that is your problem and not the postpone itself? I see something fishy in the pico_ethernet_send() function where the pico_arp_postpone() is called in which a frame is actually added to the frames_queued array. Could you please retest with the branch "dev_master_memleak"?

from picotcp.

@jelledevleeschouwer, I had a quick look at the solution you provided. I think it should work, but I'm unable to test this at the moment, sorry.
I already found a solution. Please find the patch below:
pico_arp_patch.txt

I added 'PICO_MAX_FAILURE_COUNT', to make this max count more safe.
I added 'pico_arp_queued_trigger' in the function 'pico_arp_get', so before adding a new request, existing requests are triggered.
I added
else { pico_frame_discard(f); }
in 'pico_arp_postpone', to make sure the frame is discarded when the failure is greater than max. This is needed, as the function calling the postpone cannot decide to discard the frame.

from picotcp.