Hi all,
Already exists MFC available to fix this problem in 10-STABLE?
# ipfw table 99 add 0.0.0.0/8
# ipfw table 99 list
::/8 0
Cheers,
Gondim
Em 17/05/2014 20:37, Marcelo Gondim escreveu:
Em 17/05/14 20:28, Marcelo Gondim escreveu:
Em 17/05/14 10:44, Alexander V. Chernikov escreveu:
On 13
Em 17/05/14 12:23, Alexander V. Chernikov escreveu:
On 17.05.2014 19:14, Andreas Nilsson wrote:
On Sat, May 17, 2014 at 3:44 PM, Alexander V. Chernikov
mailto:melif...@freebsd.org>> wrote:
On 13.05.2014 16:05, Dennis Yusupoff wrote:
I think that universal table for all kind of
It will e nice to have this utility function
> On 21 May, 2014, at 1:32 am, "Alexander V. Chernikov"
> wrote:
>
>> On 19.05.2014 17:38, Dennis Yusupoff wrote:
>> It's not enough, actually.
>> Imagine what you have a table with different networks. If you'll try to
>> find out is an IP belongs to
On 19.05.2014 17:38, Dennis Yusupoff wrote:
It's not enough, actually.
Imagine what you have a table with different networks. If you'll try to
find out is an IP belongs to some of that networks from the table, you
should to write relatively serious "wrapper" with network range
calculations in it.
On 19.05.2014 17:12, bycn82 wrote:
On 5/19/14 21:00, Alexander V. Chernikov wrote:
On 19.05.2014 11:51, Bill Yuan wrote:
Hi Alex,
Hello Bill!
You guys are chatting here! I agree with you, the table is the place
should
be enhanced, and I am working in this way as described below
1. Support
It's not enough, actually.
Imagine what you have a table with different networks. If you'll try to
find out is an IP belongs to some of that networks from the table, you
should to write relatively serious "wrapper" with network range
calculations in it. Or can you show differ (easier) way?
So it's
Longest prefix match, obviously. Doesn't see any reason to search for
exact match in case of existing prefix with that ip.
19.05.2014 17:01, Alexander V. Chernikov пишет:
> On 19.05.2014 12:54, Dennis Yusupoff wrote:
>> Alex, Bill, it's a good news, glad to hear it.
>>
>> Let me ask even more func
On 5/19/14 21:01, Alexander V. Chernikov wrote:
On 19.05.2014 12:54, Dennis Yusupoff wrote:
Alex, Bill, it's a good news, glad to hear it.
Let me ask even more functionality:
6. Test if entry exist in table:
ipfw table test
It extremely useful in case of big, unordered data in the table - fo
On 5/19/14 21:00, Alexander V. Chernikov wrote:
On 19.05.2014 11:51, Bill Yuan wrote:
Hi Alex,
Hello Bill!
You guys are chatting here! I agree with you, the table is the place
should
be enhanced, and I am working in this way as described below
1. Support more types.
ip : cidr
ipv4 : sa
On 19.05.2014 12:54, Dennis Yusupoff wrote:
Alex, Bill, it's a good news, glad to hear it.
Let me ask even more functionality:
6. Test if entry exist in table:
ipfw table test
It extremely useful in case of big, unordered data in the table - for
example different networks with different mask.
On 19.05.2014 11:51, Bill Yuan wrote:
Hi Alex,
Hello Bill!
You guys are chatting here! I agree with you, the table is the place should
be enhanced, and I am working in this way as described below
1. Support more types.
ip : cidr
ipv4 : same as ip
ipv6 : ip addr v6
mac : mac address
if
On Mon, May 19, 2014 at 10:54 AM, Dennis Yusupoff wrote:
> Alex, Bill, it's a good news, glad to hear it.
>
> Let me ask even more functionality:
>
> 6. Test if entry exist in table:
> ipfw table test
> It extremely useful in case of big, unordered data in the table - for
> example different ne
Alex, Bill, it's a good news, glad to hear it.
Let me ask even more functionality:
6. Test if entry exist in table:
ipfw table test
It extremely useful in case of big, unordered data in the table - for
example different networks with different mask. Now it's almost
impossible to find out is che
Hi Alex,
You guys are chatting here! I agree with you, the table is the place should
be enhanced, and I am working in this way as described below
1. Support more types.
ip : cidr
ipv4 : same as ip
ipv6 : ip addr v6
mac : mac address
iface : interface name
interface : same as iface
por
> On May 18, 2014, at 0:12, Julian Elischer wrote:
>> 2) Table type/name can be specified explicitly via one of the following
>> commands:
>> * ipfw table 1 create [type ] [name "table_name"]
> type "ports" would be nice but tricky to do right.
That . . . would be a great addition and have m
On 5/17/14, 9:44 PM, Alexander V. Chernikov wrote:
On 13.05.2014 16:05, Dennis Yusupoff wrote:
I think that universal table for all kind of data (ipv4, ipv6, ports,
etc) is a bad idea by design. At least unless you haven't any
ability to
It is not always "universal" in kernel.
Actually, differ
Em 17/05/14 20:28, Marcelo Gondim escreveu:
Em 17/05/14 10:44, Alexander V. Chernikov escreveu:
On 13.05.2014 16:05, Dennis Yusupoff wrote:
I think that universal table for all kind of data (ipv4, ipv6, ports,
etc) is a bad idea by design. At least unless you haven't any
ability to
It is not
Em 17/05/14 10:44, Alexander V. Chernikov escreveu:
On 13.05.2014 16:05, Dennis Yusupoff wrote:
I think that universal table for all kind of data (ipv4, ipv6, ports,
etc) is a bad idea by design. At least unless you haven't any ability to
It is not always "universal" in kernel.
Actually, differ
On 17.05.2014 23:57, Barney Wolff wrote:
On Sat, May 17, 2014 at 05:44:37PM +0400, Alexander V. Chernikov wrote:
On 13.05.2014 16:05, Dennis Yusupoff wrote:
I think that universal table for all kind of data (ipv4, ipv6, ports,
etc) is a bad idea by design. At least unless you haven't any abilit
On Sat, May 17, 2014 at 05:44:37PM +0400, Alexander V. Chernikov wrote:
> On 13.05.2014 16:05, Dennis Yusupoff wrote:
> > I think that universal table for all kind of data (ipv4, ipv6, ports,
> > etc) is a bad idea by design. At least unless you haven't any ability to
> It is not always "universal"
On 17.05.2014 19:14, Andreas Nilsson wrote:
On Sat, May 17, 2014 at 3:44 PM, Alexander V. Chernikov
mailto:melif...@freebsd.org>> wrote:
On 13.05.2014 16:05, Dennis Yusupoff wrote:
I think that universal table for all kind of data (ipv4, ipv6,
ports,
etc) is a b
On Sat, May 17, 2014 at 3:44 PM, Alexander V. Chernikov <
melif...@freebsd.org> wrote:
> On 13.05.2014 16:05, Dennis Yusupoff wrote:
>
>> I think that universal table for all kind of data (ipv4, ipv6, ports,
>> etc) is a bad idea by design. At least unless you haven't any ability to
>>
> It is not
On 13.05.2014 16:05, Dennis Yusupoff wrote:
I think that universal table for all kind of data (ipv4, ipv6, ports,
etc) is a bad idea by design. At least unless you haven't any ability to
It is not always "universal" in kernel.
Actually, different radix tables are used to store both IPv4 and IPv6
I think that universal table for all kind of data (ipv4, ipv6, ports,
etc) is a bad idea by design. At least unless you haven't any ability to
specify address family on add, to avoid attempts to guess what user
meant. Something like "ipfw table X add DEEF.DE ipv6".
13.05.2014 14:32, Alexander V.
On 13.05.2014 13:46, Dennis Yusupoff wrote:
May be this will help? See answer on
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/189471
I'll try to fix it within a few days.
The problem itself happens due to the fact that every CIDR table address
is packed into IPv6 address and IPv4 ones are en
May be this will help? See answer on
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/189471
12.05.2014 22:21, Marcelo Gondim пишет:
> Hi Jason,
>
> Same problem.
>
> Em 12/05/14 15:02, Jason Hellenthal escreveu:
>> Cute. Same this happen when there are paren around the quad ?
>>
> -- Jason Hellenth
Hi Jason,
Same problem.
Em 12/05/14 15:02, Jason Hellenthal escreveu:
Cute. Same this happen when there are paren around the quad ?
-- Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN
On May 12, 2014, at 13:43, Marcelo Gondim wrote:
Hi all,
Today I discovered a likely problem:
# ipfw t
Cute. Same this happen when there are paren around the quad ?
--
Jason Hellenthal
Voice: 95.30.17.6/616
JJH48-ARIN
> On May 12, 2014, at 13:43, Marcelo Gondim wrote:
>
> Hi all,
>
> Today I discovered a likely problem:
>
> # ipfw table 99 add 0.0.0.0/8
>
> # ipfw table 99 list
> ::/8 0
>
Hi all,
Today I discovered a likely problem:
# ipfw table 99 add 0.0.0.0/8
# ipfw table 99 list
::/8 0
Is this correct? IPv6?
# uname -a
FreeBSD mail.xx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #6 r265408:
Fri May 9 12:00:40 BRT 2014
r...@mail.xx.com.br:/usr/obj/usr/src/sys/GONDIM a
29 matches
Mail list logo
