RE : [lwip-users] Problem with lwip_select under Nucleus

[Frédéric BERNON]

Same question than the last time: which release? Even if a "connect" should do 
an implicit "bind", can you test to call it (bind) before connect? 
  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Kieran Mansley
Envoyé : vendredi 25 mai 2007 10:15
À : Mailing list for lwIP users
Objet : Re: [lwip-users] Problem with lwip_select under Nucleus


On Fri, 2007-05-25 at 09:54 +0200, address@hidden wrote:

> At this point, I supposed that for default, sockets in LWIP were non- 
> blocking (is this true???),

No.  By default socket operations are blocking.  I assume you haven't specified 
MSG_DONTWAIT in the flags to the recv operation, or O_NONBLOCK to the socket 
options.  These would both result in non-blocking sockets.

> I cannot find an explanation to what happens, but actually, select 
> does not wait when it is called after a connect. I would be very 
> pleased if somebody could give me some advice.

It sounds like there's a problem with your port that is causing the blocking 
operations in the sockets API to not block.  For some reason lwIP is behaving 
as if there is data to read on that socket, when in fact there is none.

Ignore select() for now as I think if we can solve the simpler recv-not- 
blocking issue, that will be a good start.

Take a look at the lwip_recvfrom() function.  Can you check the following when 
you call it by adding some extra debugging:
 - that sock->lastdata is NULL.
 - that buf returned by netconn_recv() is NULL.

If that is the case, take a look at netconn_recv().  This can return NULL for 
all sorts of reasons.  Add debugging (e.g. a printf) to each one and see which 
case is failing.

With that information we should be able to work out what's wrong.

Kieran





_______________________________________________
lwip-users mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-users

Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf