headers
Leon Woestenberg | 1 Jan 2005 22:54

lwIP 1.1.0 released

Hello all,

all the best wishes to everyone on the lists.

I have just released lwIP 1.1.0.

It is tagged STABLE-1_1_0 on CVS, archive files (tar, zip) will appear 
shortly on Savannah.

Also, as usual, I have created a branch called "STABLE-1_1" where future 
1.1.x releases
(bug fixes only releases) will appear. Main development continues on the 
root CVS branch.

Porters are encouraged to update their ports and tag them in the contrib 
module with
"STABLE-1_1_0" once they have tested their ports against 1.1.0.

Regards,

Leon Woestenberg.
Permalink | Reply | 5 comments |
headers
Leon Woestenberg | 2 Jan 2005 14:53

Re: lwIP 1.1.0 released

Hello,

>
> all the best wishes to everyone on the lists.
>
> I have just released lwIP 1.1.0.
>
See http://savannah.nongnu.org/download/lwip/

for direct downloads.

Leon.
Permalink | Reply | 3 comments |
headers
Jim Gibbons | 2 Jan 2005 17:30

Re: lwIP 1.1.0 released

Thank you!

Could we prevail upon you for a "state of lwIP" note?  It could be seen 
as timely at the New Year, and with this new release.  It's hard for me, 
and perhaps for others, to accurately judge the big picture from the 
daily flow of detail oriented messages.

Could you tell us what you think is truly stable and good?  where you 
think the development frontiers lie?  and perhaps where lwIP should not 
be taken?

Thanks again from all of us for all of your efforts.  I couldn't help 
but notice a flurry of holiday activity on your part - just when most of 
us are kicking back.  We really do appreciate it.

Leon Woestenberg wrote:

> Hello,
>
>>
>> all the best wishes to everyone on the lists.
>>
>> I have just released lwIP 1.1.0.
>>
> See http://savannah.nongnu.org/download/lwip/
>
> for direct downloads.
>
> Leon.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Leon Woestenberg | 2 Jan 2005 19:14

Re: lwIP 1.1.0 released

Hello Jim,

Jim Gibbons wrote:

> Could we prevail upon you for a "state of lwIP" note?  It could be 
> seen as timely at the New Year, and with this new release.  It's hard 
> for me, and perhaps for others, to accurately judge the big picture 
> from the daily flow of detail oriented messages.
>
Good point.

> Could you tell us what you think is truly stable and good?  where you 
> think the development frontiers lie?  and perhaps where lwIP should 
> not be taken?
>
 From my news announcement on Savannah:

"Release 1.1.0 improves TCP throughput performance, fixes some small 
bugs in TCP, and annoying bugs in the ARP cache and ARP packet queueing. 
Check the CHANGELOG for details."

In general, this is my impression:

