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
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 the
On 12/09/13(Thu) 13:50, Philip Guenther wrote:
On Thu, Sep 12, 2013 at 10:19 AM, Mike Belopuhov m...@belopuhov.com 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
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 identity
On 12/09/13(Thu) 18:56, Henning Brauer wrote:
* Mike Belopuhov m...@belopuhov.com [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
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, even
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 its
* Reyk Floeter r...@openbsd.org [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,
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 it
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?
So
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 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 12 September 2013 17:18, Martin Pieuchot mpieuc...@nolizard.org 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 that
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 point of
On 12 September 2013 17:31, Reyk Floeter r...@openbsd.org 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
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 18:28, Mike Belopuhov m...@belopuhov.com wrote:
On 12 September 2013 18:14, Reyk Floeter r...@openbsd.org 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
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.
we do
On 12 September 2013 18:14, Reyk Floeter r...@openbsd.org 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
* Mike Belopuhov m...@belopuhov.com [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
On 12 September 2013 19:07, Reyk Floeter r...@openbsd.org 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
On 12 September 2013 18:48, Reyk Floeter r...@openbsd.org 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.
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 tun(4)
On Thu, Sep 12, 2013 at 10:19 AM, Mike Belopuhov m...@belopuhov.com 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
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?
Maybe.
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 we would
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 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
drivers in
On 27 August 2013 13:39, Martin Pieuchot mpieuc...@nolizard.org 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
On Tue, Aug 27, 2013 at 01:54:34PM +0200, Mike Belopuhov wrote:
On 27 August 2013 13:39, Martin Pieuchot mpieuc...@nolizard.org 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
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
32 matches
Mail list logo
