OpenTCP Bug Fix Thread

[nerdboy]

Alright, so perhaps I'm the last person to still be using OpenTCP on the NE64, but I thought it might be nice if there were a bug fix thread on this forum since there don't seem to be too many other resources on the web...

-------
arp.c
-------

In void arp_get_response(void) :

for( i=1; i<ARP_TSIZE; i++ )

Should be changed to:

for( i=0; i<ARP_TSIZE; i++ )

 Arrays in C are indexed starting at zero, not one.  Your application will never be able to add the first target to its ARP table because of this. 

-----------------
Other notes
-----------------

If you're like me and used the Connector App as a starting point for your project, notice that you will have call RTI_Init() somewhere before you call RTI_Enable() in order for real-time interrupts to actually occur.  In main.c of the Connector App, this call is not made, and there are no real-time interrupts.  This causes unpredictable behaviour on all of the OpenTCP services which rely on real-time interrupts. 

I promise to paste in any other fixes I make.  Feel free to post your fixes here too. 

[BuddyB]

Hi, I have the following problem:

Under heavy bus load in direction HCS12 to computer (UDP) the HCS12's ethernet controller sometimes losts a package when the computer sends an UDP package back. I use the OpenTCP project NE64_Vend_OpenTCP.ZIP from sourceforge and have placed a counter which is increased by one before the udp_send(...) function is called. I can see that it's called as often as expected, but the package counter in wireshark is smaller than these counter so that some data packages are missing.

The higher the bus load the bigger the number of the missing packages. The udp_send() function never has a negative value. Is there any opportunity to see whether the ethernet controller is able to accept data?

Did anybody has this problem too?

How can data which is placed in the net_buf get lost?

[AROK]

Hi I'm using LWIP 1.4.0 stack with MPC5567. It's quite stable, but require around 35 k of flash and 35 of RAM ( UDP +  TCP and enough buffer to run a simple http server)

[WRS]

I realize this thread is a few years old, but I will start here.

We recently noticed that the dhcp client with OpenTCP is posting the chaddr in reverse order from the IP layer.

Also, I have found that in one of the projects, NE64withProcessorExpert, this code has been modified:

 /* chaddr */// *buf_ptr++=localmachine.localHW[5];// *buf_ptr++=localmachine.localHW[4];// *buf_ptr++=localmachine.localHW[3];// *buf_ptr++=localmachine.localHW[2];// *buf_ptr++=localmachine.localHW[1];// *buf_ptr++=localmachine.localHW[0]; *buf_ptr++=localmachine.localHW[0]; *buf_ptr++=localmachine.localHW[1]; *buf_ptr++=localmachine.localHW[2]; *buf_ptr++=localmachine.localHW[3]; *buf_ptr++=localmachine.localHW[4]; *buf_ptr++=localmachine.localHW[5]; buf_ptr+=10;

with no comment about the change.

My initial thoughts are that for local networks, this should make little difference as the DHCP server should be using the chaddr for issuing IP addresses, and only in the improbable situation that the transposed id conflicts with another hardware device.

I was just curious if anyone knew anything about this change and any other problems that might be encountered.

[J2MEJediMaster]

Reversing the order of bytes in an address like that looks like an Endian addressing fix-up, but I am guessing. I do not know anything about TCP implementations.

---Tom

[mjbcswitzerland]

Hi

Are you sure about this change?
The ARP table used by OpenTCP has a fixed Broadcast entry at the arp_table[0] position. See arp_init()

    /* set broadcast entry    */       qstruct = &arp_table[0];    qstruct->pradr = IP_BROADCAST_ADDRESS;    qstruct->state = ARP_RESOLVED;    qstruct->type = ARP_FIXED_IP;    qstruct->ttl = ARP_TIMEOUT;    qstruct->retries = ARP_MAXRETRY;

The reason that I know this is because the uTasker project also uses a similar method for its ARP table management. In fact it consistently uses the form (always looping from 1) except from when searching for existing entries:

    int i = 0;    while (++i < ARP_TABLE_ENTRIES) {         ...    }

 whereas OpenTCP usually loops from 0 and sometimes from 1.

Without studying all cases in detail I think that looping from 1 is in fact the correct method in all cases except from when doing a look up of the address to be sent to (when broadcast entry may need to be found). Starting from 0 is in all other cases possibly not an error but a wasted loop since the fixed broadcast entry never times out or is changed.

Check out also the uTasker forum at http://www.uTasker.com/forum/

This discusses general TCP/IP stack topics as well as the NE64 and M5223X Freescale devices.

Regards

Mark

www.uTasker.com

 

[nerdboy]

---

Are you sure about this change?
The ARP table used by OpenTCP has a fixed Broadcast entry at the arp_table[0] position. See arp_init()

---

You're right about the broadcast entry at zero, thanks Mark.  I had forgotten about it!  But OpenTCP won't exhibit proper ARP behaviour unless the ARP response processing starts looking at entry zero (supposedly the broadcast entry).  I'm wondering if there's a bug elsewhere where the broadcast entry is overwritten by a new ARP request, although I couldn't find anything after a scan through arp.c.  If I find the real cause I'll correct my proposed fix (hack) - if anyone else has any ideas, let me know!