URL: <https://savannah.nongnu.org/support/?111174>
Summary: Problem with LWIP and FreeRTOS on access to
arp_table
Group: Savannah Administration
Submitter: mazotcu16
Submitted: Sat 18 Jan 2025 09:36:25 AM UTC
Category: Savannah trackers - bugs, tasks, etc.
Priority: 5 - Normal
Severity: 3 - Normal
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Operating System: None
Open/Closed: Open
Discussion Lock: Any
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Sat 18 Jan 2025 09:36:25 AM UTC By: mazotcu16 <mazotcu16>
Hello, i didnt know how to categorize this question se excuse me if i am on
wrong one. We had a strange error that we think it should have been happened
to someone else and it is weird that there is nothing online.
When sending an IP package, if the target device is not working or not
connected, we are directed to etharp_query function. And in etharp_query
function,
if (arp_table[i].q != NULL) {
LWIP_DEBUGF(ETHARP_DEBUG | LWIP_DBG_TRACE, ("etharp_query: dropped
previously queued packet %p for ARP entry %"U16_F"\n", (void *)q, (u16_t)i));
pbuf_free(arp_table[i].q);
}
arp_table[i].q = p;
this piece of code made us a lot of problem. Because when we couldnt find the
target for specific IP address and a higher priority task tries the same, if
preemption occurs right after checking if the table is null, we put two
packets in arp_table and one is lost.
Here is exact scenario:
if (arp_table[i].q != NULL) line is executed by lower priority task, and there
is no packet, table is null.
Right after checking this, for same IP address, higher priority task also
checks the table in etharp_query function. Since there is nothing put on the
table yet, it sees the table as null and puts its own packet. When this ends,
lower priority task starts working again and since it already checked if the
table was null and it was null, it proceeds with putting its own packet in. So
the higher priority tasks packet is lost. We solved this by simply suspending
all tasks in all reachings to arp_table because while this caused %99 of the
problem, other functions that we free an arp_table index made some
confisiuns.
I just wanted to share this with comunity, thank you.
_______________________________________________________
Reply to this item at:
<https://savannah.nongnu.org/support/?111174>
_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/
signature.asc
Description: PGP signature
