jamal <[EMAIL PROTECTED]> writes:
> How is this different, conceptually, from any other flag setting being
> lost - for example a promisc or admin up/down?
How do you lose promisc or admin up/down flag setting? Do you mean
userspace listening? It has to poll then.
> In other words if you want to
Stefan Rompf <[EMAIL PROTECTED]> writes:
> Yes, my patch bases on yours and Thomas' work. You're both welcome to add
> your
> signed-off lines.
That was trivial and I don't demand credit here. I just answered
Jamal's question.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "
* jamal <[EMAIL PROTECTED]> 2005-12-07 07:56
> How is this different, conceptually, from any other flag setting being
> lost - for example a promisc or admin up/down?
> In other words if you want to reliably transmit state, shouldnt the
> "responsible system" have to worry about the reliability?
>
On Wed, 2005-07-12 at 09:05 +0100, Thomas Graf wrote:
> The implementation of the rule "if admin status down operational status
> should be down" only exists in the sysfs code. I would absolutely favour
> one clear interface representing the operational status of an interface.
>
> The transition
Stefan,
This looks better with every iteration, I'm still lacking a few minor
things though:
The implementation of the rule "if admin status down operational status
should be down" only exists in the sysfs code. I would absolutely favour
one clear interface representing the operational status of
On Tue, 2005-06-12 at 23:34 +0100, Stefan Rompf wrote:
> Am Dienstag 06 Dezember 2005 22:25 schrieb Krzysztof Halasa:
>
> > > Is Stefan's patch going to restore the functionality that you need?
> >
> > I hope so. If done correctly, it would not only provide the
> > functionality my drivers were u
Am Dienstag 06 Dezember 2005 22:25 schrieb Krzysztof Halasa:
> > Is Stefan's patch going to restore the functionality that you need?
>
> I hope so. If done correctly, it would not only provide the
> functionality my drivers were using before the breakage, it would
> enable me to cut the dirty link
jamal <[EMAIL PROTECTED]> writes:
> I ask you a very specific question, you start playing silly games with
> words. This is why it has been hard to make progress with you.
> I didnt ask what you are doing without the patch or whether you will use
> the patch at all, rather whether it will restore
On Tue, 2005-06-12 at 20:45 +0100, Krzysztof Halasa wrote:
> jamal <[EMAIL PROTECTED]> writes:
>
> > Lets start with the basics: With this patch, can you still do what you
> > used to do before the change that broke things for you?
>
> I have put workarounds in place and my drivers are currently
jamal <[EMAIL PROTECTED]> writes:
> Lets start with the basics: With this patch, can you still do what you
> used to do before the change that broke things for you?
I have put workarounds in place and my drivers are currently working,
without any additional patch. So unless something is broken a
jamal <[EMAIL PROTECTED]> writes:
> Ok, please explain again, slowly if you can.
> What is it that wont work for you that is in Stefans patch or missing
> from his patch?
Please ask for a specific thing.
> [I am going to leave the rest of your message out so we avoid
> conflicts].
I can't see a
On Tue, 2005-06-12 at 17:10 +0100, Krzysztof Halasa wrote:
> jamal <[EMAIL PROTECTED]> writes:
>
> > Ok, please explain again, slowly if you can.
> > What is it that wont work for you that is in Stefans patch or missing
> > from his patch?
>
> Please ask for a specific thing.
>
Lets start with
On Tue, 2005-06-12 at 16:19 +0100, Krzysztof Halasa wrote:
> jamal <[EMAIL PROTECTED]> writes:
> I think I made myself clear. If you don't understand something, just ask
> for explanation.
>
Ok, please explain again, slowly if you can.
What is it that wont work for you that is in Stefans patch o
jamal <[EMAIL PROTECTED]> writes:
> I dont remember asking you not to CC me. What i remember asking you is
> to _stop_ talking about your useless patch.
I will, of course, not mention my patch to you anymore but could you
please leave decisions related to me and third parties just to me and
those
On Tue, 2005-06-12 at 15:11 +0100, Krzysztof Halasa wrote:
> Jamal's address ommited as requested.
>
I dont remember asking you not to CC me. What i remember asking you is
to _stop_ talking about your useless patch. But the way this is going i
am probably going to ask you to _not CC_ me.
The que
Jamal's address ommited as requested.
Stefan Rompf <[EMAIL PROTECTED]> writes:
> I'm more unhappy about the fact that a driver can (and could) do a
> netif_carrier_off()/-on() sequence too fast for the workqueue to follow.
Precisely. So there will always be the "glitches". And we can't "fix"
it
Am Donnerstag 01 Dezember 2005 13:48 schrieb Krzysztof Halasa:
> - kernel driver signals lower-level down
> - kernel driver signals lower-level up (dormant = 1)
> - slow userspace (in this case, could be a kernel module if strict
> serialization of all operational status changes isn't required)
jamal <[EMAIL PROTECTED]> writes:
>> Sure. But the changes are said to "fix" it, without success (of course,
>> they can't succeed without doing what I outlined, that's just
>> theoretically impossible, and OTOH not needed at all).
>
> And i fail to see how.
I think I can only agree with you on t
On Thu, 2005-01-12 at 16:39 +0100, Krzysztof Halasa wrote:
> jamal <[EMAIL PROTECTED]> writes:
>
> >> This bit alone doesn't tell if it's dormant or, for example, simply down
> >> (either admin or carrier).
>
> > dormant is an operational state and _not_ an admin state.
>
> And, in your opinion
jamal <[EMAIL PROTECTED]> writes:
>> This bit alone doesn't tell if it's dormant or, for example, simply down
>> (either admin or carrier).
> dormant is an operational state and _not_ an admin state.
And, in your opinion, changing admin state has not effect on operational
state?
> How is this
On Thu, 2005-01-12 at 13:48 +0100, Krzysztof Halasa wrote:
> Hi,
>
> Stefan Rompf <[EMAIL PROTECTED]> writes:
> > +}
>
> This is of course much much more correct than those strange operations
> on dev->char_type, though netif_dormant* is still misnamed - dormant
> isn't one bit but rather a comb
Hi Stefan,
Looking good.
On Wed, 2005-30-11 at 23:29 +0100, Stefan Rompf wrote:
> Changes since last version:
>
> -remove NETIF_F_STACKED, use dev->iflink instead. Change VLAN to set
> dev->iflink properly
There is only one gotcha i noticed with vlan - as you keep stacking you
set the iflink;
Hi,
Stefan Rompf <[EMAIL PROTECTED]> writes:
> ok, seems we are getting near submission for kernel inclusion. If no new
> comments arise, the only thing missing from my side is documentation.
I understand it's supposed to be race and "race" free?
> + unsigned char operstate; /* R
Hi,
ok, seems we are getting near submission for kernel inclusion. If no new
comments arise, the only thing missing from my side is documentation. VLAN is
again included in this patch to show one use case.
Changes since last version:
-remove NETIF_F_STACKED, use dev->iflink instead. Change VLA
On Tue, 2005-29-11 at 00:26 +0100, Stefan Rompf wrote:
> Am Montag 28 November 2005 23:13 schrieb Thomas Graf:
>
> > The effort is nice but why do we need sysfs? Isn't netlink enough for
> > you?
>
> Well, there are already a *lot* of device attributes in sysfs (just ls
> -l /sys/class/net/eth
Am Montag 28 November 2005 23:13 schrieb Thomas Graf:
> Looks good, it would be nice if you could separate the vlan part as a
> separate patch for later on though.
This will happen when I submit the final patch for kernel inclusion.
> The effort is nice but why do we need sysfs? Isn't netlink en
* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-28 14:15
> Hi,
>
> ok, at least some progress has happened:
Looks good, it would be nice if you could separate the vlan part as a
separate patch for later on though.
> -Replaced device-specific oper_state method with NETIF_F_STACKED flag to
> select be
Am Montag 28 November 2005 14:15 schrieb Stefan Rompf:
> -complete sysfs
> -test netlink userspace interaction
both done, next patch will follow when docs are written. Thomas: Thanks for
libnl, it made sending netlink messages a lot easier!
Stefan
-
To unsubscribe from this list: send the line
Hi,
ok, at least some progress has happened:
-Replaced device-specific oper_state method with NETIF_F_STACKED flag to
select between IF_OPER_DOWN or IF_OPER_LOWERLAYERDOWN
-sysfs support to read operstate
-completed netlink support (Jamal, Thomas, can you verify the code?)
-added netif_oper_up()
On Wed, 2005-23-11 at 09:54 -0500, jamal wrote:
> yes, this would work. However, i am still interested in the case where
> you have a single radio but multiple AP connections - unless this is
> impossible. I have to go back and look at that paper - I know they were
> using very basic 802.11
>
I just changed the topic so as not to distract the original discussion
On Wed, 2005-23-11 at 06:41 -0800, Jouni Malinen wrote:
> The case where one radio in client mode is associating with multiple APs
> is usually done by having multiple virtual netdevs, i.e., one for each
> association.
Soun
On Wed, Nov 23, 2005 at 09:24:05AM -0500, jamal wrote:
> Well, thats certainly one way. Then the oper state machines you are
> working on + stacking will work well. But this depends on if you can
> justify the reason for those virtual devices. With wireless you can
> probably justify to map the ra
Stefan,
On Tue, 2005-22-11 at 21:38 +0100, Stefan Rompf wrote:
> we could protect operstate with a spinlock_irqsave() and then change it
> either
> from netif_[carrier|dormant]_on/off() or userspace-supplicant. However, I'm
> not feeling good about it.
Ok, what you have is fine by me.
> Loo
Stefan Rompf <[EMAIL PROTECTED]> writes:
> Sorry, I don't get that and want to avoid further misunderstandings. So can
> you use _ONE_ netdev_set_operstate() function to switch between OPER_DOWN
> (!carrier), OPER_DORMANT (!protocol) and OPER_UP (both fine) or not?
I can use whatever is availab
Hi Krzysztof,
> No big deal with my generic HDLC (I may leave it one-layer though it's
> quite dirty, and would be even less logical with the new
> dormant/whatever).
Sorry, I don't get that and want to avoid further misunderstandings. So can
you use _ONE_ netdev_set_operstate() function to swit
Stefan Rompf <[EMAIL PROTECTED]> writes:
> clear that his drivers have several independant layers, one responsible for
> carrier, mapped to netdev_carrier*(), another one responsible for the
> protocol, mapped to netdev_dormant*().
No big deal with my generic HDLC (I may leave it one-layer thou
Hi Jamal,
> be transitioned to up/dormant etc. So an ethernet driver doesnt know it
> needs to go from detecting peer link is up to next being authenticated
> in the case of 802.1x. It just calls netif_carrier_on which checks
> link_mode to decide on transition.
we could protect operstate with a
Hi Stefan,
I looked at the patch and while there are some stylistic/implementation
differences between us, I think generally all the concepts seem to be in
place. So we are almost there.
More comments below:
On Fri, 2005-18-11 at 21:52 +0100, Stefan Rompf wrote:
> This is the data flow:
>
> -D
Am Freitag 18 November 2005 04:03 schrieb jamal:
> > ok, I'll produce a patch then - first version will be available tomorrow
> > evening.
>
> beauty.
Ok, here is the first 'merger' patch. At this stage, it is only compilation
tested against 2.6.14.
This is the data flow:
-Device changes __LIN
On Thu, 2005-17-11 at 22:03 -0500, jamal wrote:
>
> I will attempt some ascii art shortly. Actually if you agree with it
> please include it in your patch so it is easier for people to make
> changes in the future.
>
ok, ascii art is hard - instead in pseudo code (please double check with
the R
On Thu, 2005-17-11 at 21:36 +0100, Stefan Rompf wrote:
> Am Donnerstag 17 November 2005 04:29 schrieb jamal:
>
> > > > 1) There are read_only oper state IFF_XXX flags which are sent via
> > > > netlink to user space. These are set by the kernel (and not by user
> > > > space); they reflect the sta
Am Donnerstag 17 November 2005 04:29 schrieb jamal:
> > > 1) There are read_only oper state IFF_XXX flags which are sent via
> > > netlink to user space. These are set by the kernel (and not by user
> > > space); they reflect the state of "link".
We can avoid a myriad of new IFF_*-flags if we all
On Wed, 2005-16-11 at 17:14 +0100, Thomas Graf wrote:
> * jamal <[EMAIL PROTECTED]> 2005-11-15 21:16
> > 3) There is a kernel dev->operstate_kernel which is accessible via
> > user space in the same manner IFF_UP flags are set etc.
>
> Just be careful about synchronization, that's one issue with
On Wed, 2005-16-11 at 16:46 +0100, Stefan Rompf wrote:
> Am Mittwoch 16 November 2005 03:16 schrieb jamal:
>
> > I will not respond to the rest of your email - I wanna make sure we are
> > in sync first on the above. So let me summarize:
>
> Ok, let's see if I understood you:
>
> > 1) There are
jamal <[EMAIL PROTECTED]> writes:
> I am afraid I would have to agree with Stefan on this Krzysztof.
Supporting false statements doesn't make them less false :-)
OTOH I hope your opinions about people have no influence on your view
of the code they write so it's not exactly important here.
> Yo
* jamal <[EMAIL PROTECTED]> 2005-11-15 21:16
> 3) There is a kernel dev->operstate_kernel which is accessible via
> user space in the same manner IFF_UP flags are set etc.
Just be careful about synchronization, that's one issue with the
currently proposed implementation. The callers cannot be mad
Am Mittwoch 16 November 2005 03:16 schrieb jamal:
> I will not respond to the rest of your email - I wanna make sure we are
> in sync first on the above. So let me summarize:
Ok, let's see if I understood you:
> 1) There are read_only oper state IFF_XXX flags which are sent via
> netlink to user
On Tue, 2005-15-11 at 21:18 +0100, Stefan Rompf wrote:
> Am Dienstag 15 November 2005 04:19 schrieb jamal:
>
> > 1) I think we need to separate the oper state from the rest; so
> > no need to add dormant to be in netdev_state_t.
>
> ok, it seems that everybody else wants to go with state flags.
On Tue, 2005-15-11 at 20:36 -0500, jamal wrote:
>
> * The first thing you do is configure the netdevice to the admin mode of
> operation. This is very close to what BSD (and some vendors) allow for
> sync PPP (I will try to find a url or look up ifconfig man pages on
> BSD). IOW, you do this when
On Tue, 2005-15-11 at 21:22 +0100, Krzysztof Halasa wrote:
> Stefan Rompf <[EMAIL PROTECTED]> writes:
>
> > This is because you don't give a damn about anything that goes beyond
> > your WAN
> > drivers.
>
> False statement.
I am afraid I would have to agree with Stefan on this Krzysztof. You a
On Tue, 2005-15-11 at 20:28 +0100, Stefan Rompf wrote:
> Am Dienstag 15 November 2005 15:16 schrieb jamal:
>
> > Having said that, perhaps thats where the concept of useroverride you
> > have or IFF_WAIT needs to go. What should be done though is to select an
> > "operational" mode via admin flags
Stefan Rompf <[EMAIL PROTECTED]> writes:
>> I even responded to it. Show me where he requests anything similar to
>> operstate_useroverride or IFF_WAIT?
>
> operstate_useroverride or IFF_WAIT are possible solutions to
[Jouni's mail]
For now they are just broken and that haven't changed since the
Am Dienstag 15 November 2005 21:22 schrieb Krzysztof Halasa:
> I even responded to it. Show me where he requests anything similar to
> operstate_useroverride or IFF_WAIT?
operstate_useroverride or IFF_WAIT are possible solutions to
-handle this part of Jouni's mail:
> [...]
> however, this woul
Stefan Rompf <[EMAIL PROTECTED]> writes:
> This is because you don't give a damn about anything that goes beyond
> your WAN
> drivers.
False statement.
> Look at <[EMAIL PROTECTED]> from Jouni Malinen, posted
> to the list.
I even responded to it. Show me where he requests anything similar to
Am Dienstag 15 November 2005 04:19 schrieb jamal:
> 1) I think we need to separate the oper state from the rest; so
> no need to add dormant to be in netdev_state_t.
ok, it seems that everybody else wants to go with state flags. Even though I'm
not convinced, I should accept this and therefore T
Stefan Rompf <[EMAIL PROTECTED]> writes:
> Please reread what is written about locking in net/core/dev.c. It has
> looked a
> bit strange to me, too, when I needed to use it for the first time, but my
> code does the right thing here. Remember, linkwatch_fire_event() is _NOT_ a
> pure reader.
Am Dienstag 15 November 2005 15:16 schrieb jamal:
> Having said that, perhaps thats where the concept of useroverride you
> have or IFF_WAIT needs to go. What should be done though is to select an
> "operational" mode via admin flags - example "the device is set by the
> admin to dormant state" or
Am Dienstag 15 November 2005 18:54 schrieb Krzysztof Halasa:
> > You said the same to Thomas on IFF_WAIT. Both operstate_useroverride and
> > IFF_WAIT exist to allow userspace 802.1X/wpa supplicant interaction.
>
> Are we sure about this? It might be the case but I don't think I've seen
> such req
Am Dienstag 15 November 2005 17:41 schrieb Krzysztof Halasa:
> > * The @dev_base list is protected by @dev_base_lock and the rtln
> > * semaphore.
> > *
> > * Pure readers hold dev_base_lock for reading.
> > *
> > * Writers must hold the rtnl semaphore while they loop through the
> > * dev_
jamal <[EMAIL PROTECTED]> writes:
> 1) I dont think operstare_useroverride is needed.
I don't either. We should ask potential users, though - doing things
we think are best but nobody is going to use is nonsense.
> a) We need new flags which get reflected to user space; i.e new IFF_XXX
> flags.
Stefan Rompf <[EMAIL PROTECTED]> writes:
> You said the same to Thomas on IFF_WAIT. Both operstate_useroverride and
> IFF_WAIT exist to allow userspace 802.1X/wpa supplicant interaction.
Are we sure about this? It might be the case but I don't think I've seen
such request.
--
Krzysztof Halasa
-
Stefan Rompf <[EMAIL PROTECTED]> writes:
> as described in net/core/dev.c:
>
> * The @dev_base list is protected by @dev_base_lock and the rtln
> * semaphore.
> *
> * Pure readers hold dev_base_lock for reading.
> *
> * Writers must hold the rtnl semaphore while they loop through the
> * de
On Tue, 2005-15-11 at 08:02 -0500, jamal wrote:
> I didnt see this issue as any different than setting any other current
> netdevice flags which goes via dev_change_flags; i gave the example of
> IFF_UP in my email because it sets the dev->state (invoked via
> dev->open/close). In the case of user
On Tue, 2005-15-11 at 08:17 +0100, Stefan Rompf wrote:
> Am Dienstag 15 November 2005 03:43 schrieb jamal:
>
> I'll have more time for a comment this evening, but let me ask one question
> until then:
>
> > 1) I dont think operstare_useroverride is needed.
>
> You said the same to Thomas on IFF
Am Dienstag 15 November 2005 03:43 schrieb jamal:
I'll have more time for a comment this evening, but let me ask one question
until then:
> 1) I dont think operstare_useroverride is needed.
You said the same to Thomas on IFF_WAIT. Both operstate_useroverride and
IFF_WAIT exist to allow userspa
As in the case of Stefan, only the negative comments:
1) I think we need to separate the oper state from the rest; so
no need to add dormant to be in netdev_state_t.
2) Events need only be generated from/to down state
3) IFF_WAIT is not needed. A device goes from NOTPRESENT
to DOWN; and may go
On Mon, 2005-14-11 at 16:53 +0100, Krzysztof Halasa wrote:
> jamal <[EMAIL PROTECTED]> writes:
>
> "Dormant" is not a flag (1 bit) but rather a specific set of flags
> (exactly as there is no "running" nor "l2down" bits). So set_dormant*()
> (with bit flags) doesn't make much sense unless it chan
On Mon, 2005-14-11 at 16:48 +0100, Stefan Rompf wrote:
> Am Montag 14 November 2005 14:57 schrieb jamal:
>
> > My suggestion is at this point to ignore any L3 issues and have people
> > post their patches. RFC 2863 states MUST be taken into consideration.
> > Proper naming must be taken into accou
> My suggestion is at this point to ignore any L3 issues and have people
> post their patches. RFC 2863 states MUST be taken into consideration.
> Proper naming must be taken into account.
Split up in 3 patches, not implementing the bits allowing userspace to
trigger leaving dormant state.
[NET]
Am Montag 14 November 2005 17:44 schrieb Krzysztof Halasa:
[As Jamal answers later, I'll just comment on the technical questions]
> Why do you do that instead of atomic write?
as described in net/core/dev.c:
* The @dev_base list is protected by @dev_base_lock and the rtln
* semaphore.
*
* P
Stefan Rompf <[EMAIL PROTECTED]> writes:
> +++ linux-2.6.14/net/core/link_watch.c
> @@ -75,7 +75,14 @@ void linkwatch_run_queue(void)
> clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state);
>
> if (dev->flags & IFF_UP) {
> - if (netif_carrier_ok(
I want to apologize in advance - I wont be able to comment on anything
for another 10 hours or so. I will comment tonight.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.o
jamal <[EMAIL PROTECTED]> writes:
> My suggestion is at this point to ignore any L3 issues and have people
> post their patches. RFC 2863 states MUST be taken into consideration.
> Proper naming must be taken into account.
I'll not repost my patch because you already have it and it lacks only
co
Am Montag 14 November 2005 14:57 schrieb jamal:
> My suggestion is at this point to ignore any L3 issues and have people
> post their patches. RFC 2863 states MUST be taken into consideration.
> Proper naming must be taken into account.
here we go. I've removed OPER_DORMANTL3* as requested and ch
jamal <[EMAIL PROTECTED]> writes:
> Thats the idea. But for now - I suggest we take L3 out of the equation
> and we revisit after the first agreeable patch is out.
L3 as in DORMANT_L3{DOWN,UP}? Sure.
>> Come on, making a patch showing the general idea as well as the
>> problematic details (locki
Stefan,
After talking to Thomas it seems to me there are no conceptual
differences - at least he and Krzysztof agree on the principle of
of the dormant state.
So what you mention below is more of implementation issues. All
implementation issues are resolvable.
My suggestion is at this point to i
On Sun, 2005-13-11 at 23:38 +0100, Krzysztof Halasa wrote:
> jamal <[EMAIL PROTECTED]> writes:
[Skipping all L3 issues ..]
> > My suggestion to move forward is:
> > i) Lets just stick to existing states in the RFC and no innovation of
> > any sort.
>
> This is backwards:
>
Why is it backwards?
On Mon, 2005-14-11 at 00:43 +0100, Thomas Graf wrote:
> * jamal <[EMAIL PROTECTED]> 2005-11-13 10:09
> > Issue-1)
> > We have agreed to implement based on 2863.
> > Stefan has gone one step further and suggested extra states for L3
> > status. The idea for the extra states being to resolve in this
Thomas Graf <[EMAIL PROTECTED]> writes:
> What has been proposed so far is a stupid hack around something broken
> in userspace.
Not sure. Ignoring routes going though failed interfaces doesn't seem like
a hack at all.
> What are you going to do when you need to overwrite a route while the
> int
* jamal <[EMAIL PROTECTED]> 2005-11-13 10:09
> Issue-1)
> We have agreed to implement based on 2863.
> Stefan has gone one step further and suggested extra states for L3
> status. The idea for the extra states being to resolve in this fix old
> standing issue (since 2.2 days) of higher metric rout
jamal <[EMAIL PROTECTED]> writes:
> a) one that depends on the L3* states that goes around and marks every
> route as "inactive". What "inactive" means is still unclear; it could
> just be to add a blackhole route. Stefan and Krzysztof main proponents.
Blackhole is different, packets get simply
On Sun, 2005-13-11 at 16:47 +0100, Stefan Rompf wrote:
> Am Sonntag 13 November 2005 16:09 schrieb jamal:
>
> > I think the discussions have been valuable despite the time they took.
> > This is just to bring us back to not go on a tangent and hopefully close
> > this sooner.
>
> thanks for takin
Am Sonntag 13 November 2005 16:09 schrieb jamal:
> I think the discussions have been valuable despite the time they took.
> This is just to bring us back to not go on a tangent and hopefully close
> this sooner.
thanks for taking the time to moderate this.
> We have agreed to implement based on
Stefan,
I am not gonna comment on this email although it is tempting.
Can you refer to my latest email and see if we can reach some closure?
cheers,
jamal
On Sun, 2005-13-11 at 16:01 +0100, Stefan Rompf wrote:
> Am Sonntag 13 November 2005 15:13 schrieb jamal:
>
> > > Obviously, no. I mean rout
I think the discussions have been valuable despite the time they took.
This is just to bring us back to not go on a tangent and hopefully close
this sooner.
There are two main outstanding issues as i see it:
Issue-1)
We have agreed to implement based on 2863.
Stefan has gone one step further a
Am Sonntag 13 November 2005 15:13 schrieb jamal:
> > Obviously, no. I mean route entry "inactive" flag (not existing yet)
> > which has exactly nothing to do with its destination.
>
> I dont know what that would buy you that a blackhole route could not
> give you: Packets will be dropped at the ip
On Sun, 2005-13-11 at 00:04 +0100, Krzysztof Halasa wrote:
> Jamal Hadi Salim <[EMAIL PROTECTED]> writes:
>
> > Issue 1:
> > 1) There are routes that are added by the kernel. These are labelled as
> > being added by the kernel.
> > 2) Others maybe added by a dynamic routing daemon and these would
jamal <[EMAIL PROTECTED]> writes:
> I have a patch that seems to work for me on my laptop.
> i.e on oper down it deletes the controversial routes added by the kernel
> and on oper up it adds back those routes.
>
> I am not going to release this patch - until we get to some consensus.
Just post it
Jamal Hadi Salim <[EMAIL PROTECTED]> writes:
> Issue 1:
> 1) There are routes that are added by the kernel. These are labelled as
> being added by the kernel.
> 2) Others maybe added by a dynamic routing daemon and these would be
> labelled as being inserted by such a daemon
> 3) Yet others are a
On Fri, 2005-11-11 at 11:39 -0500, jamal wrote:
> I will code this up when i get home on saturday.
>
I have a patch that seems to work for me on my laptop.
i.e on oper down it deletes the controversial routes added by the kernel
and on oper up it adds back those routes.
I am not going to releas
On Fri, 2005-11-11 at 21:33 +0100, Krzysztof Halasa wrote:
> jamal <[EMAIL PROTECTED]> writes:
>
> > well, the kernel doesnt add default routes - some admin or daemon does.
> > So whatever solution it is should not delete such routes either.
>
> Sure. Inactivate them instead and activate back on
jamal <[EMAIL PROTECTED]> writes:
> duh - I didnt mean to delete _all_ routes. I meant to use that event as
> a base to delete whatever the kernel added and vice-versa.
> what does inactive routes mean? blackhole routes i understand
Negative. Routes that are not considered while making actual ro
jamal <[EMAIL PROTECTED]> writes:
> well, the kernel doesnt add default routes - some admin or daemon does.
> So whatever solution it is should not delete such routes either.
Sure. Inactivate them instead and activate back on carrier (IFF_RUNNING,
not the carrier alone) return.
>> Seems inactive
On Fri, 2005-11-11 at 00:36 +0100, Thomas Graf wrote:
> * Stefan Rompf <[EMAIL PROTECTED]> 2005-11-10 19:46
> > fib_disable_ip() evicts all routes pointing to that interface, including
> > userspace generated ones, doesn't it? If so, we don't get away that easy.
>
> Right, the patch represents J
On Thu, 2005-10-11 at 23:10 +, Paul Jakma wrote:
> On Thu, 10 Nov 2005, Thomas Graf wrote:
>
> > This is not only about dial on demand but about "on demand"
> > interfaces. We need to have a route to the device so the
> > driver/manager/whatever can see the demand. If we disable routes on
>
On Thu, 2005-10-11 at 20:01 +0100, Krzysztof Halasa wrote:
> Stefan Rompf <[EMAIL PROTECTED]> writes:
>
> > fib_disable_ip() evicts all routes pointing to that interface, including
> > userspace generated ones, doesn't it? If so, we don't get away that easy.
>
> Right. I'm no longer sure we sho
On Thu, 2005-10-11 at 19:46 +0100, Stefan Rompf wrote:
> Am Mittwoch 09 November 2005 22:12 schrieb Thomas Graf:
>
> > Something like this should do the job, although it doesn't take care
> > of taking things up again for now. Now all supporters of this should
> > tell me how to implement any case
On Fri, 11 Nov 2005, Thomas Graf wrote:
The state of an on-demand interface must be visible, typically an
on-demand interface is in dormant state and goes to up while it is
in use and back to dormant after some time of inactivity. Further,
if the interface knows that a demand cannot be met it
On Fri, 11 Nov 2005, Thomas Graf wrote:
That is a very important point, actually it's the whole truth. If
we extend it a little and say, let's give userspace control of all
directly connected routes so it can delete/replace/modify/whatever
if needed.
It may or not be better. However, it /wou
* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-10 19:46
> fib_disable_ip() evicts all routes pointing to that interface, including
> userspace generated ones, doesn't it? If so, we don't get away that easy.
Right, the patch represents Jamal's interpretation. Once in a while
I please him by providing
1 - 100 of 131 matches
Mail list logo
