About ether_output() function in if_etheresubr.c

[Albert Chun-Chieh Huang]

Hi, all,

I'm currently working on adding a network device driver to rtems. The
source tree was grabbed on July, 2014. It's still not working properly
right now. But I have some questions about the network stack code.

I added printf function in if_etheresubr.c in the directory
cpukit/libnetworking/net/ as the following:
int
ether_output(struct ifnet *ifp, struct mbuf *m,
    struct sockaddr *dst, struct rtentry *rt0)
{
    short type;
    int s, error = 0;
    u_char  edst[6];
    register struct rtentry *rt;
    struct mbuf *mcopy = (struct mbuf *)0;
    register struct ether_header *eh;
    int len = m->m_pkthdr.len;
    struct arpcom *ac = (struct arpcom *)ifp;
#ifdef NETATALK
    struct at_ifaddr *aa;
#endif /* NETATALK */

    if ((ifp->if_flags & (IFF_UP|IFF_RUNNING)) != (IFF_UP|IFF_RUNNING))
        senderr(ENETDOWN);
    printk("ether_output: length = %d, if_flags = 0x%08x\n", len,
ifp->if_flags);
========================================

And I got the following messages when I ping the RTEMS system on ARM:
=======================================================
ip_output 0, length = 84, MTU = 1500
ether_output: length = 84, if_flags = 0x00000847
ether_output: length = 28, if_flags = 0x00000847
if_ethersubr.c: m_len = 28, leading space = 68
if_ethersubr.c: MSIZE = 128, MLEN = 104
if_ethersubr.c: m_len = 42
=======================================================

During this period of time, there are only two kinds of packets, one is
PING(echo reply), the other is ARP; the one with 84 bytes is PING, and the
one with 28 is ARP, both will be added 14 bytes of Ethernet header later,
and makes them 98 bytes and 42 bytes.

Here, ether_output() was called twice when a PING is sent from IP layer. Is
it normal? I didn't get PING reply from this board. And I just want to make
sure if ether_output being called twice normal or not, so that I can decide
which way to go.

Thanks in advance.


Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150317/701114c7/attachment.html>