Author Topic: bug in fnHandleIP  (Read 6320 times)

Offline guibiao

  • Newbie
  • *
  • Posts: 10
    • View Profile
bug in fnHandleIP
« on: April 02, 2013, 12:02:35 AM »
Hi, Mark. I use uTasker TCP/IP stack in my project. in the function fnHandleIP of file ip.c, the last part of the codes list like this:

if (uMemcmp(received_ip_packet->source_IP_address, cucBroadcast, IPV4_LENGTH)) { // Add the address to ARP cache as long as not broadcast
        fnAddARP(received_ip_packet->source_IP_address, frame->ptEth->ethernet_source_MAC, ARP_TEMP_IP);
    }   
       
    if (received_ip_packet->fragment_offset[0] & (IP_MORE_FRAGMENTS>>8)) return(0); // fragmented packets not supported
    *usTotalLength = tLen;     
    return (IP_MIN_HLEN + olen);                                         // return length of IP header

Do you think in the first line, it should be
received_ip_packet->destination_IP_address,

instead of

received_ip_packet->source_IP_address



Thanks,

Guibiao

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: bug in fnHandleIP
« Reply #1 on: April 02, 2013, 12:12:13 PM »
Hi Guibiao

I think that the check is correct because it is entering the source address into the ARP cache. There can be IP frames with a broadcast IP destination but the source IP still corresponds to the sender - in this case the address will be entered into the cache (example is when the source sends an ARP resolution).
If this were filtered due to the fact that the source had sent a broadcast it would not be possible to answer back to the request without first also having to send out an ARP to find out what the MAC address is to send it back to.

Regards

Mark


Offline guibiao

  • Newbie
  • *
  • Posts: 10
    • View Profile
Re: bug in fnHandleIP
« Reply #2 on: April 02, 2013, 04:14:03 PM »
Hi, Mark. Thanks for the quick response. If it is right,

1. The check does not make any sense: the source IP can never be broadcast;

2. The stack will pickup any broadcast packets, and save its source IP ARP info in its limited cache, and flush the cache regularly. That is what happen to my project. I end up have to do ARP very often: less than 1minute (the refresh timeout). Can you send me a copy of your recent ip.c file. I don't think I got any service pack lately. Thanks!

Guibiao

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: bug in fnHandleIP
« Reply #3 on: April 02, 2013, 08:51:03 PM »
Hi Guibiao

It is probably true that the IP source is never a broadcast address but I think that the check is for security - to be sure. If it were to happen, the entry would be entered and it may cause a problem with the fixed broadcast entry which is permanently in the table.

In some cases it may be required to enter also broacast addresses into the cache (there may be an application that wants to know such information) however if you enable ARP_IGNORE_FOREIGN_ENTRIES it will not enter these and so stop the available cache filling up unnecessarily - I expect that you have this in your version since it was added on 21.08.2007 (in arp.h). I have however however sent my latest arp.c and ip.c to your email address. You can download the latest project version from the sticky topic at the start of the processor's board.

Regards

Mark