[ECOS] connect ethernet cable at run-time

[ECOS] connect ethernet cable at run-time

[Lars Dahlin]

Hi all!
I have the following problem:
I want to be able to connect the ethernet cable and it shouldn't be necesary to
restart ecos. As far as I know (please correct me if i'm wrong) incoming ip
and arp requests are handled by the thread cyg_netint. It seems that this thread
is put to sleep if the network cable is not connected.

I can see two possiblilties:
1) Not to let the thread cyg_netint be put to sleep, even if cable is
not connected.
2) When the network cable is connected, cyg_netint wakes up and does its thing.

Or is there a better way? The problem is that i dont know how to do either way.

All ideas are welcome. Thank you in advance.

Best Regards
Lars Dahlin

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] connect ethernet cable at run-time

[Edgar Grimberg]

Hi Lars,

> 2) When the network cable is connected, cyg_netint wakes up and does its thing.

You can write an interrupt routine for the PHY chip and have that
start/stop the ethernet.
As an example, look at:
static cyg_uint32 phy_isr(cyg_vector_t vector, cyg_addrword_t data)
static void phy_dsr(cyg_vector_t vector, cyg_ucount32 count,
cyg_addrword_t data)
from
http://www.ecosforge.net/ecosforge/trunk/ecos_mpc8313/packages/devs/eth/powerpc/quicc2pro/current/src/tsec.c


Regards,
Edgar



>
> Or is there a better way? The problem is that i dont know how to do either way.
>
> All ideas are welcome. Thank you in advance.
>
> Best Regards
> Lars Dahlin
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>



-- 
Edgar Grimberg
System Developer
Zylin AS
ZY1000 JTAG Debugger http://www.zylin.com/zy1000.html
Phone: (+47) 51 63 25 00

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: connect ethernet cable at run-time

[Grant Edwards]

On 2009-09-24, Lars Dahlin <haraxidix@gmail.com> wrote:

> I want to be able to connect the ethernet cable and it
> shouldn't be necesary to restart ecos.

We've been using eCos for 10 years, and we've never found it
necessary to restart eCos (or the network stack, or anything
else) when the Ethernet link goes down/up.

