for( i=1; i<ARP_TSIZE; i++ ) Should be changed to: for( i=0; i<ARP_TSIZE; i++ )
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?
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)
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.
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
/* 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;
int i = 0; while (++i < ARP_TABLE_ENTRIES) { ... }
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!
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()