public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Trenton D. Adams" <tadams@theone.dnsalias.com>
To: <Fano.Ramparany@rd.francetelecom.fr>
Cc: "'eCos Disuss'" <ecos-discuss@sourceware.cygnus.com>
Subject: RE: [ECOS] Re:  	Networking in a ROM build
Date: Thu, 23 Aug 2001 14:46:00 -0000	[thread overview]
Message-ID: <000601c12c1d$0892d9c0$090110ac@TRENT> (raw)
In-Reply-To: <3B8528A0.279236E4@rd.francetelecom.fr>

Does your code hang up on the accept () call?  Mine does.  I call
accept, and the windows machine never gets to it.  It's almost as if the
bind didn't even work originally.

Anyone know if there's a way of using something like "netstat" in eCos?
I would like to be able to use CYG_TRACEX () to output the socket
connection information of the entire system.

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Fano
Ramparany
Sent: Thursday, August 23, 2001 10:01 AM
To: Trenton D. Adams
Cc: eCos Disuss
Subject: [ECOS] Re: Networking in a ROM build


Trenton,
This is exactly the problem we are currently facing and trying to solve
(see some recent threads). A socket configuration that might
solve your problem is to increase the socket timeout value:

#include <timer.h>
#define SOCK_TIMEOUT 50
...
int sd,len,rc;
sd = socket(AF_INET, SOCK_STREAM, 0);
struct timeval tv;
...
tv.tv_sec = SOCK_TIMEOUT;
tv.tv_usec = 0;
setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));

This partially solved our problem, however, by sniffing the network
traffic (using tcpdump)
We have observed some strange behaviour on the ROM version of our
application, which seems to buffer the first packets and at some stage
sends them alltogether over the network.

I've also added some delay between the ethernet driver initialization
and the ip stack initialization, but this didn't solve the problem.

I'll now try to add some tracing (CYGDBG_USE_ASSERT) to go further.

Fano

> When using a ROM version, the following thing happens:
> The transmit and status signal threads connect to my windows machine
> just fine.  After they are connected, my windows machine attempts to
> connect back to the embedded system's CommandThread socket.  The
> connection attempt times out.

  parent reply	other threads:[~2001-08-23 14:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-23  9:03 Fano Ramparany
2001-08-23  9:07 ` [ECOS] " Trenton D. Adams
2001-08-23 10:26 ` [ECOS] " Trenton D. Adams
2001-08-24  8:02   ` Fano Ramparany
2001-08-23 14:46 ` Trenton D. Adams [this message]
2001-08-31 10:01   ` Fano Ramparany

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000601c12c1d$0892d9c0$090110ac@TRENT' \
    --to=tadams@theone.dnsalias.com \
    --cc=Fano.Ramparany@rd.francetelecom.fr \
    --cc=ecos-discuss@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).