Re: [ECOS] Socket problem with smsc LAN91C96

["Andrea Scian" <andrea dot scian at wawnet dot biz>]

First of all thanks for your answer!!

After a while I've found why it takes 4 secs to connect: it's only about
line hand-shake (as you suggest in your 2nd idea). My board has a 10Mbit
ethernet interface but it's connected to a 10/100Mbit switch (because of my
office organization), today I have to connect it to an old 10Mbit hub and
I've found that it connect in only a few millisec. I don't know very well
how ethernet works at low level but it seems that the 100Mbit switch need a
few secs to "convalidate" my 10Mbit interface. (Of course this will also
happen with the usual PCs but you won't notice it because of the OS start
up...)

More than this I also saw that I can "ping" my board from a remote PC in
only 2 secs (more or less...) while "connect" still require 4 secs (more or
less...) so maybe it's also something about your 4th idea...

Regards,
Andrea

----- Original Message -----
From: "Andrew Lunn" <andrew@lunn.ch>
To: "Andrea Scian" <andrea.scian@wawnet.biz>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Thursday, October 16, 2003 3:45 PM
Subject: Re: [ECOS] Socket problem with smsc LAN91C96


> > 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