Christiaan Simons | 1 Nov 13:00 2005
Picon

Re: DCHP Client(Urgent)

"Robson" <robson.paulo <at> gmail.com> wrote on 01-11-2005 13:11:22:

> Hi,
> I´m using LWIP with an ARM Microcontroler in a specific application,
> and I want to use this in my common network. So, I want to establish
> a DHCP client. But I don´t know how to set DCHP and how to call the
> correct functions.

As I said before on the lwip-users list the contrib/ports/unix/proj/unixsim
example and the src/core/dhcp.c are some sort of a reference. Also lwip/doc
should explain the important concepts.

If something is missing there I'll try to document/fix that later.

> My question is: in a simple application, what is the configurations
> and the exactly sequence of call functions should we use?

What is simple? We get these questions all the time,
and it's getting a bit boring. Read the code please.

> I try to use dchp_start(), dchp_discover()…but no results.

You shouldn't be calling dhcp_discover() yourself.

Please note you should have created and initialised a netif,
and enabe it with netif_set_default() and netif_set_up()!

Furter documentation is from the dhcp source:

Integration with your code:
(Continue reading)

Christiaan Simons | 1 Nov 13:08 2005
Picon

Re: tcp_write with zero-copy


Sathya Thammanur <thammanur@...> wrote on 31-10-2005 18:40:32:

> Does this mean that true zero-copy is not supported by lwIP? I have
> seen issues with zero-copy and I was wondering if this is the case.

This isn't advertised anywhere as far as I know. I cannot tell for sure,
but I believe it was not one of Adam's design goals. Some users
may have tried to implement zero-copy.

Please post these questions to the lwip-users list.

Christiaan Simons

Hardware / Software Engineer
Axon Digital Design

+31 (0)13 511 66 66
+31 (0)13 511 41 51

http://www.axon.tv

>
>

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named.  If you are not the named addressee you should not
(Continue reading)

Robson | 1 Nov 13:47 2005
Picon

HELP, PLease! DCHP Client

Hi,

I´m using LWIP with an ARM Microcontroler in a specific application,
and I want to use this in my common network. So, I want to establish a
DHCP client. But I don´t know how to set DCHP and how to call the
correct functions.

My question is: in a simple application, what is the configurations
and the exactly sequence of call functions should we use?

I try to use dchp_start(), dchp_discover()…but no results.

Please, help more urgent than possible!

If anyone knows how to do this, please, help me! Write for my email
robson.paulo <at> gmail.com or to this email list.

Thanks

Robson Paulo
_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Sathya Thammanur | 1 Nov 19:16 2005
Picon

Re: tcp_write with zero-copy

Sorry Christian for the email. Has anyone tried true zero-copy for the RAW API mode? Are there changes needed in lwIP to get this working?

Thanks,

Sathya


On 11/1/05, Christiaan Simons <christiaan.simons-laxl2+jGqjQ@public.gmane.org> wrote:

Sathya Thammanur <thammanur <at> gmail.com> wrote on 31-10-2005 18:40:32:

> Does this mean that true zero-copy is not supported by lwIP? I have
> seen issues with zero-copy and I was wondering if this is the case.

This isn't advertised anywhere as far as I know. I cannot tell for sure,
but I believe it was not one of Adam's design goals. Some users
may have tried to implement zero-copy.

Please post these questions to the lwip-users list.

Christiaan Simons

Hardware / Software Engineer
Axon Digital Design

+31 (0)13 511 66 66
+31 (0)13 511 41 51

http://www.axon.tv

>
>

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named.  If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.


_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Robert Brown | 2 Nov 03:15 2005
Picon

RE: HELP, PLease! DCHP Client

This is how I did it in lwip 0.6.4.  It might be different in the latest
version.

In lwipopts.h you must set your DHCP options:

#define LWIP_DHCP             1  /* Enable DHCP  */
#define DHCP_DOES_ARP_CHECK   0  /* Set this to 1 if you want dhcp to do an
arp check on the offered address  */
#define DHCP_OPTIONS_LEN      68 /* Space allocated for options in DHCP
messages */

In your initialization routine you must call the usual lwIP init functions:
sys_init();
mem_init();
memp_init();
pbuf_init();
netif_init();
ip_init();

If you are using udp and tcp then call
udp_init();
tcp_init();

Add your network interfaces...
Set ip.addr = 0, gw.addr = 0 and netmask.addr = 0 before you call
netif = netif_add(&ip, &netmask, &gw, ...)

To start the dhcp client on a network interface call
dhcp_start(netif);
and then set the NETIF_FLAG_DHCP flag in your netif.
netif->flags &= NETIF_FLAG_DHCP;

