No more answer on Ethernet after HTTP use

[fcereja]

Hi,
in the Simulator all works fine at the beginning after installation of SP8 for M5223X. ARP, Ping, ... There was no webpages already downloaded so the HHTP server return the 404 page. Then, no problem for downloading the pages with FTP. Ping works always ok after it.
But when I use the browser to get the pages (with http://<ip_address>) the browser times out, no page is returned. From this point, nothing works : no ping response, no FTP connection, ... The application must be exited and launched again for ping to work.
If I try to get the pages, again no response. I've tryed to set breakpoints and step through the code but nothing seems to go wrong the functions sending the response are called but nothing comes out. I've checked it with Ethereal.

What do I make wrong? Thanks anybody for help.
Regards.
Francis

[mark]

Hi Francis

I don't think that you are doing anything wrong, but I think that there is a problem with WinPCapand your NIC - although I can't say what.

Do you have the possibility of testing on a second PC to verify that this problem doesn't occur there?

What you could also try (as a comparison) is to install on of the executables http://www.utasker.com/Demos/exes/exes.html These are pre-built simulator projects. I expect that the same will happen with them but it would be interesting to verify this.

Regards

Mark

[fcereja]

Hi Mark,
thank you for your advice. I've loaded the last version of WinPcap and the behaviour is quite good. The application continues to answer to ping request and its remain possible to connect with ftp. The http server still doesn't serve the pages but we get a response "TCP previous segment lost ..." (see the attached wireshark capture).

I will try the sample application on a other PC.

Regards
Francis

[mark]

Hi Francis

It looks as though the web server is basically answering.

It sends two HTTP frames (windowing) but only the second one seems to actually get sent by the NIC.
I think it is best to first check on a different PC to see whether it is really restricted to this one. I don't think that I have seen this effect before - on one PC it was seen that after a number of transmissions (ping, FTP, HTTP - it didn't matter what) no more would work and the NIC had to be reset, but this only ever was seen on one PC (also a second NIC was tried, but without solving problem).


Regards

Mark

PS: By disabling #define HTTP_WINDOWING_BUFFERS     2 in config.h the HTTP windowing operation will be removed and then only single frames will be sent. It may work in this case, but it not really a solution to the problem.

[fcereja]

Hi Mark,
I've done several tests on 3 different PC. On machine with Intel processor it works nominally : one machine has a E5200 dual core, the other is a laptop under Linux with Windows XP in a virtual machine running under VmWare Workstation. For these two configuration no problem.
The other PC has an Athlon XP2500+ processor : I have the same problem as with mine which is a Athlon 64 bit Dual Core 4600+.
What are the differences making AMD processors working bad?

Disabling HTTP_WINDOWING_BUFFERS has no effect.

Amazing no?

Regards
Francis

[mark]

Hi Francis

This is strange indeed. I don't know why the processor type in the PC should have an effect but it really does seem to at your location.

Could you also check out the following two threads just to be sure that there is nothing there which could explain something?
http://www.utasker.com/forum/index.php?topic=180.0
http://www.utasker.com/forum/index.php?topic=290.0

Regards

Mark

[jnewcomb]

I too have had some problems getting the NIC recognised in the simulator. (VS2008, XP)
It worked the first time.. but after that nothing, not even an answer to a ping.
To get it back I did the following:
Closed the simulator -> deleted the NIC.ini file -> restarted the simulator -> reselected the interface from the menu:
Hay presto : it worked again.

So, I investigated what happens in the handler for dropdown NIC selector .v. what happens during the application startup..
This is what happens when the drop down is selected.. - in SetNIC(..)

case IDOK:
  if (iNewSelection != iactive) {
  if (iUserNIC < 0) {
    iactive = iNewSelection;
    fnWinPcapClose();                            // close present adapter
    fnWinPcapSelectLAN(iNewSelection);
    fnWinPcapOpenAdapter();
  }
  iUserNIC = iNewSelection;
}

This is what happens during the application startup.. - in WndProc(..)
 case WM_CREATE:
#ifdef ETH_INTERFACE                                                     // {10}
    iUserNIC = fnGetUserNIC();
    fnWinPcapSelectLAN(iUserNIC);                                // select the NIC according to the user setting        
#endif

__
I noticed when the application is started up, the NIC was selected, but not started up. I added the following lines, and fixed the compile errors and hey presto.. it worked. Green lights flashing again!

case WM_CREATE:
#ifdef ETH_INTERFACE                                                     // {10}
  iUserNIC = fnGetUserNIC();fnWinPcapSelectLAN(iUserNIC);                                // select the NIC according to the user setting
 fnWinPcapOpenAdapter();
  fnWinPcapStartLink(ghWnd);
#endif

