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
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
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 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
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
>
20 matches
Mail list logo