and then call
dhcp_fine_tmr(); every 500ms
dhcp_coarse_tmr(); every 60 sec

To stop the dhcp client call
dhcp_stop(netif);
and unset the NETIF_FLAG_DHCP flag in your netif.
netif->flags |= NETIF_FLAG_DHCP;
stop calling dhcp_fine_tmr() and dhcp_coarse_tmr().

I think that's it.  Good luck.

Cheers,
Rob Brown

-----Original Message-----
From:
lwip-users-bounces+robw_brown=sympatico.ca@...
[mailto:lwip-users-bounces+robw_brown=sympatico.ca@...]On Behalf
Of Robson
Sent: November 1, 2005 7:48 AM
To: lwip-users@...
Subject: [lwip-users] HELP, PLease! DCHP Client

Hi,

I´m using LWIP with an ARM Microcontroler in a specific application,
and I want to use this in my common network. So, I want to establish a
DHCP client. But I don´t know how to set DCHP and how to call the
correct functions.

My question is: in a simple application, what is the configurations
and the exactly sequence of call functions should we use?

I try to use dchp_start(), dchp_discover()…but no results.

Please, help more urgent than possible!

If anyone knows how to do this, please, help me! Write for my email
robson.paulo@... or to this email list.

Thanks

Robson Paulo
Ghislain Mary | 3 Nov 16:30 2005
Picon

LCP Termination Request missing

Hi all,

I am working with lwip in a phone for mms operations and have a little
problem. When closing the ppp connection, I should have an LCP
Termination Request packet sent to the MMS server in order for it to
know the connection has been closed. But it looks like this packet is
not sent, even if I call lcp_close() explicitely. At least, it is not
received by the MMS server. Any idea of the problem?

Thanks a lot,

Ghislain
Amir Bukhari | 4 Nov 11:45 2005
Picon

A lot of packets lost by ping

I have got lwip to work with uCOS-II/MPC5200 (using Bestcomm DMA), but I
have some performance issue.

When I ping my uC from a another computer I got response but slowly here is
some of this output

################
bukhari <at> data /tftpboot> ping seska
PING seska (141.21.7.245) 56(84) bytes of data.
64 bytes from seska (141.21.7.245): icmp_seq=3 ttl=64 time=0.234 ms
64 bytes from seska (141.21.7.245): icmp_seq=7 ttl=64 time=0.230 ms
64 bytes from seska (141.21.7.245): icmp_seq=9 ttl=64 time=0.232 ms
64 bytes from seska (141.21.7.245): icmp_seq=13 ttl=64 time=0.232 ms
64 bytes from seska (141.21.7.245): icmp_seq=14 ttl=64 time=0.234 ms
64 bytes from seska (141.21.7.245): icmp_seq=15 ttl=64 time=0.232 ms
64 bytes from seska (141.21.7.245): icmp_seq=16 ttl=64 time=0.234 ms
64 bytes from seska (141.21.7.245): icmp_seq=18 ttl=64 time=0.228 ms
64 bytes from seska (141.21.7.245): icmp_seq=19 ttl=64 time=0.233 ms
64 bytes from seska (141.21.7.245): icmp_seq=20 ttl=64 time=0.246 ms
64 bytes from seska (141.21.7.245): icmp_seq=29 ttl=64 time=0.230 ms
64 bytes from seska (141.21.7.245): icmp_seq=33 ttl=64 time=0.228 ms
64 bytes from seska (141.21.7.245): icmp_seq=34 ttl=64 time=0.232 ms
64 bytes from seska (141.21.7.245): icmp_seq=37 ttl=64 time=0.230 ms
64 bytes from seska (141.21.7.245): icmp_seq=39 ttl=64 time=0.233 ms
64 bytes from seska (141.21.7.245): icmp_seq=40 ttl=64 time=0.232 ms
64 bytes from seska (141.21.7.245): icmp_seq=45 ttl=64 time=0.246 ms
64 bytes from seska (141.21.7.245): icmp_seq=47 ttl=64 time=0.230 ms
64 bytes from seska (141.21.7.245): icmp_seq=48 ttl=64 time=0.232 ms

--- seska ping statistics ---
48 packets transmitted, 19 received, 60% packet loss, time 47057ms
################

I have only two process, one is dummy and the second is the receive task,
which get activated when a packet received by the interrupt handler. I have
no any lwip TCP connection active. Just I activated my network.

As you have more experience with LWIP, you could point for experience about
increasing performance!

-Amir
ming | 4 Nov 14:05 2005
Picon

RE: A lot of packets lost by ping

