lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Behavior of netif_set_link_down


From: Nikolas Karakotas
Subject: Re: [lwip-users] Behavior of netif_set_link_down
Date: Wed, 1 May 2013 20:11:39 +1000

Hi,

For example the lpc1769 has a producer and a consumer index. If there is a free buffer available then the data will be copied to the register else it will wait until a buffer is available. You can return and ERR_OK when data has been copied or some other error if not, or timeout.

Nick

-----Original Message----- From: Richner Simon
Sent: Wednesday, May 01, 2013 7:31 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Behavior of netif_set_link_down

Thanks for your help guys

@ Marshall: Yes, you can check "NETIF_FLAG_LINK_UP", but this won't stop LwIP from sending, as <ip_route> checks "NETIF_FLAG_UP". So you must have a second mechanisme for this like Nikolas suggests...

@ Nikolas: So if I get you right, you would not activly stop the application from sending, but just return "ERR_CONN" in my driver send routine if the connection was down?

Regards
Simon


-----Ursprüngliche Nachricht-----
Von: address@hidden [mailto:address@hidden Im Auftrag von Marshall Brown
Gesendet: Mittwoch, 1. Mai 2013 11:12
An: Mailing list for lwIP users
Betreff: Re: [lwip-users] Behavior of netif_set_link_down

Here's how I do mine

/* Call the PHY status update state machine once in a while
      to keep the link status up-to-date */
   if (lpc_phy_sts_sm(netif_eth0) != 0) {
   /* Set the state of the LED to on if the ethernet link is
      active or off is disconnected. */
   if (netif_eth0->flags & NETIF_FLAG_LINK_UP){
rtu_led_RequestLEDColour(LED_ALARM_PRIORITY_8, ALARM_CLEAR); //request a low level alarm for ethernet not connected we should be able to run without it
   }
   else{
rtu_led_RequestLEDColour(LED_ALARM_PRIORITY_8, ALARM_SET); //request a low level alarm for ethernet not connected we should be able to run without it
   }
   }


Courtesy of the internet somewhere

Regards
Marshall

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Nikolas Karakotas
Sent: Wednesday, 1 May 2013 9:02 p.m.
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Behavior of netif_set_link_down

I believe it has to do with your ethernet driver and how it is implemented.
Even if you send data to your hardware you should control this with a incrementer for example just like a round robin.

Regards,
Nick

-----Original Message-----
From: Richner Simon
Sent: Wednesday, May 01, 2013 6:18 PM
To: Mailing list for lwIP users
Subject: [lwip-users] Behavior of netif_set_link_down

Hi,

In my driver I call <netif_set_link_up> and <netif_set_link_down> when I detect that a cable was connected to / removed from my device. However, I noticed, that only setting the link up triggers <dhcp_network_changed> and not setting link down. So when a cable gets removed, the NETIF_FLAG_UP stays true.

In my application, I send some data periodically to a predefined IP.
When now the cable gets disconnected, the application doesn't get informed about this, neighter gets the netif set down. So my application continues to spam my hardware and sooner or later I get a buffer overflow on my hardware!

=> What is calling <netif_set_link_down> good for, when it doesn't bring the interface down?

=> What would be the best way to tell my application to stop streaming?



Best Regards
Simon

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users



reply via email to

[Prev in Thread] Current Thread [Next in Thread]