• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 3090 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C129XNCZAD: DK-TM4C129X does not send out a gratuitous arp when its ethernet link up

chihyu wang
Prodigy 25 points
Part Number: TM4C129XNCZAD

Hi all,

I am using DK-TM4C129X with TivaWare_C_Series-2.1.4.178\examples\boards\dk-tm4c129x\enet_io.

I make the following changes to test IPADDR_USE_STATIC with static IP 192.168.127.1.

In lwipopts.h

#define LWIP_DHCP                       0
#define LWIP_AUTOIP                    0

In enet_io.c
lwIPInit(g_ui32SysClock, pui8MACArray, 0xC0A87F01, 0xFFFFFF00, 0, IPADDR_USE_STATIC);

I use a computer with Win7, Wireshark, Intel CPU and Intel I210 NIC.

I connect DK-TM4C129X to I210 with an ethernet cable.

According to third_party\lwip-1.4.1\src\core\netif.c,

every time etharp_gratuitous(netif) is called (ethernet link up), a gratuitous ARP should be captured in my Wireshark but it did not happen.

Only when I set a break point to stop TM4C129XNCZAD at etharp_gratuitous(netif) thru CCS and resume, a gratuitous ARP can be captured in my Wireshark.

Could someone give me some suggestions ?

Thanks.

  • 0
    Guru 117855 points

    chihyu wang said:
    Could someone give me some suggestions ?

    Sorry (in advance) this day will prove hectic and I cannot resist.       ("Not fully awake" staff egging me on...)

    It is hoped that any/all suggestions will prove (more) "gratuitous" than your reluctant "arp."      (I'd help - but I'm WAY "out of my league" in this area...some may say, "any/all areas")

  • 0
    TI__Guru**** 190746 points
    Hi,
    What did you see on the wireshark? Did you see FF:FF:FF:FF:FF:FF in the Ethernet header being broadcasted when you run without using breakpoint?
  • 0 in reply to Charles Tsai
    Prodigy 25 points

    Hi Charles,

    No.

    The following ARP packet can only be captured when I run with a breakpoint.

    Thanks.

  • 0 in reply to chihyu wang
    TI__Guru**** 190746 points
    Hi Chihyu,

    I'm not too sure if you need to specifically call etharp_gratuitous in your application. A table of recent IP addresses and corresponding hardware addresses is maintained in an ARP cache table. If an outgoing packet does not match any known hardware address, the code will perform an ARP query on the link to discover the right address. This is supposed to be done transparently.

    Here are some links that talk about gratuitous ARP.
    http://lwip.wikia.com/wiki/ARP
    networkengineering.stackexchange.com/.../how-does-gratuitous-arp-work
    wiki.wireshark.org/Gratuitous_ARP

    Can you please try a few things?

    1. Do you see the same problem if you use DHCP?
    2. Put some delay after you call etharp_gratuitous and see if this has any effects.
    3. Can you set a GIO pin right before you call etharp_gratuitous and clear the pin after the call? Kind of wanting to make sure the function is entered.
  • 0 in reply to Charles Tsai
    Guru 117855 points

    Charles Tsai said:
    3. Can you set a GPIO pin right before you call etharp_gratuitous and clear the pin after the call?    Kind of wanting to make sure the function is entered.

    Would not (some) such GPIO exercise "within" etharp_gratuitous (especially when placed/set "early" - and then cleared "late" - w/in the function's code) - rather than (just) before/after the function's call - provide (even) stronger proof of, "Function entry?"

  • 0 in reply to cb1_mobile
    TI__Guru**** 190746 points

    Hi cb1,

     Thanks for the suggestion. Putting the toggle before/after the function will not know if the function is entered but immediately exited without truly executing any ARP task. So placing the toggle inside the function strategically is a good point. The etharp_gratuitous() is a macro for etharp_request(). The poster may need to go deeper into etharp_raw to find out why the ARP is not sent. I will suggest the poster to first check the returned code for err_t to see why the ARP isn't successful the first time. 

     err_t
etharp_request(struct netif *netif, ip_addr_t *ipaddr)
{
  LWIP_DEBUGF(ETHARP_DEBUG | LWIP_DBG_TRACE, ("etharp_request: sending ARP request.\n"));
  return etharp_raw(netif, (struct eth_addr *)netif->hwaddr, &ethbroadcast,
                    (struct eth_addr *)netif->hwaddr, &netif->ip_addr, &ethzero,
                    ipaddr, ARP_REQUEST);
}