Hi,

Have you tried to connect it to you computer directly with a cross-over
cable ?

It's necessary to make sure that the trouble's on the MPC board, I
think.

--
************************************************************************
********
Zeng, Ming
NIKHEF,  Kruislaan 409 
1098 SJ Amsterdam - The Netherlands
email: mingz@...
Tel.   31 (0)20 592 2147
Mobile 31 (0)6 4351 5283
************************************************************************
******** 

-----Original Message-----
From: lwip-users-bounces+ming=zming.net@...
[mailto:lwip-users-bounces+ming=zming.net@...] On Behalf
Of Amir
Bukhari
Sent: Friday, November 04, 2005 11:45 AM
To: lwip-users@...
Subject: [lwip-users] A lot of packets lost by ping

I have got lwip to work with uCOS-II/MPC5200 (using Bestcomm DMA), but I
have some performance issue.

When I ping my uC from a another computer I got response but slowly here
is some of this output

################
bukhari <at> data /tftpboot> ping seska
PING seska (141.21.7.245) 56(84) bytes of data.
64 bytes from seska (141.21.7.245): icmp_seq=3 ttl=64 time=0.234 ms 64
bytes from seska (141.21.7.245): icmp_seq=7 ttl=64 time=0.230 ms 64
bytes from seska (141.21.7.245): icmp_seq=9 ttl=64 time=0.232 ms 64
bytes from seska (141.21.7.245): icmp_seq=13 ttl=64 time=0.232 ms 64
bytes from seska (141.21.7.245): icmp_seq=14 ttl=64 time=0.234 ms 64
bytes from seska (141.21.7.245): icmp_seq=15 ttl=64 time=0.232 ms 64
bytes from seska (141.21.7.245): icmp_seq=16 ttl=64 time=0.234 ms 64
bytes from seska (141.21.7.245): icmp_seq=18 ttl=64 time=0.228 ms 64
bytes from seska (141.21.7.245): icmp_seq=19 ttl=64 time=0.233 ms 64
bytes from seska (141.21.7.245): icmp_seq=20 ttl=64 time=0.246 ms 64
bytes from seska (141.21.7.245): icmp_seq=29 ttl=64 time=0.230 ms 64
bytes from seska (141.21.7.245): icmp_seq=33 ttl=64 time=0.228 ms 64
bytes from seska (141.21.7.245): icmp_seq=34 ttl=64 time=0.232 ms 64
bytes from seska (141.21.7.245): icmp_seq=37 ttl=64 time=0.230 ms 64
bytes from seska (141.21.7.245): icmp_seq=39 ttl=64 time=0.233 ms 64
bytes from seska (141.21.7.245): icmp_seq=40 ttl=64 time=0.232 ms 64
bytes from seska (141.21.7.245): icmp_seq=45 ttl=64 time=0.246 ms 64
bytes from seska (141.21.7.245): icmp_seq=47 ttl=64 time=0.230 ms 64
bytes from seska (141.21.7.245): icmp_seq=48 ttl=64 time=0.232 ms

--- seska ping statistics ---
48 packets transmitted, 19 received, 60% packet loss, time 47057ms
################

I have only two process, one is dummy and the second is the receive
task, which get activated when a packet received by the interrupt
handler. I have no any lwip TCP connection active. Just I activated my
network.

As you have more experience with LWIP, you could point for experience
about increasing performance!

-Amir

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Amir Bukhari | 4 Nov 16:52 2005
Picon

AW: A lot of packets lost by ping


I have found that my Bestcomm image doesn't work correctly, I receive bad
currupted data, although the DMA doesn't give me any errors. I solved this
after I use the Bestcomm image from linuxppc (from www.denx.de) and now I
have no packets lost, I receive all correctly.

I have another question.
When I send a ping like following (linux):
Ping seska -s 2000

Windows and linux PC echo this request but lwip doesn't do that. My FEC fire
an error indicating sending a packet more than 1538. it seem that lwip
doesn't support this. Is that correct?

-Amir

-----Ursprüngliche Nachricht-----
Von: lwip-users-bounces+bukhari=fzi.de@... im Auftrag von
ming@...
Gesendet: Fr 11/4/2005 1:05
An: 'Mailing list for lwIP users'
Betreff: RE: [lwip-users] A lot of packets lost by ping

Hi,

Have you tried to connect it to you computer directly with a cross-over
cable ?

It's necessary to make sure that the trouble's on the MPC board, I
think.

--
************************************************************************
********
Zeng, Ming
NIKHEF,  Kruislaan 409 
1098 SJ Amsterdam - The Netherlands
email: mingz@...
Tel.   31 (0)20 592 2147
Mobile 31 (0)6 4351 5283
************************************************************************
******** 

