[ECOS] Socket problem with smsc LAN91C96

[ECOS] Socket problem with smsc LAN91C96

[Andrea Scian]

Hi all!
I have a problem while running eCos on an ARM7TDMI (S3C44B0) based board
with a SMSC LAN91C96 ethernet controller.
While the whole TCP/IP stack works fine (I'm using OpenBSD at the moment) I
have a problem when I call the socket "connect" function after a hardware
reset.

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.
This happen only after a HW reset, because when, later, I need to restart
the system (I just set the program counter to start from the first location,
so behaving like a reset exception) it doesn't wait, that is the connect()
end only a few millis after it's called and the connection is full working.
Please note that the "reset exception" caused a reset of the whole board
(micro, ram, ethernet controller...)
If, after a HW reset, I wait that 4 second somewhere else (even with a dumb
"for" cicle inside cyg_user_start() before starting the scheduler) the
"connect" call doesn't stop and I get the connection without wait!

It's not so bad, the application works good both times, but I'm having
problem when I have to do a HW reset or when the power goes down because of
that 4 second that slow down the whole application.

I'm I doing something wrong or what?

Has anybody had this kind of problem before? Any clue about what is
happening?

Thank you in advance!


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

Re: [ECOS] Socket problem with smsc LAN91C96

[Andrew Lunn]

> 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

Re: [ECOS] Socket problem with smsc LAN91C96

[Andrea Scian]

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