buglwIP - A Lightweight TCP/IP stack - Bugs: bug #20409, Add netif callback function for...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #20409: Add netif callback function for link change event

Submitter:  Jared Grubb <jgrubb>
Submitted:  Mon 09 Jul 2007 04:20:04 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  Feature Request Status:  Fixed
Privacy:  Public Assigned to:  jgrubb
Open/Closed:  Closed Planned Release:  None
lwIP version:  None

Jump to the original submission

Mon 30 Jul 2007 10:12:47 PM UTC, comment #62: 

Re comment #58: Why would netif->linkoutput be thread-safe. I'm sure it would only be expected to be called by one thread at once!

Also I know this was going to be punted to a different issue, but since I haven't seen that issue created, I'll say now: when Jared talked about the way "Linux" did it, in fact he's talking about all Unix, including BSD. And since BSD pretty much dictates what TCP/IP is, I think that's quite an important precedent in fact, arguably the most important.

Jonathan Larmour <jifl>
Group Member
Fri 13 Jul 2007 10:34:46 PM UTC, comment #61: 

Ok, so, I close it

Frédéric Bernon <fbernon>
Group Member
Fri 13 Jul 2007 10:08:09 PM UTC, comment #60: 


> the choice to use tcpip_callback or a lock is outside the problem.


That's very true. Would be nice if I had a LWIP_CONSTANT_SOMEWHERE to check so my driver would work both ways :) But, otherwise, you're right. I'll set my driver that way, and we can close this.

Jared Grubb <jgrubb>
Group Member
Fri 13 Jul 2007 09:57:00 PM UTC, comment #59: 

As long as the way to call netif_set_link_up depend of driver design, the choice to use tcpip_callback or a lock is outside the problem. The best thing to do is perhaps to add a comment and/or documentation to remember that this function have to be called in a safe-thread way and to propose some solutions.

Except that, I think we can close this item...

Frédéric Bernon <fbernon>
Group Member
Fri 13 Jul 2007 04:46:31 PM UTC, comment #58: 


> Is calling the etharp_query in the netif_set_link_up a problem?


Oh yes it is! The internal ARP cache is used in etharp_query.

But we could replace that call by a call to etharp_raw (or may a new function etharp_gratuitous which calls etharp_raw) since this function doesn't access any global variables, it builds an ARP packet and sends it using netif->linkoutput. Then (as long as netif->linkoutput is thread-safe, which it should be) it would be OK.

Simon Goldschmidt <goldsimon>
Group administrator
Fri 13 Jul 2007 03:24:00 PM UTC, comment #57: 

Also... what about thread safety? Is calling the etharp_query in the netif_set_link_up a problem?

Jared Grubb <jgrubb>
Group Member
Fri 13 Jul 2007 03:20:06 PM UTC, comment #56: 

I have looked at the commits. I would maybe suggest that we add in a NULL-check for netif_set_link_up/down functions, i.e.

if (netif) {
 ....
}

Jared Grubb <jgrubb>
Group Member
Fri 13 Jul 2007 03:03:08 PM UTC, comment #55: 

Ok, I have check in some changes, hoping it will be good for everyone... Jared, if - except up/down semantics - it's good for you, tell me, I will close it...

Frédéric Bernon <fbernon>
Group Member
Fri 13 Jul 2007 01:22:41 PM UTC, comment #54: 

Yes.

Kieran Mansley <kieranm>
Group Member
Fri 13 Jul 2007 01:18:10 PM UTC, comment #53: 

So, if I understand, we can check in the callback part, but we will decide of up/down semantics in a other task, right?

Frédéric Bernon <fbernon>
Group Member
Fri 13 Jul 2007 11:22:30 AM UTC, comment #52: 

Apologies for not giving more input to this - the amount of time I've had spare for lwIP recently is laughable.  It seems like you folks have managed to thrash something out between you all, but if there's something specific you'd like me to decide upon, please let me know.

For what it's worth, I think this callback should be mandatory rather than optional as it fixes a genuine bug.

I have no major objection to changing the definition of UP/DOWN, but like Simon I can't see (other than making it more like Linux) what benefit this would bring.  I would definitely like it to be done as a separate task, rather than getting merged into this one, so lets put that to one side for now.  By all means open a new bug if you feel strongly about this one Jared!

Kieran Mansley <kieranm>
Group Member
Fri 13 Jul 2007 07:25:14 AM UTC, comment #51: 


>Also we need to work on the timer functions if we implement netif_set_link_down/up like that. Without it, it's not worth anything.


Yes, but I think it's to the port to call the function (you can have an IT, have already a thread or a timer to handle the board, etc..).

>And the feature 'set MAC to low power mode' does not work with this patch, does it?


In fact, If Jared want to "power off" his MAC, he can use the "status_callback" to do that.

Simon, I propose to check in the patch with comment #44 changes (but always with both callback), and to patch ethernetif.c to set the NETIF_FLAG_LINK_UP, + opts.h + CHANGELOG. Like this, the code doesn't change if LWIP_NETIF_LINK_CALLBACK=0, and the modification is not intrusive. Like this, Jared can have his initial feature, and we could improve that (dhcp,autoip,igmp) in next release. Agree for you ?

 


Frédéric Bernon <fbernon>
Group Member
Fri 13 Jul 2007 07:12:30 AM UTC, comment #50: 

OK, I've took the time to look over the 'patched' netif.c. Like Frédéric said: why call dhcp_stop in netif_set_down? It may be called by dhcp, so calling dhcp_stop might be wrong. Same thing for autoip?

Also we need to work on the timer functions if we implement netif_set_link_down/up like that. Without it, it's not worth anything.

And the feature 'set MAC to low power mode' does not work with this patch, does it?

Simon Goldschmidt <goldsimon>
Group administrator
Fri 13 Jul 2007 06:53:21 AM UTC, comment #49: 

So Simon, are you agree with last Jared patch+changes from comment #44 (like this, the change is really minor, and people get the information only if they want)?

Frédéric Bernon <fbernon>
Group Member
Fri 13 Jul 2007 06:43:33 AM UTC, comment #48: 

Coming back to the original problem:

After all I don't really understand what's wrong with the current UP/DOWN... If you want a netif to stay down, stop dhcp & autoip and set it down! If you want it up, either call netif_set_up yourself or call dhcp_start (or autoip_something, I don't really know that part, yet).

I agree we need to do something if the link comes back (dhcp/autoip/gratuitous arp). If it is down we simply return errors.

The only thing you'd need an indication that the netif is down would be to save power. I agree that this can't be done easily with lwIP but it can be done in most cases since you write the application yourself, so you control the netif up/down/dhcp state. After all, lwIP is still supposed to be 'lw'... :-)