-----Original Message-----
From: lwip-users-bounces+ming=zming.net@...
[mailto:lwip-users-bounces+ming=zming.net@...] On Behalf
Of Amir
Bukhari
Sent: Friday, November 04, 2005 11:45 AM
To: lwip-users@...
Subject: [lwip-users] A lot of packets lost by ping

I have got lwip to work with uCOS-II/MPC5200 (using Bestcomm DMA), but I
have some performance issue.

When I ping my uC from a another computer I got response but slowly here
is some of this output

################
bukhari <at> data /tftpboot> ping seska
PING seska (141.21.7.245) 56(84) bytes of data.
64 bytes from seska (141.21.7.245): icmp_seq=3 ttl=64 time=0.234 ms 64
bytes from seska (141.21.7.245): icmp_seq=7 ttl=64 time=0.230 ms 64
bytes from seska (141.21.7.245): icmp_seq=9 ttl=64 time=0.232 ms 64
bytes from seska (141.21.7.245): icmp_seq=13 ttl=64 time=0.232 ms 64
bytes from seska (141.21.7.245): icmp_seq=14 ttl=64 time=0.234 ms 64
bytes from seska (141.21.7.245): icmp_seq=15 ttl=64 time=0.232 ms 64
bytes from seska (141.21.7.245): icmp_seq=16 ttl=64 time=0.234 ms 64
bytes from seska (141.21.7.245): icmp_seq=18 ttl=64 time=0.228 ms 64
bytes from seska (141.21.7.245): icmp_seq=19 ttl=64 time=0.233 ms 64
bytes from seska (141.21.7.245): icmp_seq=20 ttl=64 time=0.246 ms 64
bytes from seska (141.21.7.245): icmp_seq=29 ttl=64 time=0.230 ms 64
bytes from seska (141.21.7.245): icmp_seq=33 ttl=64 time=0.228 ms 64
bytes from seska (141.21.7.245): icmp_seq=34 ttl=64 time=0.232 ms 64
bytes from seska (141.21.7.245): icmp_seq=37 ttl=64 time=0.230 ms 64
bytes from seska (141.21.7.245): icmp_seq=39 ttl=64 time=0.233 ms 64
bytes from seska (141.21.7.245): icmp_seq=40 ttl=64 time=0.232 ms 64
bytes from seska (141.21.7.245): icmp_seq=45 ttl=64 time=0.246 ms 64
bytes from seska (141.21.7.245): icmp_seq=47 ttl=64 time=0.230 ms 64
bytes from seska (141.21.7.245): icmp_seq=48 ttl=64 time=0.232 ms

--- seska ping statistics ---
48 packets transmitted, 19 received, 60% packet loss, time 47057ms
################

I have only two process, one is dummy and the second is the receive
task, which get activated when a packet received by the interrupt
handler. I have no any lwip TCP connection active. Just I activated my
network.

As you have more experience with LWIP, you could point for experience
about increasing performance!

-Amir

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

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

Attachment (winmail.dat): application/ms-tnef, 5743 bytes
_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Curt McDowell | 4 Nov 19:17 2005

RE: Applications to TCP/IP offload

Jim,
 
Your analysis is very cool, and I appreciate the insight, especially as to the effect of increased latencies depending on the application.  I'm not discouraged yet. There are pretty much two simple goals in this application.  One is to save at as many host processor cycles as possible, and the other is to achieve line rate as measured by a ~1500-byte streaming test.
 
uC/OS-II looks nice, and it's priced right.  Unfortunately, in this case our coprocessor has only 384kB of RAM, most of which is already allocated for large drivers and network buffers, so I've basically been prohibited from incorporating threads.  I'm going to have to implement the coprocessor side as an interrupt-driven state machine.
 
The latest plan is to run just the raw API on the coprocessor, and write new sockets interface client/server layers that can operate over a true message passing boundary.  As you say, hopefully I can model critical portions of this before committing to implement the whole thing.
 
Regards,
Curt McDowell
Broadcom Corp.

From: Jim Gibbons [mailto:jim-GcqFwEuwCMlBDgjK7y7TUQ@public.gmane.org]
Sent: Thursday, October 27, 2005 1:19 PM
To: csm-dY08KVG/lbpWk0Htik3J/w@public.gmane.org
Cc: 'Mailing list for lwIP users'
Subject: Re: [lwip-users] Applications to TCP/IP offload

