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
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
melif...@freebsd.org mailto:melif...@freebsd.org wrote:
On 13.05.2014 16:05, Dennis Yusupoff wrote:
I think that universal
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.
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.
It will e nice to have this utility function
On 21 May, 2014, at 1:32 am, Alexander V. Chernikov melif...@freebsd.org
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
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
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 id test item
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
On Mon, May 19, 2014 at 10:54 AM, Dennis Yusupoff d...@smartspb.net 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 id test item
It extremely useful in case of big, unordered data in the table - for
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
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 id test item
It extremely useful in case of big, unordered data in the table - for
example different networks with
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 :
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 id test item
It extremely useful in case of big, unordered data in the
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
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
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
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 always
On 17.05.2014 19:14, Andreas Nilsson wrote:
On Sat, May 17, 2014 at 3:44 PM, Alexander V. Chernikov
melif...@freebsd.org 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,
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 in
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
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,
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
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,
On May 18, 2014, at 0:12, Julian Elischer jul...@freebsd.org wrote:
2) Table type/name can be specified explicitly via one of the following
commands:
* ipfw table 1 create [type cidr|u32|ifindex|iface] [name table_name]
type ports would be nice but tricky to do right.
That . . . would
: 95.30.17.6/616 JJH48-ARIN
On May 12, 2014, at 13:43, Marcelo Gondimgon...@bsdinfo.com.br wrote:
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
Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN
On May 12, 2014, at 13:43, Marcelo Gondimgon...@bsdinfo.com.br wrote:
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
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.
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
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 gon...@bsdinfo.com.br wrote:
Hi all,
Today I discovered a likely problem:
# ipfw table 99 add 0.0.0.0/8
# ipfw table 99
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 2014r...@mail.xx.com.br:/usr/obj/usr/src/sys/GONDIM amd64
Cheers,
Gondim
29 matches
Mail list logo
