AW: [En-Nut-Discussion] Problem with PPP and NutTCPConnect

Oliver Schulz olischulz at web.de
Sun Jan 25 12:56:53 CET 2004


Hi Alex, Dan and All,

lets directly come to the bugs.

1. Because I don't know nothing about PPP stuff, I left the code untouched.
Perhaps Harald can have a look at it.

2. Now after 3 retries of connection establishing, Nut/Net returns to the
caller with ETIMEDOUT error.

3. Upon reception of the RST packet from the host, NutTcpConnect will now
fail with ECONNREFUSED error.

Note: Lastest version of tcpsm.c in CVS is now 1.9.

The whole tcp state machine is really very complicated, so I hope that there
are not any new unforseen sideeffects.
If you notice some new strange behaviour, please post it in the list.

Regards,
Oliver.



> -----Ursprüngliche Nachricht-----
> Von: en-nut-discussion-bounces at egnite.de
> [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Alex Joni
> Gesendet: Samstag, 24. Januar 2004 14:58
> An: en-nut-discussion at egnite.de
> Betreff: [En-Nut-Discussion] Problem with PPP and NutTCPConnect
>
>
> First of all we would like to send our thanks for this great
> project. Many
> thanks to all the contributors.
>
> 1. We tried out the PPP implementation over a GPRS link, and
> found a few
> minor problems.
> With a local provider (Orange-Romania) we found that the
> magic number option
> request is rejected, but the current implementation of PPP
> (we used NutOs
> version 3.3.3.1pre from CVS) doesn't recognize the reject
> properly. (that
> means that the PPP implementation recognizes the reject, but
> it doesn't send
> out a new request without magic number). We commented out the
> magic number
> option from the sources (in void LcpTxConfReq(NUTDEVICE *dev,
> u_char id) )
> and it connected successfully to the network.
>
> 2. When using NutTCPConnect over PPP over GPRS we found there are two
> problems. In case the remote host is not available, it seems that the
> NutTCPConnect just sends SYN requests without stopping ever.
> (we left it
> sending for about 50 seconds). It should use some kind of
> timeout mechanism.
> We didn't find any solutions for this problem.
>
> 3. The second problem when the remote host is available, but
> there is no
> service listening on the port we try to connect to. In this
> case a CLOSEWAIT
> package arrives, but NutTCPConnect doesn't return with error
> code (it just
> simply hangs 4ever). We were able to solve this problem in
> the following
> way: in int NutTcpStateActiveOpenEvent(TCPSOCKET * sock) we replaced
>
> NutEventWait(&sock->so_ac_tq, 0);
> with
> NutEventWait(&sock->so_ac_tq, 10000); //hang for 10 seconds
> and give up
>
> We hope that somebody can help us overcome this problem (or
> maybe point out
> if we do something wrong). If it is necessary, we can post
> parts or the
> complete source code and some logs from NutPPPTrace and NutTCPTrace.
>
> TIA,
> Alex Joni, Dan Chiciudean
>
> from the DSPLabs (http://dsplabs.utt.ro)
>
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion




More information about the En-Nut-Discussion mailing list