lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #19162] lwip_sendto: possible to corrupt remote addr/p


From: Frédéric Bernon
Subject: [lwip-devel] [bug #19162] lwip_sendto: possible to corrupt remote addr/port connection state
Date: Thu, 12 Apr 2007 13:20:34 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Follow-up Comment #23, bug #19162 (project lwip):

>Fortunately users should not be accessing these fields directly - that's
what netbuf_fromaddr() and netbuf_fromport() are for :-). 

Yes, but to my point of view, these functions are not a great idea, because
you can directly access to fields (and doing that is faster and reduce
footprint).

>I was referring to the fact that fromaddr and fromport are not initialised
in netbuf_new, so when a user sends a buffer with netconn_send, they may not
be 0. 

Ok, initialize in netbuf_new would have to be done.

>Unlike BSD, you can't send on a connection that hasn't been "connected"
first.

And I don't find that wasn't a good idea to design the sequantial api like
this, because raw api allow to use send and sendto... (continue on next
point)

>here are thread-safety issues with the netconn API in some places, but not
this one - netconn_connect and _send are straightforward...

I'm not agree with you on this point: if your comment about a TCP connection
is true about segments order (it have to be process by application and/or
protocol), I think it's wrong for UDP connections. First, an application
could want to send the same datagram to multiple destinations (if multicast
isn't supported, or if WAN is used, by example). But with current sequential
api (netconn or sockets) performance is poor (need to check, connect,
disconnect, exchange lot of messages between api_lib/api_msg...), but raw api
allows it (see udp_sendto & raw_sendto, they already do the job at low level).
Next, if two threads want to send data using the same socket or netconn, with
both we can got the problem described by Rob in the initial description. So,
even netconn_send is not safe-thread to this point of view. To be clear about
what I think to be normal "safe-thread" operations, take a look to
https://savannah.nongnu.org/task/?6683. I think we can improve sequential api
to get something safe-thread and with performance near than raw api (except
copy memory operations, of course).

We have already talk about that, but I think that two sequential api, with
one based on the other one, is not a good idea: I think it will be better to
keep the BSD one, and to add some extra functions for zero-copy. So, most of
the code will be the same, footprint will be reduced (for BSD users, of
course :) ), less code will have to be maintain, keep source code
compatibility with most of open source applications...). But this last
comment is another subject (and a bigger task)... (if you want to continue to
talk about that, I propose to continue on the forum).

>We take a relaxed view about careful error checking with lwIP sometimes,
with application errors. This might be one of those times? 

Right! And It will be...




    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?19162>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]