With the coprocessor being so much slower than the host, I'm really concerned about the overall effect upon latencies, and perhaps even bandwidth.  You could end up reducing TCP/IP performance by adding coprocessor functionality.  I would again urge you to look at the fraction of time your host is spending in the TCP/IP stack, if at all possible.  If you are bound by stack performance, that may devolve to determining the amount of time you are spending in the kernel as opposed to your app(s).  If that fraction is small, then it may not be worth your while to try to reduce it.  For example, if you are spending 90% of your time in your app and 10% of your time in TCP/IP, then cutting the TCP/IP time in half would only net you a small change in your performance.

If your protocol is heavily acknowledged and you find yourself being performance bound by the performance of the protocol, any additions to latencies will end up making you slower, not faster.  All that is speculation on my part, of course.  You could be compute bound with a streaming TCP/IP output, in which case additions to latencies wouldn't have any effect at all.

As for the RTOS question, you can find some surprisingly small ones.  We have used uC/OS-II without being horrified by its size.  Depending on the CPU you are using in the coprocessor, you may find that you have some pretty good options.

I do believe that it would probably be easiest to put on a top layer as you describe, but I also think that it would be feasible to transport the messages to the tcp thread as you originally described.  As you note, there are some difficulties, and it is possible that the message contents will have to be augmented to deal with some of the existing data references.  In either event, you will almost certainly find yourself tinkering with the stack in one way or another.  The good news is that with a small open source project like this, it is definitely feasible to do this.  The bad news is that it can still be a fair amount of work.

I'm really a bit conflicted about this.  On the one hand, it does sound like a really interesting thing to do technically.  On the other, it may actually end up costing you in system performance.  I hope you'll be able to make a good analysis of the likely outcome before you commit yourself.

Curt McDowell wrote:
Thanks for the input, Jim.
 
>As for the performance improvement, that's a very significant question.  First, I think that it is important to ask what kind of performance improvement you seek.  If you are just seeking to offload the host, so that it can go on to do some other task faster, then you stand a reasonable chance of seeing that happen.  If you are ultimately seeking to increase TCP/IP throughput, that will be a more difficult road.

In our case, the host processor would be about 4 times as powerful as the coprocessor.  The coprocessor has some spare cycles, and it'll be there regardless of whether it ends up doing TOE.  The goal is simply to reduce CPU consumption on the host processor with no reduction in throughput. The MAC has no checksum acceleration, so that's actually one of the most important things to off-load.
 
 > I feel that your assessment of feasibility is sound and that your list of problems and their resolution is reasonably complete.  Something always shows up in implementation, and I'm sure that your project will be no exception, but I do think that your design is solid.
 
I'm finding that splitting the modules in the manner depicted is not so easy after all.  E.g., for efficiency reasons the top layer routine netconn_write() calls tcp_sndbuf(), which peeks in the bottom layer data structure.  It's tempting to just add a top layer to RPC the whole sockets API (but unfortunately, the tiny RTOS on the TOE processor would then need to support threads).
 
Regards,
Curt McDowell
Broadcom Corp.

Curt McDowell wrote:

Hi,

I'm looking into using lwIP as the basis for a TOE (TCP/IP offload engine).  If I understand correctly, the lwIP environment is implemented as one thread for the IP stack, and one thread for each application:

    APPLICATION THREAD                            IP STACK THREAD
App <-> Sockets <-> API-mux <------------> API-demux <-> Stack <-> netif
                            mbox transport

This architecture appears to lend itself fairly well to the following TOE implementation (actually, SOE, as it would be a full sockets offload):

         HOST PROCESSOR                     TOE ADAPTER W/ EMBEDDED CPU
+-------------+   +--------------+            +-------+   +----------+
| App using   |---| lwIP library |------------| lwIP  |---| Network  |--->
| sockets API |   | Sockets API  |  Hardware  | stack |   | hardware |
+-------------+   +--------------+    bus     +-------+   +----------+

- Does this assessment sound correct?
- Could a significant performance improvement be realized, compared to using a host-native IP stack?
- Is anyone else interested in this type of application?

The only problems that I see are with the mbox transport mechanism, in that it assumes a shared address space.

-  It would need to send the data, instead of pointers to the data.
-  It would need to send messages for event notifications instead of using callbacks.
- Message reception on either side of the hardware bus would be signaled through interrupts.

Thanks,
Curt McDowell
Broadcom Corp.  

 

--
Jim Gibbons
jim-GcqFwEuwCMlBDgjK7y7TUQ@public.gmane.org
Gibbons and Associates, Inc.
TEL: (408) 984-1441
900 Lafayette, Suite 704, Santa Clara, CA
FAX: (408) 247-6395


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

Gmane