RE: [ECOS] Newbie network problem

["Frank Pagliughi" <fpagliughi at mindspring dot com>]

Andrew,

BTW, thanks for all the help so far.

I'm with you on the second thought. The device doesn't appear to know it's
own MAC address. It appears to reply to any broadcast, but not to any packet
sent directly to it. But:

1. It's reading the MAC from EPROM and getting the proper value (I verified
the MAC with the Intel diagnostics, and matched the values that RedBoot
comes up with). The EEPROM checksum is also valid. Everything looks good
there.

2. It's got the correct value in eth_set_mac_address() and is placing that
correct value into the p_i82559->mac_address array. I can single step via
serial port Insight/GDB to verify.

3. The MAC address also matches the one being transmitted by the device any
time it sends out a packet (as verified by ethereal).


But, if I send a packet to that MAC from another computer, the device
doesn't even appear to generate an interrupt. Broadcasts to the subnet - no
problem. Direct to the device - nothing.

Man, this one's got me.

Frank

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch]
Sent: Friday, December 10, 2004 3:36 AM
To: Frank Pagliughi
Cc: Andrew Lunn; ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Newbie network problem


On Thu, Dec 09, 2004 at 04:00:09PM -0500, Frank Pagliughi wrote:
> Andrew,
>
> Thanks for the help. The local tests (ping_lo_test & tcp_lo_test) appear
to
> work fine.
>
> Now I'm trying to walk through the 'ping_test' and a little lost. The
> behavior I'm seeing is something of the following:
>
> -----
>
> When I run the app, over the first ~12 sec it throws out five ARP's to the
> server, each of which is matched by a reply to the device that the device
> does not appear to get. "recvfrom: operation timed out"
>
> The device then puts out five ARP's looking for the bogus host
> (192.168.0.33) which go unanswered and we see the "sendto: host is down"
> messages.
>
> The app thread then ends, "EXIT:<done>", but I leave the device running
> (with the network threads going).
>
> About 90 seconds later the server sends out a broadcast looking for a
> different computer entirely (but it's the first broadcast since the app
> ended).
>
> 100ms after that an ICMP Ping Request from the device appears on the wire!
> Followed by an immediate reply by the host.

This is interesting. It suggests one of two things....

The device is receiving the ARP responces but not passing them up the
stack until the broadcast message is received. This does not sounds too
likely.

The device does not receive packets which are addressed to it, but it
does receive broadcast packets. In theory the broadcast packet from
the server is enough to complete the ARP since it contains both the
MAC address and the IP address of the server. I don't know if the
stack actually does this thought. Anyway, once the ARP is complete it
can send out the ICMP it has queued waiting for ARP to finish.

I would go with the second one. I think the device does not know its
own MAC address. Where are you getting the MAC address from? Are you
configuring it or does it come from a serial EEPROM on the card?

Try enabling DEBUG_EE and DEBUG in if_i82559.c and find out what
address is being passed to eth_set_mac_address(). Is it the same as
the source address of packets being sent out?

        Andrew




-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss