EtherLinkCallback doesn't execute on first load

[John.Ohl]

If the ethernet cable is unplugged on device boot (MOD5270 & MOD5270B), when you plug it in for the very first time, EtherLinkCallback isn't executed.

The problem comes from the following snippet in MOD5270/system/ethernet.cpp:

Code: Select all

            if( !bEverHadLink ) // Is this the first link since a full ethernet reset
            {
               bEverHadLink = TRUE;
               ResetEnetPart2();
               return;
            }
 

bEverHadLink would be set to false, causing the function to return and the callback to never be executed indicating that the ethernet interface has come up.

Solution:

Code: Select all

            if( !bEverHadLink ) // Is this the first link since a full ethernet reset
            {
               bEverHadLink = TRUE;
               ResetEnetPart2();
               if (EtherLinkCallback) {
                  (*EtherLinkCallback)(TRUE);
               }
               return;
            }
 

[John.Ohl]

Side note on the fix I suggested, it will also cause the callback to be executed the very first time the ethernet comes up, even if the cable was plugged in on boot. I find this helpful since I'd expect it to notify me every time the link came up, regardless of it's initial status. If someone else wanted it another way, they could always set the EtherLinkCallback pointer after InitializeStack is called instead of before it.

If this isn't desirable for other's, we'd have to add a check to ensure that the link was down on boot, before executing the callback on the first UP.

Any thoughts?

[dciliske]

Hmm... this is a tricky subject. If the cable is plugged in on boot, this section of code would trigger a link callback after the OS was running (a good thing), but before the IP stack has finished being initialized (probably a bad thing). In my personal opinion, this should not occur. There is an implicit expectation by users that if the ethernet is running, so is the IP stack, which is true in almost every meaningful moment in time, except here. What this means is that someone is (very rightfully) going to put some sort of IP or higher level code into the callback. What I cannot guarantee is that there will be no ill side effects of doing so before the IP stack is initialized.

I agree that it would probably make sense to be able to handle a late connection to generate a callback, but this will have to wait to be examined.

-Dan

[John.Ohl]

Interesting point.. Perhaps approaching this from a different angle would be better. Possibly having a callback executed or a variable set at the very end of the InitializeStack function, that way it would be guaranteed the stack was at least finished initializing before the callback is executed.

Quite the conundrum.