Re: [ECOS] Socket problem with smsc LAN91C96

[Andrew Lunn <andrew at lunn dot ch>]

> This is what happen to me: inside a thread, after calling
> init_all_network_interfaces(), I create a socket (AF_INET, SOCK_STREAM) and
> call connect() to a LAN server. When connect() is called after a HW reset it
> waits a long time (more or less it's 4 seconds) before send the first TCP/IP
> packet, after that it all works good.

I have a few ideas.

1) You have DHCP/BOOTP in use and its taking a while for this to
   assign you an address. Fix the IP address so you don't have to
   negotiate it.

2) The hardware takes 4 seconds to get itself sorted out, negotiate
   the line speed/duplex mode with the other end etc. This is possible
   and if so there is little you can do about it, except hard wire the
   line speed and hope the other end can cope.

3) I think both network stack do a sanity check to see if anybody else
   is using the IP address it want to use. It sends out an ARP for its
   own address, waits for a while and if it does not receive a reply
   it starts to use the address. This could take a second. If you know
   you will never have conflicting IP addresses and you can live with
   random machines doing strange things when there are conflicts, you
   can probably disable this code. 

4) The packet is reaching the HW before its completed its
   initialization and it throws it away. You then wait for TCP to do a
   resend. This resend will probably be a couple of seconds later and
   will probably work. You can try to prove this by putting in some
   debug code to see packet sent and received. Which TX actually
   causes an RX? You might be able to tune your delay so that the
   first packet gets sent correctly. Or you can might be able to
   change the retransmit timer, but you should see what the RFCs says
   about this. 

   Andrew


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