> As far as I know (please correct me if i'm wrong) incoming ip
> and arp requests are handled by the thread cyg_netint. It
> seems that this thread is put to sleep if the network cable is
> not connected.

Again, I've never seen that.  We connect/disconnect Ethernet
cables all the time, and never have to restart anything.  

We do have code in our Ethernet drivers that makes sure that
the Ethernet MAC duplex setting is changed to match the PHY's
negotiation results when a cable is plugged in, but I don't
think that has anything to do with what you're talking about.

-- 
Grant Edwards                   grante             Yow! Clear the laundromat!!
                                  at               This whirl-o-matic just had
                               visi.com            a nuclear meltdown!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: connect ethernet cable at run-time

[Jonathan Larmour]

Grant Edwards wrote:
> On 2009-09-24, Lars Dahlin <haraxidix@gmail.com> wrote:
> 
> 
>>I want to be able to connect the ethernet cable and it
>>shouldn't be necesary to restart ecos.
> 
> 
> We've been using eCos for 10 years, and we've never found it
> necessary to restart eCos (or the network stack, or anything
> else) when the Ethernet link goes down/up.
> 
> 
>>As far as I know (please correct me if i'm wrong) incoming ip
>>and arp requests are handled by the thread cyg_netint. It
>>seems that this thread is put to sleep if the network cable is
>>not connected.
> 
> 
> Again, I've never seen that.  We connect/disconnect Ethernet
> cables all the time, and never have to restart anything.  
> 
> We do have code in our Ethernet drivers that makes sure that
> the Ethernet MAC duplex setting is changed to match the PHY's
> negotiation results when a cable is plugged in, but I don't
> think that has anything to do with what you're talking about.

I think the issue may be that if you start the device with it 
disconnected, nothing _automatically_ will bring the interface up using 
BOOTP/DHCP. Static IP should probably be ok. That's a different scenario 
to being up and then being disconnected and reconnected as the interface 
already has an IP address (as long as it's reconnected within the DHCP 
lease expiry time).

I believe you should just be able to call init_all_network_interfaces() 
again, when your PHY spots the cable is inserted. If you don't have an 
interrupt for your PHY to detect that, you'll need to have a thread poll 
it. Note that init_all_network_interfaces needs to be run from a thread 
context in any case, not an ISR or DSR context.

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: connect ethernet cable at run-time

[Grant Edwards]

On 2009-09-24, Jonathan Larmour <jifl@jifvik.org> wrote:
> Grant Edwards wrote:
>> On 2009-09-24, Lars Dahlin <haraxidix@gmail.com> wrote:
>> 
>>>I want to be able to connect the ethernet cable and it
>>>shouldn't be necesary to restart ecos.

[...]

>> Again, I've never seen that.  We connect/disconnect Ethernet
>> cables all the time, and never have to restart anything.  
>> 
>> We do have code in our Ethernet drivers that makes sure that
>> the Ethernet MAC duplex setting is changed to match the PHY's
>> negotiation results when a cable is plugged in, but I don't
>> think that has anything to do with what you're talking about.
>
> I think the issue may be that if you start the device with it 
> disconnected, nothing _automatically_ will bring the interface
> up using BOOTP/DHCP.

If one calls init_all_network_interfaces() before the Ethernet
link is up does the DHCP code give up and terminate?  IOW,
doesn't the DHCP client code retry if it doesn't get a
response?  That seems a bit odd.


-- 
Grant Edwards                   grante             Yow! I don't know WHY I
                                  at               said that ... I think it
                               visi.com            came from the FILLINGS in
                                                   my rear molars ...


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: connect ethernet cable at run-time

[Jonathan Larmour]

Grant Edwards wrote:
> On 2009-09-24, Jonathan Larmour <jifl@jifvik.org> wrote:
> 
>>Grant Edwards wrote:
>>
>>>On 2009-09-24, Lars Dahlin <haraxidix@gmail.com> wrote:
>>>
>>>
>>>>I want to be able to connect the ethernet cable and it
>>>>shouldn't be necesary to restart ecos.
> 
> 
> [...]
> 
> 
>>>Again, I've never seen that.  We connect/disconnect Ethernet
>>>cables all the time, and never have to restart anything.  
>>>
>>>We do have code in our Ethernet drivers that makes sure that
>>>the Ethernet MAC duplex setting is changed to match the PHY's
>>>negotiation results when a cable is plugged in, but I don't
>>>think that has anything to do with what you're talking about.
>>
>>I think the issue may be that if you start the device with it 
>>disconnected, nothing _automatically_ will bring the interface
>>up using BOOTP/DHCP.
> 
> 
> If one calls init_all_network_interfaces() before the Ethernet
> link is up does the DHCP code give up and terminate?  IOW,
> doesn't the DHCP client code retry if it doesn't get a
> response?  That seems a bit odd.

I don't believe it does retry at present.

See for example in dhcp_prot.c that do_dhcp() calls no_lease(), whicih 
disables and deletes the alarm. Without that the needs_attention semaphore 
is not posted and the dhcp management thread gets stuck waiting on it. 
That's my belief anyway.

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: connect ethernet cable at run-time

[Laurie Gellatly]

On 25/09/2009, at 10:11 AM, Jonathan Larmour <jifl@jifvik.org> wrote:

> Grant Edwards wrote:
>> On 2009-09-24, Jonathan Larmour <jifl@jifvik.org> wrote:
>>> Grant Edwards wrote:
>>>
>>>> On 2009-09-24, Lars Dahlin <haraxidix@gmail.com> wrote:
>>>>
>>>>
>>>>> I want to be able to connect the ethernet cable and it
>>>>> shouldn't be necesary to restart ecos.
>> [...]
>>>> Again, I've never seen that.  We connect/disconnect Ethernet
>>>> cables all the time, and never have to restart anything.
>>>> We do have code in our Ethernet drivers that makes sure that
>>>> the Ethernet MAC duplex setting is changed to match the PHY's
>>>> negotiation results when a cable is plugged in, but I don't
>>>> think that has anything to do with what you're talking about.
>>>
>>> I think the issue may be that if you start the device with it  
>>> disconnected, nothing _automatically_ will bring the interface
>>> up using BOOTP/DHCP.
>> If one calls init_all_network_interfaces() before the Ethernet
>> link is up does the DHCP code give up and terminate?  IOW,
>> doesn't the DHCP client code retry if it doesn't get a
>> response?  That seems a bit odd.
>
> I don't believe it does retry at present.
>
> See for example in dhcp_prot.c that do_dhcp() calls no_lease(),  
> whicih disables and deletes the alarm. Without that the  
> needs_attention semaphore is not posted and the dhcp management  
> thread gets stuck waiting on it. That's my belief anyway.
>
> Jifl
> -- 
> --["No sense being pessimistic, it wouldn't work anyway"]--  
> Opinions==mine
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos- 
> discuss
>
With my project I found some interesting things with DHCP and network  
cables. If the network cable was unplugged at startup then there is no  
IP address. I found that I could run out of file handles and that  
DHCPinit call would never return even if the cable was later inserted.  
I had to work around that and then regularly call  
init_all_network_interfaces in the main TCP listening task just after  
it also fed the watchdog if the IP address was 0.0.0.0.
Switching in and out of DHCP or static addressing was also coded.

                  ...Laurie:{) 

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: connect ethernet cable at run-time

[Grant Edwards]

On 2009-09-25, Jonathan Larmour <jifl@jifvik.org> wrote:
> Grant Edwards wrote:

>> If one calls init_all_network_interfaces() before the Ethernet
>> link is up does the DHCP code give up and terminate?  IOW,
>> doesn't the DHCP client code retry if it doesn't get a
>> response?  That seems a bit odd.
>
> I don't believe it does retry at present.

Our customers very rarely use DHCP, so I guess we've never
tripped over that one. It doesn't really sound like acceptible
behavior for an embedded product does it?

> See for example in dhcp_prot.c that do_dhcp() calls
> no_lease(), whicih disables and deletes the alarm. Without
> that the needs_attention semaphore is not posted and the dhcp
> management thread gets stuck waiting on it.  That's my belief
> anyway.

I'm sure you're right.  It never even occurred to me that an
embedded DHCP client would act that way.  I'm pretty sure it
wouldn't be considered tolerable in any of the applications
where our eCos based products are used.  I'll have to file a
bug. :/

-- 
Grant



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: connect ethernet cable at run-time

[Grant Edwards]

On 2009-09-25, Laurie Gellatly <laurie.gellatly@netic.com> wrote:

> With my project I found some interesting things with DHCP and
> network cables. If the network cable was unplugged at startup
> then there is no IP address. I found that I could run out of
> file handles

Does that happen because of something the DHCP client task is
doing?

> and that DHCPinit call would never return even if the cable
> was later inserted.  I had to work around that and then
> regularly call init_all_network_interfaces in the main TCP
> listening task just after it also fed the watchdog if the IP
> address was 0.0.0.0.

Wouldn't fixing the DHCP client code be a better approach?

> Switching in and out of DHCP or static addressing was also
> coded.

Most of our products require you to reboot the device after
changing the IP configuration.

-- 
Grant



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: connect ethernet cable at run-time

[Laurie Gellatly]

On 25/09/2009, at 1:14 PM, Grant Edwards <grant.b.edwards@gmail.com>  
wrote:

> On 2009-09-25, Laurie Gellatly <laurie.gellatly@netic.com> wrote:
>
>> With my project I found some interesting things with DHCP and
>> network cables. If the network cable was unplugged at startup
>> then there is no IP address. I found that I could run out of
>> file handles
>
> Does that happen because of something the DHCP client task is
> doing?
It's a little time ago now but from memory I changed the client  
behaviour.
>
>> and that DHCPinit call would never return even if the cable
>> was later inserted.  I had to work around that and then
>> regularly call init_all_network_interfaces in the main TCP
>> listening task just after it also fed the watchdog if the IP
>> address was 0.0.0.0.
>
> Wouldn't fixing the DHCP client code be a better approach?
So I did change that but the solution required more. So first I had to  
make it return even if no address could be obtained (not doing so made  
the watchdog bark).
>
>> Switching in and out of DHCP or static addressing was also
>> coded.
>
> Most of our products require you to reboot the device after
> changing the IP configuration.
>
Once i'd made these changes my web server (main TCP task) then knew it  
could not do it's work and instead tries to obtain an address on a  
regular basis. The net result is that switching DHCP on or off can be  
achieved without a reboot.
> -- 
> Grant
>
>
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos- 
> discuss
>
          ...Laurie:{)

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: connect ethernet cable at run-time

[Jonathan Larmour]

Laurie Gellatly wrote:
> On 25/09/2009, at 10:11 AM, Jonathan Larmour <jifl@jifvik.org> wrote:
>> Grant Edwards wrote:
>>>
>>> If one calls init_all_network_interfaces() before the Ethernet
>>> link is up does the DHCP code give up and terminate?  IOW,
>>> doesn't the DHCP client code retry if it doesn't get a
>>> response?  That seems a bit odd.
>> I don't believe it does retry at present.
>>
>> See for example in dhcp_prot.c that do_dhcp() calls no_lease(),  
>> whicih disables and deletes the alarm. Without that the  
>> needs_attention semaphore is not posted and the dhcp management  
>> thread gets stuck waiting on it. That's my belief anyway.
>>
> With my project I found some interesting things with DHCP and network  
> cables. If the network cable was unplugged at startup then there is no  
> IP address. I found that I could run out of file handles and that  
> DHCPinit call would never return even if the cable was later inserted.  
> I had to work around that and then regularly call  
> init_all_network_interfaces in the main TCP listening task just after  
> it also fed the watchdog if the IP address was 0.0.0.0.
> Switching in and out of DHCP or static addressing was also coded.

I think it would be hard to shield the DHCP code from insufficient file 
handles. But yes that does confirm that an unplugged cable at startup 
means no IP address unless the user calls init_all_network_interfaces again.

In this respect, the DHCP code wants improvement.

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: connect ethernet cable at run-time

[Grant Edwards]

On 2009-09-25, Jonathan Larmour <jifl@jifvik.org> wrote:

> I think it would be hard to shield the DHCP code from
> insufficient file handles.

If the application is doing something insane and burning up all
of the system's file handles, then I wouldn't expect the DHCP
client to be able to overcome that.

> But yes that does confirm that an unplugged cable at startup
> means no IP address unless the user calls
> init_all_network_interfaces again.
>
> In this respect, the DHCP code wants improvement.

I can't think of any use-cases for our products where the DHCP
client should ever give up.  Telling customers they have to
guarantee the power-up sequence of various portions of their
plant to make our DHCP client happy isn't really an option. ;)

Am I missing something?  Are there situations where giving up
on acquiring an address is the right thing to do?

-- 
Grant Edwards                   grante             Yow! I just forgot my whole
                                  at               philosophy of life!!!
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Re: connect Ethernet cable at run-time

[Laurie Gellatly]

Hi Grant,
For our product there is a reason. If there is no Ethernet connection
other operations can still be done. As the web server is monitored by
the watchdog it's important that it not get stuck waiting on DHCP.
So we don't need the device to be plugged into the network either and
it will continue to work with what it can. When the network does connect,
other capabilities start.

If the user wants to change between DHCP and static addresses then
that too is possible without having to restart our device.

			...Laurie:{)

> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> owner@ecos.sourceware.org] On Behalf Of Grant Edwards
> Sent: Saturday, 26 September 2009 12:45 AM
> To: ecos-discuss@sources.redhat.com
> Subject: [ECOS] Re: connect ethernet cable at run-time
> 
> On 2009-09-25, Jonathan Larmour <jifl@jifvik.org> wrote:
> 
> > I think it would be hard to shield the DHCP code from
> > insufficient file handles.
> 
> If the application is doing something insane and burning up all
> of the system's file handles, then I wouldn't expect the DHCP
> client to be able to overcome that.
> 
> > But yes that does confirm that an unplugged cable at startup
> > means no IP address unless the user calls
> > init_all_network_interfaces again.
> >
> > In this respect, the DHCP code wants improvement.
> 
> I can't think of any use-cases for our products where the DHCP
> client should ever give up.  Telling customers they have to
> guarantee the power-up sequence of various portions of their
> plant to make our DHCP client happy isn't really an option. ;)
> 
> Am I missing something?  Are there situations where giving up
> on acquiring an address is the right thing to do?
> 
> --
> Grant Edwards                   grante             Yow! I just forgot
> my whole
>                                   at               philosophy of
> life!!!
>                                visi.com
> 
> 
> --
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: connect Ethernet cable at run-time

[Grant Edwards]

On 2009-09-26, Laurie Gellatly <laurie.gellatly@netic.com> wrote:

> For our product there is a reason. If there is no Ethernet
> connection other operations can still be done.

They can't be done while the DHCP client retries?

> As the web server is monitored by the watchdog it's important
> that it not get stuck waiting on DHCP.

I guess I don't understand your requirements.  If there's no
EThernet link, what else does the web server have to do except
wait for it?  It can't it kick the watchdog timer while the
DHCP client is attempting to acquire an address?

> So we don't need the device to be plugged into the network
> either and it will continue to work with what it can. When the
> network does connect, other capabilities start.

All of which is fine, but what I don't understand is why it
precludes the DHCP client from retrying.  When the DHCP client
does acquire an address and brings up the interface, then those
"other capabilities" can start.  None of my products have the
requirement that "capabilities" can only start during a certain
time window after the board starts.  They could start whenever
the Ethernet link does comes up?

> If the user wants to change between DHCP and static addresses
> then that too is possible without having to restart our
> device.

That's a nice feature, but again I don't understand why it
precludes the DHCP client from retrying.

-- 
Grant



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: connect ethernet cable at run-time

[Jonathan Larmour]

Grant Edwards wrote:
> On 2009-09-25, Jonathan Larmour <jifl@jifvik.org> wrote:
>>But yes that does confirm that an unplugged cable at startup
>>means no IP address unless the user calls
>>init_all_network_interfaces again.
>>
>>In this respect, the DHCP code wants improvement.
> 
> 
> I can't think of any use-cases for our products where the DHCP
> client should ever give up.  Telling customers they have to
> guarantee the power-up sequence of various portions of their
> plant to make our DHCP client happy isn't really an option. ;)
> 
> Am I missing something?  Are there situations where giving up
> on acquiring an address is the right thing to do?

On reflection, I think the choice may well have been intentional - simply 
a case of saying "let the user decide" (where user==eCos user). It may not 
be relevant to retry - maybe something else should be done instead.

The init_all_network_interfaces() call is meant to be idempotent, so I 
think all you're meant to do is pretty much what Laurie is doing and call 
it periodically, if that's what you need.

I don't believe you even need to check the interface status (unless you 
want to). After all the high level interface status (the interface is 
'up', 'running', has an IP address, a DHCP lease etc.) doesn't reflect the 
low level status (PHY knows there's a link) so it's not like you can ever 
guarantee any connectivity. Which you can't anyway as the remote host or 
an intermediate hop after the local eth switch may be down anyway.

Even then, init_all_network_interfaces() is meant to be a convenience 
function, and nothing stops someone bringing up the interfaces themselves 
(using the existing init_all_network_interfaces() as a template if need be).

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss