headers
Jonathan Larmour | 3 May 2007 12:59
Favicon

Re: Simulation of TCP connections with multiple source IP addresses

Leena Mokadam wrote:
> Hello,
> 
> I am a LWIP's new user. My query is about TCP connection with mutiple source
> IPs.
> 
> Can we maintain (send/receive) multiple network interfaces using LWIP? I
> have to simulate multiple IP addresses for the same PC and send/receive TCP
> data with multiple IP address. For example,
> My PC needs to simulate following IP addresses
> 192.168.20.120, 192.168.20.121, 192.168.20.122, 192.168.20.123,
> 192.168.20.124 and 192.168.20.125. And my program needs to maintain a TCP
> connection for all of these IP address to various different servers. It
> involves sending and receiving of data. Please let me know if this is
> possible woith the help of LWIP. I am not sure as I have yet not seen any
> LWIP API which accepts source IP address and Destination IP address.

In the current code, lwIP's routing and interface structure is 
intentionally simplified. You can have only one IP address for each 
interface ("netif"). I _think_ lwip should allow you to do what you want 
if you set up a netif for each IP address. When you need to send something 
from a specific address, then you will need to call 
bind()/netconn_bind()/tcp_bind() (depending on the interface you're using) 
to set the local IP address to use for that connection.

If you need to set up a listening port, you will also need to have 
multiple listeners - one bound to each IP address separately.

Jifl
--

--
(Continue reading)

Permalink | Reply | 6 comments |
headers
leena | 3 May 2007 13:03

Re: Simulation of TCP connections with multiple source IP addresses

Hi Jonathan,

Thanks for the response. Can I have a look at some sample code which does
similar to what I am trying to do?

Thansk and Regards,
Leena M.

Quoting Jonathan Larmour <jifl@...>:

> Leena Mokadam wrote:
> > Hello,
> > 
> > I am a LWIP's new user. My query is about TCP connection with mutiple
> source
> > IPs.
> > 
> > Can we maintain (send/receive) multiple network interfaces using LWIP? I
> > have to simulate multiple IP addresses for the same PC and send/receive
> TCP
> > data with multiple IP address. For example,
> > My PC needs to simulate following IP addresses
> > 192.168.20.120, 192.168.20.121, 192.168.20.122, 192.168.20.123,
> > 192.168.20.124 and 192.168.20.125. And my program needs to maintain a TCP
> > connection for all of these IP address to various different servers. It
> > involves sending and receiving of data. Please let me know if this is
> > possible woith the help of LWIP. I am not sure as I have yet not seen any
> > LWIP API which accepts source IP address and Destination IP address.
> 
> In the current code, lwIP's routing and interface structure is
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonathan Larmour | 3 May 2007 14:39
Favicon

Re: Simulation of TCP connections with multiple source IP addresses

leena@... wrote:
> Hi Jonathan,
> 
> Thanks for the response. Can I have a look at some sample code which does
> similar to what I am trying to do?

Not that I know of. Although someone else might, in which case they would 
probably need to know which API you are using.

Jifl
--

-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine
Permalink | Reply | 0 comments |
headers
Goldschmidt Simon | 3 May 2007 15:01

RE: Simulation of TCP connections with multiple sourceIP addresses

Hi,

> In the current code, lwIP's routing and interface structure 
> is intentionally simplified. You can have only one IP address 
> for each interface ("netif"). I _think_ lwip should allow you 
> to do what you want if you set up a netif for each IP 
> address. When you need to send something from a specific 

That's what I thought, too. At least for the TX side, having an
ethernetif.c
that allows multiple instances (multiple calls to ethernetif_init() with
multiple 'struct netif's) but sends everything on one HW-interface only,
this should work.

On the RX side I'm not so sure. Maybe you have to call netif->init()
with the
right struct netif for the local IP address. Also maybe it works for any
netif,
I really don't know that, too. You would have to check that...

As for an example, for socket API client connection, I guess you would
do it
somehow like this:

>>>>>>>>>>CODE>>>>>>>>>>
struct sockaddr_in local_addr;
struct sockaddr_in server_addr;
int sock;
sock = lwip_socket(AF_INET, SOCK_STREAM, 0)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Simon Goldschmidt | 4 May 2007 21:45
Picon

[task #1551] Make ARP more independent of interface hardware type


Follow-up Comment #8, task #1551 (project lwip):

I've had another look at ARP for IEEE1394 and it seems to me it is completely
different from ARP for IEE802.3. Maybe this is the reason our file is named
etharp? :-)

I don't think we can re-use much...

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?1551>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/
Permalink | Reply | 0 comments |
headers
PAUL.YU 喻浦軒 | 7 May 2007 08:34
Picon

lwip + FreeRTOS on STR91x

I'm using STR910-EVAL board , there has a demo project in FreeRTOS , but it used uIP .
Now I would like to change uIP to lwip . I reference other project like AVR which using lwip , but the toolchain are different .

My IDE is IAR Embedded Workbench for ARM .

Does there have any lwip demo project which using IAR Embedded Workbench for ARM ?



*************************************************************************************************************************
This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. [Delta Electronic, INC. Taiwan]
*************************************************************************************************************************
_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 0 comments |
headers
jcr_alr | 8 May 2007 15:41
Favicon

Microblaze and lwIP


Some months ago I started a thread when I ran into problems with response times 
using Microblaze and lwIP in sockets mode. I implemented the suggestions others 
had suggested - hardware multiplier, implementing a cache etc with improved 
performance but the underlying problem remained.

The application used lwip to transfer a small amount of data (requests really) 
from the PC to the host which sends back 2Kbytes of data, divided into one full 
1460 byte segment followed by the remaining 588 bytes in a partial segment. To 
make the system user-responsive, I wanted to complete the request/response time 
in, say, 100 millisecs. The problem arose when the PC client took some 200 - 
300 milliseconds to ACK the first segment, as seen on Windump traces. 

In tcp_out.c, I modified the tcp_enqueue() function to mark any full segment as 
PSH and in tcp_output() modified the conditions in the entry to the 'while' 
block to ensure that both segments were transmitted consecutively.

The complete transaction now takes place within 14 millisecs, which includes 
some short delays I added to the client code, eg between the read and close 
calls.

I am not sure why this modification was necessary - are there any settings in 
either lwipopts or Winsock that I could have changed to avoid this. I think the 
problem may lie more in the PC end - because in the original implementation the 
first segment was sent without PSH and the client then maybe waited for some 
timeout period before realising nothing more was coming, then sent the ACK at 
which time the host responded sending the second partial segment that was 
marked PSH.

Any thoughts or suggestions would be most welcome.

John Robbins.
Permalink | Reply | 9 comments |
headers
Kieran Mansley | 8 May 2007 16:06

Re: Microblaze and lwIP

On Tue, 2007-05-08 at 10:41 -0300, jcr_alr@... wrote:
> I am not sure why this modification was necessary - are there any settings in 
> either lwipopts or Winsock that I could have changed to avoid this. I think the 
> problem may lie more in the PC end - because in the original implementation the 
> first segment was sent without PSH and the client then maybe waited for some 
> timeout period before realising nothing more was coming, then sent the ACK at 
> which time the host responded sending the second partial segment that was 
> marked PSH.

Can you explain what modification you made to the while loop in
tcp_output() ?  I'm guessing you allowed it to send the second segment
even if there was insufficient window space for it?  It is this change
that is most likely getting the results you need.  

You are correct that it is the windows end that is causing your problem.
Most TCP stacks have a "delayed ACK" policy.  i.e. In certain conditions
they won't send an ACK in the hope that the connection involves bi-
directional traffic and the ACK will be able to piggyback on a returning
data packet.  In your case there is no returning data packet, and so the
ACK isn't sent until a timer goes off after about 200ms.  However, the
stack should acknowledge at least every other packet.  This is why if
you modify lwIP to send both packets, they get ACKed immediately.  The
windows end has received two packets and so must send an ACK straight
away.

Unfortunately, this is just a property of TCP, rather than either lwIP
or windows having a bug.  I think linux has some clever stuff in it to
notice when the delayed ACK protocol would harm performance and so is
able to turn it off in cases like this.

To find out more, have a look through the TCP RFCs for "delayed ACK".
These are relatively well documented problems!

Kieran
Permalink | Reply | 8 comments |
headers
Kieran Mansley | 8 May 2007 20:50

Re: Microblaze and lwIP

On Tue, 2007-05-08 at 15:06 +0100, Kieran Mansley wrote:

> Unfortunately, this is just a property of TCP, rather than either lwIP
> or windows having a bug.  I think linux has some clever stuff in it to
> notice when the delayed ACK protocol would harm performance and so is
> able to turn it off in cases like this.

A colleague has pointed out that you may be able to avoid this problem,
if you're using the sockets API, by setting the TCP_NODELAY socket
option.  This won't solve the issue in all cases, but may be good enough
for your needs.

Kieran
Permalink | Reply | 6 comments |
headers
Caglar Akyuz | 8 May 2007 21:17
Picon

Re: Microblaze and lwIP

Kieran Mansley wrote:
> On Tue, 2007-05-08 at 15:06 +0100, Kieran Mansley wrote:
> 
>> Unfortunately, this is just a property of TCP, rather than either lwIP
>> or windows having a bug.  I think linux has some clever stuff in it to
>> notice when the delayed ACK protocol would harm performance and so is
>> able to turn it off in cases like this.
> 
> A colleague has pointed out that you may be able to avoid this problem,
> if you're using the sockets API, by setting the TCP_NODELAY socket
> option.  This won't solve the issue in all cases, but may be good enough
> for your needs.

I have run into a similar problem and I solved the problem on LwIP side
forcing packets to be sent immediately using tcp_output(). On the PC
side(both Windows and Linux hosts) I tried setting TCP_NODELAY as you
have pointed, i.e. I disabled Naggle's algorithm. After a few months of
test, I realized that I'm facing some lost packets issue on the PC side.
When I removed disabling Naggle's algorithm part, I was able to manage
recovering packet loss rate a little bit. I'm not sure if it's true or
not, but I guess Windows and Linux stacks can show this kind of behavior.

Somebody please correct me if I'm wrong, as this problem really disturbs me.
Permalink | Reply | 2 comments |

Gmane