Simon Goldschmidt <goldsimon>
Group administrator
Thu 12 Jul 2007 05:46:46 PM UTC, comment #47: 

( side note: comment #46 by Frederic relates to Task #7068 dealing with documentation not to this bug... but, yeah, my mistake on that code. I'll fix it. )

> so such change we be better in 1.4.0 (it's my point of view)


I will respect that if that's what you and Simon want to do. In that case, I am going to propose it in day 1 after the release of 1.3.0.... :)

> For comment #44, your comments?


Coming soon... It looks right.. but I need to look at it again.

Jared Grubb <jgrubb>
Group Member
Thu 12 Jul 2007 05:39:13 PM UTC, comment #46: 

netconn_delete(conn); should be call with newconn ?

Frédéric Bernon <fbernon>
Group Member
Thu 12 Jul 2007 05:37:32 PM UTC, comment #45: 


>Even for a 1.3 release? Can I convince ya otherwise :) If not... maybe for the 2.0?


For 2.0? ok for me :) It's just I think that 1.3.0 is in "final" stage, so such change we be better in 1.4.0 (it's my point of view)

> In any case, if you want to stick with the current way, then I have a couple issues that I think need fixed....


I you think about internal dhcp/autoip/igmp changes, yes, but, like until now, it wasn't a big problem, is it something to fix immedialtly? Not sure (but it's not a big problem)

For comment #44, your comments? (I have to go out, I will come later or tommorrow, sorry... )

Frédéric Bernon <fbernon>
Group Member
Thu 12 Jul 2007 05:29:15 PM UTC, comment #44: 

Ok, so, about patch from comment #41:

- "netif_set_addr", "netif_set_ipaddr", "netif_set_up" : No change need (as long the job is done in "set_up", see comment #42)

- "netif_set_down" : I think we should remove dhcp/autoip_stop and let them check their state. About your "maybe not?", I think that perhaps only one callback with a flag parameter will be good, but, it's not a big problem.

- "netif_set_link_down/up" ok for me


Frédéric Bernon <fbernon>
Group Member
Thu 12 Jul 2007 05:27:02 PM UTC, comment #43: 


> (#42) Lot of "fine", can we hope to be agree ?? ;)

Sorry for the confusion... My "fine" means "that works for me" So yes I agree :)

> So since these users use already the stack like this, I think we should keep the current behavior. After all, Linux is not THE reference !!! :)


Even for a 1.3 release? Can I convince ya otherwise :) If not... maybe for the 2.0? :) I use Linux because it's very mature and has already figured out a good way to do things. Plus, matching it where possible makes it easier for new users to understand how to use the stack. In any case, if you want to stick with the current way, then I have a couple issues that I think need fixed....

> [... about who does ARP] Fine for you ?

If we stick to the current UP/DOWN definition, then you are absolutely right.

Jared Grubb <jgrubb>
Group Member
Thu 12 Jul 2007 05:08:45 PM UTC, comment #42: 

Lot of "fine", can we hope to be agree ?? ;)

>UP/DOWN is used to define whether communication actually can happen on this interface. It is set/reset by the stack in response to events (like DHCP). This is how lwIP currently works.


There is already "lot" (?) of lwIP since several years. So since these users use already the stack like this, I think we should keep the current behavior. After all, Linux is not THE reference !!! :)

>The gratutious ARP should happen whenever the IP address changes. When DHCP gets an IP address, it calls netif_set_ipaddr. If I want to use a static IP, I will call netif_set_ipaddr. AUTOIP calls netif_set_ipaddr. Can you think of a time when a call to netif_set_ipaddr should not cause a gratuitous ARP?


It's not exact: if DHCP, AUTOIP & static IP call "set_ipaddr", they also call "set_up" !!! Even for "static," if you read rawapi.txt, and look for samples, you will see :

"- netif_set_up(struct netif *netif)
When the netif is fully configured this function must be called."

It's done here since "set_up" have to be call after "set_ipaddr", "set_netmask" and "set_gw" (to "terminate" the "three-calls" sequence)...

Fine for you ?


Frédéric Bernon <fbernon>
Group Member
Thu 12 Jul 2007 05:03:22 PM UTC, comment #41: 

Here is the updated file for what def#1 of UP in comment #40 would look like. This has the changes proposed by Frederic in #38. (I added a DIFF too) (It still calls dhcp_stop() in netif_set_down(), but that can be hashed out after we agree on what UP/DOWN mean)

Most of my comments apply only to def#1, which is a change from what lwIP currently uses, but I really think it would be a GOOD change. If you both want to stick with def#2, then many of my arguments and proposals are not valid.