I have a number of possible interfaces to select, so it could be getting confused.
Also, I ended up changing the code that checks the selection had changed, this gave more reliable 'switching' between different interfaces while running. The condition: "if (iUserNIC < 0)" was never satisfied, and hence, never changed the interface.
case IDOK:
  if (iNewSelection != iactive) {
    if (iNewSelection >= 0) {
      fnWinPcapClose();                            // close present adapter
      fnWinPcapSelectLAN(iNewSelection);
      fnWinPcapOpenAdapter();
    }
    iactive = iNewSelection;
    iUserNIC = iNewSelection;
  }

This caused the NIC to startup reliably in the sim, and change following a reselection in the drop down.

Not saying I fixed it, its just what got me working.
I'm hoping I have not introduced a new bug in the process!!
These problems could be linked to having a long list of interfaces in the drop down list. In my case 4. I have to select the third of 4.
Post here if this helps..
Jon.

EDIT:
The application sometimes crashes on startup, and the green LEDs dont work too well.. but it is responding ok.
I think there is a threading issue with PCap and the Windows application.
A better solution anybody?

[mark]

Hi Jon

I recently had a problem with the NIC. It always worked when I first set the interface but after a restart it stopped.

I was using the SAM7X package and had set up a project without PHY interrupt and at first couldn't understand why it only worked when I had deleted the NIC.ini and set the interface again... until I finally realised that in

extern void fnConfigEthernet(ETHTABLE *pars) (in sam7x.c)

    fnOpenDefaultHostAdapter();                                          // simulate link up

was not being called. This meant that the WINPCAP thread was never being started. (It was however started on a NIC setting change, which caused it to work in that case)

After I moved the fnOpenDefaultHostAdapter() so that it also gets called when no PHY interrupt is configured (it shouldn't be dependent on the PHY interrupt, just the Ethernet configuration) the problem disappeared. This change is also prepared in the development code ready for the next release. Does it perhaps explain your problem?

Regards

Mark

[jnewcomb]

Thanks.. I nearly got there! I was calling fnOpenDefaultHostAdapter earlier on... unconditionally (bad)
fnConfigEthernet() is the obvious place to call it.. Thanks for pointing me to a better solution!

In summary:
When LAN_REPORT_ACTIVITY is commented out, INTERRUPT_TASK_PHY is not defined and WINCAP thread is not started.
To Fix it, I moved fnOpenDefaultHostAdapter(); in SAM7X.c :
#if defined SUPPORT_PORT_INTERRUPTS
    #if defined INTERRUPT_TASK_PHY
    interrupt_setup.int_type = PORT_INTERRUPT;                           // identifier when configuring
    interrupt_setup.int_handler = fnPhyInterrupt;                        // handling function
    interrupt_setup.int_priority = PRIORITY_PIOB;                        // port interrupt priority
    interrupt_setup.int_port = PORT_B;                                   // the port used
    interrupt_setup.int_port_sense = IRQ_FALLING_EDGE;                   // interrupt on this edge
    interrupt_setup.int_port_bits = PHY_INTERRUPT;                       // the input connected
    fnConfigureInterrupt((void *)&interrupt_setup);                      // configure test interrupt

    fnWriteMII(KS8721_INTERRUPT_CONTROL_STATUS_REGISTER,                 // enable various PHY interrupts
//             PHY_REMOTE_FAULT_INT_ENABLE
//             PHY_LINK_PARTNER_ACK_INT_ENABLE
//             PHY_PARALLEL_DETECT_FAULT_INT_ENABLE
//             PHY_PAGE_RECEIVED_INT_ENABLE
//             PHY_RECEIVE_ERROR_INT_ENABLE
//             PHY_JABBER_INT_ENABLE
              (PHY_LINK_UP_INT_ENABLE | PHY_LINK_DOWN_INT_ENABLE)
               );
    #endif
#else
    fnEnterInterrupt(PIOB, PRIORITY_PIOB, PortB_Interrupt);
    PIO_IER_B = PHY_INTERRUPT;                                           // enable interrupt line from PHY
    #ifdef _WINDOWS
    PIO_IMR_B |= PIO_IER_B;
    #endif
    fnWriteMII(KS8721_INTERRUPT_CONTROL_STATUS_REGISTER,                 // enable various PHY interrupts
//             PHY_REMOTE_FAULT_INT_ENABLE
//             PHY_LINK_PARTNER_ACK_INT_ENABLE
//             PHY_PARALLEL_DETECT_FAULT_INT_ENABLE
//             PHY_PAGE_RECEIVED_INT_ENABLE
//             PHY_RECEIVE_ERROR_INT_ENABLE
//             PHY_JABBER_INT_ENABLE
              (PHY_LINK_UP_INT_ENABLE | PHY_LINK_DOWN_INT_ENABLE)
               );
#endif
#ifdef _WINDOWS
   // Moved by JN, fnOpenDefaultHostAdapter should be called at all times, not just when the INTERRUPT_TASK_PHY
   // is defined. Ref: http://www.utasker.com/forum/index.php?topic=542.0
   fnOpenDefaultHostAdapter();                                          // simulate link up
#endif
}