* [ECOS] connect ethernet cable at run-time
@ 2009-09-24 10:34 Lars Dahlin
2009-09-24 11:45 ` Edgar Grimberg
2009-09-24 14:42 ` [ECOS] " Grant Edwards
0 siblings, 2 replies; 15+ messages in thread
From: Lars Dahlin @ 2009-09-24 10:34 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] connect ethernet cable at run-time
2009-09-24 10:34 [ECOS] connect ethernet cable at run-time Lars Dahlin
@ 2009-09-24 11:45 ` Edgar Grimberg
2009-09-24 14:42 ` [ECOS] " Grant Edwards
1 sibling, 0 replies; 15+ messages in thread
From: Edgar Grimberg @ 2009-09-24 11:45 UTC (permalink / raw)
To: Lars Dahlin; +Cc: ecos-discuss
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ECOS] Re: connect ethernet cable at run-time
2009-09-24 10:34 [ECOS] connect ethernet cable at run-time Lars Dahlin
2009-09-24 11:45 ` Edgar Grimberg
@ 2009-09-24 14:42 ` Grant Edwards
2009-09-24 16:26 ` Jonathan Larmour
1 sibling, 1 reply; 15+ messages in thread
From: Grant Edwards @ 2009-09-24 14:42 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Re: connect ethernet cable at run-time
2009-09-24 14:42 ` [ECOS] " Grant Edwards
@ 2009-09-24 16:26 ` Jonathan Larmour
2009-09-24 16:32 ` Grant Edwards
0 siblings, 1 reply; 15+ messages in thread
From: Jonathan Larmour @ 2009-09-24 16:26 UTC (permalink / raw)
To: haraxidix; +Cc: Grant Edwards, eCos discussion
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ECOS] Re: connect ethernet cable at run-time
2009-09-24 16:26 ` Jonathan Larmour
@ 2009-09-24 16:32 ` Grant Edwards
2009-09-25 0:11 ` Jonathan Larmour
0 siblings, 1 reply; 15+ messages in thread
From: Grant Edwards @ 2009-09-24 16:32 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Re: connect ethernet cable at run-time
2009-09-24 16:32 ` Grant Edwards
@ 2009-09-25 0:11 ` Jonathan Larmour
2009-09-25 1:23 ` Laurie Gellatly
2009-09-25 3:12 ` Grant Edwards
0 siblings, 2 replies; 15+ messages in thread
From: Jonathan Larmour @ 2009-09-25 0:11 UTC (permalink / raw)
To: Grant Edwards; +Cc: eCos discussion
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Re: connect ethernet cable at run-time
2009-09-25 0:11 ` Jonathan Larmour
@ 2009-09-25 1:23 ` Laurie Gellatly
2009-09-25 3:20 ` Grant Edwards
2009-09-25 13:16 ` Jonathan Larmour
2009-09-25 3:12 ` Grant Edwards
1 sibling, 2 replies; 15+ messages in thread
From: Laurie Gellatly @ 2009-09-25 1:23 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Grant Edwards, eCos discussion
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ECOS] Re: connect ethernet cable at run-time
2009-09-25 0:11 ` Jonathan Larmour
2009-09-25 1:23 ` Laurie Gellatly
@ 2009-09-25 3:12 ` Grant Edwards
1 sibling, 0 replies; 15+ messages in thread
From: Grant Edwards @ 2009-09-25 3:12 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ECOS] Re: connect ethernet cable at run-time
2009-09-25 1:23 ` Laurie Gellatly
@ 2009-09-25 3:20 ` Grant Edwards
2009-09-25 3:36 ` Laurie Gellatly
2009-09-25 13:16 ` Jonathan Larmour
1 sibling, 1 reply; 15+ messages in thread
From: Grant Edwards @ 2009-09-25 3:20 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Re: connect ethernet cable at run-time
2009-09-25 3:20 ` Grant Edwards
@ 2009-09-25 3:36 ` Laurie Gellatly
0 siblings, 0 replies; 15+ messages in thread
From: Laurie Gellatly @ 2009-09-25 3:36 UTC (permalink / raw)
To: Grant Edwards; +Cc: ecos-discuss
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Re: connect ethernet cable at run-time
2009-09-25 1:23 ` Laurie Gellatly
2009-09-25 3:20 ` Grant Edwards
@ 2009-09-25 13:16 ` Jonathan Larmour
2009-09-25 14:54 ` Grant Edwards
1 sibling, 1 reply; 15+ messages in thread
From: Jonathan Larmour @ 2009-09-25 13:16 UTC (permalink / raw)
To: Laurie Gellatly; +Cc: Grant Edwards, eCos discussion
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ECOS] Re: connect ethernet cable at run-time
2009-09-25 13:16 ` Jonathan Larmour
@ 2009-09-25 14:54 ` Grant Edwards
2009-09-26 8:12 ` [ECOS] Re: connect Ethernet " Laurie Gellatly
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Grant Edwards @ 2009-09-25 14:54 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [ECOS] Re: connect Ethernet cable at run-time
2009-09-25 14:54 ` Grant Edwards
@ 2009-09-26 8:12 ` Laurie Gellatly
[not found] ` <26548.8079087392$1253952764@news.gmane.org>
2009-09-27 22:06 ` [ECOS] Re: connect ethernet " Jonathan Larmour
2 siblings, 0 replies; 15+ messages in thread
From: Laurie Gellatly @ 2009-09-26 8:12 UTC (permalink / raw)
To: 'Grant Edwards', ecos-discuss
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ECOS] Re: connect Ethernet cable at run-time
[not found] ` <26548.8079087392$1253952764@news.gmane.org>
@ 2009-09-26 15:11 ` Grant Edwards
0 siblings, 0 replies; 15+ messages in thread
From: Grant Edwards @ 2009-09-26 15:11 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Re: connect ethernet cable at run-time
2009-09-25 14:54 ` Grant Edwards
2009-09-26 8:12 ` [ECOS] Re: connect Ethernet " Laurie Gellatly
[not found] ` <26548.8079087392$1253952764@news.gmane.org>
@ 2009-09-27 22:06 ` Jonathan Larmour
2 siblings, 0 replies; 15+ messages in thread
From: Jonathan Larmour @ 2009-09-27 22:06 UTC (permalink / raw)
To: Grant Edwards; +Cc: eCos discussion
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
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2009-09-27 22:06 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-24 10:34 [ECOS] connect ethernet cable at run-time Lars Dahlin
2009-09-24 11:45 ` Edgar Grimberg
2009-09-24 14:42 ` [ECOS] " Grant Edwards
2009-09-24 16:26 ` Jonathan Larmour
2009-09-24 16:32 ` Grant Edwards
2009-09-25 0:11 ` Jonathan Larmour
2009-09-25 1:23 ` Laurie Gellatly
2009-09-25 3:20 ` Grant Edwards
2009-09-25 3:36 ` Laurie Gellatly
2009-09-25 13:16 ` Jonathan Larmour
2009-09-25 14:54 ` Grant Edwards
2009-09-26 8:12 ` [ECOS] Re: connect Ethernet " Laurie Gellatly
[not found] ` <26548.8079087392$1253952764@news.gmane.org>
2009-09-26 15:11 ` Grant Edwards
2009-09-27 22:06 ` [ECOS] Re: connect ethernet " Jonathan Larmour
2009-09-25 3:12 ` Grant Edwards
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).