[lwip-users] [lwip] cs8900a dropping Rx packets on failing Tx - discussion

[leon . woestenberg]

--0__=4EBBE684DFAB601D8f9e8a93df938690918c4EBBE684DFAB601D
Content-type: text/plain; charset=us-ascii


Hello Duncan et al,

while I was enjoying my holiday you have encountered some stupidities in my
cs8900a driver.

1) I'm dropping Rx packets from the cs8900a buffer space if a Tx packets
cannot be sent (mostly
because that buffer space is full).

2) You mention "a serious bug". Do you mean the 16-bit depencies? Patches
are welcomed, I
do not have the time to test 8-bit I/O at this time.

Regarding to problem (1): the etharp.c module in the newer lwIP versions
does in fact support
some way of caching IP packet(s?!) behind each IP address in the ARP cache.

A possibility is to use this cache also when a packet could not be send
because of a chip
buffer full condition.

This will be my approach in solving the issue.

Whilst browsing the ARP code to do this, I may have found some new ARP
issues though which
I'll try to tackle first.

Regards,

Leon Woestenberg

Axon Digital Design
Phone: +31 13 511 6666
Fax: +31 13 511 4151
web: www.axon.tv

================================================================================

=====================
The information contained in this communication is confidential and is
intended
solely for the use of the individual or entity to whom it is addressed.
Axon
Digital Design Group is neither liable for the proper nor for the complete
transmission of the information contained in this communication nor for any

delay in its receipt. Axon Digital Design Group does not guarantee that the

integrity of this communication has been maintained nor that the
communication
is free of viruses, interceptions or interference. If you are not the
intended
recipient of this communication, you are hereby notified that reading,
disseminating, distributing or copying this message is strictly prohibited.
In
that case please return the communication to the sender and delete and
destroy
all copies. In carrying out its engagements, Axon Digital Design Group
applies
general terms and conditions, which contain a clause that limits its
liability.
A copy of these terms and conditions is available on request free of
charge.
================================================================================

=====================


                                                                                
                                                       
                      Duncan Palmer                                             
                                                       
                      <address@hidden        To:       address@hidden           
                                                       
                      group.com>               cc:                              
                                                       
                      Sent by:                 Subject:  [lwip] Buglet in 
lwip_recvfrom() [patch]                                      
                      address@hidden                                            
                                                    
                      e                                                         
                                                       
                                                                                
                                                       
                                                                                
                                                       
                      02-08-2002 12:10                                          
                                                       
                      Please respond to                                         
                                                       
                      lwip                                                      
                                                       
                                                                                
                                                       
                                                                                
                                                       




lwip_recvfrom() was converting the port number of the incoming connection
into network byte order which is incorrect - the socket structures are
sposed
to contain information in host byte order. udp_input() and tcp_input()
convert port numbers into host byte order, and udp_send() and tcp_output()
convert the port numbers back into network byte order. One-liner patch
attached...
(See attached file: sockets.c.patch)


--0__=4EBBE684DFAB601D8f9e8a93df938690918c4EBBE684DFAB601D
Content-type: application/octet-stream; 
        name="sockets.c.patch"
Content-Disposition: attachment; filename="sockets.c.patch"
Content-transfer-encoding: base64

LS0tIGx3aXAtY3ZzLTIwMDIwNTI5L3NyYy9hcGkvc29ja2V0cy5jCVdlZCBNYXkgMjkgMTU6MDA6
MTYgMjAwMg0KKysrIHRjcGlwL3NyYy9hcGkvc29ja2V0cy5jCVRodSBBdWcgIDEgMTk6MDM6NTcg
MjAwMg0KQEAgLTI2OSw3ICsyNjksNyBAQA0KICAgLyogQ2hlY2sgdG8gc2VlIGZyb20gd2hlcmUg
dGhlIGRhdGEgd2FzLiAqLw0KICAgaWYoZnJvbSAhPSBOVUxMICYmIGZyb21sZW4gIT0gTlVMTCkg
ew0KICAgICBhZGRyID0gbmV0YnVmX2Zyb21hZGRyKGJ1Zik7DQotICAgIHBvcnQgPSBodG9ucyhu
ZXRidWZfZnJvbXBvcnQoYnVmKSk7ICANCisgICAgcG9ydCA9IG5ldGJ1Zl9mcm9tcG9ydChidWYp
OyAgDQogICAgICgoc3RydWN0IHNvY2thZGRyX2luICopZnJvbSktPnNpbl9hZGRyLnNfYWRkciA9
IGFkZHItPmFkZHI7DQogICAgICgoc3RydWN0IHNvY2thZGRyX2luICopZnJvbSktPnNpbl9wb3J0
ID0gcG9ydDsNCiAgICAgKmZyb21sZW4gPSBzaXplb2Yoc3RydWN0IHNvY2thZGRyX2luKTsNCg==

--0__=4EBBE684DFAB601D8f9e8a93df938690918c4EBBE684DFAB601D--

[This message was sent through the lwip discussion list.]