The lwIP 1.1.0 core is as stable as 0.7.2 in general, which has proven 
production quality.
It is more correct/stable regarding TCP operation, as well as more 
performant in TCP.
Outgoing packet queueing is stable (but limited to one packet per ARP entry,
the multipacket implementation clashed with TCP's queue.)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul C | 4 Jan 2005 04:16
Picon

Lwip 1.1.0 upd_send

Hi List,

I use 
            err = udp_connect( Shout, IP_ADDR_ANY, A_PORT);
            err = udp_send(Shout, pcb);

With LWIP 1.1.0 release the udp is sent to 0.0.0.0 I have this patch 
in udp.c to make it use the network address (which is what I want).
Am I using udp_connect/ udp_send wrongly or is this a patch
that should be in lwip? Should I really use IP_ADDR_BROADCAST here 
instead?

Thanks 

Paul Clarke

 <at>  <at>  -448,16 +448,22  <at>  <at>  udp_send(struct udp_pcb *pcb, struct pbu
   /* PCB local address is IP_ANY_ADDR? */
   if (ip_addr_isany(&pcb->local_ip)) {
     /* use outgoing network interface IP address as source address */
     src_ip = &(netif->ip_addr);
   } else {
     /* use UDP PCB local IP address as source address */
     src_ip = &(pcb->local_ip);
   }
+  /* PCB remote address is IP_ANY_ADDR? */
+  if (ip_addr_isany(&pcb->remote_ip)) {
+    /* use outgoing network interface network address as destination
address */
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul C | 4 Jan 2005 04:42
Picon

Re: Lwip 1.1.0 upd_send

I notice that dhcp.c uses 

    /* set remote IP association to any DHCP server */
    udp_bind(dhcp->pcb, IP_ADDR_ANY, DHCP_CLIENT_PORT);
    udp_connect(dhcp->pcb, IP_ADDR_ANY, DHCP_SERVER_PORT);
    /* broadcast to server */
    udp_sendto(dhcp->pcb, dhcp->p_out, IP_ADDR_BROADCAST,
    DHCP_SERVER_PORT);

and also 

    udp_bind(dhcp->pcb, IP_ADDR_ANY, DHCP_CLIENT_PORT);
    udp_connect(dhcp->pcb, IP_ADDR_BROADCAST, DHCP_SERVER_PORT);
    LWIP_DEBUGF(DHCP_DEBUG | DBG_TRACE | DBG_STATE, ("dhcp_inform:
    INFORMING\n"));
    udp_send(dhcp->pcb, dhcp->p_out);
    udp_connect(dhcp->pcb, IP_ADDR_ANY, DHCP_SERVER_PORT);

Is there a reason why udp_sendto(,,,) cannot be used in the second case?
What is the prefered way to send/receive a broadcast address?
1)
bind (ANY)
connect(ANY)
udp_sendto(BROADCAST)

OR 
2)
bind (ANY)
connect(BROADCAST)
udp_Send( )
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Frost | 4 Jan 2005 05:41

Re: slip recvs corrupted packets

On Wed, Dec 15, 2004 at 12:15:01PM +0100, christiaan.simons@... wrote:
> > These two example ip headers probably don't say anything obvious, but I
> was
> > curious if they might?
> 
> The IP checksum failure could be caused
> by a malfunction in the slip driver.
> 
> I'm unfamliar with this code, but if it is true what you say
> "slipf_loop() appears to be designed for  multithread programs"
> then this might be the culprit.

Thanks for this suggestion, this lead to my finding the problem and correcting
not long after your message. (That next day I had lwip pingable and tcp
mostly working, thank you!)

The problem and my solution, in case it might be helpful for others:

lwip's slipif driver is designed to use threads, but I wanted all of lwip
to run in one process as my port isn't multithreaded [yet]. The solution
is pretty straightforward, instead of using two threads and letting the
os do scheduling, I changed slipif slightly to be able to run an iteration
at a time and run an iteration inside of the loop that calls tcp_tmr().

More specifically, I added a new slipif_loop_iter() to use instead of
slipif_loop():

static void
slipif_loop(void *nf)
{
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Anburaj | 4 Jan 2005 09:11
Picon
Favicon

ERR_RST is returned by netconn_write()

Hi,

LwIP source: CVS, pulled today <same problem is seen
using various other versions too>

When my http serv application sends file contents of
sizes around 2018 bytes by calling netconn_write(),
ERR_RST is returned by it.

Before I get down to debug this any further, let me
know of any ideas or clue on this.

Thanks,
-Mike.

		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250
Permalink | Reply | 0 comments |
headers
christiaan.simons | 4 Jan 2005 10:25
Picon

Re: lwIP 1.1.0 released


lwip-users-bounces+christiaan.simons=axon.tv@... wrote
on 01-01-2005
22:54:27:

> Porters are encouraged to update their ports and tag them in the contrib
> module with "STABLE-1_1_0" once they have tested their ports against
1.1.0.

Tagged the c16x port as STABLE-1_1_0 since it proved
to be stable for the release candidate.

Bye,

Christiaan Simons

Software Engineer
Axon Digital Design

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

christiaan.simons@...
http://www.axon.tv
Permalink | Reply | 0 comments |
headers
Leon Woestenberg | 4 Jan 2005 13:11

Re: Lwip 1.1.0 upd_send

Hello,

sendto() was later added, so I recon send() is the old method in DHCP,
and non-converted code is floating around.  This should be tracable from
CVS, unfortunately I cannot remember the details.

> What is the prefered way to send/receive a broadcast address?
> 1)
> bind (ANY)
> connect(ANY)
> udp_sendto(BROADCAST)
> 
This looks preferable to me, as the sendto() will not affect the
connection.

Regards,

Leon.
Permalink | Reply | 0 comments |

Gmane