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

[Jonathan Larmour]

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

>re api_msg.c changes, fromport and fromaddr being used when
>sending. I think their names would need changing in that case.
>
>Yes, It would be better, but this change the netconn API on
>"recv", and I wouldn't do that 

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

>> In any case, these fields would now need initialising in
>> netbuf_new, otherwise they may have any value.
>
> Yes, except that now, netconn users could avoid to do the same
> job than in older lwip_send (check conn state, connect, send,
> disconnect). In a general way, this new patch give better
> performance than older (less operations), and it's thread
> safe... 

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.

In answer to what you did say though, the netconn API has a different model
to BSD. There's no benefit from avoiding doing the same job at all because
the netconn API never had that paradigm in the first place! With the netconn
API, it's nice and simple: you always connect first, then you use send.
Unlike BSD, you can't send on a connection that hasn't been "connected"
first.

> The problem is that netconn & sockets have the same problem.
> Even if you want to use netconn, you will got the same problem
> explain in first comments about this bug. The problem is that
> the original design of ALL the sequential API (netconn or
> sockets) wasn't do to be thread safe.

But with the netconn API, this part /is/ thread-safe. There are thread-safety
issues with the netconn API in some places, but not this one - netconn_connect
and _send are straightforward. Each function operates separately. If multiple
threads tried to do things with them at the same time, that would be no
different than with sockets on Linux. For example, if two threads try to
write a connection at the same time, that's safe, but you can't guarantee the
order. The same is true for Linux. So when it comes to the relative ordering
of different netconn calls - that's an application issue. The order of close
and write would be even more important :-).

> About the opengroup link, some others things are missing (using
> NULL is only possible if you use a TCP connection, or if the
> UDP connection is already "connect"ed, etc...) 

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

Thank you for working on this 

Jifl


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/