TCP take 20 minutes to receive a packet

[macpherson]

See the code below. It blocks at "accept" then, about 20 minutes later, it continues.

Code: Select all

    while ( 1 )
    {
writestring( fdlancon, "Inside\r\n" );                                                 // serial port
      fdnet = accept( fdListen, &client_addr, &port, 0 );                       // it gets stuck here waiting
      writestring( fdlancon, MTS_WHEN_CONNECTION_OPENED );
sprintf(buf, "fdnet = %d\r\n", fdnet);
writestring( fdlancon, buf );

Thanks,
Ewan.

[rnixon]

Hi Ewan,

That was the code I was referring to, but my question was a little more involved. The accept() will block forever waiting for an incoming connection. So one good data point would be the time from which your PC (are you using a PC?) program tries to connect to the device (the time of the SYN), to when you see output on the serial port.

For example, if you run the MTTTY program to monitor serial output, then run telnet like "telnet x.x.x.x 19777", how much time does it take from when you hit <enter> on the keyboard to start the telnet session to when you see your serial debug message? Note that you need to substitute the IP address and port number you are actually using.

[macpherson]

Hi rnixon,

The device sending the packet is not a PC, it is an MCF52233. It worked just fine when the "network" code was in the "UserMain" without anything else blocking. When it currently sends a packet it gets no reply from the NetBurner for a long time, but it does not give up until the connection is successful. I have attached a WireShark image.

Thanks,
Ewan.

[rnixon]

There isn't any reason why the same code (emphasis on "same") should run different in usermain versus a task priority of 49. So we're missing something subtle here, or possibly not comparing the identical code. If you comment out the task creation, and change the task function call header so it can be called as just a function (not a task) from UserMain, does it work then?

[macpherson]

rnixon,

I don't want to wast anyone's time here. I have to tell you that I went back to the first tcp code that I had working with the external hardware and it now does not work. Something has changed. Of course, it changed when I went to a seperate task! Murphy is still laughing.

I thank all of you for your efforts and I will post the cause of the failure as soon as I know it.

Regards,
Ewan.

[macpherson]

Well, ladies & gentlemen,

Once again, thanks for all your efforts. Here is the story.

I noticed that the MAC address of the target (the netburner) is visible in the wireshark image (above). I idly checked the netburner MAC address lable and, lo, it was different. How could this be?

I had had a netburner module which died afer the MCF52233 had been set up for its target to have the fixed IP and MAC address of the MOD5270. I just replaced the bad MOD5270 with another and uploaded the software. Never again will I disable ARP!

I changed the MCF52233 to doing the ARP thing and all is working. The question which begs to be asked is "How on earth did the MOD5270 EVER get the data, even after 20 minutes?".

Regards to all,
Ewan.