(file #13307, file #13308)

Jared Grubb <jgrubb>
Group Member
Thu 12 Jul 2007 04:36:12 PM UTC, comment #40: 


> (#32) manually up/down a netif is a basic operation on lwIP. Any embedded application can decide to down its netif if it want to "stop" any services activity.


> (#38) If you want to power off an netif, the right thing to do is the down it and to remove it


Let's just decide exactly what UP/DOWN means, because I dont think we are all speaking the same language. There are two options:

  • UP/DOWN means that the user intends the interface to do its best to make communication happen. UP/DOWN is always user-driven, and the stack cannot change this state. This is how Linux works.
  • UP/DOWN is used to define whether communication actually can happen on this interface. It is set/reset by the stack in response to events (like DHCP). This is how lwIP currently works.

 
I think people who have used Linux before will expect our stack to behave the same way, and that is the one that I would like to lwIP use. If we use definition #1, then the stack knows it is in a good communication state is by checking to see if the netif has a valid IP address (just like Linux does). Thus, when DHCP or AUTOIP or my application that uses a static IP calls netif_set_ipaddr, that is the trigger to the stack that we have a ready netif.

> (#38) link_status will be a better name. [ That's fine. ]
> (#38) #define NETIF_LINK_CALLBACK(n)...  [ Much better. ]


> (#38) the place to do the "gratuitous ARP", I think netif_set_up


The gratutious ARP should happen whenever the IP address changes. When DHCP gets an IP address, it calls netif_set_ipaddr. If I want to use a static IP, I will call netif_set_ipaddr. AUTOIP calls netif_set_ipaddr. Can you think of a time when a call to netif_set_ipaddr should not cause a gratuitous ARP?

If you say that UP means definition #1 above, then netif_set_ipaddr is the place to do it, because it will trigger every time a new IP address is acquired; the netif is ready to use. If you say that UP means #2 above, then netif_set_up is the place to do it, because this is the "ready to use" function.

> (#38) the netif doesn't have to stop the dhcp client by example. It's another reason to let the module do the job...


Under def#2 you're right. Under def#1, that will work only as long as DHCP checks for down interfaces.

> (#38) I prefer two functions (netif_set_link_up/down). It will also set/rest the NETIF_FLAG_LINK_UP flag.


That is fine.

> (#38) About calling dhcp_link_change/autoip_link_change, I always thing that do the job inside the module timer is better


That is fine too. The netif_set_link_up() can do an ARP and we wont check for DHCP or AUTOIP.

Jared Grubb <jgrubb>
Group Member
Thu 12 Jul 2007 04:26:44 PM UTC, comment #39: 


> In this case, link_status will be a better name.


Sorry, I would like to say "link_callback"...

Frédéric Bernon <fbernon>
Group Member
Thu 12 Jul 2007 07:42:15 AM UTC, comment #38: 


>If we give the user "master" powers over a netif, then he expects the stack to obey them


If you want to power off an netif, the right thing to do is the down it and to remove it

About the patch file:

>netif->driver_callback = NULL;


Can you confirm that driver_callback is to provide the information to the application? In this case, link_status will be a better name.

>#if LWIP_NETIF_LINK_CALLBACK
> if ( netif->driver_callback )
> (netif->driver_callback)( netif );
>#endif


It's not specific to this callback, but to avoid such block, I propose to change with at the beginning of the file:

#if LWIP_NETIF_LINK_CALLBACK
#define NETIF_LINK_CALLBACK(n) if (n->link_callback)\
                               (n->link_callback)(n)
#else
#define NETIF_LINK_CALLBACK(n)
#define  
#endif /* LWIP_NETIF_LINK_CALLBACK */

And place use it in all file where the callback is invoked (same for status_callback. It's more a good pratice we should do in most file (in fact, I think this is already the case). Perhaps one callback for both cases, with a "netif_change" parameter will be better (a flag saying what is the event)?

About the place to do the "gratuitous ARP", I think netif_set_up stay better (see https://savannah.nongnu.org/patch/index.php?5824, comment #2 & comment #3). But since it's only two lines, ok to call it when the link become up (like you do), but not in netif_set_ipaddr.

>netif_set_down

I think it's wrong, since down the netif doesn't have to stop the dhcp client by example. It's another reason to let the module do the job...

>netif_link_change


I prefer two functions (netif_set_link_up/down). It will also set/rest the NETIF_FLAG_LINK_UP flag. About calling dhcp_link_change/autoip_link_change, I always thing that do the job inside the module timer is better (direct calls from netif could cause circular references problems). Last you forget IGMP module.

Frédéric Bernon <fbernon>
Group Member
Thu 12 Jul 2007 06:42:30 AM UTC, comment #37: 


> But these modules are not the only ones which need to react to a
> link up, IGMP is another one (the target have to resend its "IGMP
> reports")


Couldn't that happen from netif_set_up()?

> I don't like the idea that a link down cause to "down" the netif,
> and the link up cause to "up". It's also possible to manually
> "down" a netif, and to don't want it's "up" when the link is
> "up". To my point of view, this is two really different state.


That would mean the netif could be UP & the link DOWN. Then when the link comes back UP, dhcp would work on a netif that is UP/UP and set it to UP again once it gets an IP? Or set it to DOWN when it realizes the old IP is not valid any more?

> Yes, and LOCK_TCPIP_CORE/UNLOCK_TCPIP_CORE can do this job...


But not with the current sequential api implementation!

> Otherwise, we could have the user call netif_set_down only to
> find that DHCP called netif_set_up() all on its own later on
> because it wasnt stopped.


Or netif_set_down should stop dhcp...

re comment #35: didn't have time to look at the file yet, but the idea seem kind of ok to me (although maybe ip_input should check more than NETIF_FLAG_UP and null IP).

Simon Goldschmidt <goldsimon>
Group administrator
Thu 12 Jul 2007 02:59:45 AM UTC, comment #36: 

(attachment for comment #35 proposal ... messed up first time)

(file #13292)

Jared Grubb <jgrubb>
Group Member
Thu 12 Jul 2007 02:58:00 AM UTC, comment #35: 

Based on my last comment, I changed netif.c to show what it would look like. It will have minimal impact on how things already work, while offering lots of optional new features. The changes to netif.c:

  • LWIP_NETIF_LINK_CALLBACK defines whether there is a link change callback feature, and whether there is a status callback to the driver (may as well couple these together for "smart" drivers)
  • The gratuitous ARP and the status_callback happen in netif_set_ipaddr(), since these are the events we want to capture
  • netif_set_up is shorter, optionally calling the driver callback
  • netif_set_down is more intelligent, calling dhcp_stop() or autoip_stop(), the optional driver callback, and the optional status_callback.
  • netif_link_change() (optional via LWIP_NETIF_LINK_CALLBACK) calls dhcp_link_change(), autoip_link_change, or etharp_query() as appropriate.


External changes not shown:

  • new LWIP_NETIF_LINK_CALLBACK option
  • new NETIF_FLAG_AUTOIP flag
  • dhcp_start(), dhcp_stop(), autoip_start(), autoip_stop() do not call netif_set_up/down, but instead call netif_set_ipaddr(addr) or netif_set_ipaddr(NULL) depending on whether they get an IP or lose one.
  • ip_input() still checks both for up/down, but will fail (properly) on NULL ip adress, as set possibly from DHCP
  • new (optional) functions dhcp_link_change() and autoip_link_change().


What you guys think? Minimal impact to current design, lots of new optional features, user gets global up/down ability... (havent addressed the core-locking on link change stuff, but that can be addressed next, if you guys like this much.)

(file #13291)

Jared Grubb <jgrubb>
Group Member
Thu 12 Jul 2007 01:55:24 AM UTC, comment #34: 


> manually up/down a netif is a basic operation on lwIP. Any embedded application can decide to down its netif if it want to "stop" any services activity...


If we give the user "master" powers over a netif, then he expects the stack to obey them. The stack should not call those same functions that the user has -- DHCP should not call netif_set_up if that's the function we tell the user he can use. Otherwise, we could have the user call netif_set_down only to find that DHCP called netif_set_up() all on its own later on because it wasnt stopped.

Let's talk about how the user and driver could interact with the stack in an ideal world, as though the stack is a big black box:

Let's emulate Linux. The user calls netif_set_up() and netif_set_down() which has global enabling and disabling powers. Inside of that, the user can call whatever IP acquisition he chooses; netif_set_down() is smart enough to call any *_stop() functions that are appropriate. For example:

netif_add();
netif_set_up();
dhcp_start();
dhcp_renew();
dhcp_stop();
autoip_start();
/* let's say this next line happens somewhere else in code that doesn't know what IP acquisition we used */
netif_set_down();
// user forgot (or didnt know he had to do) autoip_stop()
// that's ok, the stack will do it for him

So, we define states just like in Linux

  • UP and DOWN are completely controlled by the user.
  • LINK and NO LINK are completely controlled by the driver.
  • RUNNING and NOT RUNNING are completely controlled by the stack.


We have an entry point for the driver for link change:

  • netif_link_change(), called whenever the link changes.


We have the following callbacks (both optional via lwipopts) defined in the netif:

  • application_status_callback to the application in response to changes in RUNNING/NOT RUNNING; for example, IP address acquisition
  • driver_status_callback to the driver in response to UP/DOWN; for example, a down driver can turn off its circuits (but stay initialized)


This only defines how the USER and DRIVER interact with the stack, but does not define how the stack actually implements these behaviors. In my world, this would be my ideal way to interact with the stack. What do you think?

Jared Grubb <jgrubb>
Group Member
Wed 11 Jul 2007 11:52:48 PM UTC, comment #33: 

Som points from comment #25 to change:

No "netif timers" in the stack (but it can be internal to the driver). The way to communicate the link change from the driver to the stack is decide by the port (tcpip_callback, locking, no protection...)

About gratuitous ARP, let it synchrone in both "set_up" functions.

About DHCP, AUTOIP, IGMP, it could be done later (after all, these modules work like this today, right?). We could improve them in next release.

And we add a recommandation to port maintainers to set NETIF_FLAG_LINK_UP by default, to be compatible with future changes...

Like this, is it good for you Jared? Simon?

Frédéric Bernon <fbernon>
Group Member
Wed 11 Jul 2007 11:43:51 PM UTC, comment #32: 


>Do we want to let the netif be up'd or down'd manually? Why would we allow that to happen?


manually up/down a netif is a basic operation on lwIP. Any embedded application can decide to down its netif if it want to "stop" any services activity...

>This whole up/down thing is a new feature to lwIP. We can define its behavior however we want, but in the future we will have to provide backwards-compatibility for it. I want to make sure we do this right the first time around.


Yes, but the initial impact have to be less intrusive as possible. Change timers is not a big job to do. But I'm not sure it's really something to change in next "1.3.0"...

>I say the timers idea is a bit too decentralized -- we have to handle the static IP case as well, and that has no timers.


For a static IP, there is only gratuitous ARP (but it will be a synchrone call) and IGMP's reports (and there is already a timer).


Frédéric Bernon <fbernon>
Group Member
Wed 11 Jul 2007 10:59:52 PM UTC, comment #31: 


> it could need to add a new state inside each one, but IT IS a new state, so, it's logical...


This whole up/down thing is a new feature to lwIP. We can define its behavior however we want, but in the future we will have to provide backwards-compatibility for it. I want to make sure we do this right the first time around.

Using timers may be the "small code impact", but it still is ending up to be a bit of work. I dont think this will ever be simple, so let's do this "right", even if it means changing more than we'd like.

I say the timers idea is a bit too decentralized -- we have to handle the static IP case as well, and that has no timers.

Jared Grubb <jgrubb>
Group Member
Wed 11 Jul 2007 10:53:29 PM UTC, comment #30: 


>I don't like the idea that a link down cause to "down" the netif, and the link up cause to "up". It's also possible to manually "down" a netif, and to don't want it's "up" when the link is "up". To my point of view, this is two really different state. But that a "link up" send a gratuitous ARP is the netif is already "up" (in a netif_set_link_up) is not a big problem, since it's only two lines of code.


Do we want to let the netif be up'd or down'd manually? Why would we allow that to happen?

Jared Grubb <jgrubb>
Group Member
Wed 11 Jul 2007 10:33:34 PM UTC, comment #29: 


>Are DHCP, AUTOIP, and static IP the only three choices we support for IP acquisition?


Yes, lwIP got full features now. Do you see another one possible?

But these modules are not the only ones which need to react to a link up, IGMP is another one (the target have to resend its "IGMP reports")

Frédéric Bernon <fbernon>
Group Member
Wed 11 Jul 2007 10:29:55 PM UTC, comment #28: 


>The reason for a flag LINK_WAS_DOWN is that if the link changes fast, a timer function might only see UP and UP again, not the DOWN in between. Thus seeing no change, it wouldn't do anything.


But if the change is short (<1000ms, I would even say <500ms), I think it's not a problem to do nothing.

>As such, I don't know if it is enough to let the timers deal with such a flag. You'd need one LINK_WAS_DOWN flag for every protocol or else one will set it back and the others won't see it.


I'm in flavour to let timers handle that, since like I said they are the only ones to know what is the "right thing to do" on link down/up cases. Of course, it could need to add a new state inside each one, but IT IS a new state, so, it's logical...

>I think netif_set_up can stay like it is and the gratuitous ARP can be sent there, as long as we make sure the interface is enabled again.


Agree

>For that, we could set the netif DOWN if the link is down and UP when the link is back (from dhcp or autoip; or from hand when static IPs are used). That way, the gratuitous ARP will be sent when the link is back.


I don't like the idea that a link down cause to "down" the netif, and the link up cause to "up". It's also possible to manually "down" a netif, and to don't want it's "up" when the link is "up". To my point of view, this is two really different state. But that a "link up" send a gratuitous ARP is the netif is already "up" (in a netif_set_link_up) is not a big problem, since it's only two lines of code.

>The only problem I see there is that the ARP timer is too slow...


That's why, do the gratuitous ARP in both (netif_set_up & netif_set_link_up) seems to be the best solution.

>a callback might be better after all...


Agree with you: a callback, a "lock"... yes, it's better than a timer. The problem is to provide the simplest way and less "intrusive" way to do that (call netif_set_link_up/down).

>This brings us back to the old question of having a define that tells us whether lwIP is running multithreaded or standalone


Yes ;)

>The only other solution would be to include locking in the whole core which does nothing in standalone / raw mode.


Yes, and LOCK_TCPIP_CORE/UNLOCK_TCPIP_CORE can do this job...


Frédéric Bernon <fbernon>
Group Member
Wed 11 Jul 2007 10:22:27 PM UTC, comment #27: 

Are DHCP, AUTOIP, and static IP the only three choices we support for IP acquisition?

Jared Grubb <jgrubb>
Group Member
Wed 11 Jul 2007 08:57:44 PM UTC, comment #26: 

The reason for a flag LINK_WAS_DOWN is that if the link changes fast, a timer function might only see UP and UP again, not the DOWN in between. Thus seeing no change, it wouldn't do anything.

As such, I don't know if it is enough to let the timers deal with such a flag. You'd need one LINK_WAS_DOWN flag for every protocol or else one will set it back and the others won't see it.

I think netif_set_up can stay like it is and the gratuitous ARP can be sent there, as long as we make sure the interface is enabled again. For that, we could set the netif DOWN if the link is down and UP when the link is back (from dhcp or autoip; or from hand when static IPs are used). That way, the gratuitous ARP will be sent when the link is back.

The only problem I see there is that the ARP timer is too slow...

And since other timers are either slow, too, or produce processor load while the link is not changed, a callback might be better after all...

This brings us back to the old question of having a define that tells us whether lwIP is running multithreaded or standalone! The only other solution would be to include locking in the whole core which does nothing in standalone / raw mode.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 11 Jul 2007 07:05:53 PM UTC, comment #25: 

So, to resume my last comments, I prefer (it's my point of view):

1/ netif_add should not be change, as long the "low_level_init" is enough to init flags (and, to be compatible with current source, NETIF_FLAG_LINK_UP should be set by default, if ports maintainers doesn't want to do the job). Like this, this is not really mandatory (except set the flag).

2/ Only one flag NETIF_FLAG_LINK_UP which have to be change by the driver using netif_set_link_up()/_down(). The check can be done in a netif timer (1Hz is enough I think), or by "locking" the stack (which will be less intrusive than a timer - after all, we don't plug/unplug the device often).

3/ DHCP, AUTOIP, IGMP have to handle/check in timers that the link change of state (if it's necessary), adding - if necessary - new internal states, because each module know the "right thing" to do.

4/ "gratuitous ARP" should be send as soon as possible in netif_set up & netif_set_link_up to update LAN routers & switchs

Again, it's my point of view... ;)

Frédéric Bernon <fbernon>
Group Member
Wed 11 Jul 2007 06:51:29 PM UTC, comment #24: 

Comment #21

I think the "gratuitous ARP " have to be send as soon as possible to inform network switch, so call it in a synchrone way (like in current code) is better.

About flags, I think that LINK_UP is enough: each module working during the interface is "down" should handle that in it's states: if when it check an interface, it is LINK DOWN, it have to do the "right changes" in its internal states (for DHCP, come to DHCP_OFF, and reset some fields like in a part of dhcp_release, for AUTOIP, change to AUTOIP_STATE_OFF, etc...). Perhaps add some specific states for these modules is necessary (add a DHCP_LINKDOWN, etc...), so, when they check netif's flags, and now, the LINK UP, they can also do the "right things" (restart for DHCP/AUTOIP, send the ARP gratuitous, resend group for IGMP...)

Frédéric Bernon <fbernon>
Group Member
Wed 11 Jul 2007 06:38:45 PM UTC, comment #23: 

Comment #18:

Handle a flag which have to be reset be several tasks is not very nice. A timer? Why not? Since to handle the autonegociate at phy level, most of time, we have to check the link. But as you know, I don't like current lwIP timers implementation, but...


Frédéric Bernon <fbernon>
Group Member
Wed 11 Jul 2007 06:27:43 PM UTC, comment #22: 

Comment #17

>I personally like the idea of making it mandatory, because having lwIP respond to changes in link is a desirable thing. Saying "users upgrading to lwIP 1.3 need to be aware of the following changes" is not a bad thing, and I believe this could be a reasonable thing to require users to address.


But made mandatory something we wasn't need to users until now if not a good solution.

About DHCP, I think dhcp_release is not the good function to call, since it try to inform the DHCP server. I not look for another one, but I think it exists...

Frédéric Bernon <fbernon>
Group Member
Wed 11 Jul 2007 06:25:44 PM UTC, comment #21: 


> [ Have timers implement the events ]


That sounds like a good solution. The side effect is that the response could be a bit slow for ARP (5 seconds), but it's "gratuitous" anyhow :)

I would suggest two flags then: LINK_UP and LINK_EVENT. LINK_UP would always represent the current link status and is only set or cleared by driver, but LINK_EVENT is set by driver and cleared by the appropriate timer.

The only side effect is that a timer will only really see the last event that happened. For example, suppose LINK->NOLINK->LINK before the timer triggers. The timer will see LINK_UP and LINK_CHANGED and assume the NOLINK->LINK is the event it has to handle.

  • ARP doesn't care; it only fires if LINK_UP is set.
  • Would DHCP care? It could detect this by noticing that it sees LINK_UP and LINK_EVENT but it's also currently bound.
  • Does AUTOIP care?


I havent used AUTOIP or DHCP, so I'm not sure if it's an issue. If it matters, we could use three flags (e.g., LINK_UP, LINK_LOST, LINK_GAINED) and let the handlers handle both events in the "proper" order.

Jared Grubb <jgrubb>
Group Member
Wed 11 Jul 2007 06:25:04 PM UTC, comment #20: 

Comment #15 seems good, but I don't like the idea to have to extend netif_add, since the field can be set inside the "low_level_init"...

Frédéric Bernon <fbernon>
Group Member
Wed 11 Jul 2007 06:22:57 PM UTC, comment #19: 

About comment #16, direct access is not very "clean", I prefer netif_set_link_up()/_down(). But I prefer a message than a direct access to netif fields in the driver .

>About the state UP, NO LINK: when it returns to UP, LINK, dhcp should negotiate again, shouldn't it?

Yes

>So we would have to set the netif state to down when the link is down?

Not necessary, as long the driver error is forwarded...

Frédéric Bernon <fbernon>
Group Member
Wed 11 Jul 2007 05:41:22 PM UTC, comment #18: 

I still think that DHCP and AUTOIP could check the LINK_UP flag (compared to the current state) in their timer routines. For gratouitous ARP, this would also work:

The current FLAG_LINK_UP is not really used yet. For this purpose, a flag LINK_WAS_GONE would be better. Any time one of the timer functions sees this flag, they would do something and set back the bit. This works because only one part is really responsible for one netif at any time (i.e. AUTOIP 'knows' when DHCP is responsible for the netif, so it does nothing but is triggered after DHCP timed out; also, ARP would only send the gratuitous ARP if no DHCP is configured.

We could also include a new netif timer to do all that work. In any case, I think it's a better solution than all the callbacks because it's the same for raw and callback mode!

Simon Goldschmidt <goldsimon>
Group administrator
Wed 11 Jul 2007 04:42:24 PM UTC, comment #17: 


> The problem with not making it mandatory would be the decision of when to send the gratuitous ARP.


I personally like the idea of making it mandatory, because having lwIP respond to changes in link is a desirable thing. Saying "users upgrading to lwIP 1.3 need to be aware of the following changes" is not a bad thing, and I believe this could be a reasonable thing to require users to address.

> the network driver [...set link up flag]


A driver should most certainly do that anyway. The problem is how do we notify the stack of this event.

I got an idea. The same events need to happen for all interfaces, therefore it's not necessary to set a field per netif. The behavior could be done this way:

  • Create global variable void (*netif_state_change)(*netif) in netif.c. Drivers call this function when link changes.
  • Create netif_set_state_change(*fcn) {netif_link_change=fcn;}
  • Create netif_do_state_change(netif) that does all the stuff (see below for pseudo-code)
  • netif_init() {... netif_set_state_change(netif_do_link_change);} (default behavior, try to make this emulate how it's already being done in lwIP)
  • tcpip_init() {... netif_set_state_change(tcpip_link_change);} (overridable if the user uses API)
  • Create tcpip_state_change() { return tcpip_callback(netif_do_state_change,netif); }

This can all be marked off by #if..#endif if this is not mandatory. (I use "state" instead of "link" since we are handling UP<->DOWN and LINK<->NOLINK. Therefore netif_set_up/down calls it for UP/DOWN and driver calls it for LINK/NOLINK)

> So we would have to set the netif state to down when the link is down?


Yes, I think so. Here is what I picture:
netif_do_state_change {
  if (DOWN & NOLINK) { nothing? }
  if (DOWN & LINK) {
     if (DHCP) {
        dhcp_bind (which will set up)
     }
  }
  if (UP & LINK) { ARP }
  if (UP & NOLINK) {
     if (DHCP) {
        dhcp_release (which sets down)
     } else {
        set down??
     }
  }
}

Jared Grubb <jgrubb>
Group Member
Wed 11 Jul 2007 07:23:36 AM UTC, comment #16: 


> Would this be a mandatory feature of a version


The problem with not making it mandatory would be the decision of when to send the gratuitous ARP.

> I think we could something like netif->linkstatus (on the same
> idea than netif->input) to be able to work on all design cases
> (NO_SYS=0/1 netif->with/without tcpip.c...). We could define
> inside tcpip.c a new function like tcpip_linkstatus using
> perhaps tcpip_callback or the "lock".


That would require having a new parameter in netif_add which only few people would need! Why don't we make it more simple? For example, the network driver execute the following code when the link is up:

SYS_ARCH_PROTECT();
netif->flags |= NETIF_FLAG_LINK_UP;
SYS_ARCH_UNPROTECT();

Then the ARP / DHCP or AUTOIP timer can appropriately react on a change from UP to DOWN. This wouldn't require changes that are inconsistent from raw to sequential API. Also, this doesn't require much code and thus might be smaller.

This can also be moved into a function netif_set_link_up()/_down() to be more robust.


About the state UP, NO LINK: when it returns to UP, LINK, dhcp should negotiate again, shouldn't it? So we would have to set the netif state to down when the link is down?

Simon Goldschmidt <goldsimon>
Group administrator
Tue 10 Jul 2007 11:19:55 PM UTC, comment #15: 

Alright, how does this sound:

  • opts.h: #define LWIP_NETIF_LINK_CHANGE_CALLBACK
  • netif.h: add a void (*link_change_callback)(*netif) fcn to netif struct. The driver will call this function on link change.
  • netif.c#netif_link_change(*netif) will be the destination for the link change event. It will cause the right things to trigger (ARP, DHCP, AUTOIP). Who calls it?
    • If LWIP_NETIF_LINK_CHANGE_CALLBACK==1, then there should be an extra parameter passed to netif_add that sets the proper callback function (just like we do for *input). This is a bit awkward, but I'm not sure who else would set it...
    • If LWIP_NETIF_LINK_CHANGE_CALLBACK==0, then netif_set_up and netif_set_down should call netif_link_change() directly
  • tcpip.c#tcpip_link_change(*netif) { return tcpip_callback(netif_link_change,netif); }


Thus, a program that uses tcpip.c would do:
netif_add(netif, ipaddr, netmask, gw, NULL, driver_init, tcpip_ethinput, tcpip_link_change);

A program that does not use tcpip.c would do:
netif_add(netif, ipaddr, netmask, gw, NULL, driver_init, tcpip_ethinput, netif_link_change);

Jared Grubb <jgrubb>
Group Member
Tue 10 Jul 2007 09:07:13 PM UTC, comment #14: 


>Since linkoutput is defined to return err_t, we can use ERR_CONN (link down). ERR_BUF or ERR_MEM would work for other types of errors. I would suggest creating a new bug to address this issue and the code changes required.


I'm not sure that ERR_CONN is good (from memory, it's more "conn" like "netconn"). Perhaps we could add a new error code ? ERR_LDOWN or something like that. About ERR_BUG & ERR_MEM, since the "close" in api_msg.c check exactly the return value, I think we have to decide which code to return. I think a documentation about "lwIP driver design" will be good...

>Would this be a mandatory feature of a version 1.3 driver, or would it become optional via a flag (just like the status_callback function is)?


In a general way, a feature which is not useful for everyone should be optionnal. Since until now, no user ask for it, I think it's more optionnal than mandatory (like the status_callback).


Frédéric Bernon <fbernon>
Group Member
Tue 10 Jul 2007 08:55:46 PM UTC, comment #13: 

Sounds good.

> 1/ I think we have to define - or recommend - exactly what codes to return when the link is down, and when the MAC buffers are all full.


Since linkoutput is defined to return err_t, we can use ERR_CONN (link down). ERR_BUF or ERR_MEM would work for other types of errors. I would suggest creating a new bug to address this issue and the code changes required.

> 2/ I think we could something like netif->linkstatus...


Agreed. Would this be a mandatory feature of a version 1.3 driver, or would it become optional via a flag (just like the status_callback function is)? I would vote for mandatory, but I'm not sure how much support lwIP traditionally allows for legacy code.

Jared Grubb <jgrubb>
Group Member
Tue 10 Jul 2007 08:40:44 PM UTC, comment #12: 

For the last four states you give, I'm agree with you. In cases where LINK DOWN, this is because the "link_output" will return an error that the "core" know there is a problem.

>status_callback goes to application, not driver. Driver runs the same regardless of whether its netif is UP or DOWN.


Agree with you

>driver signals link change back to the stack (via one of the methods you mention)


When the link go from DOWN to UP state, it will be good to do some stack actions (ARP gratuitous, DHCP/AUTOIP renew). So the problem is here: found a way to communicate from driver to stack (actually, only link_output return code, and netif->input are available).

1/ I think we have to define - or recommend - exactly what codes to return when the link is down, and when the MAC buffers are all full.

2/ I think we could something like netif->linkstatus (on the same idea than netif->input) to be able to work on all design cases (NO_SYS=0/1 with/without tcpip.c...). We could define inside tcpip.c a new function like tcpip_linkstatus using perhaps tcpip_callback or the "lock". The idea is to reinitialize any stack state to respect RFC 3220 "IP Mobility Support for IPv4" (or other).




Frédéric Bernon <fbernon>
Group Member
Tue 10 Jul 2007 07:41:20 PM UTC, comment #11: 

As I think about it further, the stack would never need to know about STARTED and STOPPED (as I think you are arguing, Frederic). I want my driver to be startable and stoppable, but I can do that myself:

driver_init(); // this is first-time init
driver_start();
netif_set_up();
...
netif_set_down();
driver_stop();
...
driver_start(); // bring up again later
netif_set_up();
....

Which would leave us with:
(DOWN,NO LINK) Driver running but no link found (yet)
(DOWN, LINK  ) Driver ready to go. DHCP would neogtiate here.
( UP , LINK  ) All good.
( UP ,NO LINK) Lost link. Driver returns error on transmit. Perhaps DHCP would bring down?

  • status_callback goes to application, not driver. Driver runs the same regardless of whether its netif is UP or DOWN.
  • driver signals link change back to the stack (via one of the methods you mention)


This is what you are saying, right Frederic?

Jared Grubb <jgrubb>
Group Member
Tue 10 Jul 2007 07:20:05 PM UTC, comment #10: 


> when the DHCP client is negociated an ip address, the netif is "down"


I haven't used the DHCP module at all. Now I understand what you mean. So, instead of 4 states, there are 6. Let's agree on the states the application, stack, and driver should understand (correct them if wrong, I'm just doing this off the top of my head):

UP = application is allowed to use this interface
DOWN = application is not allowed to use this interface

LINK = driver is able to RX and TX
NO LINK = driver cannot RX and TX

STARTED = driver is active and running
STOPPED = driver has been initialized, but is inactive

In this definition, there would be the following:
(DOWN,NO LINK,STOPPED) All off, driver circuits maybe powered down
(DOWN,NO LINK,STARTED) Driver running but no link found (yet)
(DOWN, LINK  ,STARTED) Driver ready to go. DHCP would neogtiate here.
( UP , LINK  ,STARTED) All good.
( UP ,NO LINK,STARTED) Lost link. Driver returns error on transmit. Perhaps DHCP would bring down?

The following states would not be allowed:
(DOWN, LINK  ,STOPPED) Stopped implies no link
( UP , LINK  ,STOPPED) UP & STOPPED is invalid
( UP ,NO LINK,STOPPED) UP & STOPPED is invalid

What do you think of this much?

Jared Grubb <jgrubb>
Group Member
Tue 10 Jul 2007 06:35:59 PM UTC, comment #9: 


>I agree that the UP and DOWN are primarily for the application and stack. But, a driver does care about UP and DOWN. For example, if the interface is DOWN, then the driver can turn its RX and TX circuts off (to save power, for example).


I'm not sure you have understand the problem with DHCP/AUTOIP: when the DHCP client is negociated an ip address, the netif is "down", until the DHCP finally bind the ip address, and it "up" the netif. If like you said, the driver turn off its RX/TX circuits, how can DHCP client negociate with the server?

>Driver initialization is a one-time thing, but "start" and "stop" can happen repeatedly if the interface is brought up and down in the code.


Perhaps this is the part I misunderstood: what do you call "start" and "stop" in this context?

>I suggested the callback function, but I think your event is much better.


When I said "event" I don't want to say "an OS event" (like semaphore, mutex...), but a feature which have to call the "link_callback": by example, saying you use tcpip.c, you could call tcpip_callback, or we could extend the optionnal netifapi.c to add a function like "netifapi_link_change/do_netifapi_link_change" on the same model than "netifapi_dhcp_start/do_netifapi_dhcp_start"...

Since we have to support NO_SYS=0 (with or without netifapi) & NO_SYS=1, I think the patch have to complete with such cases.

To come back with the power saving, if it's one of your goal, I think you could use the status_callback to do it, right? And the "ARP gratuitous" can be forced with current netif functions if your driver call ...

netif_set_down();
netif_set_up();

Of course, this is just a workaround (I think it do the job), but the idea of a "link_callback" is always good...

Frédéric Bernon <fbernon>
Group Member
Tue 10 Jul 2007 06:10:06 PM UTC, comment #8: 


> current "up" and "down" have only a sense for the stack & the application, not for driver


I agree that the UP and DOWN are primarily for the application and stack. But, a driver does care about UP and DOWN. For example, if the interface is DOWN, then the driver can turn its RX and TX circuts off (to save power, for example). Driver initialization is a one-time thing, but "start" and "stop" can happen repeatedly if the interface is brought up and down in the code.

> But we could say it's not directly the driver which have to do that, but the "event" signaled by the driver.


I suggested the callback function, but I think your event is much better.

Jared Grubb <jgrubb>
Group Member
Tue 10 Jul 2007 05:08:07 PM UTC, comment #7: 


>When I wrote the driver I assumed that was what status_callback was for?


In current code, netif's "up" & "down" can't be see like "enable send&receive" and "disable send&receive". By example, this is the DHCP client which call "netif_set_up" when it binds an ip address. But to do that, it have to be able to communicate with the DHCP server. So, that's why, to my point of view, current "up" and "down" have only a sense for the stack & the application, not for driver.

>In any case, I feel uncomfortable with making it the driver's responsibility to run DHCP, AUTOIP, or ARP, as these are things that should be managed higher up.


But isn't it what do netif_link_change_callback in your patch file (for ARP)? But we could say it's not directly the driver which have to do that, but the "event" signaled by the driver. To be clear (my english is not very good), the code for DHCP/AUTOIP/ARP doesn't have to be in the driver file, but in netif.c to mark the link is up, and in dhcp/autoip timers to handle that (perhaps is would work by default, but delay could be long)...

>Do we need three callbacks?

To my point of view, yes for the first, but using tcpip_callback or locking the core (this callback is the one you propose), yes for the second one (this could be the current status_callback, but with perhaps some parameters to notify the kind of event), but I'm not sure for the third (due to the DHCP problem, which is the same for AUTOIP).

>I hate to go overboard on callbacks...

Not sure to understand...




Frédéric Bernon <fbernon>
Group Member
Tue 10 Jul 2007 04:48:52 PM UTC, comment #6: 


> I think it's more "TO the application" than the driver.
> In my case, I use it to log any change about IP address.
> Of course, we can use it like we want.


It seems that "go up" and "go down" would be things every driver should know how to do. When I wrote the driver I assumed that was what status_callback was for?

In any case, I feel uncomfortable with making it the driver's responsibility to run DHCP, AUTOIP, or ARP, as these are things that should be managed higher up.

Do we need three callbacks?

  • Driver -> Stack on link change
  • Stack -> Application on status changes due to link (LINK UP) or status change (IFACE UP)
  • Stack -> Driver on netif changes due to application


I hate to go overboard on callbacks, but I dont think this is "too much" just yet.

Jared Grubb <jgrubb>
Group Member
Tue 10 Jul 2007 12:20:06 PM UTC, comment #5: 


>About the driver return values: TCP will retry if the link is down, for UDP you get back an error. Maybe we really should define a return value so applications see this (we should have a look at opengroup.org and other OSes what they return).


About that, it's about http://savannah.nongnu.org/bugs/?20021, comment #21, last part...

Frédéric Bernon <fbernon>
Group Member
Tue 10 Jul 2007 10:40:01 AM UTC, comment #4: 


> I think it should be an option, and not something "mandatory" if you don't have such possibility...


You can make it like that: if the link is set up after initializing (NETIF_FLAG_LINK_UP set), we can directly do all the stuff. If it's down (NETIF_FLAG_LINK_UP not set) we can wait for the status callback to come. In the satus callback, we can simply check the flag again.

About the driver return values: TCP will retry if the link is down, for UDP you get back an error. Maybe we really should define a return value so applications see this (we should have a look at opengroup.org and other OSes what they return).

Simon Goldschmidt <goldsimon>
Group administrator
Tue 10 Jul 2007 10:33:47 AM UTC, comment #3: 


>status_callback is a call from netif TO the driver for the netif_set_up and *_down events.


I think it's more "TO the application" than the driver. In my case, I use it to log any change about IP address. Of course, we can use it like we want.

>netif_link_change_callback would be a callback FROM the driver into the stack when it experiences link changes.


Yes (but if you are in the driver context, don't forget to protect the core). I think it should be an option, and not something "mandatory" if you don't have such possibility...

>It seems better to keep any stack operations (ARP, DHCP, etc) out of the driver and initiated by the stack in response to a driver event. As for the context the callback should be executed... I hadnt thought that part through :)


If we don't talk about details, each time your "link change to up", we should do :

- update AUTOIP/DHCP to renew or get a new IP
- send a "gratuitous ARP"

Like this, a device is more "mobile".

Last, there is no real guidelines for "driver design". Any value to return if a driver can't send a packet is defined (because all its internal "buffers" are full by example). That the "phy link is down" is another case. It's something to define...




Frédéric Bernon <fbernon>
Group Member
Mon 09 Jul 2007 04:40:52 PM UTC, comment #2: 

status_callback is a call from netif TO the driver for the netif_set_up and *_down events.

netif_link_change_callback would be a callback FROM the driver into the stack when it experiences link changes.

For example, the initial etharp_query as currently done in netif_set_up could be generated before the link has been established (NETIF_FLAG_LINK_UP is actually never tested in the lwIP code at all). If the link changes later on, the stack never even knows this.

It seems better to keep any stack operations (ARP, DHCP, etc) out of the driver and initiated by the stack in response to a driver event. As for the context the callback should be executed... I hadnt thought that part through :)

Jared Grubb <jgrubb>
Group Member
Mon 09 Jul 2007 04:30:57 PM UTC, comment #1: 

I think we should "renew" any DHCP or AUTOIP IP Address to respect some IP mobility requirements...

But I'm not sure to understand: it seems that your "link" callback replace the status_callback? Or I miss something?

To have something "safe", I think your callback have to be called by a tcpip_callback, or something like that, to avoid to use the core by multi threads/context (IT by example).

Last, It would be good if the "link" callback called an "application-level" callback like LWIP_NETIF_CALLBACK (to report that in any log by example)...

Frédéric Bernon <fbernon>
Group Member
Mon 09 Jul 2007 04:20:04 PM UTC, original submission:  

We should delay the gratutitous ARP until the link is actually UP, and regenerate it each time the link comes up new. Therefore, we can use a link change callback function to hold all the things that should be done when a new link is established or when a link is broken.

Attached: Proposed diff for netif.c
Not attached: Need to add prototype to netif.h

Jared Grubb <jgrubb>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #13307:  netif_comment_40.c added by jgrubb (13KiB - text/plain)
file #13292:  netif.c added by jgrubb (13KiB - text/plain)
file #13291:  netif.2.c added by jgrubb (1B - application/octet-stream)
file #13272:  netif.c.diff added by jgrubb (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jifl (Posted a comment)
  • -email is unavailable- added by kieranm (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by fbernon (Posted a comment)
  • -email is unavailable- added by jgrubb (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-07-13 fbernon StatusNone Fixed
        Assigned toNone jgrubb
        Open/ClosedOpen Closed
    2007-07-13 kieranm Planned Release 1.3.0
    2007-07-12 jgrubb Attached File- Added netif_comment_40.c, #13307
        Attached File- Added netif_comment_40.diff.txt, #13308
    2007-07-12 jgrubb Attached File- Added netif.c, #13292
    2007-07-12 jgrubb Attached File- Added netif.2.c, #13291
    2007-07-09 jgrubb Attached File- Added netif.c.diff, #13272

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code