On Sat, Oct 19, 2013 at 01:26:39PM +0200, Mike Belopuhov wrote:
> hi,
>
> since mpi's if_index diff is now in, this should probably
> go in as well. it has received some testing in the meantime.
>
> original description:
>
> in order to make our life a bit easier and prevent rogue
> accesses to
hi,
since mpi's if_index diff is now in, this should probably
go in as well. it has received some testing in the meantime.
original description:
in order to make our life a bit easier and prevent rogue
accesses to the routing table from the hardware interrupt
context violating all kinds of spl
Reyk Floeter wrote:
> Yes, in theory if_index should be fixed and return a consistent number
> between 1 and the number of interfaces. But this is obviously
> difficult and I'm not sure if it's worth the effort. So the "hack"
> that you're going to remove was a best effort. But putting another
On Fri, Sep 13, 2013 at 10:45:57AM +0200, Martin Pieuchot wrote:
> > No, that's utterly stupid. The interface index is a value that is
> > supposed to be consistent across the system. How should it be synced
> > with other userland tools? How would you handle it in if_nametoindex
> > and friends
On 13/09/13(Fri) 10:14, Reyk Floeter wrote:
> On Fri, Sep 13, 2013 at 09:53:03AM +0200, Martin Pieuchot wrote:
> > > -let snmpd (or sth else) make up ifindices just for that purpose
> >
> > That looks like the best solution to me. If a userland program want
> > to expose following numbers, then i
* Reyk Floeter [2013-09-13 10:20]:
> please read the history: if_index _was_ created for SNMP.
I'm not at all certain you got the history right there...
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS Servi
On 2013/09/13 09:53, Martin Pieuchot wrote:
> On 12/09/13(Thu) 18:56, Henning Brauer wrote:
> > -let snmpd (or sth else) make up ifindices just for that purpose
>
> That looks like the best solution to me. If a userland program want
> to expose following numbers, then it probably needs to create
On Fri, Sep 13, 2013 at 09:53:03AM +0200, Martin Pieuchot wrote:
> > -let snmpd (or sth else) make up ifindices just for that purpose
>
> That looks like the best solution to me. If a userland program want
> to expose following numbers, then it probably needs to create its own
> indexes anyway, e
On 12/09/13(Thu) 18:56, Henning Brauer wrote:
> * Mike Belopuhov [2013-09-12 17:54]:
> > it makes no sense whatsoever, reyk. those indices can be easily
> > stolen and nobody guarantees that if you create vlan10, vlan11,
> > then destroy vlan10, create vlan12 and vlan10 that vlan10 will
> > have
On 2013/09/13 09:10, Martin Pieuchot wrote:
> On 12/09/13(Thu) 13:50, Philip Guenther wrote:
> > (I don't get why it's useful for tun0-in-layer3 mode to have the same
> > if_index as tun0-in-layer2 mode. The properties are so different that
> > there doesn't really seem to be continuity of identit
On 12/09/13(Thu) 13:50, Philip Guenther wrote:
> On Thu, Sep 12, 2013 at 10:19 AM, Mike Belopuhov wrote:
> ...
> > either way, we need to move forward on this. we want to use if_index
> > for the purpose of looking up the interface w/o a pointer to the ifnet.
>
> This sounds like just using a pi
On Thu, Sep 12, 2013 at 06:59:13PM +0200, Mike Belopuhov wrote:
> > Ok, let's stop this. I don't think you read what I replied before. I
> > didn't say that we're static with if_indexes, just that we shouldn't
> > make it worse.
> >
>
> or implement persistent indices in the snmpd itself maybe?
On Thu, Sep 12, 2013 at 10:19 AM, Mike Belopuhov wrote:
...
> either way, we need to move forward on this. we want to use if_index
> for the purpose of looking up the interface w/o a pointer to the ifnet.
This sounds like just using a pid to identify processes and hoping
they haven't wrapped aro
On Thu, Sep 12, 2013 at 05:53:42PM +0200, Mike Belopuhov wrote:
> looks like you misunderstand the problem we're dealing with here.
>
Sure, I do. You're trying to push one thing and you don't want to
hear the concerns about a specific detail of it.
> >> FWIW it would be interesting to modify tu
On 12 September 2013 18:48, Reyk Floeter wrote:
> On Thu, Sep 12, 2013 at 06:28:15PM +0200, Mike Belopuhov wrote:
>> > Sure, I do. You're trying to push one thing and you don't want to
>> > hear the concerns about a specific detail of it.
>> >
>>
>> with all respect, i think you don't. otherwise
On 12 September 2013 19:07, Reyk Floeter wrote:
> On Thu, Sep 12, 2013 at 06:59:13PM +0200, Mike Belopuhov wrote:
>> > Ok, let's stop this. I don't think you read what I replied before. I
>> > didn't say that we're static with if_indexes, just that we shouldn't
>> > make it worse.
>> >
>>
>> or
* Mike Belopuhov [2013-09-12 17:54]:
> it makes no sense whatsoever, reyk. those indices can be easily
> stolen and nobody guarantees that if you create vlan10, vlan11,
> then destroy vlan10, create vlan12 and vlan10 that vlan10 will
> have the same index as before. in fact it might be a differe
On 12 September 2013 18:14, Reyk Floeter wrote:
> On Thu, Sep 12, 2013 at 05:53:42PM +0200, Mike Belopuhov wrote:
>> looks like you misunderstand the problem we're dealing with here.
>>
>
> Sure, I do. You're trying to push one thing and you don't want to
> hear the concerns about a specific deta
On Thu, Sep 12, 2013 at 06:28:15PM +0200, Mike Belopuhov wrote:
> > Sure, I do. You're trying to push one thing and you don't want to
> > hear the concerns about a specific detail of it.
> >
>
> with all respect, i think you don't. otherwise you wouldn't be asking
> the questions you're asking.
On 12 September 2013 18:28, Mike Belopuhov wrote:
> On 12 September 2013 18:14, Reyk Floeter wrote:
>> On Thu, Sep 12, 2013 at 05:53:42PM +0200, Mike Belopuhov wrote:
>>> looks like you misunderstand the problem we're dealing with here.
>>>
>>
>> Sure, I do. You're trying to push one thing and y
On Thu, Sep 12, 2013 at 07:19:34PM +0200, Mike Belopuhov wrote:
> either way, we need to move forward on this. we want to use if_index
> for the purpose of looking up the interface w/o a pointer to the ifnet.
> should we implement additional indices for that or snmp problem will
> be dealt with?
On 12 September 2013 17:31, Reyk Floeter wrote:
> On Thu, Sep 12, 2013 at 05:18:39PM +0200, Martin Pieuchot wrote:
>> > For example, you have to query the IfIndex via SNMP to get further
>> > information, like the ifName or statistics, and most monitoring
>> > systems would save interface informat
On 12/09/13(Thu) 16:40, Reyk Floeter wrote:
> On Thu, Sep 12, 2013 at 06:51:46AM +0200, Claudio Jeker wrote:
> > On Tue, Aug 27, 2013 at 01:39:14PM +0200, Martin Pieuchot wrote:
> > > I think that's the right approach but the current code generating
> > > interfaces indexes is too clever from my po
On 12 September 2013 17:18, Martin Pieuchot wrote:
> FWIW it would be interesting to modify tun(4) so that it doesn't
> need to detach/reattach itself when switching between mode, this
> would allow us to stop reusing the last index.
>
this definitely makes a lot of sense.
On Thu, Sep 12, 2013 at 05:18:39PM +0200, Martin Pieuchot wrote:
> > For example, you have to query the IfIndex via SNMP to get further
> > information, like the ifName or statistics, and most monitoring
> > systems would save interface information based on the index - they
> > would not recognize
On Thu, Sep 12, 2013 at 06:51:46AM +0200, Claudio Jeker wrote:
> On Tue, Aug 27, 2013 at 01:39:14PM +0200, Martin Pieuchot wrote:
> > I think that's the right approach but the current code generating
> > interfaces indexes is too clever from my point of view, it tries
> > to reuse the last index if
On Tue, Aug 27, 2013 at 01:39:14PM +0200, Martin Pieuchot wrote:
> On 26/08/13(Mon) 13:36, Mike Belopuhov wrote:
> > hi,
> >
> > in order to make our life a bit easier and prevent rogue
> > accesses to the routing table from the hardware interrupt
> > context violating all kinds of spl assumptions
On Mon, Aug 26, 2013 at 13:36 +0200, Mike Belopuhov wrote:
> hi,
>
> in order to make our life a bit easier and prevent rogue
> accesses to the routing table from the hardware interrupt
> context violating all kinds of spl assumptions we would
> like if_link_state_change that is called by network
On Tue, Aug 27, 2013 at 01:54:34PM +0200, Mike Belopuhov wrote:
> On 27 August 2013 13:39, Martin Pieuchot wrote:
> > I think that's the right approach but the current code generating
> > interfaces indexes is too clever from my point of view, it tries
> > to reuse the last index if possible. Thi
On 27 August 2013 13:39, Martin Pieuchot wrote:
> I think that's the right approach but the current code generating
> interfaces indexes is too clever from my point of view, it tries
> to reuse the last index if possible. This could lead to some
> funny races if we detach and reattach an interfac
On 26/08/13(Mon) 13:36, Mike Belopuhov wrote:
> hi,
>
> in order to make our life a bit easier and prevent rogue
> accesses to the routing table from the hardware interrupt
> context violating all kinds of spl assumptions we would
> like if_link_state_change that is called by network device
> driv
hi,
in order to make our life a bit easier and prevent rogue
accesses to the routing table from the hardware interrupt
context violating all kinds of spl assumptions we would
like if_link_state_change that is called by network device
drivers in their interrupt service routines to defer its
work to
32 matches
Mail list logo
